Re: [PATCH] OMAP: Asynchronous clock disable

[Tony Lindgren <tony@atomide.com>]

Hi,

* Woodruff, Richard <r-woodruff2@ti.com> [071005 06:29]:
> 
> > 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.

Sounds like this could also allow the same performance as keeping clocks
on all the time for some drivers.

We just have to take care not to use it too much with timers going off
all the time :)

Tony