aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-davinci/board-dm646x-evm.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2010-10-21Merge branch 'davinci-next' into davinci-for-linusKevin Hilman1-5/+16
Conflicts: arch/arm/mach-davinci/board-da830-evm.c arch/arm/mach-davinci/board-da850-evm.c
2010-10-20arm: remove machine_desc.io_pg_offst and .phys_ioNicolas Pitre1-4/+0
Since we're now using addruart to establish the debug mapping, we can remove the io_pg_offst and phys_io members of struct machine_desc. The various declarations were removed using the following script: grep -rl MACHINE_START arch/arm | xargs \ sed -i '/MACHINE_START/,/MACHINE_END/ { /\.\(phys_io\|io_pg_offst\)/d }' [ Initial patch was from Jeremy Kerr, example script from Russell King ] Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org> Acked-by: Eric Miao <eric.miao at canonical.com>
2010-09-24davinci: cleanup mdio arch code and switch to phy_idCyril Chemparathy1-5/+2
This patch removes davinci architecture code that has now been rendered useless by the previous patches in the MDIO separation series. In addition, the earlier phy_mask definitions have been replaced with corresponding phy_id definitions. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Tested-by: Michael Williamson <michael.williamson@criticallink.com> Tested-by: Caglar Akyuz <caglarakyuz@gmail.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-09-24davinci: dm6467t evm: setup NAND flash timingSekhar Nori1-0/+14
Setup NAND flash timing on DM6467T EVM. Without the timing setup, the NAND flash on DM6467T RevC EVM reports a number of random bad blocks because of read errors. Also, with this, copying a 100M file on RevB EVM takes ~35 sec against 1 minute 30 seconds earlier. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-08-08Merge branch 'davinci-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinciLinus Torvalds1-0/+35
* 'davinci-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci: davinci: dm646x EVM: Specify reserved EDMA channel/slots davinci: da8xx/omapl EVM: Specify reserved channels/slots davinci: support for EDMA resource sharing davinci: edma: provide ability to detect insufficient CC info data davinci: da8xx: sparse cleanup: remove duplicate entries in irq priorities davinci: DM365: fixed second serial port Davinci: tnetv107x evm board initial support Davinci: tnetv107x initial gpio support Davinci: tnetv107x soc support Davinci: tnetv107x decompresser uart definitions Davinci: generalized debug macros
2010-08-05davinci: dm646x EVM: Specify reserved EDMA channel/slotsRajashekhara, Sudhakar1-0/+35
Not all the channels and slots available on the DM646x EVM are used by the devices on the EVM. These resources can be used by the DSP to speed up codec operations. This patch reserves these channels for the DSP. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-07-20ASoC: davinci: let platform data define edma queue numbersSekhar Nori1-2/+2
Currently the EDMA queue to be used by for servicing ASP through internal RAM is fixed to EDMAQ_0 and that to service internal RAM from external RAM is fixed to EDMAQ_1. This may not be the desirable configuration on all platforms. For example, on DM365, queue 0 has large fifo size and is more suitable for video transfers. Having audio and video transfers on the same queue may lead to starvation on audio side. platform data as defined currently passes a queue number to the driver but that remains unused inside the driver. Fix this by defining one queue each for ASP and RAM transfers in the platform data and using it inside the driver. Since EDMAQ_0 maps to 0, thats the queue that will be used if the asp queue number is not initialized. None of the platforms currently utilize ping-pong transfers through internal RAM so that functionality remains unchanged too. This patch has been tested on DM644x and OMAP-L138 EVMs. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2010-05-13Davinci: aintc/cpintc - use ioremap()Cyril Chemparathy1-7/+2
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>
2010-05-06DaVinci: move IDE platform device to its proper placeSergei Shtylyov1-1/+1
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>
2010-05-06DaVinci: move AEMIF #define's to the proper headersSergei Shtylyov1-7/+4
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>
2010-03-01davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookupKevin Hilman1-5/+5
Remove unneeded 'struct davinci_clk' wrapper around 'struct clk_lookup' and use clk_lookup directly. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-02-04davinci: add CDCE949 support on DM6467 EVMNageswari Srinivasan1-0/+31
This patch adds the CDCE949 reference oscillator to the davinci clock list. On the DM6467T EVM, the CDCE949 is responsible for generating the pixel clock for display. On the DM6467 EVM, this pixel clock was being obtained from an internal source. This is not possible on the DM6467T EVM because of the presence of a 33MHz oscillator. The TSIF module also requires the CDCE949 to generate the data clocks. The actual clock definitions will be added by patches adding support for DM6467T VPIF and TSIF. This patch mearly lays the foundation for that work. Signed-off-by: Nageswari Srinivasan <nageswari@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-02-04davinci: add support for DM6467T EVMSekhar Nori1-0/+24
DM6467T (T for Turbo) is a newer and faster DM6467 part from TI. The new part supports 1080p video and has the ARM running at 495MHz. More SoC information: http://focus.ti.com/docs/prod/folders/print/tms320dm6467t.html Spectrum Digital, Inc has a new EVM for this part. It is _mostly_ same as the older DM6467 EVM except for a 33MHz crystal input and THS8200 video encoder for 1080p support. The meat of this patch is dedicated to initializing the crystal frequency from EVM board file. Additional notes: I did consider some alternative ways to make the crystal input board specific including - (1) having board code initialize the crystal frequency using the first member of soc_info->cpu_clks array (2) introducing a new ref_clk_rate member in soc_info structure. But, the current way seems to be the simplest and least intruding considering that both the clock array and SoC info structure are actually private to the SoC file. Also the fact that davinci_common_init() initializes both the soc_info and clocks in one go. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-02-04davinci: board-dm646x-evm.c: arrange related code togetherSekhar Nori1-45/+45
Currently all the #defines and static variables in the board-dm646x-evm.c file are located right at the start of the file because of which the related code is not together - making reading the code difficult. This patch moves around the code keeping related code together. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-11-25davinci: fix section mismatch warning in arch/arm/mach-davinci/board-dm646x-evm.cSekhar Nori1-1/+1
A section mismatch is reported for gpio_led_platform_data as it is referenced by a non annotated function (evm_led_setup) This patch fixes the issue by converting the __initconst to const as is the case in arch/arm/mach-davinci/board-dm644x-evm.c file. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-11-25davinci: dm646x-evm: Add platform data for NANDHemant Pedanekar1-0/+69
This patch adds platform data and partition info for NAND on dm6467 EVM. Note that the partition layout is dependent on the UBL, U-Boot etc. used. This patch tries to minimize that dependency by setting first partition for UBL, U-Boot and environment altogether. Signed-off-by: Hemant Pedanekar <hemantp@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-11-25DaVinci: remove unneeded #include'sSergei Shtylyov1-15/+0
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>
2009-09-16DaVinci: DM646x - platform changes for vpif capture and display driversMuralidharan Karicheri1-1/+318
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: Manjunath Hadli <mrh@ti.com> Signed-off-by: Brijesh Jadav <brijesh.j@ti.com> Signed-off-by: Chaithrika U S <chaithrika@ti.com> Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-26davinci: audio: move tlv320aic33 i2c setup into board filesChaithrika U S1-0/+3
Tested on DM6446, DM355, DM6447, DA850 EVMs. Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-26davinci: audio clocks: use struct device instead of clock namesKevin Hilman1-2/+0
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>
2009-08-26davinci: dm646x-evm: Add support for IDEHemant Pedanekar1-0/+59
Controls ATA_RSTn and ATA_PWD through CPLD register 0 to enable ATA. An I2C driver is added for the same. Calls ide init if enabled in configuration. Signed-off-by: Hemant Pedanekar <hemantp@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-08-26davinci: ASoC: Add the platform devices for ASPChaithrika U S1-0/+33
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>
2009-07-25ARM: includecheck fix: board-dm646x-evm.cJaswinder Singh Rajput1-1/+0
fix the following 'make includecheck' warning: arch/arm/mach-davinci/board-dm646x-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>
2009-05-28davinci: Factor out emac mac address handlingMark A. Greer1-18/+2
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>
2009-05-28davinci: Remove unused i2c eeprom_read/write routinesMark A. Greer1-16/+0
The dm644x and dm646x board files have i2c eeprom read and write routines but they are not used so remove them. Signed-off-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-28davinci: Move emac platform_data to SoC-specific filesMark A. Greer1-7/+8
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>
2009-05-26davinci: Encapsulate SoC-specific data in a structureMark A. Greer1-1/+1
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>
2009-05-26davinci: EMAC platform supportKevin Hilman1-2/+15
Add SoC and platform-specific data and init for DaVinci EMAC network driver. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2009-05-26davinci: DM646x: add base SoC and board supportKevin Hilman1-0/+280
Add support for DM646x SoC (a.k.a DaVinci HD) and its Evalution Module (EVM.) Original support done by Sudhakar Rajashekhara. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>