[linux-pm] Re: Runtime PM and device locking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 8 Aug 2005, Woodruff, Richard wrote:

...

Thanks for explaining the terminology.

> Yes, I'm talking about what it takes to do runtime power management of
> shared clocks.  It at times does take a central coordinator to allow a
> clock change.
> 
> Devices can auto idle at times or ask for gating of their local clocks.
> This is the kind of thing which you must be thinking of.   Along with
> idling/gating devices can scale their clocks to save power.

Right, that's what I had in mind.  Centralized clock control is a 
different, more difficult problem -- as you know!

> With scaling the CPU is the device which comes to mind first but need
> not be the only case.  For many embedded systems, scaling the CPU also
> means adjusting device clock notions.  In order to due this you need
> coordination.  
> 
> A device can also request a clock speed change which also forces the
> need for a sub tree recalculation if the request changes a common clock.
> Related drivers may be able to react by adjusting local dividers if
> given a chance.
> 
> > The situation you described involves a new concept: a driver that
> cannot
> > change its power usage without first asking all its clients to
> temporarily
> > suspend operations.  Note that the messages you described are not the
> same
> > kind of "notifications" as I've been talking about, because they go
> down
> > the tree instead of up.
> 
> Yes.  That is true.  I'm presently looking at some clock code, and going
> up and down trees is an issue.  There are few possible use cases from
> devices wanting a change which requires a notification going up which
> cause a change coming back down to other drivers.  
> 
> To do run time frequency scaling of the CPU requires a notification
> structure down to the drivers.  Why not use the same or extended
> structure to propagate clock request from drivers.

At the moment I'm inclined to leave clock control somewhat separate from 
other aspects of runtime PM.  There are other people already working on 
it, as we've seen from recent activity in the mailing list.

Alan Stern


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux