VPIF display changes (Chaithrika)

Add platform device and resource structures. Also define a platform specific
clock setup function that can be accessed by the driver to configure the clock
and CPLD.

VPIF caputure changes (Murali)

1) Modify vpif_subdev_info to add board_info, routing information and
   vpif interface configuration. Remove addr since it is part of
   board_info

2) Add code to setup channel mode and input decoder path for vpif
   capture driver

Also incorporated comments against version v0 of the patch series and
added a spinlock to protect writes to common registers

Tested on DM6467 on channel 0 using TVP514x. Following bootargs used
for drivers:

   vpif_capture.ch0_bufsize=829440 vpif_display.ch2_bufsize=829440
Signed-off-by: NManjunath Hadli <mrh@ti.com>
Signed-off-by: NBrijesh Jadav <brijesh.j@ti.com>
Signed-off-by: NChaithrika U S <chaithrika@ti.com>
Reviewed-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMuralidharan Karicheri <m-karicheri2@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

DM355 platform and board setup

This has platform and board setup changes to support vpfe capture
driver for DM355 EVMs.

Tested video capture on DM355 using tvp514x
Reviewed-by: NHans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
Reviewed-by: NDavid Brownell <david-b@pacbell.net>
Signed-off-by: NMuralidharan Karicheri <m-karicheri2@ti.com>
Signed-off-by: NDenys Dmytriyenko <denis@denix.org>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

DM644x platform and board setup

This adds platform and board setup changes required to support
vpfe capture driver on DM644x

Tested video capture on DM6446 with tvp514x driver
Reviewed-by: NHans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
Reviewed-by: NDavid Brownell <david-b@pacbell.net>
Signed-off-by: NMuralidharan Karicheri <m-karicheri2@ti.com>
Signed-off-by: NDenys Dmytriyenko <denis@denix.org>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

For best performance, codecs often setup linked triggered
transfers with a contiguous block of params, and that is when
this API is used. Setup/configuration of these parameter RAMs
is most efficient if they are contiguous.
There is an API to allocate a set of contiguous parameter RAMs and
a corresponding API to free a set of contiguous parameter RAMs
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch adds definitions for some DM365 IRQs that are used by
the codecs. Codecs will also use the IRQs.
Entries are being added to enable/disable IRQ's.
There is no use as such for these entires in the kernel itself.
Instead these will be used by the "linuxutils" package of the DVSDK.

For further information on IRQ muxing refer to
http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdfSigned-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NSneha Narnakaje <nsnehaprabha@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch adds PINMUX entries for DM355 Display.
These will be used by the DM355 display driver.
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch adds platform data for the 8MB NOR flash
found on da850/omap-l138 EVM. Both NOR and NAND can
co-exist on da850/omap-l138 as they are using different
chip selects.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch adds platform data for the 512MB NAND Flash
found on DA850/OMAP-L138 EVM. Currently it supports
only 1-bit ECC.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

There are two instances of MMC/SD on da850/omap-l138.
Connector for the first instance is available on the
EVM. This patch adds support for this instance.

This patch also adds support for card detect and write
protect switches on da850/omap-l138 EVM.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch adds platform support for the graphic display
(Sharp LK043T1DG01) found on DA850/OMAP-L138 based EVM.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Adds a macro to convert the GPIO signal passed as bank number
and signal to GPIO pin number.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Define resources for McASP used on DA850/OMAP-L138 EVM, add platform
device defintion and Pin Mux configurations.
Signed-off-by: NChaithrika U S <chaithrika@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Define resources for McASP1 used on DA830/OMAP-L137 EVM, add platform
device defintion, initialization function.  Additionally, this patch
also adds version and FIFO related members to platform data structure.
Signed-off-by: NChaithrika U S <chaithrika@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

DA850/OMAP-L138 has 144 pins configurable as GPIO, but
currently this has been configured as 128. This patch
corrects it.

Also, this patch adds the base address for GPIO pins
greater than 128.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Earlier patch which adds EMAC support for da850/omap-l138
was not configuring the MDIO pins.

Ethernet was working fine with the earlier patch, because
the MDIO pins were configured from the boot loader. This
patch removes that dependency.

Also, this patch populates a member in the emac clk structure
to say that EMAC LPSC sits on controller 1.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The mask can hold only 8 bit values. This gave a
compilation warning. This patch rectifies the warning.
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

EDMA queues in DM365 are a little different than those
on other DaVinci's. On DM365 Q0 and Q1 have the larger
FIFO size. We want Q0 and Q1 to be used by codecs and
DVSDK demos.
MMC driver is the only driver which uses the flag
'EVENTQ_DEFAULT'. So MMC driver should be using Q2 instead of
Q1 on DM365.
This patch allows us to declare a "default queue" from
SOC specific code. If it is not declared then the EDMA
driver assumes a default of queue 1.
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

