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

[Woodruff, Richard]

> 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 ---