Re: Power Management Framework architectural design

["Juha Keski-Saari" <juha.keski-saari%teleca.com@localhost>]

Juha Keski-Saari wrote:

> Joerg Sonnenberger wrote:
> > I never said configuration, just providing the registration
> > hierachical.  mainbus or whatever it is called on $RANDOM_ARCH is
> > already MD, so it can just register the powerdomain or whatever it
> > should be called hooks with PMF and child devices will inherit that.
> > What you are doing in the hooks would be up to you.
> > 
> > Joerg
> 
> All right, I believe I caught your message. I created a thread to
> collect platform specific requirements to see a bigger picture what
> kind of functions different platforms desire for their power
> management. For our case, if it is acceptable to have a clock
> framework with both MI and MD parts outside PMF, we should be all
> covered for power management
> 
> Juha K-S

A few more questions came up while considering the structure based on
the recommendations, and it would be good to have closure on these to
know the challenge before we go searching for a solution

For the situation where every device inherits from OBIO in the OMAP
case, a clock "bus" that extends the OBIO layer could be formed, and
below it all the clocks in a hierarchical tree. Devices would then be
able to inherit from the clock they need. The problem of principle here
is multiple inheritance, is it possible? Because devices are bound to
require more than one clock.

- Use/Enable multiple inheritance so a single device can link to
several clocks in the hierarchy
OR
- Keep rigid clock hierarchy and fragment drivers, so they would have
to implement an interface for each clock they want to use, these
interfaces would inherit single clocks and link together to a single
device

If multiple inheritance is a working concept in NetBSD, there is no
real problem but just to use the method, but if this is not the case,
we only have the second alternative at the moment and it's not looking
very inviting

Juha K-S