The "clk_internal" platform data member which contols the
CLKMOD bit in Global Control Register 1 is not useful
since CLKMOD needs be set to 1 *always* to ensure master
mode operation.

Remove this platform data.
Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Due to the full duplex nature of the SPI bus, the SPI master
on DaVinci needs transmit to be active even if the tranfer is
only meant to collect receive data.

The current code achieves this by using a temporary zeroed buffer
to provide DMA data in case the transfer does not have a transmit
buffer provided.

However, the transmit DMA is started only if transmit buffer is
provided rendering the temporary buffer unused. Instead the code
relies on a write to SPIDAT1 register to trigger transmit operation.
This however only sends two bytes of data.

Fix this by starting transmit DMA always.

This changes exposes a bug on DM355 where the CSHOLD bit in
SPIDAT1 needs to be written to in between transfers. Handle
that by introducing a "cshold_bug" platform data which is
set to true for DM355.
Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

The interrupt mode support as it stands is another version
of poll mode. Even when interrupt mode is selected, the code
tight loops on interrupt status register, rendering it totally
useless. A completion variable is initialized, but never used.

Remove this fake interrupt mode since users can anyway use
poll mode with no functional difference. A usefully implemented
interrupt mode support can be added later.
Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Some chip-select specific paramterers like wdelay, parity, usage of
chip-select timers (and the actual timer values) are included in
platform data forcing the same behaviour across all chip-selects.

Create a new davinci_spi_config data structure which can be passed
along using controller_data member of spi_device data structure
on a per-device basis.
Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Let davinci_spi_chipselect() perform both activation and
deactivation of chip selects. This lets spi_bitbang fully
control chip select activation, as intended by the SPI API.

With this change, the chip select activation code need not
be duplicated in davinci_spi_bufs_{pio|dma}().

Also, keeping chip select active control is removed as a
platform data and simply controlled using information from
spi_bitbang on whether chip slect should be activated or
de-activated.
Signed-off-by: NBrian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: NMichael Williamson <michael.williamson@criticallink.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Multi-component commit f0fba2ad broke a few things which this patch should
fix. Tested on the DM355 EVM. I've been as careful as I can, but it would be
good if those with access to other Davinci boards could test.

--

The multi-component commit put the initialisation of
snd_soc_dai.[capture|playback]_dma_data into snd_soc_dai_ops.hw_params of the
McBSP, McASP & VCIF drivers (davinci-i2s.c, davinci-mcasp.c & davinci-vcif.c).
The initialisation had to be moved from the probe function in these drivers
because davinci_*_dai changed from snd_soc_dai to snd_soc_dai_driver.

Unfortunately, the DMA params pointer is needed by davinci_pcm_open (in
davinci-pcm.c) before hw_params is called. I have moved the initialisation to
a new snd_soc_dai_ops.startup function in each of these drivers. This fix
indicates that all platforms that use davinci-pcm must have been broken and
need to test with this fix.

--

The multi-component commit also changed the McBSP driver name from
"davinci-asp" to "davinci-i2s" in davinci-i2s.c without updating the board
level references to the driver name. This change is understandable, as there
is a similarly named "davinci-mcasp" driver in davinci-mcasp.c.

There is probably no 'correct' name for this driver. The DM6446 datasheet
calls it the "ASP" and describes it as a "specialised McBSP". The DM355
datasheet calls it the "ASP" and describes it as a "specialised ASP". The
DM365 datasheet calls it the "McBSP". Rather than fix this problem by
reverting to "davinci-asp", I've elected to avoid future confusion with the
"davinci-mcasp" driver by changing it to "davinci-mcbsp", which is also
consistent with the names of the functions in the driver. There are other
fixes required, so it was never going to be as simple as a revert anyway.

--

The DM365 only has one McBSP port (of the McBSP platforms, only the DM355 has
2 ports), so I've changed the the id of the platform_device from 0 to -1.

--

In davinci-evm.c, the DM6446 EVM can no longer share a snd_soc_dai_link
structure with the DM355 EVM as they use different cpu DAI names (the DM355
has 2 ports and the EVM uses the second port, but the DM6446 only has 1 port).
This also means that the 2 boards need different snd_soc_card structures.

--

The codec_name entries in davinci-evm.c didn't match the i2c ids in the board
files. I have only checked and fixed the details of the names used for the
McBSP based platforms. Someone with a McASP based platform (eg DA8xx) should
check the others.
Signed-off-by: NChris Paulson-Ellis <chris@edesix.com>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

On Davinci SRAM is mapped as MT_DEVICE becasue of the section
mapping pre-requisite instead of intended MT_MEMORY_NONCACHED

Since the section mapping limitation gets fixed with first
patch in this series, the MT_MEMORY_NONCACHED can be used now.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch modifies the EDMA driver to expect the channel
controller (CC) infomation passed on by the platform as a fixed
size (EDMA_MAX_CC) array of pointers to structures.

Doing so helps catch errors of the sort where the resource
structure has information for more channel controllers than
the number channel controller info structures defined.

Such insufficient platform data would lead to illegal memory
accesses.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch modifies the pinmux implementation so as to ioremap() the pinmux
register area on first use.
Signed-off-by: NCyril Chemparathy <cyril@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch implements the following:

 - interrupt initialization uses ioremap() instead of passing a virtual address
   via davinci_soc_info.

 - machine definitions directly point to cp_intc_init() or davinci_irq_init()

 - davinci_intc_type and davinci_intc_base now get initialized in controller
   specific init functions instead of davinci_common_init()

 - minor fix in davinci_irq_init() to use intc_irq_num instead of
   DAVINCI_N_AINTC_IRQ
Signed-off-by: NCyril Chemparathy <cyril@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch modifies the psc and clock control code to use ioremap()ed
registers.
Signed-off-by: NCyril Chemparathy <cyril@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch replaces the jtag id base info in davinci_soc_info with a physical
address which is then ioremap()ed within common code.

This patch (in combination with a similar change for PSC) will allow us to
eliminate the SYSCFG nastiness in DA8xx code.
Signed-off-by: NCyril Chemparathy <cyril@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch modifies the gpio_base definition in davinci_soc_info to be a
physical address, which is then ioremap()ed by the gpio initialization
function.
Signed-off-by: NCyril Chemparathy <cyril@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The earlier watchdog reset mechanism had a couple of limitations.  First, it
embedded a reference to "davinci_wdt_device" inside common code.  This
forced all derived platforms (da8xx and tnetv107x) to define such a device.
This also would have caused problems in including multiple socs in a single
build due to symbol redefinition.

With this patch, davinci_watchdog_reset() now takes the platform device as an
argument.  The davinci_soc_info struct has been extended to include a reset
function and a watchdog platform_device.  arch_reset() then uses these
elements to reset the system in a SoC specific fashion.
Signed-off-by: NCyril Chemparathy <cyril@ti.com>
Tested-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Pinmux registers are sequential, and do not need to be enumerated out as they
currently are.  This reduces code volume and keeps things simple.

If some future SoC comes up with a discontiguous register map, PINMUX() can
then be expanded with local token pasting.
Signed-off-by: NCyril Chemparathy <cyril@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch allows for gpio controllers that deviate from those found on
traditional davinci socs.  davinci_soc_info has an added field to indicate the
soc-specific gpio controller type.  The gpio initialization code then bails
out if necessary.

More elements (tnetv107x) to be added later into enum davinci_gpio_type.
Signed-off-by: NCyril Chemparathy <cyril@ti.com>
Tested-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

- Convert data/functions to static
- include headers for missing declarations
- pointer cleanups:  struct foo *__iomem f --> struct foo __iomem *f;
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This patch does the following

1) Minor change to the SPI clocks making it
similar to DM365.
2) Changing the interrupt used by SPI0
3) Adding EDMA resources that can be used by SPI0
4) Adding platform specific data.
Signed-off-by: NSandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

This adds platform code for ccdc driver on DM355 and DM6446.

