aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/cm4xxx.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2010-05-20OMAP4: hwmod & CM: Implement the omap4_cm_wait_module_ready functionBenoit Cousson1-7/+29
The return of the omap4_cm_wait_module_ready function is checked in order to avoid accessing the sysconfig register if the module is not in the correct state. In that case the _setup will exit without trying to reset using sysconfig. For the moment a warning is printed. A proper management of fclk and module reset will have to be done in order to init correctly the problematic IPs listed below. <4>omap_hwmod: ivahd: cannot be enabled (3) <4>omap_hwmod: iss: cannot be enabled (3) <4>omap_hwmod: tesla: cannot be enabled (3) <4>omap_hwmod: sdma: cannot be enabled (3) <4>omap_hwmod: sl2: cannot be enabled (3) <4>omap_hwmod: sad2d: cannot be enabled (3) <4>omap_hwmod: ducati: cannot be enabled (3) Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-05-20OMAP: CM: Move MAX_MODULE_READY_TIME to cm.hBenoit Cousson1-17/+1
The maximum timeout to wait for the PRCM to request that a module exit idle or reach functionnal state is common to OMAP2/3/4 SoCs, so, move it to the chip family-common cm.h include file. Reduce the timeout from 20 ms to 2 ms. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2009-09-24omap: Fix 44xx compileTony Lindgren1-15/+2
Looks like these patches were not tested that well.. Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-09-03OMAP2/3/4 PRCM: add module IDLEST wait codePaul Walmsley1-0/+68
After a hardware module's clocks are enabled, Linux must wait for it to indicate readiness via its IDLEST bit before attempting to access the device, otherwise register accesses to the device may trigger an abort. This has traditionally been implemented in the clock framework, but this is the wrong place for it: the clock framework doesn't know which module clocks must be enabled for a module to leave idle; and if a module is not in smart-idle mode, it may never leave idle at all. This type of information is best stored in a per-hardware module data structure (coming in a following patch), rather than a per-clock data structure. The new code will use these new functions to handle waiting for modules to enable. Once hardware module data is filled in for all of the on-chip devices, the clock framework code to handle IDLEST waiting can be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com>