Re: [RFC] PowerOP Take 3, sysfs UI core 2/5

[Matthew Locke <matt@nomadgs.com>]

On Jul 26, 2006, at 4:55 PM, Gross, Mark wrote:

>
>
>> -----Original Message-----
>> From: Eugeny S. Mints [mailto:eugeny.mints@gmail.com]
>> Sent: Thursday, July 20, 2006 1:00 PM
>> To: linux-pm@lists.osdl.org
>> Cc: Matthew Locke; toddpoynor@gmail.com; linux@dominikbrodowski.net;
> Gross, Mark;
>> igor.stoppa@nokia.com; amit.kucheria@nokia.com;
> sampsa.fabritius@nokia.com; r-woodruff2@ti.com;
>> Mochel, Patrick
>> Subject: Re: [RFC] PowerOP Take 3, sysfs UI core 2/5
>>
>> Now with patch attached.
>> Sorry.
>>
>> 2006/7/20, Eugeny S. Mints <eugeny.mints@gmail.com>:
>>> A sysfs interface for PowerOP that allows operating points to be
> created
>>> and activated from userspace.
>>>
>>> The platform-specific backend provides the code to read and write
> sysfs
>>> attributes for each power parameter; the core sysfs interface has no
>>> knowledge of the struct powerop_point contents.  This interface could
> be
>>> seen as possible extension of cpufreq sysfs.  It is not
>>> an integral part of PowerOP and is provided in part to facilitate
>>> discussion and experimentation with PowerOP, but could serve as a
> basis
>>> for a basic userspace power policy management stack.
>>>
>>> Operating points are created by writing the name of the operating
> point
>>> to /sys/powerop/new.  This may be a job for configfs.
>>> /sys/powerop/<op>/ will contain an attribute for each power parameter
>>> that may be written to set the associated parameter for the new
>>> operating point.  An operating point may be activated by writing its
>>> name to /sys/powerop/active.  The hardware power parameters currently
>>> set may be read and written via /sys/powerop/hw/, a special operating
>>> point that reads and writes parameter attribute values immediately,
>>> primarily for diagnostic purposes.
>>>
>>> Buried in this interface is also the notion of a registry of "named
>>> operating points", allowing operating points created by some other
>>> interface (such as cpufreq or loading a module with the definitions
> as
>>> suggested previously by David Brownell) to be activated from
> userspace
>>> via /sys/powerop/active.
>>>
>>> Please note that the interface is not hooked up with the rest of the
> code
>>> yet and is provided just for reference/review.
>
> Drivers/powerop/powerop_sysfs.c : includes asm/powerop.h and will not
> compile on i386.
> There are other places where it will not compile for non-omap
> architectures.  The architecture independent code should build for all
> architectures.

That should be fixed before the next rev of patches are sent out.

>
> Now just rambling a bit, while catching up on the email thread some of
> this may be wrong but....
>
> Is it realistic to have the dimensionality of the operating points
> defined at the architecture level?  Why couldn't there be multiple 
> types
> of operating points based on presence of different peripherals?  Having
> the array defined at compile time seems wrong.

An operating point definition is the list of system/board power 
parameters.  Generally this means clocks/busses and voltages.  All 
peripherals are connected to a CPU by a bus and therefore a clock, even 
peripherals external to an SoC.  The list of parameters does not change 
when a USB, PCI hotplug or MMC device is plugged in.  The valid values 
of the those parameters may change but not the list of parameters.  The 
device state and device internal power parameters should be (is) 
handled by its driver.  The driver is responsible for changing a 
devices state and internal power parameters based on activity, user 
space input, or another kernel subsystem.

So the operating point is defined at compile time because the 
definition doesn't change.

> Couldn't the platform
> startup code enumerate all its power control knobs and define the 
> number
> of parameters per operating point, or have one have the dimensions grow
> with platform power drivers, one per control knob?

I think there is too much interdependencies between the various knobs 
to control them separately.


> While we are at it, would it make more sense to define the UI for the
> operating points in some way that exports mins, max, and target values
> for each dimension?
>
> Would it make sense to have the different dimensions broken out into
> separate sysfs entries / attributes?
>
> Would it also make sense to support multiple powerop_driver instances?
> Powerop.c can only register one powerop_driver instance at a time.  
> What
> if I want to break up my power management into multiple powerop_driver
> (power, voltage, clock) domains?  Being stuck defining a large n-tuple
> space of operating points at compile time doesn't work for me.  I want
> to have them at least built up at startup time, and preferably
> associated with some platform power driver loading operation.

Not sure about these points.  Again, I think the different areas are 
too connected to control independently.

Summary:
  - Operating point definition is static because it represents the base 
system (board) physical parameters which are clocks and voltages.
  - Devices are connected to the CPU by clocks/busses and therefore are 
represented in the operating point definition that does not change if a 
device is present or not.
  - Valid operating point values may change if a device is present or 
not.
  - Device state and internal power parameters should be controlled by 
the device driver.

>
> --mgross
>
> PS I'm sorry for using outlook on this email thread  I know I'm going 
> to
> regret it more than I all ready do....
>
>