1) new ccdc platform devices added
2) added clock aliases master and slave for CCDC clocks
3) added dm355_ccdc_setup_pinmux() pin-mux setup hook in dm355 ccdc driver platform data
Reviewed-by: NVaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
Reviewed-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMuralidharan Karicheri <m-karicheri2@ti.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remove unneeded 'struct davinci_clk' wrapper around 'struct clk_lookup'
and use clkdev_add_table() to add the list of clocks in one go.
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Currently, the edma_noevent list is passed from platform data.
But on some architectures, there will be many EDMA channels
which will not be used at all. This patch scans all the
platform devices and then builds a list of events which are
not being used. The unused event list will be used to allocate
EDMA channels in case of EDMA_CHANNEL_ANY usage instead of the
edma_noevent being used earlier for this purpose.

This patch is based on David Brownells's suggestion at
http://article.gmane.org/gmane.linux.davinci/15176.
Signed-off-by: NSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

There have accumulated quite a lot of them after the code reorganizations...

In several cases I had to replace #include <linux/dma-mapping.h> which wasn't
needed directly but happened to #include <linux/err.h> which was needed.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.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>

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>

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>

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>

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>

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>

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

Different SoC have different numbers of pinmux registers and other
resources that overlap with each other.  To clean up the code and
eliminate defines that overlap with each other, move the PINMUX
defines to the SoC specific files.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Currently, there is one set of platform_device and platform_data
structures for all DaVinci SoCs.  The differences in the data
between the various SoCs is handled by davinci_serial_init()
by checking the SoC type.  However, as new SoCs appear, this
routine will become more & more cluttered.

To clean up the routine and make it easier to add support for new
SoCs, move the platform_device and platform_data structures into the
SoC-specific code and use the SoC infrastructure to provide access
to the data.

In the process, fix a bug where the wrong irq is used for uart2
of the dm646x.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The current gpio code needs to know the number of
gpio irqs there are and what the bank irq number is.
To determine those values, it checks the SoC type.

It also assumes that the base address and the number
of irqs the interrupt controller uses is fixed.

To clean up the SoC checks and make it support
different base addresses and interrupt controllers,
have the SoC-specific code set those values in
the soc_info structure and have the gpio code
reference them there.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The watchdog code currently hardcodes the base address
of the timer its using.  To support new SoCs, make it
support timers at any address.  Use the soc_info structure
to do this.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The davinci timer code currently hardcodes the timer register
base addresses, the timer irq numbers, and the timers to use
for clock events and clocksource.  This won't work for some
a new SoC so put those values into the soc_info structure
and set them up in the SoC-specific files.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Use the SoC infrastructure to hold the interrupt controller
information (i.e., base address, default priorities,
interrupt controller type, and the number of IRQs).

The interrupt controller base, although initially put
in the soc_info structure's intc_base field, is eventually
put in the global 'davinci_intc_base' so the low-level
interrupt code can access it without a dereference.

These changes enable the SoC default irq priorities to be
put in the SoC-specific files, and the interrupt controller
to be at any base address.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The pinmux register base and setup can be different for different
SoCs so move the pinmux reg base, pinmux table (and its size) to
the SoC infrastructure.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The current code to support the DaVinci Power and Sleep Controller (PSC)
assumes that there is only one controller.  This assumption is no longer
valid so expand the support to allow greater than one PSC.

To accomplish this, put the base addresses for the PSCs in the SoC
infrastructure so it can be referenced by the PSC code.  This also
requires adding an extra parameter to davinci_psc_config() to specify
the PSC that is to be enabled/disabled.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

All of the davinci SoCs need to call davinci_clk_init() so
put the call in the common init routine.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The Davinci cpu_is_davinci_*() macros use the SoC part number
and variant retrieved from the JTAG ID register to determine the
type of cpu that the kernel is running on.  Currently, the code to
read the JTAG ID register assumes that the register is always at
the same base address.  This isn't true on some newer SoCs.

To solve this, have the SoC-specific code set the JTAG ID register
base address in soc_info structure and add a 'cpu_id' member to it.
'cpu_id' will be used by the cpu_is_davinci_*() macros to match
the cpu id.  Also move the info used to identify the cpu type into
the SoC-specific code to keep all SoC-specific code together.

The common code will read the JTAG ID register, search through
an array of davinci_id structures to identify the cpu type.
Once identified, it will set the 'cpu_id' member of the soc_info
structure to the proper value and the cpu_is_davinci_*() macros
will now work.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>