DM365 and DM6467 have 4 queues. The patch updates the
'dma_event_q' enum to reflect this.
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

There is no need to pass clock name strings in platform_data.
Instead, setup clkdev nodes to have correct ASoC device names.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Ethernet Media Access Controller (EMAC) on da850/omap-l138
supports 10/100 Mbps operation. It also supports Media
Independent Interface (MII) and Reduced Media Independent
Interface (RMII) to physical layer (PHY).

Phy which supports MII is present on the DA850/OMAP-L138
base board and Phy supporting RMII is present on the
UI card. This patch adds support only for the MII Phy.
Support for RMII Phy will be added later.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Add support for the DA850/OMAP-L138 Evaluation Module (EVM)
from TI.  The EVM has User Interface (UI) card which contains
various devices. This UI card can be connected to the base
board. Support for all the devices on the UI card and ones on
the EVM will be added in subsequent patches.

The EVM schematics are not available publicly yet; but should
be available soon.

A new defconfig for this board has been added mainly because
the DA830/OMAP-L137 defconfig forces writethrough cache mode
which is not required on DA850/OMAP-L138.

This patch has been boot tested on DA850/OMAP-L138 EVM
using ramdisk as filesystem.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The DA850/OMAP-L138 is a new SoC from TI in the same family as
DA830/OMAP-L137.

Major changes include better support for power management,
support for SATA devices and McBSP (same IP as DM644x).

DA850/OMAP-L138 documents are available at
http://focus.ti.com/docs/prod/folders/print/omap-l138.html.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Rearrange the PINMUX macros and pinmux_setup function which
are common between da830/omap-l137 and da850/omap-l138.

Also, replace the da830 string in function names to da8xx.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

With the introduction of TI da850/omap-l138, some of the macros
defined for da830/omap-l137 will be needed in da850 source file.
So, move the common macros to da8xx.h header file.

Also, modify the macro names from DA830_... to DA8XX_.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch adds platform data and init function for IDE which could be called
from board specific file to register IDE device.

Note that for 594MHz device the transfer mode is limited to UDMA4 since ideclk
rate is less than 100 MHz, which forces udma_mask in palm_bk3710.c to UDMA4,
while for 729MHz device, it is UDMA5.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Make arch_idle and arch_reset inline as inline function.

Not having them inline leads to a warning of this sort when only
one of these functions is used:

arch/arm/mach-davinci/include/mach/system.h:24: warning: 'arch_reset' \
defined but not used

boot, re-boot tested on OMAP-L138 EVM
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch takes out IO mapping macros from mach/io.h and puts them in
mach/hardware.h avoiding need to include mach/io.h in various files such as
serial.h, vmalloc.h etc.

The main reason to avoid inclusion of mach/io.h is, when default in/out macros
are overridden by machine specific functions (e.g., in case of PCI I/O), they
result into linker error. An example snippet and error snapshot is listed below.

Following code in mach/io.h:

	#define inl(p)  my_inl()

	static inline unsigned int my_inl(unsigned int addr)
	{
		if (IS_PCI_IO(addr))
			return pci_inl ();
		else
			return le32_to_cpu(__raw_readl(__typesafe_io(addr)));
	}

leads to error:
	LD      arch/arm/boot/compressed/vmlinux
	arch/arm/boot/compressed/misc.o: In function `my_inl':
	misc.c:(.text+0x2744): undefined reference to `pci_inl'
	make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 1

This is because mach/io.h gets included in arch/arm/boot/compressed/misc.c
through mach/serial.h but pci.c file, which defines 'pci_inl' doesn't get built
into compressed vmlinux.
Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

1) Registers the platform devices for ASP on dm355, dm644x and dm646x
   so that the machine driver can probe to get ASP related platform
   data.
2) Move towards definition of the asp clocks using physical name(for
   dm355 and dm644x)
3) Add platform data to board specific files.
Signed-off-by: NNaresh Medisetty <naresh@ti.com>
Signed-off-by: NChaithrika U S <chaithrika@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Support DM365 GPIOs ... primarily by handling non-banked GPIO IRQs:

 - Flag DM365 chips as using non-banked GPIO interrupts, using a
   new soc_info field.

 - Replace the gpio_to_irq() mapping logic.  This now uses some
   runtime infrastructure, keyed off that new soc_info field,
   which doesn't handle irq_to_gpio().

 - Provide a new irq_chip ... GPIO IRQs handled directly by AINTC
   still need edge triggering managed by the GPIO controller.

DM365 chips no longer falsely report 104 GPIO IRQs as they boot.

Intelligence about IRQ muxing is missing, so for the moment this
only exposes the first eight DM365 GPIOs, which are never muxed.
The next eight are muxed, half with Ethernet (which uses most of
those pins anyway).

Tested on DM355 (10 unbanked IRQs _or_ 104 banked ones) and also
on DM365 (16 unbanked ones, only 8 made available).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Patch updates DM365 PINMUX by adding entries for Video, SPI 1 - 4,
PWM 0 - 3.
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Add support for the DA830/OMAP-L137 Evaluation Module (EVM)
from TI.  The EVM has User Interface (UI) and Audio cards
that can be connected which contain various devices.
Support for those devices and ones on the EVM will be
added in subsequent patches.

Additional generalizations for future SoCs in da8xx family done by
Sudhakar Rajashekhara and Sekhar Nori.
Signed-off-by: NSteve Chen <schen@mvista.com>
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The da830/omap l137 is a new SoC from TI that is similar
to the davinci line.  Since its so similar to davinci,
put the support for the da830 in the same directory as
the davinci code.

There are differences, however.  Some of those differences
prevent support for davinci and da830 platforms to work
in the same kernel binary.  Those differences are:

1) Different physical address for RAM.  This is relevant
   to Makefile.boot addresses and PHYS_OFFSET.  The
   Makefile.boot issue isn't truly a kernel issue but
   it means u-boot won't work with a uImage including
   both architectures.  The PHYS_OFFSET issue is
   addressed by the "Allow for runtime-determined
   PHYS_OFFSET" patch by Lennert Buytenhek but it
   hasn't been accepted yet.

2) Different uart addresses.  This is only an issue
   for the 'addruart' assembly macro when CONFIG_DEBUG_LL
   is enabled.  Since the code in that macro is called
   so early (e.g., by _error_p in kernel/head.S when
   the processor lookup fails), we can't determine what
   platform the kernel is running on at runtime to use
   the correct uart address.

These areas have compile errors intentionally inserted
to indicate to the builder they're doing something wrong.

A new config variable, CONFIG_ARCH_DAVINCI_DMx, is added
to distinguish between a true davinci architecture and
the da830 architecture.

Note that the da830 currently has an issue with writeback
data cache so CONFIG_CPU_DCACHE_WRITETHROUGH should be
enabled when building a da830 kernel.

Additional generalizations for future SoCs in the da8xx family done by
Sudhakar Rajashekhara and Sekhar Nori.
Signed-off-by: NSteve Chen <schen@mvista.com>
Signed-off-by: NMikhail Cherkashin <mcherkashin@ru.mvista.com>
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The patch adds base support for new TI SOC DM365, which s
similar to the dm355.
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

watchdog info is not needed in soc_info, platform_device can
be used directly in core code.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

- restructure to support multiple channel controllers by using
  additional struct resources for each CC

- interface changes visible to EDMA clients

  Introduce macros to build IDs from controller and channel number,
  and to extract them. Modify the edma_alloc_slot function to take an
  extra argument for the controller.

  Also update ASoC drivers to use API.  ASoC changes
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

- Move queue related mappings to dm<soc>.c

  EDMA in DM355 and DM644x has two transfer controllers while DM646x
  has four transfer controllers. Moving the queue to tc mapping and
  queue priority mapping to dm<soc>.c will be helpful to probe these
  mappings from platform device so that the machine_is_* testing will
  be avoided.

- add channel mapping logic

  Channel mapping logic is introduced in dm646x EDMA. This implies
  that there is no fixed association for a channel number to a
  parameter entry number. In other words, using the DMA channel
  mapping registers (DCHMAPn), a PaRAM entry can be mapped to any
  channel. While in the case of dm644x and dm355 there is a fixed
  mapping between the EDMA channel and Param entry number.
Signed-off-by: NNaresh Medisetty <naresh@ti.com>
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Reviewed-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Minimal support for the 4-bit ECC engine found on DM355, DM365,
DA830/OMAP-L137, and similar recent DaVinci-family chips.

This is limited to small-page flash for now; there are some page
layout issues for large page chips.  Note that most boards using
this engine (like the DM355 EVM) include 2GiB large page chips.

Sanity tested on DM355 EVM after swapping the socketed NAND for
a small-page one.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Provide a generic SRAM allocator using genalloc, and vaguely
modeled after what AVR32 uses.  This builds on top of the
static CPU mapping set up in the previous patch, and returns
DMA mappings as requested (if possible).

Compared to its OMAP cousin, there's no current support for
(currently non-existent) DaVinci power management code running
in SRAM; and this has ways to deallocate, instead of being
allocate-only.

The initial user of this should probably be the audio code,
because EDMA from DDR is subject to various dropouts on at
least DM355 and DM6446 chips.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Package on-chip SRAM.  It's always accessible from the ARM, so
set up a standardized virtual address mapping into a 128 KiB
area that's reserved for platform use.

In some cases (dm6467) the physical addresses used for EDMA are
not the same as the ones used by the ARM ... so record that info
separately in the SOC data, for chips (unlike the OMAP-L137)
where SRAM may be used with EDMA.

Other blocks of SRAM, such as the ETB buffer or DSP L1/L2 RAM,
may be unused/available on some system.  They are ignored here.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>