Summary of today's IRC discussion

Summary of today's IRC discussion

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4271 bytes --]

Note: the live IRC log is available (thanks to Bernard!) at
<http://helicon.ucs.uwa.edu.au/~bernard/irc/%23pm.log>.

The session got started after some minor confusion caused by incorrect
time-zone calculations (now all fixed up on the wiki for the future 
sessions).

People agreed that the list of topics I wrote up in
<http://lists.osdl.org/pipermail/linux-pm/2005-March/000633.html> was
good but too extensive to cover over IRC.  Patrick suggested sticking
to a single topic, more or less, for each session.

We started by talking about the internal representation of device power
states.  It was agreed that the representation should be a pointer to
struct, where the contents of the struct are to be determined.  (In
some cases it might just encapsulate pm_message_t.)  There will be a
name field, but other fields are bus- and device-specific.  Should
attributes like FROZEN be included as well?

Information about these states is passed to/from userspace via sysfs.
It can also be passed between drivers, as in a child telling its
parent when it changes state, or a parent asking a child to change
state.  (Although the PM core never asks a device to go from one
suspend state to another without passing through resume, such a
requirement should not be enforced generally.)

A good way of doing state transformations is needed.  The important case
is going from generic system states (Standby, STR, STD) to device states.  
Often ACPI can help provide such a mapping, but many systems don't support
ACPI and sometimes the ACPI mappings are wrong.  There should be a way to
override them from userspace, say at boot time.  Also ACPI only knows
about devices on the motherboard.  But when available (and appropriate!)
it makes a good starting point.

In many situations these mapping can be done at the bus level so
device drivers don't need to worry about it.  There may also be a set
of mappings available for a device to use, like "PCI", "ACPI",
"Custom",...

(Side issue: The list of wakeup devices currently maintained by the
ACPI core is a temporary hack that will go away, replaced by a
property of the real devices in sysfs.  David Brownell will repost an
old patch that exposes this information.)

Mapping for device sub-states, as used in runtime power management, is
harder.  Maybe such sub-states shouldn't be exposed at all.  Sometimes
there are intricate relations among device states and system states
that are platform-specific; it would be easist to leave the complexity
sitting in the driver.

There was considerable disagreement over the matter of vetoing system
sleep transitions.  A driver might want to avoid sleeping if it's busy
doing something that shouldn't be interrupted.  But some situations
(like battery power low) can't be vetoed.  Suggestions included adding
a new system power state for non-vetoable sleeping and multi-stage
suspend messaging (first stage is notification with a chance to
veto).  Multi-stage was tried in the past and didn't work because of
bugs in drivers and immaturity of the model.  We may need to revisit
it in the future.

(Note that even now drivers are allowed to delay a suspend, although
they can't veto it.)

Since system sleeps come from userspace, perhaps questions of vetoable
or forced sleeps should be considered part of the userspace policy.
There's also the question of computer-user interaction: When people
tell their computer to do something, they want it to obey.  But other
people might not care so much, especially if they just told the
computer to do something it shouldn't.  The relations between a
userspace policy manager and the kernel's policy manager (if any!) are
very unclear.

Lastly people decided it was a good idea to have a small list of
targeted systems for PM development.  That way we have a minimum set
of goals for PM -- it has to work on those platforms -- and something to
focus on.  Also we'll have an excuse when someone asks "Why doesn't
this work on platform X?"  Suggested targets included x86 and ppc (both
workstations and laptops), a couple of embedded systems (OMAP ARM and
ppc8xx) with maybe a few odd additions such as MIPS.

It was also agreed that we should document what hardware is supported,
and what states are supported by which drivers.

Alan Stern


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

Re: Summary of today's IRC discussion

[Pavel Machek]

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

Hi!

> Note: the live IRC log is available (thanks to Bernard!) at
> <http://helicon.ucs.uwa.edu.au/~bernard/irc/%23pm.log>.

First, sorry for my more or less non-presence. I had too much to do
and too little time, too much rain and not enough signal.

To nigel: No, I'm not going to do cpu hotplug on my scrap-metal smp
system. It took 2 hours to build ;-).

[I still hope to get that S3/smp support using cpu hotplug in my
mailbox tommorow morning ;-)]

At one point I asked:
21:52:11< pavelm> I was playing with variable scheduling ticks here, hoping to save some power.
21:52:31< pavelm> How big power savings should I expect?
21:52:48< pavelm> What cpu will benefit most?
21:53:04< pavelm> Is there easy way to measure it?
...noone replied. Does anyone know?

>From reviewing the logs... There's big difference between system sleep
state, and cpu sleep state. It seems to me that Arm "deep sleep" is
more cpu sleep state (which may have some implications outside cpu,
but device is still perceived as functional). That's really different
thing from PC-style suspend to RAM (takes 5 seconds to sleep and
wakeup, and device is not usefull while suspended). I agree that for
arm "deep sleep" vetoing etc makes sense.

We should be carefull to separate cpu sleep states from system sleep
states...

jcrouse: Any small machine would certainly be very welcome. I have
sharp zaurus here, but it is a) getting quite old and b) I use it so
much I don't dare hack it.

> A good way of doing state transformations is needed.  The important case
> is going from generic system states (Standby, STR, STD) to device states.  
> Often ACPI can help provide such a mapping, but many systems don't support
> ACPI and sometimes the ACPI mappings are wrong.  There should be a way to
> override them from userspace, say at boot time.  Also ACPI only knows
> about devices on the motherboard.  But when available (and appropriate!)
> it makes a good starting point.
> 
> In many situations these mapping can be done at the bus level so
> device drivers don't need to worry about it.  There may also be a set
> of mappings available for a device to use, like "PCI", "ACPI",
> "Custom",...

I think this is overdoing it. Most devices go to lowest possible state
for suspend-to-RAM; I'm not sure what ACPI has to say about that,
but... Having 

pci_power_t acpi_please_suggest_good_state(pm_message_t *state, struct
pci_dev *me)

...and similar helpers would probably not hurt, but I doubt they'll
get many users.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

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

Re: Summary of today's IRC discussion

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2165 bytes --]


On Thu, 17 Mar 2005, Alan Stern wrote:

> Lastly people decided it was a good idea to have a small list of
> targeted systems for PM development.  That way we have a minimum set
> of goals for PM -- it has to work on those platforms -- and something to
> focus on.  Also we'll have an excuse when someone asks "Why doesn't
> this work on platform X?"  Suggested targets included x86 and ppc (both
> workstations and laptops), a couple of embedded systems (OMAP ARM and
> ppc8xx) with maybe a few odd additions such as MIPS.
>
> It was also agreed that we should document what hardware is supported,
> and what states are supported by which drivers.

Just to clarify exactly what I was suggesting..

I was not trying to suggest that we choose a set of target platforms.
Rather, that we simply identify, document, and focus solely on the
platforms and devices that are available to us collectively.

It is impossible and undesirable to everyone to all possess and develop
for the same hardware, so we will by default have a heterogenuous array of
systems. Simply by being a collection of mobile and embedded systems, we
will cover enough of the common cases to benefit most people once the
model is complete.

We can spend eternities trying to factor in every corner case that we can
think of. And, if we do so, we will make the wrong decision. Look at the
platform and system device code in the driver model. Those are the result
of creative thinking about problems that were only be addressed
vicariously. People kept saying we needed to provide for This and That,
without stepping and writing any code. I took several stabs at it, trying
to do what I thought was right. Now, it kinda works, but everyone hates
it. The lesson: design for what you possess; when it doesn't work for
someone, let them work with you to fix it. If they care enough about it,
and you're open-minded enough, it will get adapted quickly.

Besides, I cannot tell you how annoying hearing pathological examples can
be (like properly representing a swap device over NFS over a serial line
that resides on a PCI bus) when they have an infintismally small real
world applicability. :)


	Pat


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