History log of /arch/arm/mach-davinci/dm355.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
5cfb19ac604a68c030b245561f575c2d1bac1d49 21-Dec-2011 Manjunath Hadli <manjunath.hadli@ti.com> ARM: davinci: streamline sysmod access

There are instances of IO_ADDRESS() being used for system module
(sysmod) register access. Eliminate this in favor of a ioremap()
based access. ioremap() the entire sysmod address space once during
boot-up and provide a helper macro to access specific register
offsets within the address space.

With this, also eliminate ioremap() of specific sysmodule registers
related to VPIF happening in DM646x EVM code.

While at it, also eliminate some duplicate sysmod register offset macros
defined in code and place offset definitions at one place in davinci.h

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
[nsekhar@ti.com: removed the addition of ifndef __ASSEMBLER__
in davinci.h, eliminate IO_ADDRESS() usage left out in dm646x.c,
cleanup VPIF sysmodule register access as part of this patch and
keep all sysmod offsets in davinci.h Also, convert the WARN_ON()
on failure to setup sysmod base to BUG_ON()]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
/arch/arm/mach-davinci/dm355.c
39c6d2d1d743b8c925abae7043acc35e6cdc0051 21-Dec-2011 Manjunath Hadli <manjunath.hadli@ti.com> ARM: davinci: create new common platform header for davinci

Remove individual platform header files for dm365, dm355, dm644x
and dm646x and consolidate it into a single and common
header file davinci.h placed in arch/arm/mach-davinci.

