aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* ARM: OMAP2420: hwmod data: Add MMC hwmod data for 2420Tony Lindgren2012-05-08
| | | | | | | | | | | | | | Add MMC for 2420 so we can pass the DMA request lines the same way as we already do on omap2430 and later. Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com> [paul@pwsan.com: updated to apply on top of the 3.5 hwmod cleanup; changed mmc hwmod name/class to "msdi" as documented in the 2420 TRM Rev X; added sysconfig register information; added 16 bit register width flag; added MSDI custom reset code] Signed-off-by: Paul Walmsley <paul@pwsan.com>
*---. Merge branches 'clock_am35xx_cleanup_3.5', 'prm_cm_devel_a_3.5', ↵Paul Walmsley2012-05-08
|\ \ \ | | | | | | | | | | | | 'clock_devel_a_3.5' and 'pwrdm_clkdm_cleanup_3.5' into prcm_devel_a_3.5
| | | * arm: omap3: clockdomain data: Remove superfluous commas from ↵Mark A. Greer2012-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gfx_sgx_3xxx_wkdeps[] Clean up clockdomains3xxx_data.c a bit by removing the superfluous commas in gfx_sgx_3xxx_wkdeps[]. Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | | * ARM: OMAP2+: powerdomain: Get rid off duplicate pwrdm_clkdm_state_switch() APISantosh Shilimkar2012-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With patch 'ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()', the pwrdm_clkdm_state_switch() API becomes duplicate of pwrdm_state_switch(). Get rid off duplicate pwrdm_clkdm_state_switch() and update the users of it with pwrdm_state_switch() Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | * | ARM: OMAP3: clock data: add clockdomain for HDQ functional clockPaul Walmsley2012-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the correct clockdomain for the HDQ functional clock. This is needed for the clock and hwmod PM code to work correctly. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: NeilBrown <neilb@suse.de>
| | * | ARM: OMAP3+: dpll: Configure autoidle mode only if it's supportedVaibhav Bedia2012-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current DPLL code enables and disables autoidle features without checking whether the autoidle register is available. Fix this by putting a check for the existence of the autoidle register in the DPLL data. With such a check in place, for DPLLs which do not support this feature, simply skipping the autoidle_reg entry in the DPLL data is sufficient. Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | * | ARM: OMAP2+: dmtimer: cleanup iclk usageTarun Kanti DebBarma2012-05-08
| | |/ | | | | | | | | | | | | | | | | | | | | | We do not use iclk anywhere in the dmtimer driver and so removing it. Hence removing the timer iclk entries from OMAP4 clkdev table as well. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
| * | ARM: OMAP4+: Add prm and cm base init function.R Sricharan2012-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of statically defining seperate arrays for every OMAP4+ archs, have a generic init function to populate the arrays. This avoids the need for creating new array for every arch added in the future that reuses the prm and cm registers read/write code. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
| * | ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common headerVaibhav Hiremath2012-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing idle_st bit for 32k-sync timer into the prcm-common header file, required for hwmod data. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
| * | ARM: OMAP3: Fix CM register bit masksRajendra Nayak2012-05-08
| |/ | | | | | | | | | | | | | | The register bits for MPU_CLK_SRC and IVA2_CLK_SRC in CM_CLKSEL1_PLL register are 3 bits wide. Fix the MASK definition accordingly. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* | ARM: OMAP: clock: convert AM3517/3505 detection/flags to AM35xxKevin Hilman2012-05-08
| | | | | | | | | | | | | | | | | | | | To improve the clarity of the code, replace the CK_3517 flag used in the clock data with CK_AM35XX. The CK_3505 flag can also be removed, since it is now unused. Acked-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* | ARM: OMAP3: clock data: treat all AM35x devices the sameKevin Hilman2012-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The init for 3505/3517 specific clocks depends on the ordering of cpu_is checks, is error prone and confusing (there are 2 separate checks for cpu_is_omap3505()). Remove the 3505-specific checking since CK_3505 flag is not used, and treat all AM35x clocks the same. This means that the SGX clock (the only AM35x clkdev not currently flagged for 3505) will now be registered on 3505, but that is harmless. That can be cleaned up when the clkdev nodes are removed in favor of them being registered by hwmod. Acked-by: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* | ARM: OMAP3: clock data: replace 3503/3517 flag with AM35x flag for UART4Kevin Hilman2012-05-08
|/ | | | | | | | | | The AM35x UART4 is common to all AM35x devices, so use CK_AM35XX instead of (CK_3505 | CK_3517), which is equivalent. Acked-by: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP4: hwmod data: add DEBUGSS skeletonBenoît Cousson2012-04-19
| | | | | | | | | | Add a skeleton hwmod for the DEBUGSS and associated interconnect data. This is a basic set of data that will need further additions as further DEBUGSS information becomes available. Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP4: hwmod data: add PRCM and related IP blocksPaul Walmsley2012-04-19
| | | | | | | | | Add the PRCM, CM, PRM, and related hwmod and associated interconnect data. These IP blocks handle most of the on-chip power, reset, and clock control. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: add System Control ModulePaul Walmsley2012-04-19
| | | | | | | Add the System Control Module hwmod and associated interconnect data. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: add the OCP-WP IP blockBenoît Cousson2012-04-19
| | | | | | | | | Add the OCP-WP hwmod and associated interconnect data. The OCP-WP, or OCP watchpoint, can be used to collect interconnect data and transmit it via the STM port. Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP4: hwmod data: add OCM RAM IP blockPaul Walmsley2012-04-19
| | | | | | | | Add the OCM RAM IP block and interconnect data. This is an oh-chip block of SRAM connected directly to the L3 bus. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: add remaining USB-related IP blocksBenoît Cousson2012-04-19
| | | | | | | | | | | | | | Add the OCP2SCP IP block and interconnect data. The OCP2SCP can be used in conjunction with the on-chip embedded USB PHY, associated with the OTG controller. Add the on-chip full-speed USB host controller IP block and interconnect data. Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP4: hwmod data: add some interconnect-related IP blocksPaul Walmsley2012-04-19
| | | | | | | | | | | | | | | | | Add the SL2 interface IP block and interconnect data. The SL2 is related to the IVA-HD subsystem. Add IP block and interconnect data for the C2C ("Chip-to-chip") interconnect. This can provide a direct system interconnect link to other devices stacked on the OMAP package. Add the ELM IP block and interconnect data. The ELM can be used to locate errors in NAND flash connected to the GPMC. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: add McASPBenoît Cousson2012-04-19
| | | | | | | | Add the McASP hwmod and associated interconnect data. The McASP is a general-purpose audio serial port. Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP4: hwmod data: add the Slimbus IP blocksBenoît Cousson2012-04-19
| | | | | | | | | | | Add the Slimbus hwmods and associated interconnect data. The Slimbus IP blocks implement a two-wire serial interface. Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP4: hwmod data: add GPUPaul Walmsley2012-04-19
| | | | | | | | Add the GPU hwmod and associated interconnect data. The GPU is a graphics accelerator. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: add EMIF1 and 2Paul Walmsley2012-04-19
| | | | | | | | Add the EMIF1 and 2 hwmods and associated interconnect data. The EMIFs are SDRAM interface IP blocks. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: add GPMCBenoît Cousson2012-04-19
| | | | | | | | | | Add the GPMC hwmod and associated interconnect data. The GPMC is a programmable parallel-bus memory controller. Signed-off-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP4: hwmod data: add HDQ/1-wirePaul Walmsley2012-04-19
| | | | | | | | | Add the HDQ/1-wire hwmod and associated interconnect data. The HDQ/1-wire IP block is a low-speed serial interconnect. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: introduce fdif(face detect module) hwmodMing Lei2012-04-19
| | | | | | | | | | | | | | | | | | Add hwmod data for the OMAP4 FDIF IP block. This patch also includes a change (originally from Fernando Guzman Lugo <fernando.lugo@ti.com>) to set a softreset delay for the FDIF IP block: http://www.spinics.net/lists/arm-kernel/msg161874.html Signed-off-by: Ming Lei <ming.lei@canonical.com> Acked-by: Benoît Cousson <b-cousson@ti.com> Cc: Fernando Guzman Lugo <fernando.lugo@ti.com> [paul@pwsan.com: rearranged to match script output; fixed FDIF end address to match script data; wrote trivial changelog; combined the FDIF portion of Fernando's srst_udelay patch] Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm commonPaul Walmsley2012-04-19
| | | | | | | | | The PRM and CM implicit clockdomains will soon be used by OMAP44xx. So, make them common to OMAP2+ and modify the OMAP4 clockdomains code so use of these clockdomains doesn't crash the system. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
* ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSPPaul Walmsley2012-04-19
| | | | | | | | | | | | N800 logs this message on boot: [ 0.182281] omap_hwmod: iva: cannot be enabled for reset (3) Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2 hwmod for OMAP2430. There is still more information to be added, but this should resolve the immediate issue. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP3: hwmod data: add IVA hard reset lines, main clock, clockdomainPaul Walmsley2012-04-19
| | | | | | | | | | | | The IVA hwmod data is missing some fields that cause the following warning on boot: [ 0.118011] omap_hwmod: iva: cannot be enabled for reset (3) Fix by encoding the IP block's main functional clock, reset lines, and clockdomain. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP3: hwmod data: fix IVA interface clockPaul Walmsley2012-04-19
| | | | | | | | | | | | | | | The OMAP3 hwmod data listed iva2_ck as an interface clock between the IVA and L3. This is incorrect. iva2_ck is not an interface clock. Since it cannot auto-idle, specifying it here prevents the IVA and at least one of the CORE clockdomains from going idle, which causes PM problems such as these upon system suspend: [ 70.626129] Powerdomain (iva2_pwrdm) didn't enter target state 1 [ 70.626190] Powerdomain (core_pwrdm) didn't enter target state 1 Fix by specifying the actual interface clock in the hwmod data. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP2xxx: hwmod data: share common interface dataPaul Walmsley2012-04-19
| | | | | | | | | | | | Several struct omap_hwmod_ocp_if records can be shared between OMAP2420 and OMAP2430. Move these shared records out of the chip-specific files into mach-omap2/omap_hwmod_2xxx_interconnect_data.c. This should save some memory and source lines, at the cost of readability. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP2xxx: hwmod data: share common hwmods between OMAP2420 and OMAP2430Paul Walmsley2012-04-19
| | | | | | | | | | | | | After the link registration conversion, it's much easier to share some hwmod data between OMAP2420 and 2430. Move the shareable data into a common file. This should save some memory and lines of source, at the cost of readability. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP2+: hwmod data: remove forward declarations, reorganizePaul Walmsley2012-04-19
| | | | | | | | | | | | | Reorganize the hwmod data to declare the IP blocks first and the interconnects second. This allows us to remove the forward declarations, which this patch also does. Saves some lines of source data. While here, take the opportunity to synchronize the order of the OMAP44xx hwmod data with the autogenerator output -- it's slightly different due to past mismerges -- and fix a few minor typos and whitespace problems in the files. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP: hwmod: remove code support for direct hwmod registrationPaul Walmsley2012-04-19
| | | | | | | | Now that the data has been converted to use interface registration, we can remove the (now unused) direct hwmod registration code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP2+: hwmod data: convert to link registrationPaul Walmsley2012-04-19
| | | | | | | | | | | | | | | | Register interconnect links between IP blocks, rather than the IP blocks themselves. (The IP blocks will be registered as a side-effect of registering the links.) The objective is to reduce the number of lines of static data and facilitate the sharing of IP block data between different SoCs. These objectives come at the penalty of increased boot time due to increased computation. While here, fix a few whitespace problems and inaccurate variable names. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP2+: hwmod: add support for link registrationPaul Walmsley2012-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP2+: hwmod: consolidate finding the MPU port index and storing itPaul Walmsley2012-04-19
| | | | | | | | | | An IP block's MPU interface port only needs to be found once. The result can be cached to speed further lookups. This patch consolidates these two steps into a single function. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_ifPaul Walmsley2012-04-19
| | | | | | | | | | | | To reduce the number of lines of data in the OMAP portion of the Linux code base, subsequent patches will remove the lists of hwmod interconnect links from the static hwmod data. These lists will be built dynamically during boot. To ease this transition, this patch centralizes the way that interconnect links are iterated into a single function, _fetch_next_ocp_if(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP2+: hwmod: add _find_mpu_rt_port()Paul Walmsley2012-04-19
| | | | | | | | | | | | | | | Most IP blocks on the OMAP SoC have an interconnect link that is intended to be used by the MPU to communicate with the IP block. Several parts of the hwmod code need to be able to identify this link. Currently, this is open-coded. However, future patches will change the way that interconnect links are represented and will make identifying the link more complex. So to avoid code duplication, this patch centralizes the MPU port link identification code into a new function, _find_mpu_rt_port(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP2+: hwmod: extend OCP_* register offsets from 16 to 32 bitsPaul Walmsley2012-04-19
| | | | | | | | | | | | | | | Extend the OCP_* register offsets in the struct omap_hwmod_class_sysconfig to 32 bits. This is required to add the OMAP4+ GPU hwmod, which uses OCP_* register offsets larger than 16 bits. Another possible solution may be to simply add a single 16 bit offset field in this structure, and to add code to factor that offset into all OCP_* register accesses. This would save some memory, since almost no modules need 32 bit offsets. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: uncomment some "excluded" hwmodsPaul Walmsley2012-04-19
| | | | | | | | | | | | | Some hwmods were commented out from the OMAP4 data, under the theory that they shouldn't be added until drivers were ready. But part of the utility of the hwmod code is that it can reset and properly initialize IP blocks that have no drivers associated with them. Rather than commenting the links in the future hwmod data conversion patches, discussing this with Benoit, it seems best to simply uncomment them now. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: add OCP_USER_DSP; mark omap44xx_dsp__iva appropriatelyPaul Walmsley2012-04-19
| | | | | | | | | | | | | | | | One of the OMAP4 links was missing OCP_USER flags, since it was only used by the DSP initiator, and we did not have an OCP_USER_DSP flag. Future patches will switch the hwmod code and data to register interfaces, rather than hwmods, and it will be mandatory for all interfaces to have at least one user bit set. This patch resolves the issue by adding OCP_USER_DSP and marking the DSP-IVA interface appropriately. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP4: hwmod data: remove bandgap hwmodPaul Walmsley2012-04-19
| | | | | | | | | | | | | Commit 407a6888f7362cb3dabe69ea6d9dcf3c750dc56a ("OMAP4: hwmod data: Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU") adds a hwmod for the bandgap die temperature sensor IP block. This IP block has no interconnect port or firewall region, nor does it have an independent register space or OCP control registers. Its registers are embedded in the System Control Module (SCM) IP block. So it appears that the bandgap device should be created by the SCM driver. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
* ARM: OMAP3: hwmod data: GPTIMER12 is attached to a separate interconnectPaul Walmsley2012-04-19
| | | | | | | GPTIMER12 is attached to the L4 SEC interconnect, not directly to L4 WKUP. Add the L4 SEC interconnect and attach GPTIMER12 to it. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP3: hwmod data: add DSS->L3 interconnect for 3430ES1Paul Walmsley2012-04-19
| | | | | | | | | | | | The OMAP3 hwmod data was missing a DSS->L3 interconnect link for the OMAP3430 ES1 DSS hwmod. Since the hwmod code and data is being modified to register interfaces rather than hwmods, this would result in the DSS hwmod not being registered correctly on OMAP3430ES1. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP3: hwmod data: fix interfaces for the MMC hwmodsPaul Walmsley2012-04-19
| | | | | | | | | | | | | | Commit a52e2ab66d4a9305e1ba64d9b9d25754b6c70895 ("ARM: OMAP3: hwmod data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx <= ES2.1") didn't link the MMC hwmods to the interconnects correctly. Future patches will register hwmods by interface, so if this is not fixed, the MMC IP blocks won't be registered. Update the interface data records to point to the correct IP blocks. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP2/3: hwmod data: update old namesPaul Walmsley2012-04-19
| | | | | | | | | | | Some of the 2xxx and 3xxx hwmod data files use the old naming style for hwmods, ending in a "_hwmod". These names are used by the OMAP integration code to map hwmods to platform_devices, so they need to be consistent, or the platform_devices won't be created. Remove the _hwmod suffix to conform with the rest of the OMAP SoC data. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* ARM: OMAP2+: timer: use a proper interface to get hwmod dataPaul Walmsley2012-04-19
| | | | | | | | | | arch/arm/mach-omap2/timer.c pokes around inside the hwmod data structures. Since the hwmod data structures are about to change, this code will break. This patch modifies the timer code to use recently-added hwmod functions instead. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: hwmod: add omap_hwmod_get_resource_byname()Paul Walmsley2012-04-19
| | | | | | | | | | | | | | | | | | The timer integration code pokes around in hwmod data structures. Those data structures are about to change. Define a function, omap_hwmod_get_resource_byname(), for the timer integration code to use instead. The original patch has been changed to use struct resource by Tony's request, although the caller of this function should not be a driver._ Platform drivers should get their data through the regular platform_* functions; DT drivers through the appropriate of_* functions. This a function is only for use by OMAP core code in arch/arm/*omap*. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-10-23 14:31:18 -0400