Re: Alternative Concept

[David Brownell <david-b@pacbell.net>]

On Sunday 18 March 2007 1:25 pm, Dmitry Krivoschekov wrote:
> 
> For me, there is a point that seems debatable already at the starting stage:
> 
> > The goal of this parameter framework is to expose the resources in  a  
> > way that allows other s/w (governors, policy mangers, etc) to control  
> > the resources while keeping the system operational.  One of the main  
> > requirements in our thinking is that we want this layer to represent  
> > the h/w and not include policy or decision making.  Meaning the 
> > software using the parameter framework would be responsible for  
> > deciding the appropriate value for the parameters.   
> 
> 
> Sometimes it's quite reasonable to make decisions (or policy)
> at the low level, without exposing events to higher layers,

Of course.  Any layer can incorporate a degree of policy.

It's only when that's badly done -- or the problem is so complex
that multiple policies need to be supported -- that you need to
pull out that old "mechanism not policy" chestnut, and support
some kind of policy switching mechanism (governors, userspace
agents, etc) for different application domains.


> e.g. turning a clock off when reference counter gets zero, this is
> what OMAP's clock framework currently does.

There are no choices to be made in that layer; it's no more "policy"
than following the laws of arithmetic is "policy".  Software clock
gating is what the clock framework is defined as doing; there's
nothing OMAP-specific about that.

The interesting bit for OMAP is that clock gating will often be done
in hardware, not just in software.  There are other low-power SOC
designs that do such things, but the ones I'm most aware of are for
microcontrollers (MSP430, picoAVR, etc) that can't run Linux.

- Dave