RE: [linux-pm] [PATCH] PowerOP, PowerOP Core, 1/2

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

 

> I've been hoping somebody would send a good description of exactly
what
> they mean by "power domain" or "voltage domain", so we could talk
about
> it...
> 
> scott

Here are a couple early mails which illustrate it a bit (sorry if they
mess up any ones mail reader).  I try an place a device inside of some
of the abstractions.

Regards,
Richard W.
--- Begin Message --- 
> > We want to
> > support multiple parents, and the notion of dependencies and
> > constraints. Is a core capability that is needed to accommodate the
> > hierarchical and overlapping areas of influence for clock and
voltage
> > domains.
> 
> It supports reparenting, which is how I read "multiple parents".
> If that's not what you mean by "multiple parents", please give an
> example of what you mean.  As a rule, once a base clock is generated
> (say, by a PLL) it gets gated into children (and maybe subdivided).
> 
> Dependencies of the parent/child type are explicit, while any others
> (as well as constraints, if any) are platform-specific.  And right
> now there's no generic code that needs to know about **either** ...

I need to do a little catch up reading...  I'm not sure this bit is
complete on target, but...

As far as clocks go a functional module can have multiple independent
clocks required for operation.  Say for MMC on OMAP2, the DPLL derived
clock might supply the interface clock, a fixed APLL might provide the
functional clock, and a 32KHz clock might provide denounce.  All clocks
are necessary for proper operation.  And in the case of OMAP2 all 3 are
controllable at the module level.

In a more general sense for a module's functional operation there may be
many dependencies.  This kind of thing goes beyond just clocks.  This
can be inter-driver, LCD needs I2C to turn on a backlight.

If you look at any block of functionality you create a 'driver' for
there can be a lot of external dependencies.  How to best express these
dependencies is where things get unclear.  Currently things like sysfs
and the clk_api handle part of them.  They are not complete.  

It all gets less and less clear as you layer on more intra-soc-chip
levels.  A chip has multiple voltage domains (VD), within each VD there
are several power domains (PD), across several of the PDs (or fully
within a PD) there are multiple clock domains (CD).  Each domain level
has a number of sub levels with certain functionality states.  Finally
you drop the end module function say MMC into this.  Software writes a
single end driver for this which is likely part of some subsystem stack.
This functional block (say MMC) will be part of a VD, PD, multiple CD's
(each domain has multiple levels of operation).  To achieve power
management at the end module you get somewhat simple controls
(clk_enable), to achieve domain power controls, you must act on entire
groups with-in each domain type.  Domains are contained with-in domains
(VD contains PD) so in order to make a VD change all internal PD need to
be at a certain state, and for this to happen all CD in a PD need to be
in at a certain state.  For this to happen end functions (MMC) must have
each managed their end clocks and idles properly.  

If you handle each layer from the bottom up, you can achieve massive
power savings.  There are many explicit relationships in this picture
which need to be expressed.  You can't look at devices individually and
get a domain state, you must look at them together.

OMAP1 which you are very familiar with does not provide this type of
domain partitioning nor the intermediate states (and control of each)
with in each domain.  You get much more of the whole chip in sleep
states, but not all the partial states which are useable during active
mode.

Regards,
Richard W.

--- End Message ---
--- Begin Message --- 
On Sunday 28 May 2006 7:55 am, Woodruff, Richard wrote:

> I need to do a little catch up reading...  I'm not sure this bit is
> complete on target, but...

In terms of explaining clock, power, and voltage domains I think it's a
good explanation, likely worth putting into the framework writeup.  The
concepts apply both within chips and across larger systems (like boards),
but they're not always apparent to folks who don't build computers that
run for a long time on itty bitty batteries.  ;)

Plus it didn't disagree with that point I was making:  the clock API has
no major issues handling some of the most complex real-world clock trees
that Linux deals with today, except the missing clk_must_disable() call.


> As far as clocks go a functional module can have multiple independent
> clocks required for operation.  Say for MMC on OMAP2, the DPLL derived
> clock might supply the interface clock, a fixed APLL might provide the
> functional clock, and a 32KHz clock might provide denounce.  All clocks
> are necessary for proper operation.  And in the case of OMAP2 all 3 are
> controllable at the module level.

And I'm sure Intel and Freescale can come up with similar examples using
their own most power-efficient chips:  devices that use multiple clock
domains, each clock having a single parent.


> In a more general sense for a module's functional operation there may be
> many dependencies.  This kind of thing goes beyond just clocks.  This
> can be inter-driver, LCD needs I2C to turn on a backlight.
> 
> If you look at any block of functionality you create a 'driver' for
> there can be a lot of external dependencies.  How to best express these
> dependencies is where things get unclear.  Currently things like sysfs
> and the clk_api handle part of them.  They are not complete.  

Well, sysfs is just a way to present kernel data structures, emphasis
currently being on device and driver related information.  Using that
kobject framework also helps solve some memory management nightmares.

One example of something that's missing would be an entity explicitly
representing a power or voltage domain.  While "struct clk" exposes
clock (sub)domains so drivers can work with them, and associates them
with device model tree nodes (which tend to reflect bus hierarchies not
power or clock hierarchies...) the corresponding notions for switching
power domains on/off/higher/lower are platform-specific rarities.
Any driver needing to use one adds lots of platform-specific code...
which is contrary to the goal of maintainability.


> It all gets less and less clear as you layer on more intra-soc-chip
> levels.  A chip has multiple voltage domains (VD), within each VD there
> are several power domains (PD), across several of the PDs (or fully
> within a PD) there are multiple clock domains (CD).  Each domain level
> has a number of sub levels with certain functionality states.  Finally
> you drop the end module function say MMC into this.  Software writes a
> single end driver for this which is likely part of some subsystem stack.
> This functional block (say MMC) will be part of a VD, PD, multiple CD's
> (each domain has multiple levels of operation).  To achieve power
> management at the end module you get somewhat simple controls
> (clk_enable), to achieve domain power controls, you must act on entire
> groups with-in each domain type.  Domains are contained with-in domains
> (VD contains PD) so in order to make a VD change all internal PD need to
> be at a certain state, and for this to happen all CD in a PD need to be
> in at a certain state.  For this to happen end functions (MMC) must have
> each managed their end clocks and idles properly.  

Most of that also applies at the board integration level.  MMC is a good
example to build on here, because "supply 1.8V to slot 2" is likely to
have a variety of board-specific implementations, and a given MMC card
might well need a voltage that is not currently available.


> If you handle each layer from the bottom up, you can achieve massive
> power savings.  There are many explicit relationships in this picture
> which need to be expressed.  You can't look at devices individually and
> get a domain state, you must look at them together.

Does "need to be expressed" need to be much more than "here's the
API that drivers use"?  That is, what's the point of expressing
that stuff?  It's easy to understand "writing power-aware drivers".
Also "monitoring power-aware systems".  Neither of those goals would
seem to need much in terms of infrastructure, beyond adopting some
lightweight APIs, analagous to the current clock API.


> OMAP1 which you are very familiar with does not provide this type of
> domain partitioning nor the intermediate states (and control of each)
> with in each domain.  You get much more of the whole chip in sleep
> states, but not all the partial states which are useable during active
> mode.

So who defines the states a given Linux system will use ... in terms
of the scope this new "framework" will address?

SOC/chip vendor docs more or less define what the SOC is expected to handle. 
Board designers add to that, including constraints that reduce scope, as
does that platform's Linux support.  The application software layer(s) do
the same.  And most end users won't care about many of the details.

- Dave

--- End Message ---
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux