RE: PCI power state mapping

RE: PCI power state mapping

[Li, Shaohua]

Hi,
I agree with what you said. Currently most drivers will directly send
'PM_*" state to 'pci_set_power_state', which cause many drivers can't
suspend. I found my two laptops, Toshiba Satellite M20 and Thinkpad T40,
EHCI can't suspend and the reason is exactly they only support D3 state
but 'PM_SUSPEND_MEM' equals to 2.

I suggest that 'pci_set_power_state' should be called in
'pci_device_suspend', so even a device has no driver, it gets a chance
to sleep. I have a sample patch for it actually, but it still uses wrong
D-state number ('PM_*').
 
For determining D-state of a device in sleep state, bind guess is not a
good idea. Some devices only support D3 or D2 for S3. ACPI defined
methods _SxD, which return maximum device's D-state when entering Sx.
But it's not easy to find a clean way to relate ACPI devices with PCI
devices.

Thanks,
Shaohua

>-----Original Message-----
>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-
>admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Pierre Ossman
>Sent: Monday, July 26, 2004 11:53 PM
>To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: [ACPI] PCI power state mapping
>
>Hi!
>
>I've been trying to get suspend-to-ram to work on my laptop and found
>some weird behavior with the handling of PCI power states. I know this
>mailing list is for ACPI, not PCI, but I figure that you are the
>resident experts on all power related matters. :)
>
>As far as I know the kernel has three different power modes. The ACPI
>ones (S0-S5), the linux ones (PM_SUSPEND_*) and the PCI ones (D0-D3).
>Mapping between the first two is done by the ACPI routines. But mapping
>between kernel power states and PCI is not done at all. The
>PM-enumerations are propagated all the way down to
>pci_set_power_state(). I.e. the function expects PCI states but gets
>kernel states. Both happen to be four levels with less power with
>increasing value so one might not notice it.
>
>Now for the problem. Most PCI devices do not support state D1 and D2
>(which would be called when entering PM_SUSPEND_STANDBY or
>PM_SUSPEND_MEM). This causes the pci_set_power_state() to fail and the
>suspend to be aborted. I haven't found any good documentation about the
>PCI power states but from what I can gather D0 is full power, D1-D2 are
>used during normal operation to conserve some power (when the device is
>idle I guess) and D3 when it enters some form of suspend. So
>PM_SUSPEND_MEM should probably put the devices in D3, not D2. Microsoft
>seem to increase the state until it finds on the device supports:
>
>"For example, if system power state S1 can be mapped into D1, D2, or D3
>power state for the device, the operating system selected the highest
>supported and valid device power state for mapping. In this example, S1
>would map to D1. If the device supports only D0 and D3 power states,
the
>system power state S1 would be mapped to D3 for the device."
> From http://www.microsoft.com/whdc/system/bus/PCI/pciids.mspx.
>
>Windows has something called system-to-device (SxD) mapping which seems
>to handle most of this. I can't find the equivalent in linux ACPI
>implementation. To me, this looks like a rather crucial part of the
system.
>
>I did a dirty hack in the pci_set_power_state() which does a simple
>escalation of the power state based on device capabilities. That, at
>least, got the suspend to go through without an abort. Still hangs the
>machine instead of suspending it though, which brings me to another
>question:
>
>Shouldn't all devices (or at least those with PM functions) on the PCI
>bus be shut down? As it is now it is up to the driver to power down the
>devices. Devices without drivers, or with drivers that forget to power
>down the unit, are left turned on. Couldn't this be a source of problem
>when getting the machine to suspend? PCI suspend doesn't require
>explicit driver support so it should be handled by the PCI subsystem.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>Acpi-devel mailing list
>Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click

Re: PCI power state mapping

[Pierre Ossman]

Hi,
I'm still learning the structure of the linux kernel so I wasn't aware 
that there was a device layer above the drivers. I figured that devices 
that weren't claimed by any driver were just ignored :)

Anyhow, I did some hacks into pci_device_suspend() getting it to suspend 
devices without a driver. Combined with my escalation patch in 
pci_set_power_state() all devices on the machine now enters D2 or D3 
depending on device capabilities. My laptop still cannot enter the 
suspend state so there is still something missing... Are there any more 
areas of power management in linux that aren't quite up to spec.?

