RE: RE: on-ness

RE: RE: on-ness

[Brown, Len]

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

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[Pavel Machek]

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

Hi!

> (restored linux-pm to cc:)

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

Please, put there translation layer from the begining. Otherwise
people will assme they *are* ACPI states, and great confusion will
begin.

See suspend functions, where half people assumed they are acpi Dx
states, half people thought they are pci Dx states, and half the
people assumed they are system Sx states.


It took quite long to sort out.

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

Second issue is that you might want to "insert" between states.

Lets look at disk. Old disks had:

spinning
spindown

states. You'd name them 0 and 1, eventually apps will learn to use
that. But (some) newer disks have

spinning
slowspin
spindown

if app does echo 1 > state, it will get slowspin instead of spindown
it wanted.

Yes, inventing good names may be tricky in some cases, but in other
cases names are very natural (arm has sleep, deep sleep and big sleep,
iirc).... And we can always fall back to state0..state5.

						Pavel
-- 
Thanks, Sharp!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[David Brownell]

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

On Thursday 20 April 2006 6:25 am, Pavel Machek wrote:
> > 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.
> 
> Please, put there translation layer from the begining. Otherwise
> people will assme they *are* ACPI states, and great confusion will
> begin.

Better yet, don't use numbers, since that's the root cause of the
problem.  Typed enums are OK.  (But of course, ACPI-specific enums
should appear *only* inside the ACPI code...)


> See suspend functions, where half people assumed they are acpi Dx
> states, half people thought they are pci Dx states, and half the
> people assumed they are system Sx states.

When I did the research on this a while back, it was self-evident
that the original 2.4 suspend calls expected system Sx states.

Otherwise the drivers which looked at the parameter and used it
when selecting a target device state would have made no sense.
(Likewise, all those drivers had to **remove functionality** as
part of the pm_message_t search'n'destroy mission...)

There was mild confusion about them being PCI_Dx states, mostly
because the simplest mostly-works mapping of ACPI_Sx states to
PCI_Dx states was the identity mapping.  And especially for PM,
many driver writers are lazy.

I don't ever recall seeing drivers assume the parameter was an
ACPI_Dx state.  That would have been deeply wrong, since most
hardware will never run ACPI.  What I did see was that the first
incarnation of the 2.6 power management framework changed the
state numbers in a way that broke most of the drivers relying on
that identity mapping ... and I also saw disagreement between that
framework and the swsusp code about what numbers to pass.

All that's resolved now, but with a net loss of functionality.
And yes, the root cause was the initial use of (untyped) numbers,
where a translation layer would have reduced trouble.  But not
using numbers could have avoided the problems entirely!
 

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

This is called a "lack of imagination".  ;)

