Commit Graph

4 Commits

Author SHA1 Message Date
Benoit Cousson 9a23dfe128 OMAP4: hwmod & CM: Implement the omap4_cm_wait_module_ready function
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-20 12:31:08 -06:00
Benoit Cousson d9e6625c70 OMAP: CM: Move MAX_MODULE_READY_TIME to cm.h
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>
2010-05-20 12:31:08 -06:00
Tony Lindgren 61f04ee83c omap: Fix 44xx compile
Looks like these patches were not tested that well..

Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-09-24 16:23:07 -07:00
Paul Walmsley 71348bcaac OMAP2/3/4 PRCM: add module IDLEST wait code
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>
2009-09-03 20:14:02 +03:00