On Fri, Jul 10, 2009 at 6:56 AM, Mahalingam, Nithish<nithish.mahalingam@xxxxxxxxx> wrote: > On Thu, Jul 9, 2009 at 10:48 PM, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote: >>> On Thu, 9 Jul 2009, Magnus Damm wrote: >>> >>>> Clocks should be stopped as soon as possible without any delay. The >>>> clock stopping is very cheap performance wise. Also, the clock >>> stopping is done on bus level without invoking any driver callbacks. >>>> Delaying the clock stopping does not make any sense to me. >>> >>> In that case the device driver or bus subsystem should manage the >>> device's clock directly. There's no need to tie it in with the runtime >>> PM framework. Simply start the clock before each I/O operation and >>> stop it afterward. > >> It's not that easy. The clock needs to be enabled to let the hardware >> device perform device specific stuff. For instance, the clock for the >> LCD controller needs to be on to redraw the screen. When the driver >> knows that it's done with the clock it can notify the bus using >> Runtime PM. > > Is there any plan to look into the "Clock Framework" that was developed as part of OMAP and extending this to make it generic for all platforms? Do you mean vendor specific extensions to the clock framework? I'm quite sure a bunch of architectures already support the clock framework. Some architectures probably have extensions that would be nice if they could be made more generic. Do you have any special extensions in mind? =) As for Runtime PM, clock stopping is only one part of the problem. On SuperH we manage clock stopping through the clock framework and I'm pretty sure other embedded architectures do that as well. That problem is more or less already solved in my opinion. For efficient power management on embedded systems we need more than just clock stopping. We also want to save and restore device context so we can turn off power to power domains during runtime. This is somewhat tied together with clock stopping because we want to disable clocks as soon as possible when the device gets idle but in the case of domain power off we also need to start the clock before we can call the ->runtime_suspend() callback provided by the driver. All this can of course be handled by the device driver, but that would just be duplicating too much code - I'd rather let the Runtime PM bus code manage that. Many runtime power management aware device drivers use clk_enable() and clk_disable() stop and start clocks. But the clk_disable() function is actually often used to signal that the device is idle. Allowing device drivers to replace clk_enable()/clk_disable() with Runtime PM callbacks to add support for context save and restore is a logical next step from my point of view. For SuperH we will most likely allow clock stopping through the clock framework _or_ using Runtime PM in parallel, at least until all drivers are converted to make use of Runtime PM. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