Most SOC specs I look at don't use numbers to describe either
device, CPU, or system states ...  many don't even distinguish
CPU sleep/idle states from system states.  They use a variety
of names to describe various aspects of the hardware states, and
often the issues are more like "which clocks are available".
(Or, for system states, "clock domains" ... e.g. "everything
derived from oscillator X" or tied to a given PLL.)


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

In my observation, "strict order" would be the exception not
the rule.  There are often three or four orthogonal factors,
and they don't naturally fit any two-dimensional linear order.


> Second issue is that you might want to "insert" between states.
> ...

Of course, "between" implies some strict/linear order...


> Yes, inventing good names may be tricky in some cases, but in other
> cases names are very natural (arm has sleep, deep sleep and big sleep,
> iirc).... And we can always fall back to state0..state5.

Well, OMAP is one implementation that uses ARM, and it certainly has
"deep sleep" and "big sleep".  But other ARM based SOCs provide very
different power abstractions (consider "slow clock mode", "idle",
"frozen", "standby", "stop", "sleep") and may use the same names to
indicate different things.  System state names are system specific.

If ACPI wants to use names like "ACPI_S0".."ACPI_S5", that's fine;
but Linux should not inflict such an approach on systems that don't
use ACPI.  Developers might find it handy to contrast one SOC's
"deep sleep" to "ACPI_S3" (or to "deep sleep" on another SOC), but
it won't be an exact match; square peg, round hole.

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[Dominik Brodowski]

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

On Fri, Apr 21, 2006 at 08:27:32AM -0700, David Brownell wrote:
> > > 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.
> 
> In my observation, "strict order" would be the exception not
> the rule.  There are often three or four orthogonal factors,
> and they don't naturally fit any two-dimensional linear order.

We need to distinguish two aspects here -- the "whole system states", which
in fact create a multi-dimensional problem, and one specific attribute of
one specific device. The performance level of one specific networking device,
for example. Or its sleep state. Or, if you can describe sub-aspects of a
networking device, the performance level or the sleep state of that
sub-device. So each strict-order parameter has its own file (that's why
the RFC mentioned three files for CPUs in the ACPI-model, for performance,
idle and throttling; different CPUs in different, especially embedded
surroundings may require additional files).

> > Yes, inventing good names may be tricky in some cases, but in other
> > cases names are very natural (arm has sleep, deep sleep and big sleep,
> > iirc).... And we can always fall back to state0..state5.
> 
> Well, OMAP is one implementation that uses ARM, and it certainly has
> "deep sleep" and "big sleep".  But other ARM based SOCs provide very
> different power abstractions (consider "slow clock mode", "idle",
> "frozen", "standby", "stop", "sleep") and may use the same names to
> indicate different things.  System state names are system specific.

Well, the big problem with names and anything "system specific" is that it
makes _abstractions_ harder. It makes userspace's life harder, as it needs
to know what "idle" means on a specific system, instead.

> If ACPI wants to use names like "ACPI_S0".."ACPI_S5", that's fine;
> but Linux should not inflict such an approach on systems that don't
> use ACPI.  Developers might find it handy to contrast one SOC's
> "deep sleep" to "ACPI_S3" (or to "deep sleep" on another SOC), but
> it won't be an exact match; square peg, round hole.

Here you're talking about "system states" instead of "device states" again.

	Dominik

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[David Brownell]

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

On Friday 21 April 2006 8:40 am, Dominik Brodowski wrote:
> On Fri, Apr 21, 2006 at 08:27:32AM -0700, David Brownell wrote:
> > > > 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.
> > 
> > In my observation, "strict order" would be the exception not
> > the rule.  There are often three or four orthogonal factors,
> > and they don't naturally fit any two-dimensional linear order.
> 
> We need to distinguish two aspects here -- the "whole system states", which
> in fact create a multi-dimensional problem, and one specific attribute of
> one specific device.

Individual device operating points are multi-dimensional too.  Controllers
are just mini-systems after all, and some of the device attributes will
be constrained by system attributes ...


> The performance level of one specific networking device, 
> for example. Or its sleep state.

... e.g. if it's suspended during system-wide "slow clock mode" it might
be pretty well unusable, except maybe for PHY based wakeup events; but
if it's suspended during a more functional system state, enough clocks
may be available for wake-on-LAN may behave.

And then there can be PM-aware drivers that keep idle devices in low
power states whenever that's possible (activating on TX or from
wake-on-LAN RX) ... so there might be no hardware-level differences
between states before and after suspend(), other than that suspend()
always shutting down the network stack state (TX queues etc) too.


> Or, if you can describe sub-aspects of a 
> networking device, the performance level or the sleep state of that
> sub-device. So each strict-order parameter has its own file (that's why
> the RFC mentioned three files for CPUs in the ACPI-model, for performance,
> idle and throttling; different CPUs in different, especially embedded
> surroundings may require additional files).

I seem to have missed some RFC... the note on "on-ness" I responded to
had some musings, but no evident proposal.  (It wasn't even clear
what it was describing...)  The embedded CPUs I've worked with wouldn't
have much need for "idle" and "throttling" controls, either.


> > > Yes, inventing good names may be tricky in some cases, but in other
> > > cases names are very natural (arm has sleep, deep sleep and big sleep,
> > > iirc).... And we can always fall back to state0..state5.
> > 
> > Well, OMAP is one implementation that uses ARM, and it certainly has
> > "deep sleep" and "big sleep".  But other ARM based SOCs provide very
> > different power abstractions (consider "slow clock mode", "idle",
> > "frozen", "standby", "stop", "sleep") and may use the same names to
> > indicate different things.  System state names are system specific.
> 
> Well, the big problem with names and anything "system specific" is that it
> makes _abstractions_ harder. It makes userspace's life harder, as it needs
> to know what "idle" means on a specific system, instead.

If by "userspace" we can mean just "what writes the /sys/power/state file",
it's straightforward for a given system to provide mappings between some
common tokens ("standby", "mem", etc) to a system-specific meaning.

Of course, those tokens don't necessarily expose all the meanings that
are wanted for managing power on that system.  But they're probably a
reasonable start.  The code behind a system's pm_ops will package a lot
of decisions about the operating points associated with "standby" etc,
and it's a bit of work to make sure any given operating point is both
sensible and functional.


> > If ACPI wants to use names like "ACPI_S0".."ACPI_S5", that's fine;
> > but Linux should not inflict such an approach on systems that don't
> > use ACPI.  Developers might find it handy to contrast one SOC's
> > "deep sleep" to "ACPI_S3" (or to "deep sleep" on another SOC), but
> > it won't be an exact match; square peg, round hole.
> 
> Here you're talking about "system states" instead of "device states" again.

The same points hold for "ACPI_D0"..."ACPI_D3" states.  If a device may need
up to four clocks for its fully operational state, but doesn't need all of
them for more typical reduced-function (and reduced-power) states, there's
not necesssarily going to be a natural linear/"strict" sequencing of those
states.  "More power for task one and less power to task two" might be just
as much power as "more-for-two/less-for-one" ... and from the userspace
perspective, they could act just like "full power for both" for drivers
that automatically handle the transitions.

And those might all map to ACPI_D0 states ... there's still the same peg/hole
problem, coming from thinking that details of the ACPI model should apply.

(That is, the ACPI model makes general sense when talking about different
device and system states  but not when trying to define details -- which
should be system-specific! -- about what those states should be/model, and
how they should behave.)

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[Dominik Brodowski]

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

On Fri, Apr 21, 2006 at 10:03:40AM -0700, David Brownell wrote:
> > We need to distinguish two aspects here -- the "whole system states", which
> > in fact create a multi-dimensional problem, and one specific attribute of
> > one specific device.
> 
> Individual device operating points are multi-dimensional too.  Controllers
> are just mini-systems after all, and some of the device attributes will
> be constrained by system attributes ...

Exactly, that is what I was referring to as well :)

> > The performance level of one specific networking device, 
> > for example. Or its sleep state.
> 
> ... e.g. if it's suspended during system-wide "slow clock mode" it might
> be pretty well unusable, except maybe for PHY based wakeup events; but
> if it's suspended during a more functional system state, enough clocks
> may be available for wake-on-LAN may behave.

Sure. But again you're mixing system state and device state. Of course the
former may constrain the latter, and vice versa.

> > Or, if you can describe sub-aspects of a 
> > networking device, the performance level or the sleep state of that
> > sub-device. So each strict-order parameter has its own file (that's why
> > the RFC mentioned three files for CPUs in the ACPI-model, for performance,
> > idle and throttling; different CPUs in different, especially embedded
> > surroundings may require additional files).
> 
> I seem to have missed some RFC... the note on "on-ness" I responded to
> had some musings, but no evident proposal.

Mis-naming on my part - I was just referring to the "on-ness" proposal too.

> The embedded CPUs I've worked with wouldn't
> have much need for "idle" and "throttling" controls, either.

Other embedded CPUs do, though... and we're trying to abstract things here,
right?

> > Well, the big problem with names and anything "system specific" is that it
> > makes _abstractions_ harder. It makes userspace's life harder, as it needs
> > to know what "idle" means on a specific system, instead.
> 
> If by "userspace" we can mean just "what writes the /sys/power/state file",
> it's straightforward for a given system to provide mappings between some
> common tokens ("standby", "mem", etc) to a system-specific meaning.

