RE: [PATCH] OMAP: Asynchronous clock disable

Woodruff, Richard
2007-10-05T13:27:45Z

> Subject: [PATCH] OMAP: Asynchronous clock disable

Generally I think something like this is good. Internally I've been
calling this clock_disable_lazy().

For OMAP3 we have been trying to make drivers more aggressive in their
FCLCOK handling. As much of this control happens in bottom layers of
large stacks, we don't always know the call frequency on all entry
points into a driver. This call can have local clock implications like
you are seeing and also power domain and chip wide ones.

As for what is the right number for each driver we were floating ideas
like if you have an active inner region of the driver, it should use a
small number and for outer regions use a larger number.

* If you don't have the time or knowledge to instrument these drivers
call in points as their may be many (or to be more future proof with
less maintenance) it might be ok to set the time out to coincide with
some global system wide or domain wide activity timers.

This might apply more to say power domains, but one point is, if the
display is on and the user is interacting the touch screen, it is
impossible to hit _chip_ OFF modes anyway. This will only happen after
the screen has blanked. Thus for some timers having them approximately
set to user input speeds might be ok. Once these major events have
happened (screen blank and no input activity), it now becomes about
optimizing duty cycle of chip low power modes. In this case shorter
timer outs are better as they are more impacting in that system mode.

I'll try to look at actual code a bit more later on.

Regards,
Richard W.