summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/omap_hwmod_2430_data.c
AgeCommit message (Collapse)Author
2011-09-04OMAP2430: hwmod: musb: add missing terminator to omap2430_usbhsotg_addrs[]Paul Walmsley
Add a missing array terminator to omap2430_usbhsotg_addrs[]. Without this terminator, the omap_hwmod resource building code runs off the end of the array, resulting in at least this error -- if not worse behavior: [ 0.578002] musb-omap2430: failed to claim resource 4 [ 0.583465] omap_device: musb-omap2430: build failed (-16) [ 0.589294] Could not build omap_device for musb-omap2430 usb_otg_hs This should have been part of commit 78183f3fdf76f422431a81852468be01b36db325 ("omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays") but was evidently missed. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10OMAP: hwmod: fix the i2c-reset timeout during bootupAvinash.H.M
The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a special sequence to reset the module. The sequence is - Disable the I2C. - Write to SOFTRESET bit. - Enable the I2C. - Poll on the RESETDONE bit. The sequence is implemented as a function and the i2c_class is updated with the correct 'reset' pointer. omap_hwmod_softreset function is implemented which triggers the softreset by writing into sysconfig register. On following this sequence, i2c module resets properly and timeouts are not seen. Cc: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Avinash.H.M <avinashhm@ti.com> [paul@pwsan.com: combined this patch with a patch to remove HWMOD_INIT_NO_RESET from the 44xx hwmod flags; change register offset conditional code to use the IP block revision; minor code cleanup] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attrAndy Green
This adds the new functionality flags for omap i2c unit to all OMAP2 hwmod definitions Cc: patches@linaro.org Cc: Ben Dooks <ben-linux@fluff.org> Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andy Green <andy.green@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revisionAndy Green
Since we cannot trust (or even reliably find) the OMAP I2C peripheral unit's own revision register, we must inform the OMAP i2c driver of which IP version it is running on. We do this by tagging the omap_hwmod_class for i2c on all the OMAP2+ platform / cpu specific hwmod init and passing it up to the driver (next patches). Cc: patches@linaro.org Cc: Ben Dooks <ben-linux@fluff.org> Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andy Green <andy.green@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2cAndy Green
Peter Maydell noticed when running under QEMU he was getting errors reporting 32-bit access to I2C peripheral unit registers that are documented to be 8 or 16-bit only[1][2] The I2C driver is blameless as it wraps its accesses in a function using __raw_writew and __raw_readw, it turned out it is the hwmod stuff. However the hwmod code already has a flag to force a perhipheral unit to only be accessed using 16-bit operations. This patch applies the 16-bit only flag to the 2430, OMAP3xxx and OMAP44xx hwmod structs. 2420 was already correctly marked up as 16-bit. The 2430 change will need testing by TI as arranged in the comments to the previous patch version. When the 16-bit flag is or-ed with other flags, it is placed first as requested in comments. [1] OMAP4430 Technical reference manual section 23.1.6.2 [2] OMAP3530 Techincal reference manual section 18.6 Cc: patches@linaro.org Cc: Ben Dooks <ben-linux@fluff.org> Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andy Green <andy.green@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09omap_hwmod: share identical omap_hwmod_class, omap_hwmod_class_sysconfig arraysPaul Walmsley
To reduce kernel source file data duplication, share struct omap_hwmod_class and omap_hwmod_class_sysconfig arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09omap_hwmod: share identical omap_hwmod_dma_info arraysPaul Walmsley
To reduce kernel source file data duplication, share struct omap_hwmod_dma_info arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09omap_hwmod: use a terminator record with omap_hwmod_dma_info arraysPaul Walmsley
Previously, struct omap_hwmod_dma_info arrays were unterminated; and users of these arrays used the ARRAY_SIZE() macro to determine the length of the array. However, ARRAY_SIZE() only works when the array is in the same scope as the macro user. So far this hasn't been a problem. However, to reduce duplicated data, a subsequent patch will move common data to a separate, shared file. When this is done, ARRAY_SIZE() will no longer be usable. This patch removes ARRAY_SIZE() usage for struct omap_hwmod_dma_info arrays and uses a sentinel value (irq == -1) as the array terminator instead. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09omap_hwmod: share identical omap_hwmod_mpu_irqs arraysPaul Walmsley
To reduce kernel source file data duplication, share struct omap_hwmod_mpu_irqs arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arraysPaul Walmsley
Previously, struct omap_hwmod_mpu_irqs arrays were unterminated; and users of these arrays used the ARRAY_SIZE() macro to determine the length of the array. However, ARRAY_SIZE() only works when the array is in the same scope as the macro user. So far this hasn't been a problem. However, to reduce duplicated data, a subsequent patch will move common data to a separate, shared file. When this is done, ARRAY_SIZE() will no longer be usable. This patch removes ARRAY_SIZE() usage for struct omap_hwmod_mpu_irqs arrays and uses a sentinel value (irq == -1) as the array terminator instead. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09omap_hwmod: share identical omap_hwmod_addr_space arraysPaul Walmsley
To reduce kernel source file data duplication, share struct omap_hwmod_addr_space arrays across OMAP2xxx and 3xxx hwmod data files. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-09omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space ↵Paul Walmsley
arrays Previously, struct omap_hwmod_addr_space arrays were unterminated; and users of these arrays used the ARRAY_SIZE() macro to determine the length of the array. However, ARRAY_SIZE() only works when the array is in the same scope as the macro user. So far this hasn't been a problem. However, to reduce duplicated data, a subsequent patch will move common data to a separate, shared file. When this is done, ARRAY_SIZE() will no longer be usable. This patch removes ARRAY_SIZE() usage for struct omap_hwmod_addr_space arrays and uses a null structure member as the array terminator instead. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-04-20OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup.Avinash.H.M
GPIO module expects the debounce clocks to be enabled during reset. It doesn't reset properly and timeouts are seen, if this clock isn't enabled during reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with which the debounce clocks are enabled during reset. Cc: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Avinash.H.M <avinashhm@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-04-19OMAP2+: hwmod data: Fix wrong dma_system end addressBenoit Cousson
OMAP2420, 2430 and 3xxx were using the OMAP4 end address that unfortunately is not located at the same base address. Moreover the OMAP4 size was set to 256 instead of 4096. Change all .pa_end to set them to .pa_start + 0xfff Cc: "G, Manjunath Kondaiah" <manjugk@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Reported-by: Michael Fillinger <m-fillinger@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-31Fix common misspellingsLucas De Marchi
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-22Merge branch 'for-paul' of git://gitorious.org/linux-omap-dss2/linuxPaul Mundt
Conflicts: arch/arm/mach-omap2/board-overo.c Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-03-11OMAP: DSS2: Have separate irq handlers for DISPC and DSIarchit taneja
Currently, the core DSS platform device requests for an irq line for OMAP2 and OMAP3. Make DISPC and DSI platform devices request for a shared IRQ line. On OMAP3, the logical OR of DSI and DISPC interrupt lines goes to the MPU. There is a register DSS_IRQSTATUS which tells if the interrupt came from DISPC or DSI. On OMAP2, there is no DSI, only DISPC interrupts goto the MPU. There is no DSS_IRQSTATUS register. Hence, it makes more sense to have separate irq handlers corresponding to the DSS sub modules instead of having a common handler. Since on OMAP3 the logical OR of the lines goes to MPU, the irq line is shared among the IRQ handlers. The hwmod irq info has been removed for DSS to DISPC and DSI for OMAP2 and OMAP3 hwmod databases. The Probes of DISPC and DSI now request for irq handlers. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-03-10Merge remote branch 'remotes/origin/hwmod_a_2.6.39' into ↵Paul Walmsley
tmp-integration-2.6.39-20110310-024 Conflicts: arch/arm/mach-omap2/omap_hwmod_2430_data.c arch/arm/mach-omap2/omap_hwmod_3xxx_data.c arch/arm/plat-omap/include/plat/omap_hwmod.h
2011-03-10omap: hwmod: add syss reset done flags to omap2, omap3 hwmodsAvinash.H.M
Some of the omap2, omap3 peripherals support software reset. This can be done through the softreset bit in sysconfig register. The reset status can be checked through resetdone bit of sysstatus register. syss_has_reset_status is added to the hwmod database of peripherals which have resetdone bit in sysstatus register. Cc: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Reviewed-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Avinash.H.M <avinashhm@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-03-09OMAP2/3: VENC hwmod: add OCPIF_SWSUP_IDLE flag to interfacePaul Walmsley
According to the hwmod interface data, the DSS submodule "VENC" uses a clock, "dss_54m_fck"/"dss_tv_fck", which the PRCM cannot autoidle. By default, the hwmod code assumes that interface clocks can be autoidled by the PRCM. When the interface clock can't be autoidled by the PRCM, those interfaces must be marked with the OCPIF_SWSUP_IDLE flag. Otherwise, the "interface clock" will always have a non-zero use count, and the device won't enter idle. This problem was observed on N8x0. Fix the immediate problem by marking the VENC interface with the OCPIF_SWSUP_IDLE flag. But it's not clear that "dss_54m_fck"/"dss_tv_fck" is really the correct interface clock for VENC. It may be that the VENC interface should use a hardware-autoidling interface clock. This is the situation on OMAP4, which uses "l3_div_ck" as the VENC interface clock, which can be autoidled by the PRCM. Clarification from TI is needed. Problem found and patch tested on N8x0 by Tony Lindgren <tony@atomide.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Senthilvadivu Guruswamy <svadivu@ti.com> Cc: Sumit Semwal <sumit.semwal@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-02Merge branches 'devel-iommu-mailbox', 'devel-mcbsp', 'devel-board' and ↵Tony Lindgren
'devel-hsmmc' into omap-for-linus Conflicts: arch/arm/mach-omap2/omap_hwmod_44xx_data.c
2011-03-01OMAP: hwmod data: Add dev_attr and use in the host driverKishore Kadiyala
Add a device attribute to hwmod data of omap2430, omap3, omap4. Currently the device attribute holds information regarding dual volt MMC card support by the controller which will be later passed to the host driver via platform data. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Acked-by: Benoit Cousson<b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-01OMAP2430: hwmod data: Add HSMMCPaul Walmsley
Update the omap2430 hwmod data with the HSMMC info. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-02-28OMAP2+: hwmod: rename some init functionsPaul Walmsley
Rename omap_hwmod_init() to omap_hwmod_register(). Rename omap_hwmod_late_init() to omap_hwmod_setup_all(). Also change all of the callers to reflect the new names. While here, update some copyrights. Suggested by Tony Lindgren <tony@atomide.com>. N.B. The comment in mach-omap2/serial.c may no longer be correct, given recent changes in init order. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com>
2011-02-27OMAP2430: hwmod data: add dmtimerThara Gopinath
Add dmtimer data. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com>
2011-02-24OMAP2430: hwmod data: Add McBSPCharulatha V
Add McBSP hwmod data for OMAP2430. Added a revision member inorder to facilitate the driver to differentiate between mcbsp in different omap. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-02-24OMAP2: hwmod data: add mailbox dataOmar Ramirez Luna
Mailbox hwmod data for omap2430 and 2420. Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-02-23OMAP2430: hwmod data: add DSS DISPC RFBI VENCSenthilvadivu Guruswamy
Hwmod needs database of all IPs in a system. This patch generates the hwmod database for OMAP2430 Display Sub System. Since DSS is also considered as an IP as DISPC, RFBI, name it as dss_core. Acked-by: Benoit Cousson <b-cousson@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-02-22Merge branch 'for-tony' of git://gitorious.org/usb/usb into omap-for-linusTony Lindgren
Conflicts: arch/arm/mach-omap2/omap_hwmod_2430_data.c arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
2011-02-17OMAP2430: hwmod data: Add McSPICharulatha V
Update the 2430 hwmod data file with McSPI info. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-02-17OMAP2430: hwmod data: Add USBOTGHema HK
OMAP2430 hwmod data structures are populated with base address, L3 and L4 interface clocks, IRQs and sysconfig register details. As per OMAP USBOTG specification, need to configure the USBOTG to smart idle/standby or no idle/standby during data transfer and force idle/standby when not in use to support retention and off-mode. By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework will take care of configuring to no idle/standby when module is enabled and force idle/standby when suspended. Signed-off-by: Hema HK <hemahk@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Cousson, Benoit <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2010-12-21OMAP2430: hwmod data: Use common dev_attr for i2c1 and i2c2Benoit Cousson
Since i2c1 and i2c2 are using the same data, remove the two previous instances and use a common i2c_dev_attr one. Moreover, that will fix the following warning: arch/arm/mach-omap2/omap_hwmod_2430_data.c:485: warning: 'i2c_dev_attr' defined but not used Signed-off-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Charulatha V <charu@ti.com>
2010-12-21OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanismPaul Walmsley
The OMAP watchdog timer IP blocks require a specific set of register writes to occur before they will be disabled[1], even if the device clocks appear to be disabled in the CM_*CLKEN registers. In the MPU watchdog case, failure to execute this reset sequence will eventually cause the watchdog to reset the OMAP unexpectedly. Previously, the code to disable this watchdog was manually called from mach-omap2/devices.c during device initialization. This causes the watchdog to be unconditionally disabled for a portion of kernel initialization. This should be controllable by the board-*.c files, since some system integrators will want full watchdog coverage of kernel initialization. Also, the watchdog disable code was not connected to the hwmod shutdown code. This means that calling omap_hwmod_shutdown() will not, in fact, disable the watchdog, and the goal of omap_hwmod_shutdown() is to be able to shutdown any on-chip OMAP device. To resolve the latter problem, populate the pre_shutdown pointer in the watchdog timer hwmod classes with a function that executes the watchdog shutdown sequence. This allows the hwmod code to fully disable the watchdog. Then, to allow some board files to support watchdog coverage throughout kernel initialization, add common code to mach-omap2/io.c to cause the MPU watchdog to be disabled on boot unless a board file specifically requests it to remain enabled. Board files can do this by changing the watchdog timer hwmod's postsetup state between the omap2_init_common_infrastructure() and omap2_init_common_devices() function calls. 1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. ZH [SWPU222H], Section 16.4.3.6, "Start/Stop Sequence for WDTs (Using WDTi.WSPR Register)" Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Charulatha Varadarajan <charu@ti.com>
2010-12-21Merge branch 'devel-dma' into omap-for-linusTony Lindgren
2010-12-20omap2430: hwmod: remove stray declarationAnand Gadiyar
Patch "OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430" in linux-next as of 20101203 introduced the following build warning - fix this by removing the stray i2c_dev_attr. arch/arm/mach-omap2/omap_hwmod_2430_data.c:483: warning: 'i2c_dev_attr' defined but not used Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-20OMAP2430: hwmod data: add system DMAG, Manjunath Kondaiah
Add OMAP2430 DMA hwmod data and also add required DMA device attributes. Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-12-07OMAP2430: hwmod data: Add GPIOVaradarajan, Charulatha
Add GPIO hwmod data for OMAP2430 Also remove "omap24xx.h" header file as it is not required anymore. Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-11-09OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430Paul Walmsley
Add hwmod structures for I2C controllers on OMAP2420/2430. NOTE: I2C module on OMAP2420 has 16bit registers and causes imprecise aborts if 32bits are read/written to it. Use the HWMOD_16BIT_REG flag to notify the hmwod framework of this hard requirement so that __raw_writew/readw is used to read /write the mdoule registers. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-10-01manual merge for pm-hwmod-uart due to conflictsKevin Hilman
2010-09-29OMAP2/3: UART: add omap_hwmod data for UARTs 1-4Kevin Hilman
This patch adds omap_hwmod data for UARTs on OMAP2 and OMAP3 platforms. UART4 support for 3630 and OMAP2 hwmod data added by Govindraj R. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-09-29OMAP2430: hwmod data: Add watchdog timerVaradarajan, Charulatha
Add watchdog timer hwmod data for OMAP2430 chip Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
2010-07-26OMAP2: hwmod data: add IVA1 (2420), IVA2 (2430) hwmodsPaul Walmsley
Add IVA1 hwmod data for OMAP2420 and IVA2 hwmod data for 2430. The data is based on Benoît Cousson's hwmod data for the OMAP3 IVA blocks. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-07-26OMAP2&3: hwmod: Replace l3 -> l3_mainKevin Hilman
Replace all the struct that contain l3 with l3_main in order to be consistent with the OMAP4 naming convention. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP2&3: hwmod: Remove _hwmod prefix in name stringBenoit Cousson
In the lastest OMAP4 hwmod data file, the _hwmod was removed in order to save some memory space and because it does not bring a lot. Align OMAP2420, 2430 and 3430 data files with the same convention. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLESTKevin Hilman
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag, otherwise _enable() will fail due to failing _wait_target_ready(). Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-05-20OMAP: hwmod: Rename hwmod name for the MPUBenoit Cousson
In the lastest OMAP4 hwmod data file, the _hwmod was removed in order to save some memory space and because it does not bring a lot. The same cleanup will be have to done for other hwmods in OMAP2 & 3 data files. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
2010-02-24OMAP hwmod: add hwmod class supportPaul Walmsley
Add support for categorizing and iterating over hardware IP blocks by the "class" of the IP block. The class is the type of the IP block: e.g., "timer", "timer1ms", etc. Move the OCP_SYSCONFIG/SYSSTATUS data from the struct omap_hwmod into the struct omap_hwmod_class, since it's expected to stay consistent for each class. While here, fix some comments. The hwmod_class structures in this patch were designed and proposed by Benoît Cousson <b-cousson@ti.com> and were refined in a discussion between Thara Gopinath <thara@ti.com>, Kevin Hilman <khilman@deeprootsystems.com>, and myself. This patch uses WARN() lines that are longer than 80 characters, as Kevin noted a broader lkml consensus to increase greppability by keeping the messages all on one line. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Cc: Thara Gopinath <thara@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-02-24OMAP hwmod: convert header files with static allocations into C filesPaul Walmsley
Code should be able to #include any header file without the fear that the header file will go allocating memory. This is a coding style issue, similar to commit 82e9bd588563c4e22ebb55b684ebec7e310cc715. Move the existing hwmod data from .h files to .c files. While here, convert "omap34xx" to "omap3xxx" in the hwmod files, since most of these structures should be reusable across all OMAP3 chips. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>