Uh. Not /sys/power/state. But /sys/devices/...../power/{[a],[b],[c]} where
[a], [b] and [c] need sensible names.

> Of course, those tokens don't necessarily expose all the meanings that
> are wanted for managing power on that system.  But they're probably a
> reasonable start.  The code behind a system's pm_ops will package a lot
> of decisions about the operating points associated with "standby" etc,
> and it's a bit of work to make sure any given operating point is both
> sensible and functional.

The "on-ness" thingy was about device power sates, AFAIK, but not about
/sys/power/state. So not about what some call "operating points" of the
system, but only about specific settings of a "device" or "part of the
system".

> The same points hold for "ACPI_D0"..."ACPI_D3" states.  If a device may need
> up to four clocks for its fully operational state, but doesn't need all of
> them for more typical reduced-function (and reduced-power) states, there's
> not necesssarily going to be a natural linear/"strict" sequencing of those
> states.  "More power for task one and less power to task two" might be just
> as much power as "more-for-two/less-for-one" ... and from the userspace
> perspective, they could act just like "full power for both" for drivers
> that automatically handle the transitions.

Yes. That's why there is talk about having different files describing a
device, and not just one. So you might have four files describing these four
clocks... and yet another file for describing the non-working states.

	Dominik

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[David Brownell]

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

On Friday 21 April 2006 10:12 am, Dominik Brodowski wrote:
> On Fri, Apr 21, 2006 at 10:03:40AM -0700, David Brownell wrote:
> > > We need to distinguish two aspects here -- the "whole system states", which
> > > in fact create a multi-dimensional problem, and one specific attribute of
> > > one specific device.
> > 
> > Individual device operating points are multi-dimensional too.  Controllers
> > are just mini-systems after all, and some of the device attributes will
> > be constrained by system attributes ...
> 
> Exactly, that is what I was referring to as well :)

Good, it helps when folk are on the same page!


> > The embedded CPUs I've worked with wouldn't
> > have much need for "idle" and "throttling" controls, either.
> 
> Other embedded CPUs do, though... and we're trying to abstract things here,
> right?

Not exactly.  I'd hope we're solving problems.  Generalization makes
solutions work in multiple contexts, and abstraction helps generalization,
but IMO the goal is problem solving.

I've certainly seen cases where abstracting creates/causes problems, rather
than solving them.  And creating abstractions that don't make sense on the
hardware is a good start on such confusion...


> > > Well, the big problem with names and anything "system specific" is that it
> > > makes _abstractions_ harder. It makes userspace's life harder, as it needs
> > > to know what "idle" means on a specific system, instead.
> > 
> > If by "userspace" we can mean just "what writes the /sys/power/state file",
> > it's straightforward for a given system to provide mappings between some
> > common tokens ("standby", "mem", etc) to a system-specific meaning.
> 
> Uh. Not /sys/power/state. But /sys/devices/...../power/{[a],[b],[c]} where
> [a], [b] and [c] need sensible names.

Well, "on" could have one defined meaning.  Maybe it's the only option
available, until drivers add intelligence.  I don't see any problem
with the other names being system-specific, since it's rather unlikely
that a PCI_D3hot state will ever appear on most embedded ARM boxes.
And if any userspace code tries to set power states, it had darn well
better understand exactly what's going on.


> > Of course, those tokens don't necessarily expose all the meanings that
> > are wanted for managing power on that system.  But they're probably a
> > reasonable start.  The code behind a system's pm_ops will package a lot
> > of decisions about the operating points associated with "standby" etc,
> > and it's a bit of work to make sure any given operating point is both
> > sensible and functional.
> 
> The "on-ness" thingy was about device power sates, AFAIK, but not about
> /sys/power/state. So not about what some call "operating points" of the
> system, but only about specific settings of a "device" or "part of the
> system".

Hence my confusion in reading the original note ... Len said it applied
to both, but I found a bias towards CPU power states (rather than device
or system states).


