Generic clock framework considerations

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

Through requirement considerations and analysis of current NetBSD
components, it looks clear that for OMAP2 power management
functionality we need a clock control framework. We have a barebones
implementation running now on our TISDP2420 development platform but
it's completely machine dependent and with a supported understanding of
a more diverse range of platforms that are interested in clock
framework functionality, we could refactor it to provide machine
independent functionality to ease porting of other platforms. For this
purpose it would be greatly appreciated if the persons responsible for
maintenance of ports that are interested in a generic clock framework
would post their view of their platform specific requirements for power
management and clock management.

The current understanding we have of the TISDP2420 specifications is as
follows:
- Power domains. Are not useful is run-time power management since they
have no definite idle-state control, it is managed through individual
clock states
- Clock domains. Are good as a base for interdependency policies while
evaluating root clock state transitions by the status of their children
- Clock tree. A hierarchical division that provides parent-child
grouping and recursive dependency information

So in essence the TISDP2420 would require a framework that controls
individual clock-states and manipulates root clock states based on
defined policies from the states of its children.

Do you have similar knowledge of another platform? Please share it here
and we can do our refactoring with a better overview that includes your
interests.

If someone with better knowledge of the hardware can correct any and
all possible flaws in our view, it would be much appreciated.