Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
USBHOST, and HSOTGUSB devices. These devices are both interconnect
initiators and targets. Without this patch, clk_enable()s on clocks for
these modules can be very high latency (potentially up to ~200
milliseconds) and message such as the following are generated:
Clock usbhost_48m_fck didn't enable in 100000 tries
Two bugs are fixed by this patch. First, OMAP hardware only supports
target CM_IDLEST register bits on ES2+ chips and beyond. ES1 chips
should not wait for these clocks to enable. So, split the appropriate
clocks into ES1 and ES2+ variants, so that kernels running on ES1
devices won't try to wait.
Second, the current heuristic in omap2_clk_dflt_find_idlest() will
fail for these clocks. It assumes that the CM_IDLEST bit to wait upon
is the same as the CM_*CLKEN bit, which is false[1]. Fix by
implementing custom clkops .find_idlest function pointers for the
appropriate clocks that return the correct slave IDLEST bit shift.
This was originally fixed in the linux-omap kernel during 2.6.29 in a
slightly different manner[2][3].
In the medium-term future, all of the module IDLEST code will
eventually be moved to the omap_hwmod code.
Problem reported by Jarkko Nikula <jhnikula@gmail.com>:
http://marc.info/?l=linux-omap&m=124306184903679&w=2
...
1. See for example 34xx TRM Revision P Table 4-213 and 4-217 (for the
DSS case).
2. http://www.spinics.net/lists/linux-omap/msg05512.html et seq.
3. http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/01498.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>
3c82e229f0