> > The same points hold for "ACPI_D0"..."ACPI_D3" states.  If a device may need
> > up to four clocks for its fully operational state, but doesn't need all of
> > them for more typical reduced-function (and reduced-power) states, there's
> > not necesssarily going to be a natural linear/"strict" sequencing of those
> > states.  "More power for task one and less power to task two" might be just
> > as much power as "more-for-two/less-for-one" ... and from the userspace
> > perspective, they could act just like "full power for both" for drivers
> > that automatically handle the transitions.
> 
> Yes. That's why there is talk about having different files describing a
> device, and not just one. So you might have four files describing these four
> clocks... and yet another file for describing the non-working states.

That seems too complicated to me.  When debugging, I want to visualize the
entire tree ... so I'd want a /sys/kernel/debug/clocktree file, with lots
of system-specific information.  (Which gate bits are set/cleared?  What
speeds? etc.)  Or else I just want to know which state the driver is in,
like "mostly one".  Some of that is taste, but also don't forget that each
attribute in sysfs has a cost.

- Dave

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[Dominik Brodowski]

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

On Fri, Apr 21, 2006 at 11:30:05AM -0700, David Brownell wrote:
> > > > Well, the big problem with names and anything "system specific" is that it
> > > > makes _abstractions_ harder. It makes userspace's life harder, as it needs
> > > > to know what "idle" means on a specific system, instead.
> > > 
> > > If by "userspace" we can mean just "what writes the /sys/power/state file",
> > > it's straightforward for a given system to provide mappings between some
> > > common tokens ("standby", "mem", etc) to a system-specific meaning.
> > 
> > Uh. Not /sys/power/state. But /sys/devices/...../power/{[a],[b],[c]} where
> > [a], [b] and [c] need sensible names.
> 
> Well, "on" could have one defined meaning.  Maybe it's the only option
> available, until drivers add intelligence.  I don't see any problem
> with the other names being system-specific, since it's rather unlikely
> that a PCI_D3hot state will ever appear on most embedded ARM boxes.
> And if any userspace code tries to set power states, it had darn well
> better understand exactly what's going on.

Yes. However if a network managing userspace code wants to set the power
conusmption of a WLAN device to the lowest possible setting, it shouldn't
need a configuration file specific for each platform.

> > Yes. That's why there is talk about having different files describing a
> > device, and not just one. So you might have four files describing these four
> > clocks... and yet another file for describing the non-working states.
> 
> That seems too complicated to me.  When debugging, I want to visualize the
> entire tree ... so I'd want a /sys/kernel/debug/clocktree file, with lots
> of system-specific information.  (Which gate bits are set/cleared?  What
> speeds? etc.)  Or else I just want to know which state the driver is in,
> like "mostly one".  Some of that is taste, but also don't forget that each
> attribute in sysfs has a cost.

Uh, there's a rule "one-value-per-file" for sysfs. Arrays might be OK in
certain cases, but lots of system-specific information in one file? No way,
IMHO.

Thanks,
	Dominik

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[David Brownell]

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


> > Well, "on" could have one defined meaning.  Maybe it's the only option
> > available, until drivers add intelligence.  I don't see any problem
> > with the other names being system-specific, since it's rather unlikely
> > that a PCI_D3hot state will ever appear on most embedded ARM boxes.
> > And if any userspace code tries to set power states, it had darn well
> > better understand exactly what's going on.
> 
> Yes. However if a network managing userspace code wants to set the power
> conusmption of a WLAN device to the lowest possible setting, it shouldn't
> need a configuration file specific for each platform.

The current wireless extensions have power management calls, and I'd
expect that whatever replaces them would do so as well.  Which brings
out a point I've made before:  userspace power management should not as
a rule be driven through /sys/devices/... files, but instead as part
of the normal API to the devices.  That's the best way to ensure that
the operations fit into the devices' usage models, rather than as an
ill-fitting frankenstein bolt-on.  ;)


