aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/omap_hwmod_2420_data.c
AgeCommit message (Collapse)AuthorFilesLines
2012-04-13ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from VENC slave ↵Archit Taneja1-1/+0
interface The clocks for all DSS slave interfaces were recently changed to "dss_ick" on OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface previously had "dss_54m_fck" as it's clock which couldn't be autoidled, and hence the OCPIF_SWSUP_IDLE flag was needed. Remove the OCPIF_SWSUP_IDLE flag from VENC interfaces as it's clock is now "dss_ick". This allows the PRCM hardware to autoidle the VENC interface clocks when they are not active, rather than relying on the software to do it, which can keep the interface clocks active unnecessarily. Signed-off-by: Archit Taneja <[email protected]> [[email protected]: add a short description of the fix to the commit log] Signed-off-by: Paul Walmsley <[email protected]>
2011-11-08ARM: OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in ↵Archit Taneja1-0/+1
bootloader Resetting DISPC when a DISPC output is enabled causes the DSS to go into an inconsistent state. Thus if the bootloader has enabled a display, the hwmod code cannot reset the DISPC module just like that, but the outputs need to be disabled first. Add function dispc_disable_outputs() which disables all active overlay manager and ensure all frame transfers are completed. Modify omap_dss_reset() to call this function and clear DSS_CONTROL, DSS_SDI_CONTROL and DSS_PLL_CONTROL so that DSS is in a clean state when the DSS2 driver starts. This resolves the hang issue(caused by a L3 error during boot) seen on the beagle board C3, which has a factory bootloader that enables display. The issue is resolved with this patch. Thanks to Tomi and Sricharan for some additional testing. Acked-by: Tomi Valkeinen <[email protected]> Tested-by: R, Sricharan <[email protected]> Signed-off-by: Archit Taneja <[email protected]> [[email protected]: restructured code, removed omap_{read,write}l(), removed cpu_is_omap*() calls and converted to dev_attr] Signed-off-by: Paul Walmsley <[email protected]>
2011-11-08ARM: OMAP2xxx: HWMOD: fix DSS clock dataTomi Valkeinen1-2/+8
The OMAP2xxx HWMOD data currently contains two errors with DSS clocks: - dss_rfbi is missing ick opt-clock, which is needed for RFBI to calculate timings - dss_venc's interface and main clocks are wrong, causing VENC to fail to start These problems were temporarily fixed with a DSS patch 9ede365aa6f74428a1f69c21ca1cf21213167576 ("HACK: OMAP: DSS2: clk hack for OMAP2/3"), which can be reverted after this patch (and the similar patches for other OMAPs). Signed-off-by: Tomi Valkeinen <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2011-11-08ARM: OMAP2xxx: HWMOD: Fix DSS resetTomi Valkeinen1-1/+5
DSS needs all DSS clocks to be enabled to be able to finish reset properly. Before v3.1-rc1 the omapdss driver was managing clocks and resets correctly. However, when omapdss started using runtime PM at v3.1-rc1, the responsibility for the reset moved to HWMOD framework. HWMOD framework does not currently enable all the DSS clocks when resetting the DSS hardware. This hasn't caused any problems so far, but we may just have been lucky. This patch sets HWMOD_CONTROL_OPT_CLKS_IN_RESET for dss_core in OMAP2xxx HWMOD data, fixing the issue. Signed-off-by: Tomi Valkeinen <[email protected]> [[email protected]: merged duplicate .flags fields] Signed-off-by: Paul Walmsley <[email protected]>
2011-09-21ARM: OMAP2+: dmtimer: convert to platform devicesTarun Kanti DebBarma1-0/+22
Add routines to converts dmtimers to platform devices. The device data is obtained from hwmod database of respective platform and is registered to device model after successful binding to driver. In addition, capability attribute of each of the timers is added in hwmod database. Signed-off-by: Tarun Kanti DebBarma <[email protected]> Signed-off-by: Thara Gopinath <[email protected]> Reviewed-by: Santosh Shilimkar <[email protected]> Acked-by: Cousson, Benoit <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2011-09-14OMAP2+: hwmod: remove OMAP_CHIP*Paul Walmsley1-37/+0
At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and replace it instead with chip family, variant, and ES level-specific lists of hwmods to register. Thanks to Gražvydas Ignotas <[email protected]> for finding a bug in the AM3517/3505 support, and for other review comments. Signed-off-by: Paul Walmsley <[email protected]> Cc: Gražvydas Ignotas <[email protected]>
2011-07-10OMAP: hwmod: fix the i2c-reset timeout during bootupAvinash.H.M1-0/+1
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 <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Benoit Cousson <[email protected]> Cc: Kevin Hilman <[email protected]> Signed-off-by: Avinash.H.M <[email protected]> [[email protected]: 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 <[email protected]>
2011-07-10I2C: OMAP2+: add correct functionality flags to all omap2plus i2c dev_attrAndy Green1-1/+6
This adds the new functionality flags for omap i2c unit to all OMAP2 hwmod definitions Cc: [email protected] Cc: Ben Dooks <[email protected]> Reported-by: Peter Maydell <[email protected]> Signed-off-by: Andy Green <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2011-07-10I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revisionAndy Green1-0/+1
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: [email protected] Cc: Ben Dooks <[email protected]> Reported-by: Peter Maydell <[email protected]> Signed-off-by: Andy Green <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2011-07-09omap_hwmod: share identical omap_hwmod_class, omap_hwmod_class_sysconfig arraysPaul Walmsley1-237/+30
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 <[email protected]>
2011-07-09omap_hwmod: share identical omap_hwmod_dma_info arraysPaul Walmsley1-77/+10
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 <[email protected]>
2011-07-09omap_hwmod: use a terminator record with omap_hwmod_dma_info arraysPaul Walmsley1-10/+10
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 <[email protected]>
2011-07-09omap_hwmod: share identical omap_hwmod_mpu_irqs arraysPaul Walmsley1-142/+25
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 <[email protected]>
2011-07-09omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arraysPaul Walmsley1-28/+28
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 <[email protected]>
2011-07-09omap_hwmod: share identical omap_hwmod_addr_space arraysPaul Walmsley1-265/+26
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 <[email protected]>
2011-07-09omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space ↵Paul Walmsley1-33/+33
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 <[email protected]>
2011-04-20OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup.Avinash.H.M1-0/+4
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 <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Benoit Cousson <[email protected]> Cc: Kevin Hilman <[email protected]> Signed-off-by: Avinash.H.M <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2011-04-19OMAP2+: hwmod data: Fix wrong dma_system end addressBenoit Cousson1-1/+1
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" <[email protected]> Cc: Benoit Cousson <[email protected]> Reported-by: Michael Fillinger <[email protected]> Signed-off-by: Benoit Cousson <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2011-03-22Merge branch 'for-paul' of git://gitorious.org/linux-omap-dss2/linuxPaul Mundt1-7/+6
Conflicts: arch/arm/mach-omap2/board-overo.c Signed-off-by: Paul Mundt <[email protected]>
2011-03-11OMAP: DSS2: Have separate irq handlers for DISPC and DSIarchit taneja1-7/+6
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 <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2011-03-10Merge remote branch 'remotes/origin/hwmod_a_2.6.39' into ↵Paul Walmsley1-5/+6
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.M1-5/+6
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 <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Benoit Cousson <[email protected]> Cc: Kevin Hilman <[email protected]> Reviewed-by: Govindraj.R <[email protected]> Signed-off-by: Avinash.H.M <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2011-03-09OMAP2/3: VENC hwmod: add OCPIF_SWSUP_IDLE flag to interfacePaul Walmsley1-0/+1
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 <[email protected]>. Signed-off-by: Paul Walmsley <[email protected]> Cc: Tony Lindgren <[email protected]> Cc: Senthilvadivu Guruswamy <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: Benoît Cousson <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2011-03-02Merge branches 'devel-iommu-mailbox', 'devel-mcbsp', 'devel-board' and ↵Tony Lindgren1-0/+202
'devel-hsmmc' into omap-for-linus Conflicts: arch/arm/mach-omap2/omap_hwmod_44xx_data.c
2011-02-28OMAP2+: hwmod: rename some init functionsPaul Walmsley1-1/+1
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 <[email protected]>. 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 <[email protected]> Cc: Benoît Cousson <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: Tony Lindgren <[email protected]>
2011-02-27OMAP2420: hwmod data: add dmtimerThara Gopinath1-0/+634
Add dmtimer data. Signed-off-by: Thara Gopinath <[email protected]> Signed-off-by: Tarun Kanti DebBarma <[email protected]> Acked-by: Benoit Cousson <[email protected]>
2011-02-24OMAP2420: hwmod data: Add McBSPCharulatha V1-0/+129
Add McBSP hwmod data for OMAP2420. Also add macros in prcm-common.h for idlest bit of OMAP24XX McBSP devices Signed-off-by: Charulatha V <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Shubhrajyoti D <[email protected]> Cc: Benoit Cousson <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2011-02-24OMAP2: hwmod data: add mailbox dataOmar Ramirez Luna1-0/+73
Mailbox hwmod data for omap2430 and 2420. Signed-off-by: Omar Ramirez Luna <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2011-02-23OMAP2420: hwmod data: add DSS DISPC RFBI VENCSenthilvadivu Guruswamy1-0/+310
Hwmod needs database of all IPs in a system. This patch generates the hwmod database for OMAP2420 Display Sub System,. Since DSS is also considered as an IP as DISPC, RFBI, name it as dss_core. Acked-by: Benoit Cousson <[email protected]> Reviewed-by: Kevin Hilman <[email protected]> Tested-by: Kevin Hilman <[email protected]> Signed-off-by: Sumit Semwal <[email protected]> Signed-off-by: Senthilvadivu Guruswamy <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2011-02-17OMAP2420: hwmod data: Add McSPICharulatha V1-0/+156
Update the omap2420 hwmod data with the McSPI info. Add a device attribute structure which will be used for passing number of chipselects from hwmod data. Add revision macros to be passed from rev field from hwmod. Signed-off-by: Charulatha V <[email protected]> Signed-off-by: Govindraj.R <[email protected]> Acked-by: Grant Likely <[email protected]> Reviewed-by: Kevin Hilman <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2010-12-21OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanismPaul Walmsley1-2/+4
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 <[email protected]> Cc: Benoît Cousson <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: Charulatha Varadarajan <[email protected]>
2010-12-20OMAP2420: hwmod data: add system DMAG, Manjunath Kondaiah1-0/+86
Add OMAP2420 DMA hwmod data and also add required DMA device attributes. Signed-off-by: G, Manjunath Kondaiah <[email protected]> Acked-by: Paul Walmsley <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2010-12-07OMAP2420: hwmod data: Add GPIOVaradarajan, Charulatha1-1/+229
Add GPIO hwmod data for OMAP2420 and add the required GPIO device attributes in the gpio header file Also remove "omap24xx.h" header file as it is not required anymore. Signed-off-by: Charulatha V <[email protected]> Acked-by: Benoit Cousson <[email protected]> Acked-by: Kevin Hilman <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2010-11-09OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430Paul Walmsley1-3/+142
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 <[email protected]> Signed-off-by: Rajendra Nayak <[email protected]> Signed-off-by: Kevin Hilman <[email protected]>
2010-10-01manual merge for pm-hwmod-uart due to conflictsKevin Hilman1-0/+193
2010-09-29OMAP2/3: UART: add omap_hwmod data for UARTs 1-4Kevin Hilman1-0/+193
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 <[email protected]> Signed-off-by: Kevin Hilman <[email protected]>
2010-09-29OMAP2420: hwmod data: Add watchdog timerVaradarajan, Charulatha1-0/+64
Add watchdog timer hwmod data for OMAP2420 chip Signed-off-by: Charulatha V <[email protected]> Acked-by: Cousson, Benoit <[email protected]> Signed-off-by: Kevin Hilman <[email protected]>
2010-07-26OMAP2: hwmod data: add IVA1 (2420), IVA2 (2430) hwmodsPaul Walmsley1-0/+30
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 <[email protected]> Cc: Benoît Cousson <[email protected]> Cc: Kevin Hilman <[email protected]>
2010-07-26OMAP2&3: hwmod: Replace l3 -> l3_mainKevin Hilman1-17/+17
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 <[email protected]> Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2010-07-26OMAP2&3: hwmod: Remove _hwmod prefix in name stringBenoit Cousson1-3/+3
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 <[email protected]> Cc: Rajendra Nayak <[email protected]> Acked-by: Kevin Hilman <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2010-07-26OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLESTKevin Hilman1-3/+6
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 <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2010-05-20OMAP: hwmod: Rename hwmod name for the MPUBenoit Cousson1-1/+1
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 <[email protected]> Signed-off-by: Paul Walmsley <[email protected]> Cc: Rajendra Nayak <[email protected]>
2010-02-24OMAP hwmod: add hwmod class supportPaul Walmsley1-0/+6
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 <[email protected]> and were refined in a discussion between Thara Gopinath <[email protected]>, Kevin Hilman <[email protected]>, 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 <[email protected]> Signed-off-by: Benoît Cousson <[email protected]> Cc: Thara Gopinath <[email protected]> Cc: Kevin Hilman <[email protected]>
2010-02-24OMAP hwmod: convert header files with static allocations into C filesPaul Walmsley1-0/+143
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 <[email protected]> Cc: Benoît Cousson <[email protected]> Cc: Rajendra Nayak <[email protected]> Cc: Kevin Hilman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.