Re: [RFC] PowerOP Take 3, ARM OMAP1 platform support 3/5

Gross, Mark
2006-07-27T00:03:30Z

>-----Original Message-----
>From: linux-pm-bounces@lists.osdl.org [mailto:linux-pm-bounces@lists.osdl.org] On Behalf Of David
>Brownell
>Sent: Sunday, July 23, 2006 9:25 AM
>To: linux-pm@lists.osdl.org
>Cc: Matthew Locke; Mochel, Patrick; sampsa.fabritius@nokia.com; linux@dominikbrodowski.net
>Subject: Re: [linux-pm] [RFC] PowerOP Take 3, ARM OMAP1 platform support 3/5
>
>On Thursday 20 July 2006 1:01 pm, Eugeny S. Mints wrote:
>> +struct powerop_point {
>> +       unsigned int v;         /* voltage in mV */
>> +       unsigned int dpll;      /* in KHz */
>> +       unsigned int cpu;       /* CPU frequency in KHz */
>> +       unsigned int tc;        /* in KHz */
>> +       unsigned int per;       /* in KHz */
>> +       unsigned int dsp;       /* in KHz */
>> +       unsigned int dspmmu;    /* in KHz */
>> +       unsigned int lcd;       /* in KHz */
>> +};
>
>A few comments:
>
> - This should be part of patch #4; it's not truly separate.
>
> - I take it "v" is CPU voltage rather than some random component?
> Either way, there seems to be an omission here since boards
> could have multiple voltages to care about ...

I think the components be exposed in a stand alone manner in addition to the structure. Also, could we have a driver module per element to expose each one to the system and user. That way you can just load the drivers for the control knobs you care about, and add more for your platform more easily.

>
> - In general, shouldn't an operating point be board-specific, so
> that the parts of the system outside the SOC can be included?
>
> - I'd still rather see operating points be identified by a name
> string of some kind so that the userspace API resembles that
> of /sys/power/state: just write the state name to that file.
>

What would you name an n-tuple of integers? I can't think how this would work.

--mgross

>Still looking at the patches, otherwise.
>

Me too...