> > That seems too complicated to me.  When debugging, I want to visualize the
> > entire tree ... so I'd want a /sys/kernel/debug/clocktree file, with lots
> > of system-specific information.  (Which gate bits are set/cleared?  What
> > speeds? etc.)  Or else I just want to know which state the driver is in,
> > like "mostly one".  Some of that is taste, but also don't forget that each
> > attribute in sysfs has a cost.
> 
> Uh, there's a rule "one-value-per-file" for sysfs. Arrays might be OK in
> certain cases, but lots of system-specific information in one file? No way,
> IMHO.

Remember that sysfs != debugfs, and /sys/kernel/debug is debugfs.  Debugfs
explicitly allows seq_printf() and friends.   (And for that matter, binary
data in sysfs is more than one-value-per-file ... there are plenty of cases
where that "rule" doesn't need to be obeyed.)

- Dave




[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

[OT] debugfs and sysfs [Was: Re: RE: on-ness]

[Dominik Brodowski]

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

On Fri, Apr 21, 2006 at 12:00:45PM -0700, David Brownell wrote:
> > Uh, there's a rule "one-value-per-file" for sysfs. Arrays might be OK in
> > certain cases, but lots of system-specific information in one file? No way,
> > IMHO.
> 
> Remember that sysfs != debugfs, and /sys/kernel/debug is debugfs.

Sorry, missed that bit. Editing my fstab right now :)

>  (And for that matter, binary
> data in sysfs is more than one-value-per-file ... there are plenty of cases
> where that "rule" doesn't need to be obeyed.)

Binary data is special, indeed, but needs to be rare -- and I sincerely
doubt there are "plenty of cases" for sysfs where this rule doesn't need to
be obeyed, but that would be OT now...

Thanks,
	Dominik


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[Pavel Machek]

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

Hi!
> > > > > Well, the big problem with names and anything "system specific" is that it
> > > > > makes _abstractions_ harder. It makes userspace's life harder, as it needs
> > > > > to know what "idle" means on a specific system, instead.
> > > > 
> > > > If by "userspace" we can mean just "what writes the /sys/power/state file",
> > > > it's straightforward for a given system to provide mappings between some
> > > > common tokens ("standby", "mem", etc) to a system-specific meaning.
> > > 
> > > Uh. Not /sys/power/state. But /sys/devices/...../power/{[a],[b],[c]} where
> > > [a], [b] and [c] need sensible names.
> > 
> > Well, "on" could have one defined meaning.  Maybe it's the only option
> > available, until drivers add intelligence.  I don't see any problem
> > with the other names being system-specific, since it's rather unlikely
> > that a PCI_D3hot state will ever appear on most embedded ARM boxes.
> > And if any userspace code tries to set power states, it had darn well
> > better understand exactly what's going on.
> 
> Yes. However if a network managing userspace code wants to set the power
> conusmption of a WLAN device to the lowest possible setting, it shouldn't
> need a configuration file specific for each platform.

I'd say that "on" and "off" are well defined.

For certain classes (like ethernet), other states may be common
between platforms, too, like "off-with-WOL".
									Pavel
-- 
Thanks for all the (sleeping) penguins.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[David Brownell]

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


> > > > Uh. Not /sys/power/state. But /sys/devices/...../power/{[a],[b],[c]} where
> > > > [a], [b] and [c] need sensible names.
> > > 
> > > Well, "on" could have one defined meaning.  Maybe it's the only option
> > > available, until drivers add intelligence.  I don't see any problem
> > > with the other names being system-specific, since it's rather unlikely
> > > that a PCI_D3hot state will ever appear on most embedded ARM boxes.
> > > And if any userspace code tries to set power states, it had darn well
> > > better understand exactly what's going on.
> > 
> > Yes. However if a network managing userspace code wants to set the power
> > conusmption of a WLAN device to the lowest possible setting, it shouldn't
> > need a configuration file specific for each platform.
> 
> I'd say that "on" and "off" are well defined.

Are they?  Does "off" imply the device will have been reset the next
time it goes to "on"?  If not, there would seem to be two "off" states.
Or maybe more ... PCI_D0 is probably "on", but all of the other PCI
device states seem to be variants of "off", not of "on".

And for that matter, "on" doesn't seem to me to imply anything more
than "full functionality from external POV".  That doesn't necessarily
imply "full power-on", and in fact it'd be better if it were using the
lowest power state(s) available.  That state might be compatible with
certain system sleep states, or not, depending on the device's workload.

Is either "on" or "off" a suspend state?  Why, or why not?  :)


> For certain classes (like ethernet), other states may be common
> between platforms, too, like "off-with-WOL".

Actually the wakeup characteristics are orthogonal, there are per-device
bits controlling whether a device can and should do the wakeup.  We don't
for example treat "PCI_D3hot with wakeup" as a distinct state.

- Dave



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[Pavel Machek]

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

On Po 24-04-06 14:04:40, David Brownell wrote:
> 
> > > > > Uh. Not /sys/power/state. But /sys/devices/...../power/{[a],[b],[c]} where
> > > > > [a], [b] and [c] need sensible names.
> > > > 
> > > > Well, "on" could have one defined meaning.  Maybe it's the only option
> > > > available, until drivers add intelligence.  I don't see any problem
> > > > with the other names being system-specific, since it's rather unlikely
> > > > that a PCI_D3hot state will ever appear on most embedded ARM boxes.
> > > > And if any userspace code tries to set power states, it had darn well
> > > > better understand exactly what's going on.
> > > 
> > > Yes. However if a network managing userspace code wants to set the power
> > > conusmption of a WLAN device to the lowest possible setting, it shouldn't
> > > need a configuration file specific for each platform.
> > 
> > I'd say that "on" and "off" are well defined.
> 
> Are they?  Does "off" imply the device will have been reset the next
> time it goes to "on"?  If not, there would seem to be two "off" states.
> Or maybe more ... PCI_D0 is probably "on", but all of the other PCI
> device states seem to be variants of "off", not of "on".

I'd say "off" is as low as possible, perhaps including device reset.

> And for that matter, "on" doesn't seem to me to imply anything more
> than "full functionality from external POV".  That doesn't necessarily
> imply "full power-on", and in fact it'd be better if it were using the
> lowest power state(s) available.  That state might be compatible with
> certain system sleep states, or not, depending on the device's
> workload.

Agreed.

> > For certain classes (like ethernet), other states may be common
> > between platforms, too, like "off-with-WOL".
> 
> Actually the wakeup characteristics are orthogonal, there are per-device
> bits controlling whether a device can and should do the wakeup.  We don't
> for example treat "PCI_D3hot with wakeup" as a distinct state.

Ok, "off-with-WOL" was example. Hopefully there's better example. 
								Pavel
-- 
Thanks for all the (sleeping) penguins.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[David Brownell]

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


> Ok, "off-with-WOL" was example. Hopefully there's better example. 

Sure.  That's part of why I asked about "off", since it's easy to
have several states that could be described that way ... "reset",
"powerdown", and "unclocked" for starters ("on" plus three); or
for PCI, states other than PCI_D0.  Multiple "on" states could
be identified on some devices.

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: RE: on-ness

[David Brownell]

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

On Friday 21 April 2006 8:27 am, David Brownell wrote:

> 	  And especially for PM, many driver writers are lazy.

Let me update that.  The issue is less that the driver writers
are lazy, and more that the system PM infrastructure tends to not
work well on PCs, given issues with BIOS/ACPI/... and the Linux
code that talks to it.

In my own case, I don't even own a PC any more where Linux PM will
properly enter and exit (!!) true power-managed states like "standby"
or "suspend-to-RAM".  So there is very little point in putting effort
into driver PM test/debug, beyond the basic test-through-sysfs stuff
(which may not suffice to shake loose bugs in STR paths etc).

On those rare platforms where Linux system infrastructure handles
power sanely -- including letting drivers get information about
the target system state, so suspend() can be smart enough -- the
only real issue with PM is testing.  And that's no harder than any
other thing driver writers do; it can often be easier, in fact.

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]