Re: Power management framework for OMAP2

[Chris Gilbert <chris%dokein.co.uk@localhost>]

Juha Keski-Saari wrote:
>> 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.
> 

This sounds like cool & quiet and speed step on x86.  I think the speed
is changed from userland by twiddling a sysctl (although some CPUs may
automatically throttle themselves)

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

Have you taken a look at the work on a power management framework (pmf)
that's happening in -current.  It provides generic hooks for drivers to
use, see:
http://netbsd.gw.com/cgi-bin/man-cgi?pmf++NetBSD-current

It's focus is on suspend/resume activity, rather than idle mode. It's
likely to be the most tested system, and the one that will cover all
drivers in the tree.  I believe it can be used to turn off a subtree of
devices, eg all usb devices attached to something.

If you really want to detach device completly (rather than power off)
then drvctl might be what you're looking for:
http://netbsd.gw.com/cgi-bin/man-cgi?drvctl++NetBSD-current

We do have the very simple idea of idle, which is to call a cpu specific
function that puts the chip to sleep (until an interrupt occurs)

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

Obviously we'd like to see any work included in NetBSD :)

Thanks,
Chris