Hi all, I'd like to post a patch in a couple of days to refactor the EHCI clock management code. This would be useful to do aggressive clock management in the idle path.
A current implementation I have is to simply factor out the clock_enable/disable calls out. Does it make sense to move this out to mach-omap2/* and provide the function pointer through platform data? Does the driver need to be aware of the clocks that it needs, or is it sufficient for it to just call a platform-specific function that turns on/off all the clocks needed by the driver? The reason I ask is, in a future OMAP, we may need to enable a different set of clocks, but we should be able to re-use the rest of the code directly. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
