Re: Power management framework for OMAP2

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

> Greetings to all concerned
> 
> I would appreciate your input and opinions about a power management
> framework implementation for OMAP2. Such a framework is on our To-do
> list and we would be happy to see a solution that would be useful to
> all, and also coherent with the whole of NetBSD and its concepts.
> 
> Earlier we made an adaptation of a basic clock framework based on an
> old concept from another OS, and comments from Mr. Matt Thomas lead me
> to believe you may be looking for something more along the lines of
> the ACPI standard, am I correct?
> 
> We have the adapted codes and both the clock configurations and
> methods for their manipulation currently in hand, and I'm sure we
> could develop something we can all agree upon. If you can share your
> opinion and define some parameters to our design, we are ready to
> start working on it


We are circulating first drafts of the power management implementation
design and by definition we're coming up with a dual domain design, the
idle-time and run-time domains. The idle-time domain is responsible for
idle-time clock tree pruning and auxiliary device shutdown and handling
of special circumstances such as overheating and critical power supply
conditions. The run-time domain is the driver<->power management
connection, which governs run-time power management with the driver
being the motivating force. In essence, giving an opportunity to write
good drivers that save power.


System awareness

The idle-time domain requires information about the system state to do
its control decisions, and this component is one logical start of the
control flow which continues in the power management core and results
in commands to drivers. It would be possible to plug prioritized
condition policies here if desired.


Power Management Core

This core component governs the clock tree and provides clock control
services to the drivers as well as management commands to select
devices which are capable of power saving states. It is also possible
to plug prioritized condition policies here if desired.


VFS

A basic concept of a Voltage and Frequency scaling support component
for the PM Core could be implemented as a driver. However, by current
conception the VFS power savings appear not to be overly appealing
compared to the complexity required to operate it. Thus the VFS is
currently just a mention in the design as an optional component.


PM Aware drivers

the run-time domain requires that the drivers naturally support and
additionally are implemented with specific concern of power saving in
mind. The clock tree tracking and pruning of the PM Core in the
idle-time domain ensures that unused devices are deactivated, but
drivers are responsible for run-time clock uptime optimization.



In our investigation of current NetBSD components looks like there
wouldn't be much code to reuse in this context, but if somebody knows
of relevant components that should be planned to be utilized here,
please let us know. This is the nature of the direction we're taking,
and since there haven't been any parameters I'll interpret that there
are no problems with the design either. Please take the time to comment
if this direction is not desirable for future inclusion to the NetBSD
OMAP2 port so we can concentrate on working towards something that is
useful to you.

Best regards, 
Juha Keski-Saari
Teleca Finland