summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/cm.c
AgeCommit message (Collapse)Author
2010-07-26OMAP24xx: CM: fix mask used for checking IDLEST statusKevin Hilman
On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3. The mask used to check this was using the bit position instead of the bit mask. This patch fixes the problem by using the bit mask instead of the bit field. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-05-20OMAP: CM: Move MAX_MODULE_READY_TIME to cm.hBenoit Cousson
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-12-12OMAP clock/hwmod: fix off-by-one errorsPaul Walmsley
Fix loop bailout off-by-one bugs reported by Juha Leppänen <juha_motorsportcom@luukku.com>. This second version incorporates comments from Russell King <linux@arm.linux.org.uk>. A new macro, 'omap_test_timeout', has been created, with cleaner code, and existing code has been converted to use it. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Juha Leppänen <juha_motorsportcom@luukku.com> Cc: Russell King <linux@arm.linux.org.uk>
2009-09-03OMAP2/3/4 PRCM: add module IDLEST wait codePaul Walmsley
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>