When it comes to ACPI to PCI mapping, one immediately wonders how 
Windows handles this. I only see one option and that is comparing 
allocated resources. But that assumes that the driver assumes resources 
identically to how the guy writing the DSDT. Does anyone here have 
insight into how Windows does this?

In my attempts to fiddle with PCI power states I also tried using 
/sys/devices/pci*/*/power/state but nothing happens when writing values 
to this file. Where in the kernel is this file attached?

Rgds
Pierre Ossman

Li, Shaohua wrote:

>Hi,
>I agree with what you said. Currently most drivers will directly send
>'PM_*" state to 'pci_set_power_state', which cause many drivers can't
>suspend. I found my two laptops, Toshiba Satellite M20 and Thinkpad T40,
>EHCI can't suspend and the reason is exactly they only support D3 state
>but 'PM_SUSPEND_MEM' equals to 2.
>
>I suggest that 'pci_set_power_state' should be called in
>'pci_device_suspend', so even a device has no driver, it gets a chance
>to sleep. I have a sample patch for it actually, but it still uses wrong
>D-state number ('PM_*').
> 
>For determining D-state of a device in sleep state, bind guess is not a
>good idea. Some devices only support D3 or D2 for S3. ACPI defined
>methods _SxD, which return maximum device's D-state when entering Sx.
>But it's not easy to find a clean way to relate ACPI devices with PCI
>devices.
>
>Thanks,
>Shaohua
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: PCI power state mapping

[Pavel Machek]

Hi!

> Anyhow, I did some hacks into pci_device_suspend() getting it to 
> suspend devices without a driver. Combined with my escalation patch 
> in pci_set_power_state() all devices on the machine now enters D2 or 
> D3 depending on device capabilities. My laptop still cannot enter the 
> suspend state so there is still something missing... Are there any 
> more areas of power management in linux that aren't quite up to spec.?

You forgot to say if you are trying to suspend to ram or to disk.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: PCI power state mapping

[Pierre Ossman]

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

Pavel Machek wrote:

>Hi!
>
>  
>
>>Anyhow, I did some hacks into pci_device_suspend() getting it to 
>>suspend devices without a driver. Combined with my escalation patch 
>>in pci_set_power_state() all devices on the machine now enters D2 or 
>>D3 depending on device capabilities. My laptop still cannot enter the 
>>suspend state so there is still something missing... Are there any 
>>more areas of power management in linux that aren't quite up to spec.?
>>    
>>
>
>You forgot to say if you are trying to suspend to ram or to disk.
>				Pavel
>  
>
RAM. It was in the beginning of the thread...

Rgds
Pierre

[-- Attachment #2: Type: text/html, Size: 1075 bytes --]

Re: PCI power state mapping

[Pavel Machek]

Hi!

> Anyhow, I did some hacks into pci_device_suspend() getting it to 
> suspend devices without a driver. Combined with my escalation patch 
> in pci_set_power_state() all devices on the machine now enters D2 or 
> D3 depending on device capabilities. My laptop still cannot enter the 
> suspend state so there is still something missing... Are there any 
> more areas of power management in linux that aren't quite up to spec.?
>     
> 
> You forgot to say if you are trying to suspend to ram or to disk.
>                                 Pavel
>   
> 
>    RAM. It was in the beginning of the thread...

Okay, try suspending to disk, first. It tends to work better. Are your
"hacks into pci_device_suspend() getting it to suspend devices without
a driver" available somewhere?
								Pavel

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: PCI power state mapping

[Pierre Ossman]

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

Pavel Machek wrote:

>Hi!
>
>  
>
>>Anyhow, I did some hacks into pci_device_suspend() getting it to 
>>suspend devices without a driver. Combined with my escalation patch 
>>in pci_set_power_state() all devices on the machine now enters D2 or 
>>D3 depending on device capabilities. My laptop still cannot enter the 
>>suspend state so there is still something missing... Are there any 
>>more areas of power management in linux that aren't quite up to spec.?
>>    
>>
>>You forgot to say if you are trying to suspend to ram or to disk.
>>                                Pavel
>>  
>>
>>   RAM. It was in the beginning of the thread...
>>    
>>
>
>Okay, try suspending to disk, first. It tends to work better. Are your
>"hacks into pci_device_suspend() getting it to suspend devices without
>a driver" available somewhere?
>								Pavel
>
>  
>
Suspend to disk works fine. It's just the ram-bit that won't work. There 
is an earlier thread about this with more details (search for 
"suspend-to-ram hangs on HP NX7010"). I haven't bothered making a patch 
of my changes since they do not add any functionality. If you have a 
look at pci_device_suspend() it's fairly easy to change it. It's a very 
compact and obvious function.

Rgds
Pierre

[-- Attachment #2: Type: text/html, Size: 1670 bytes --]

Re: PCI power state mapping

[Pavel Machek]

Hi!

[Please do not use html on the lists.]

[me:]
> Okay, try suspending to disk, first. It tends to work better. Are your
> "hacks into pci_device_suspend() getting it to suspend devices without
> a driver" available somewhere?

[you:]
>    Suspend to disk works fine. It's just the ram-bit that won't work.
>    There is an earlier thread about this with more details (search for
>    "suspend-to-ram hangs on HP NX7010"). I haven't bothered making a
>    patch of my changes since they do not add any functionality. If you
>    have a look at pci_device_suspend() it's fairly easy to change it.
>    It's a very compact and obvious function.

Why do you think it is a driver problem? I have nx5000 here, it fails
to suspend, too, but I suspect some ACPI weirdness. Similar problem is
there on compaq 620c, btw.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: PCI power state mapping

[Pierre Ossman]

Pavel Machek wrote:

>Hi!
>
>[Please do not use html on the lists.]
>  
>
Sorry about that. This account is supposed to only send plain text. 
Don't know why it decided that HTML would be a good idea :/

>[me:]
>  
>
>>Okay, try suspending to disk, first. It tends to work better. Are your
>>"hacks into pci_device_suspend() getting it to suspend devices without
>>a driver" available somewhere?
>>    
>>
>
>[you:]
>  
>
>>   Suspend to disk works fine. It's just the ram-bit that won't work.
>>   There is an earlier thread about this with more details (search for
>>   "suspend-to-ram hangs on HP NX7010"). I haven't bothered making a
>>   patch of my changes since they do not add any functionality. If you
>>   have a look at pci_device_suspend() it's fairly easy to change it.
>>   It's a very compact and obvious function.
>>    
>>
>
>Why do you think it is a driver problem? I have nx5000 here, it fails
>to suspend, too, but I suspect some ACPI weirdness. Similar problem is
>there on compaq 620c, btw.
>								Pavel
>  
>
That depends on how you define a problem. But as I see it there can only 
be two reasons that the suspend fails. Either the ACPI implementation or 
one of the drivers is not up to spec. or the system relies on some 
"feature" present in Windows. Not being bug-for-bug compatible with 
Windows might not constitute a problem in the driver per se but can 
still cause undesired behavior.

Suspending all devices, not just those with well behaved drivers, was 
one thing that seemed reasonable to try. The next step would be manually 
putting devices into the states specified in the _SxD fields. But I 
haven't got the "state" files under sysfs to work yet...

Rgds
Pierre


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: PCI power state mapping

[Pavel Machek]

Hi!

> >>  Suspend to disk works fine. It's just the ram-bit that won't work.
> >>  There is an earlier thread about this with more details (search for
> >>  "suspend-to-ram hangs on HP NX7010"). I haven't bothered making a
> >>  patch of my changes since they do not add any functionality. If you
> >>  have a look at pci_device_suspend() it's fairly easy to change it.
> >>  It's a very compact and obvious function.
> >>   
> >>
> >
> >Why do you think it is a driver problem? I have nx5000 here, it fails
> >to suspend, too, but I suspect some ACPI weirdness. Similar problem is
> >there on compaq 620c, btw.
> >
> That depends on how you define a problem. But as I see it there can only 
> be two reasons that the suspend fails. Either the ACPI implementation or 
> one of the drivers is not up to spec. or the system relies on some 
> "feature" present in Windows. Not being bug-for-bug compatible with 
> Windows might not constitute a problem in the driver per se but can 
> still cause undesired behavior.
> 
> Suspending all devices, not just those with well behaved drivers, was 
> one thing that seemed reasonable to try. The next step would be manually 
> putting devices into the states specified in the _SxD fields. But I 
> haven't got the "state" files under sysfs to work yet...

Aha, okay, I see now.

I believe it is "ACPI implementation is not up to spec or or the
system relies on some "feature" present in Windows.". It might make
sense to try noapic (but it does not help here).

Hmm, strange.

My nx5k has "interesting" bios feature when it enters some kind of
bios-based-suspend-to-RAM upon pressing fn-F3... But it only works as
long as you keep accessing disk (yes, strange!). It works at grub
prompt, too (even without disk accessing). If disk is not accessed,
normally nothing will happen, but with "noapic nolapic" it will freeze
machine in similar way "echo 3 > /proc/acpi/sleep" will.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

PCI power state mapping

[Pierre Ossman]

Hi!

I've been trying to get suspend-to-ram to work on my laptop and found 
some weird behavior with the handling of PCI power states. I know this 
mailing list is for ACPI, not PCI, but I figure that you are the 
resident experts on all power related matters. :)

As far as I know the kernel has three different power modes. The ACPI 
ones (S0-S5), the linux ones (PM_SUSPEND_*) and the PCI ones (D0-D3). 
Mapping between the first two is done by the ACPI routines. But mapping 
between kernel power states and PCI is not done at all. The 
PM-enumerations are propagated all the way down to 
pci_set_power_state(). I.e. the function expects PCI states but gets 
kernel states. Both happen to be four levels with less power with 
increasing value so one might not notice it.

Now for the problem. Most PCI devices do not support state D1 and D2 
(which would be called when entering PM_SUSPEND_STANDBY or 
PM_SUSPEND_MEM). This causes the pci_set_power_state() to fail and the 
suspend to be aborted. I haven't found any good documentation about the 
PCI power states but from what I can gather D0 is full power, D1-D2 are 
used during normal operation to conserve some power (when the device is 
idle I guess) and D3 when it enters some form of suspend. So 
PM_SUSPEND_MEM should probably put the devices in D3, not D2. Microsoft 
seem to increase the state until it finds on the device supports:

"For example, if system power state S1 can be mapped into D1, D2, or D3 
power state for the device, the operating system selected the highest 
supported and valid device power state for mapping. In this example, S1 
would map to D1. If the device supports only D0 and D3 power states, the 
system power state S1 would be mapped to D3 for the device."
 From http://www.microsoft.com/whdc/system/bus/PCI/pciids.mspx.

Windows has something called system-to-device (SxD) mapping which seems 
to handle most of this. I can't find the equivalent in linux ACPI 
implementation. To me, this looks like a rather crucial part of the system.

I did a dirty hack in the pci_set_power_state() which does a simple 
escalation of the power state based on device capabilities. That, at 
least, got the suspend to go through without an abort. Still hangs the 
machine instead of suspending it though, which brings me to another 
question:

Shouldn't all devices (or at least those with PM functions) on the PCI 
bus be shut down? As it is now it is up to the driver to power down the 
devices. Devices without drivers, or with drivers that forget to power 
down the unit, are left turned on. Couldn't this be a source of problem 
when getting the machine to suspend? PCI suspend doesn't require 
explicit driver support so it should be handled by the PCI subsystem.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: PCI power state mapping

[Pavel Machek]

Hi!

> As far as I know the kernel has three different power modes. The ACPI 
> ones (S0-S5), the linux ones (PM_SUSPEND_*) and the PCI ones (D0-D3). 
> Mapping between the first two is done by the ACPI routines. But 
> mapping between kernel power states and PCI is not done at all. The 
> PM-enumerations are propagated all the way down to 
> pci_set_power_state(). I.e. the function expects PCI states but gets 

I have patch that converts all this to enums, and introduces
to_pci_state() function. That should solve part of confusion.


> Now for the problem. Most PCI devices do not support state D1 and D2 
> (which would be called when entering PM_SUSPEND_STANDBY or 
> PM_SUSPEND_MEM). This causes the pci_set_power_state() to fail and 
> the suspend to be aborted. I haven't found any good documentation 
> about the PCI power states but from what I can gather D0 is full 
> power, D1-D2 are used during normal operation to conserve some power 
> (when the device is idle I guess) and D3 when it enters some form of 
> suspend. So PM_SUSPEND_MEM should probably put the devices in D3, not 
> D2. Microsoft seem to increase the state until it finds on the device 
> supports:

Okay, to_pci_state will have to be fixed.

> Windows has something called system-to-device (SxD) mapping which 
> seems to handle most of this. I can't find the equivalent in linux 
> ACPI implementation. To me, this looks like a rather crucial part of 
> the system.

Someone will need to write that one...
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285