On 4/1/2011 8:21 PM, Rajendra Nayak wrote:
Hi Paul,
<snip>..
In omap_hwmod.c:_enable(), what do you think about:
1. saving the current idle mode of the clockdomain,
2. forcing the clockdomain to software-supervised wakeup.
3. enabling clocks and waiting for the module as we currently do, then
4. switching the clockdomain's idle mode back to its original state?
Seems like that would be a reasonable approach for the short term, at
least for drivers that have been converted to PM runtime.
Ok, I'll try and get some RFC patches in these lines soon.
I tried some of what you were suggesting here and it seems to
work well, like you said, for the drivers which are converted
to PM runtime.
Now the issue seems to be, how do we handle the ones which
are *still* using clock framework to enable main clocks and
are yet to be converted to PM runtime.
One such, MMC, is showing me issues on OMAP4 even at boot
and causes a crash.
Its a different thing that some of these drivers which use
direct clock calls are working by fluke on OMAP4 since the
clock framework does not even wait for the modules to become
accessible after the clock enable.
I know the right way seems to be to get all these drivers
converted to PM runtime, but that might take sometime.
One way I am able to get this working (atleast MMC)
is by preventing the clock domain belonging to MMC module
from being programmed into HW_SUP mode.
Acceptable hack in the interim while we wait for the MMC
driver to be using PM runtime?
regards,
Rajendra
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
