From: Li, S. <sha...@in...> - 2004-07-27 07:10:27
|
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_*'). =20 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: acp...@li... [mailto:acpi-devel- >ad...@li...] On Behalf Of Pierre Ossman >Sent: Monday, July 26, 2004 11:53 PM >To: acp...@li... >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=3D4721&alloc_id=3D10040&op=3Dclick >_______________________________________________ >Acpi-devel mailing list >Acp...@li... >https://lists.sourceforge.net/lists/listinfo/acpi-devel |
From: Pierre O. <drz...@dr...> - 2004-07-27 18:16:55
|
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 > > > |
From: Pavel M. <pa...@uc...> - 2004-07-29 10:03:12
|
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 |
From: Pierre O. <drz...@dr...> - 2004-07-29 10:47:41
|
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 |
From: Pavel M. <pa...@uc...> - 2004-07-29 10:53:07
|
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! |
From: Pierre O. <drz...@dr...> - 2004-07-29 11:15:47
|
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 |
From: Pavel M. <pa...@su...> - 2004-07-29 11:24:19
|
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! |
From: Pierre O. <drz...@dr...> - 2004-07-29 11:45:51
|
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 |
From: Pavel M. <pa...@su...> - 2004-07-29 12:34:10
|
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! |