RE: [PATCH 28/28] omap2 clock: handle (almost) all clock autoidling viathe clock framework

Woodruff, Richard
2007-08-20T13:18:40Z

One further note is in the 'ideal' model you should never have to
control your I-CLK at all just your F-CLK. I'm sure our hardware people
would be very pleased if the code moved in that direction (me too if it
turned out to all work). They generally dislike the idea of the clock
frame work as they feel it allows duplication of work the hardware can
do if setup properly. Its APIs open up some choices which can nullify
or reduce understanding of hardware capabilities. For OMAP1 there was no
other way. For OMAP2/3 there are some options. I do very much like the
frame work but do understand their points.

Ideally, you set all idles at all levels and all async interrupt wake
and use the PRCM interrupt to clear status at wake up time, then the
system can handle all clocks based on dependency. Iclocks can be
managed automatically. Fclocks should be dynamically controlled by
drivers on a demand basis. This means some activity timers. When this
does work the savings are really massive and dramatic. The catch in it
is that one dependency break from a bad driver (sw or hw) at any of the
multiple levels will stop it from working. Looking at that way rather
than OMAP1 compatibility results in something which looks a bit
different.

Regards,
Richard W.

> Hi Paul,
>
> > Existing OMAP2 code autoidles clocks via pm.c. OMAP clock framework
> > already has some support for enabling autoidle mode via the
allow_idle
> > function; however, this is currently unused. Take advantage of this
> > support by adding autoidle register and bit information for each
> > clock, defining an omap2_clk_allow_idle() function, and adding a
> > framework-wide function, clk_allow_idle_all(), to autoidle all
clocks,
> > intended to be called on init. Remove all but the APLL/DPLL
autoidle
> > bit twiddling from pm.c -- we don't yet have generalized support for
> APLL
> > autoidle. Handling autoidle via the clock framework ensures that we
> only
> > touch clocks that are currently configured.
>
> I thought about doing this back when OMAP1 added this when I was more
> active on OMAP2. However, I dropped it as it didn't have enough
'bang' in
> this form. I think these registers (even in OMAP1) are widely mis-
> understood. This is partially a TRM issue and one of complexity.
>
> Meaning you can set this register on a per-clock basis however they do
> nothing for run time except at L3/L4 domain change time. In the
OMAP-GIT
> code this means at retention time the PRCM has permission to shut off
your
> ICLK assuming your module acknowledges it. If the PM code does this
> manually (enable/disable) then this register has no effect.
>
> It does have a useful run time property in that it is one form to gate
a
> clock stop state assuming you have not forced it. This is one way to
stop
> a cascade clock stop from happening when you are not expecting it. It
> would be a lighter weight way then the mutex which OMAP2-GIT code
uses.
> However, for that to work other code would have to change.
>
> Each IP-Module _does_ have an AUTOIDLE bit in its SYSCONIG space which
> does act as you might expect this bit to. Setting this AUTOIDLE does
save
> significant power. It would be more useful to control that one from
here.
>
> If you hook up a current meter you can toggle all the CM_AUTOIDLES you
> like and nothing will happen. But if you do the same with the module
> autoidle you will see a bit change.
>
> Regards,
> Richard W.