The IDE platform device is registered in three different places (2 board files
for DM644x and in dm646x.c for DM646x) while both the IDE base address and the
IDE IRQ are the same for both SoCs -- therefore, the proper place for the IDE
platform seems to be in devices.c. Merge the IDE platform data and registration
code and create davinci_init_ide() in place of dm646x_init_ide()...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Currently each DaVinci board file #define's its own version of the EMIFA base
addresses (all named DAVINCI_ASYNC_EMIF_*_BASE), which leads to duplication.
Move these #define's to the SoC specific headers, changing their prefixes from
'DAVINCI' to the 'DM355', 'DM644X', and 'DM646X' since all these base addresses
are SoC specific...
And while at it, rename DM646X_ASYNC_EMIF_DATA_CE0_BASE to
DM646X_ASYNC_EMIF_CS2_SPACE_BASE in order to match the DM646x datasheet.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Patch adds SDA and SCL pin numbers to the i2c platform data
structure for Davinci DM355 and DM6446. This at present is
used for i2c bus recovery.
TODO: Add SDA and SCL pin number information to include all
Davinci platforms such as dm355-leopard, dm365, dm646x, da8xx etc.
Signed-off-by: Philby John <pjohn@in.mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The I2C adapter ID is actually depends on Board and may vary, Davinci
uses id=1, but in case of AM3517 id=3.
So modified respective davinci board files.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Rename setup_usb() into davinci_setup_usb(). While at it:
- move its declaration from <mach/common.h> to more fitting <mach/usb.h>;
- teach it to handle values of the 'mA' parameter greater than 510 and thus
pass 1000 instead of 500 for the power switches capable of sourcing over 1 A;
- teach it to handle odd values of the 'potpgt_ms' parameter...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Kevin 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: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Kevin 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: 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>
Tested on DM6446, DM355, DM6447, DA850 EVMs.
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: Kevin 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: Kevin 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: Naresh Medisetty <naresh@ti.com>
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
fix the following 'make includecheck' warning:
arch/arm/mach-davinci/board-dm644x-evm.c: mach/common.h is included more than once.
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Factor out the code to extract that mac address from
i2c eeprom.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Since most of the emac platform_data is really SoC specific
and not board specific, move it to the SoC-specific files.
Put a pointer to the platform_data in the soc_info structure
so the board-specific code can set some of the platform_data
if it needs to.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
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>
As per commit 284901a90a, use
DMA_BIT_MASK(n)
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Update NAND partitioning for the dm6446 evm, unmasking the hidden
data at the beginning and letting the kernel be updated from Linux.
- This is boot-compatible with TI's software (U-Boot 1.20 and both
the 2.6.10 and 2.6.18 kernels), in terms of startup and loading
kernels from flash.
- In the same way, it's also boot-compatible with mainline U-Boot,
which stores U-Boot params in block 0 not block 16.
- It's not quite compatible with systems that previously used NAND
partitions to hold (filesystem) data. The compatibilities are a
bit different based on which kernel was used previously
+ Users of TI/MV kernels no longer see mtd2 "params"
(mainline u-boot env is in a different place)
* Filesystem is now mtd2 ... vs mtd3
+ Users of GIT kernels now see mtd0 and mtd1 partitions
* Filesystem partition starts 640 KBytes earlier
* Filesystem is now mtd2 ... vs mtd0
* Linux now *uses* the flash-resident BBT
* Removes annoying slowdown/hiccup during boot
* Potentially ~64KB less space available with TI/MV kernels
If you *used* NAND partitions from Linux, there is no solution that's
fully compatible with all previous kernels in those respects ... ergo
this "best compromise". It'd be good to back back up the filesystem
data; or, carry your own backwards-compatibility patch for awhile.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Rework DM644x code into SoC specific and board specific parts.
This is also to generalize the structure a bit so it's easier to add
support for new SoCs in the DaVinci family.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Rename DM6446 EVM board file, no functional changes. Code is updated
and reworked in following patch.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Sergei Shtylyov