On Friday 23 June 2006 1:36 pm, Adam Belay wrote:
> On Fri, Jun 23, 2006 at 09:26:26AM -0700, David Brownell wrote:
> > On Thursday 22 June 2006 4:31 pm, Benjamin Herrenschmidt wrote:
> > > - cpufreq (this is a design bug with cpufreq with the "core/midlayer"
> > > trying to get in charge instead of the driers and registering a sysdev
> > > which is very wrong).
> >
> > That could stand some elaboration in a separate thread; there are folk
^^^^^^^^^^^^^^^^^^^^
Notice changed $SUBJECT ...
> > working to enhance cpufreq so that it handles other frequency/voltage
> > scaling approaches. I happened to notice that cpufreq isn't even using
> > the driver model very well, too ...
>
> On a related note, let's remember that cpufreq needs a sort of "FREEZE"
> functionality, on some platforms, before transitioning the cpu operating
> point.
Actually I don't think FREEZE is the right model there, especially
considering the cases where other clocks are coupled to the CPU clock
and therby need to be adjusted.
One potential model is that resume() should verify clock settings and
adjust things as needed (e.g. MMC, USART, or SPI dividers), and that
suspend() should be invoked for the devices that need re-clocking.
Linux knows the devices affected by a clk_set_rate(), since clk_get()
takes the device as a parameter.
As an example, on at91 hardware cpufreq can easily change the cpu
clock using /1, /2, and /4 dividers and not change the I/O clocks.
But other frequency changes involve updating PLL settings and then
reclocking at least the peripherals mentioned above.
> Moreover, we need similar stuff for PCI resource rebalancing
> (although this case would be partial tree suspending), a feature that
> will likely become very necessary in the near future.
How about elaborating on what you mean by that?
> It would be nice
> if the suspend model was robust enough to handle these runtime device
> suspend cases as well.
Yes.
- Dave