This reduces the pollution in the include/mach and is consistent
with Russell's suggestions as part of his "pet peaves" mail.
(See #4 in: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/071516.html)

While at it, fix the forward declaration of spi_board_info,
and include the right header file instead.

The further patches in the series take advantage of this consolidation
for easy implementation of IO_ADDRESS elimination.

Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
[nsekhar@ti.com: make davinci.h the first local include file,
fix forward declaration of spi_board_info and add back Deep Root
Systems, LLC copyright]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
/arch/arm/mach-davinci/dm355.c
c6121ddd1f75278ab77504af2914d07831558672 05-Dec-2011 Sekhar Nori <nsekhar@ti.com> ARM: 7190/1: restart: davinci: use new restart hook

Rather than using DaVinci specific davinci_soc_info based
restart hook, use the restart hook available in the machine
descriptor instead.

Tested on DM365 and AM18x EVMs.

v2:
Changed to use restart hook in machine descriptor
per Russell's comment.

Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/arch/arm/mach-davinci/dm355.c
3e965b176341b78620f7404fd8b7f9a0d061f8a2 31-Oct-2011 Arnd Bergmann <arnd@arndb.de> Merge branch 'next/fixes' into next/cleanup

Conflicts:
arch/arm/mach-mxs/include/mach/gpio.h
arch/arm/plat-mxc/include/mach/gpio.h
drivers/video/omap/lcd_apollon.c
drivers/video/omap/lcd_ldp.c
drivers/video/omap/lcd_overo.c
f23fe857bbea393b4b94fe2218c98d934bd3d4cf 10-Jul-2011 Ido Yariv <ido@wizery.com> ARM: davinci: Explicitly set channel controllers' default queues

Davinci platforms may define a default queue for each channel
controller. If one is not defined, the default queue is set to EVENTQ_1.
However, there's no way to distinguish between an unset default queue to
one that is set to EVENTQ_0, as EVENTQ_0 = 0.

Explicitly specify the default queue for all channel controllers on all
Davinci platforms to EVENTQ_1, and don't overwrite it in the EDMA probe
function.

One exception is the DA850 board, for which EVENTQ_1 is not a valid
option for its second channel controller. Use EVENTQ_0 instead for that
channel controller.

Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
/arch/arm/mach-davinci/dm355.c
5f3fcf9649dbb010ccac41259d04147775ec8fc2 22-Aug-2011 Linus Walleij <linus.walleij@linaro.org> ARM: 7040/1: mach-davinci: break out GPIO driver specifics

The <mach/gpio.h> file is included from upper directories
and deal with generic GPIO and gpiolib stuff. Break out the
platform and driver specific defines and functions into its own
header file.

Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/arch/arm/mach-davinci/dm355.c
e9c549998dc24209847007e1f209f3b6c88d21ba 27-Apr-2011 Lucas De Marchi <lucas.demarchi@profusion.mobi> Revert wrong fixes for common misspellings

These changes were incorrectly fixed by codespell. They were now
manually corrected.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
/arch/arm/mach-davinci/dm355.c
25985edcedea6396277003854657b5f3cb31a628 31-Mar-2011 Lucas De Marchi <lucas.demarchi@profusion.mobi> Fix common misspellings

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
/arch/arm/mach-davinci/dm355.c
2e3e2a5e4fef586ae9b1cfef42823c0aef1797f4 08-Feb-2011 Michael Williamson <michael.williamson@criticallink.com> davinci: spi: move event queue parameter to platform data

For DMA operation, the davinci spi driver needs an event queue number.
Currently, this number is passed as a IORESOURCE_DMA. This is not
correct, as the event queue is not a DMA channel. Pass the event queue
via the platform data structure instead.

On dm355 and dm365, move the eventq assignment for spi0 out of resources
array and into platform data.

Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Kevin Hilman <khilman@ti.com>
/arch/arm/mach-davinci/dm355.c
496a2e360a34e1f41c336d23947f800216cb9bdf 29-Dec-2010 Grant Likely <grant.likely@secretlab.ca> Merge branch 'for-grant' of git://arago-project.org/git/projects/linux-davinci into spi/next

* 'for-grant' of git://arago-project.org/git/projects/linux-davinci into spi/next
spi: davinci: fix checkpatch errors
spi: davinci: whitespace cleanup
spi: davinci: remove unused variable 'pdata'
spi: davinci: set chip-select mode in SPIDEF only once
spi: davinci: enable both activation and deactivation of chip-selects
spi: davinci: remove unnecessary data transmit on CS disable
spi: davinci: enable GPIO lines to be used as chip selects
spi: davinci: simplify prescalar calculation
spi: davinci: remove 'wait_enable' platform data member
spi: davinci: make chip-slect specific parameters really chip-select specific
spi: davinci: consolidate setup of SPIFMTn in one function
spi: davinci: setup chip-select timers values only if timer enabled
spi: davinci: add support for wait enable timeouts
spi: davinci: remove unused members of davinci_spi_slave
spi: davinci: eliminate the single member structure davinci_spi_slave
spi: davinci: eliminate unnecessary update of davinci_spi->count
spi: davinci: simplify calculation of edma acount value
spi: davinci: check for NULL buffer pointer before using it
spi: davinci: remove unnecessary disable of SPI
spi: davinci: remove unnecessary 'count' variable in driver private data
spi: davinci: remove unnecessary completion variable initialization
spi: davinci: remove non-useful interrupt mode support
spi: davinci: simplify poll mode transfers
spi: davinci: add support for interrupt mode
spi: davinci: configure the invariable bits in spipc0 only once
spi: davinci: remove unnecessary function davinci_spi_bufs_prep()
spi: davinci: remove unnecessary call to davinci_spi_setup_transfer()
spi: davinci: do not store DMA channel information per chip select
spi: davinci: always start transmit DMA
spi: davinci: do not use temporary buffer if no transmit data provided
spi: davinci: always start receive DMA
spi: davinci: use edma_write_slot() to setup EDMA PaRAM slot
spi: davinci: fix DMA event generation stoppage
spi: davinci: fix EDMA CC errors at end of transfers
spi: davinci: handle DMA completion errors correctly
spi: davinci: remove usage of additional completion variables for DMA
spi: davinci: let DMA operation be specified on per-device basis
spi: davinci: remove non-useful "clk_internal" platform data
spi: davinci: enable and power-up SPI only when required
spi: davinci: setup the driver owner
spi: davinci: add additional comments
spi: davinci: add EF Johnson Technologies copyright
spi: davinci: removed unused #defines
spi: davinci: remove unnecessary typecast
spi: davinci: do not treat Tx interrupt being set as error
spi: davinci: do not allocate DMA channels during SPI device setup
spi: davinci: remove unnecessary private data member 'region_size'
spi: davinci: shorten variable names
spi: davinci: kconfig: add manufacturer name to prompt string
3409e408ab0d7171ae81d198110a1f293852959f 06-Oct-2010 Brian Niebuhr <bniebuhr@efjohnson.com> spi: davinci: remove non-useful "clk_internal" platform data

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: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
/arch/arm/mach-davinci/dm355.c
c29e3c60e75d1cc1262ac8af379738b6fd851f33 28-Sep-2010 Brian Niebuhr <bniebuhr@efjohnson.com> spi: davinci: always start transmit DMA

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: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
/arch/arm/mach-davinci/dm355.c
cf90fe73504764cbcc2552c7ea69b1866059db30 20-Aug-2010 Brian Niebuhr <bniebuhr@efjohnson.com> spi: davinci: remove non-useful interrupt mode support

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: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
/arch/arm/mach-davinci/dm355.c
53a31b07c5aea4001bbb36ddd5ef2addffc7ccbd 16-Aug-2010 Brian Niebuhr <bniebuhr@efjohnson.com> spi: davinci: make chip-slect specific parameters really chip-select specific

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: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
/arch/arm/mach-davinci/dm355.c
7978b8c385a86f0b5b9304e81a1dfb5dcaf21528 13-Aug-2010 Brian Niebuhr <bniebuhr@efjohnson.com> spi: davinci: enable both activation and deactivation of chip-selects

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: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
/arch/arm/mach-davinci/dm355.c
bedad0ca3fb2ba52c347b54a97b78d32e406dd96 16-Nov-2010 Chris Paulson-Ellis <chris@edesix.com> ASoC: davinci: fixes for multi-component

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: Chris Paulson-Ellis <chris@edesix.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
/arch/arm/mach-davinci/dm355.c
2de5c00ac06c8983ab33ad51a8341584f1cf42c3 24-Sep-2010 Santosh Shilimkar <santosh.shilimkar@ti.com> ARM: 6409/1: davinci: map sram using MT_MEMORY_NONCACHED instead of MT_DEVICE

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: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/arch/arm/mach-davinci/dm355.c
bc3ac9f31642fb4697b313c2eb575c5286f35c2a 29-Jun-2010 Sekhar Nori <nsekhar@ti.com> davinci: edma: provide ability to detect insufficient CC info data

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: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
779b0d53ca41873d59225eb776c5d4493a0abd0f 07-May-2010 Cyril Chemparathy <cyril@ti.com> Davinci: pinmux - use ioremap()

This patch modifies the pinmux implementation so as to ioremap() the pinmux
register area on first use.

Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
bd808947040ba53b2b0e52dde598a9414fb27bba 07-May-2010 Cyril Chemparathy <cyril@ti.com> Davinci: aintc/cpintc - use ioremap()

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: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
e4c822c7e98cdda78b10a696b030fc20b22dcab4 07-May-2010 Cyril Chemparathy <cyril@ti.com> Davinci: psc - use ioremap()

This patch modifies the psc and clock control code to use ioremap()ed
registers.

Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
3347db8392486a1b52aab980cc445cf505c36d45 07-May-2010 Cyril Chemparathy <cyril@ti.com> Davinci: jtag_id - use ioremap()

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: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
b8d44293952e4b32b8595d924a377351f3cd1565 07-May-2010 Cyril Chemparathy <cyril@ti.com> Davinci: gpio - use ioremap()

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: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
c78a5bc2e77e8fc5be29cda5b28c9b9afd0f4b6d 02-May-2010 Cyril Chemparathy <cyril@ti.com> Davinci: watchdog reset separation across socs

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: Cyril Chemparathy <cyril@ti.com>
Tested-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
5b3a05ca911688c53680f2b020a1512b9da29c89 02-May-2010 Cyril Chemparathy <cyril@ti.com> Davinci: eliminate pinmux offset verbosity

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: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
686b634a07451fc4fe3b712fe211bfa861a53241 02-May-2010 Cyril Chemparathy <cyril@ti.com> Davinci: gpio - controller type support

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: Cyril Chemparathy <cyril@ti.com>
Tested-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
28552c2eae472a0a52d1cdb02eb32766c7f690e1 26-Feb-2010 Kevin Hilman <khilman@deeprootsystems.com> davinci: misc cleanups from sparse

- Convert data/functions to static
- include headers for missing declarations
- pointer cleanups: struct foo *__iomem f --> struct foo __iomem *f;

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
13dda80e48439b446d0bc9bab34b91484bc8f533 01-Mar-2010 Linus Torvalds <torvalds@linux-foundation.org> Merge branch 'davinci-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci

* 'davinci-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci: (40 commits)
DaVinci DM365: Adding support for SPI EEPROM
DaVinci DM365: Adding DM365 SPI support
DaVinci DM355: Modifications to DM355 SPI support
DaVinci: SPI: Adding header file for SPI support.
davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup
davinci: clkdev cleanup: remove clk_lookup wrapper, use clkdev_add_table()
DaVinci: DM365: Voice codec support for the DM365 SoC
davinci: clock: let clk->set_rate function sleep
Add SDA and SCL pin numbers to i2c platform data
davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138
davinci: build list of unused EDMA events dynamically
davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case
davinci: Keep count of channel controllers on a platform
davinci: Correct return value of edma_alloc_channel api
davinci: add CDCE949 support on DM6467 EVM
davinci: add support for CDCE949 clock synthesizer
davinci: da850/omap-l138 EVM: register for suspend support
davinci: da850/omap-l138: add support for SoC suspend
davinci: add power management support
DaVinci: DM365: Changing default queue for DM365.
...
15e865859a9e65a3f39e95bcb7ee72d0645b9a0e 01-Feb-2010 Sandeep Paulraj <s-paulraj@ti.com> DaVinci DM355: Modifications to DM355 SPI support

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: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
77c8b5fb0ee6e367332167eaa26470d843596270 14-Jan-2010 Muralidharan Karicheri <m-karicheri2@ti.com> V4L/DVB: vpfe-capture: converting ccdc drivers to platform-drivers

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: Vaibhav Hiremath <hvaibhav@ti.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
/arch/arm/mach-davinci/dm355.c
08aca087f263e8089420b2723fe0c1a0cbe5de0c 11-Jan-2010 Kevin Hilman <khilman@deeprootsystems.com> davinci: clkdev cleanup: remove clk_lookup wrapper, use clkdev_add_table()

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: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
f900d552f95a009e4c4910aff7acbd45f952aa2e 06-Jan-2010 Sudhakar Rajashekhara <sudhakar.raj@ti.com> davinci: build list of unused EDMA events dynamically

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: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
42d399e4189346b495fec8a9a267e8b7f744ee48 02-Oct-2009 Sergei Shtylyov <sshtylyov@ru.mvista.com> DaVinci: remove unneeded #include's

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: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
51e68e27d310034332b67a6762914af9589b3db5 16-Sep-2009 Muralidharan Karicheri <m-karicheri2@ti.com> davinci: DM355 - platform changes for vpfe capture

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: Hans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Reviewed-by: David Brownell <david-b@pacbell.net>
Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Signed-off-by: Denys Dmytriyenko <denis@denix.org>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
1aebb50e06b8c184dcf1dde4314cb782f42f9e21 21-Aug-2009 Sandeep Paulraj <s-paulraj@ti.com> DaVinci: DM355: Adding PINMUX entries for DM355 Display

This patch adds PINMUX entries for DM355 Display.
These will be used by the DM355 display driver.

Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
61aa07328d8e70d95a1e2325288df52a1e92a694 15-Jul-2009 Kevin Hilman <khilman@deeprootsystems.com> davinci: audio clocks: use struct device instead of clock names

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: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
25acf553aeed86f93f2cf39227b59fc6eb3e8c78 05-Jun-2009 Chaithrika U S <chaithrika@ti.com> davinci: ASoC: Add the platform devices for ASP

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: Naresh Medisetty <naresh@ti.com>
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
5fcd294df26e6160f32ea551ef074630b4df728d 03-Jun-2009 Kevin Hilman <khilman@deeprootsystems.com> davinci: remove watchdog from soc_info

watchdog info is not needed in soc_info, platform_device can
be used directly in core code.

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
60902a2cb12c3c1682ee7a04ad7448ec16dc0c29 21-May-2009 Sudhakar Rajashekhara <sudhakar.raj@ti.com> davinci: EDMA: multiple CCs, channel mapping and API changes

- 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: Mark 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: Naresh Medisetty <naresh@ti.com>
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Reviewed-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
0d04eb47054f685b23033ed6ceadfb20db77c5b3 01-May-2009 David Brownell <dbrownell@users.sourceforge.net> davinci: soc-specific SRAM setup

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: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
96ed299fdb572fd694d361dc49285dddc0c87da4 30-Apr-2009 Kevin Hilman <khilman@deeprootsystems.com> davinci: cleanup: move dm355 UART2 define to dm355.c

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
5570078c0ec5ecc5df0bbd7d06f43549b7127ae7 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Move PINMUX defines to SoC files

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: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
65e866a9741126c678e6dcd5d4fa8c9eca18e945 18-Mar-2009 Mark A. Greer <mgreer@mvista.com> davinci: Move serial platform_device into SoC-specific files

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: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
a994955cc091a8a51b7d7412174d9cf6de04d26b 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Make GPIO code more generic

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: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
951d6f6d703110790256abfce03ced117d2dcc6b 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Add watchdog base address flexibility

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: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
f64691b3ab795268072e76ddb89290b6277cdf33 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Add base address and timer flexibility

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: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
673dd36f0d0cf8893d6b46d524ad80e81076b885 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Move interrupt ctlr info to SoC infrastructure

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: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
0e585952ac6a06b3c77d6b8eadb9c359766a700d 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Move pinmux setup info to SoC infrastructure

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: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
d81d188cafecbc9e01df51527ac4c84a5b19e033 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Add support for multiple PSCs

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: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
66e0c3991c5a1735dd8add77ab8aff5005f57681 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Add clock init call to common init routine

All of the davinci SoCs need to call davinci_clk_init() so
put the call in the common init routine.

Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
b9ab12797e74d93a3656ea0bf5591f8b3e094fd5 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Support JTAG ID register at any address

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: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
79c3c0b729647a6246c120408f36e6804dab244e 15-Apr-2009 Mark A. Greer <mgreer@mvista.com> davinci: Encapsulate SoC-specific data in a structure

Create a structure to encapsulate SoC-specific information.
This will assist in generalizing code so it can be used by
different SoCs that have similar hardware but with minor
differences such as having a different base address.

The idea is that the code for each SoC fills out a structure
with the correct information. The board-specific code then
calls the SoC init routine which in turn will call a common
init routine that makes a copy of the structure, maps in I/O
regions, etc.

After initialization, code can get a pointer to the structure
by calling davinci_get_soc_info(). Eventually, the common
init routine will make a copy of all of the data pointed to
by the structure so the original data can be made __init_data.
That way the data for SoC's that aren't being used won't consume
memory for the entire life of the kernel.

The structure will be extended in subsequent patches but
initially, it holds the map_desc structure for any I/O
regions the SoC/board wants statically mapped.

Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c
95a3477fe57e0669dcb531516f2930fe1cf27e6b 29-Apr-2009 Kevin Hilman <khilman@deeprootsystems.com> davinci: DM355: add base SoC and board support

In addition, add board support for the DM355 Evaluation Module (EVM)
and the DM355 Leopard board.

Original DM355 EVM support done by Sandeep Paulraj, with significant
updates and improvements by David Brownell. DM355 Leopord support
done by Koen Kooi.

Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
/arch/arm/mach-davinci/dm355.c