RE: RE: on-ness

Brown, Len
2006-04-18T18:39:37Z

[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]

(restored linux-pm to cc:)

yes, the concept was to explore a language generic enough
that it could describe either CPUs or any other devices.

no, this wasn't expected to be complete, just a start.
yes, wakeup capability is one thing we we discussed.
note that we may need to differentiate between enabling
the device to wakeup the system, and waking up just
the device itself.

no, if the numbers happen to corrolate to ACPI states,
that is purely lucky for the ACPI maintainer:-)
But honestly, we should "leverage" all we can from ACPI.
My role, of course, it to make sure that the generic
description can accommodate everything ACPI can do.

yes, idle refers to either Cx or Dx states -- it depends
on the device. 0 means operating, non zero means non-operating.

Re: strings.
we breifly debated strings vs numbers.
I'm not confident that there are enough unique strings
available without falling into state0, state1, state2, state3 --
so numbers seemed simpler.
The only issue I see with numbers is that they imply order,
and it may be that some operating points might not have
such a strict order.

appology in advace for the top-post, Intel IT re-installed my
laptop and a lot of things are not "quite right"...

-Len

-----Original Message-----
From: David Brownell [mailto:david-b@pacbell.net]
Sent: Tuesday, April 18, 2006 2:15 PM
To: Brown, Len
Cc: Richard A. Griffiths
Subject: Re: [linux-pm] RE: on-ness

On Monday 17 April 2006 2:43 pm, Brown, Len wrote:
> > Thinking about the discussion of the ON field. How about Limiter?
Then
> > maps to no limit (max power, max freq, whatever) and any
> > other number is
> > some limit of performance/power, similar to what was decided for
Idle.
>
> my scribbles on generic sysfs device directory file names say:

That is, you're talking about parameters related to individual devices?
Or CPUs?

Let's surface more parameters first, before talking about managers!

One more is the wakeup capability; devices may easily have two parameter
sets, one spending a bit of power to deliver wakeup capability.

Another is which <linux/clk.h> clocks are associated with the device.

> state:
> on - running and available
> off - requires a full device initialization to be usable

Also e.g. "bus suspend" causing maybe 2 mA current draw vs normal
usb root port power budgets of 100+ mA ... two modes like that, one
supporting remote wakeup and one not.

> idle: # = "how idle"
> 0 - active, not idle at all eg C0, D0
> 1 - idle. eg C1, D1
> ...
> n - most power saving, highest latency idle state, eg. Cn, Dn

These are ACPI CPU states Cx? Or device states Dx? Such values
should be a string, which need not match acpi conventions...