On Saturday, March 30, 2013 02:53:00 AM Martin Mokrejs wrote: > Rafael J. Wysocki wrote: > > On Saturday, March 30, 2013 02:17:38 AM Martin Mokrejs wrote: > >> Rafael J. Wysocki wrote: > >>> On Friday, March 29, 2013 03:11:13 PM Martin Mokrejs wrote: > >>>> Hi Ying, > >>>> thank you for the patch. Here are the results. > >>>> > >>>> Huang Ying wrote: > >>>>> On Thu, 2013-03-28 at 19:38 +0100, Martin Mokrejs wrote: > >>>>>> Hi Ying, > >>>>>> would you please tell me how this report relate to this patch? > >>>>>> > >>>>>> [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications > >>>>>> > >>>>>> Could you tell me why this PME was being flipped back and forth now? > >>>>>> Actually, does that make finally some sense to you, pci/acpi devs? > >>> > >>> Can you please test this patch: > >>> > >>> https://patchwork.kernel.org/patch/2359611/ > >>> > >>> and report back as I asked you? > >> > >> Sorry for the delay I just had to sort out what belongs under what thread > >> and the patch was under the other. But I agree its testing with this > >> particular eSATA/ExpressCardSlot/PM fits better here. > >> > >> > >> The good news is that the eSATA card hotplug works almost perfectly with the patch. > >> I cold booted as always with the card in the slot already loaded, same kernel > >> .config and commandline options as described under this thread. But the kernel > >> was 3.8.3! Not 3.9-rc1. > > > > Good. The goal was to fix the problem with eSATA hotplug. > > I thought that was aimed at the XHCI dead port issue. ;-) > > > > >> What is important is the fact that this patch resulted in runtime_status set to > >> "active" instead of "auto" (3.8.3 with incidentally enabled laptop-mode-tools) > >> or "on" (also tested on 3.8.3 once laptop-mode-tools were uninstalled). With this > >> patch, devices did not get suspended during the tests (per /sys/*/power/runtime_status > >> files). > > > > You seem to be confusing power/runtime_status with power/control. runtime_status > > can never be "on", while control can never be "active". > > Too late here, but yes, I likely swapped the two filename and value pairs. Thanks. > > > > >> I haven't realized so far that the rtl8169 card at 05:00 and the TI xHCI > >> controller at 0b:00 support D2 state. > > > > Which probably doesn't matter, because that state isn't used by the kernel > > anyway. > > > >> # grep PME dmesg_final.txt > >> [ 1.571475] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold > >> [ 1.571500] pci 0000:00:16.0: PME# disabled > >> [ 1.571760] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold > >> [ 1.571766] pci 0000:00:1a.0: PME# disabled > >> [ 1.571991] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold > >> [ 1.571997] pci 0000:00:1b.0: PME# disabled > >> [ 1.572200] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold > >> [ 1.572205] pci 0000:00:1c.0: PME# disabled > >> [ 1.572409] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold > >> [ 1.572414] pci 0000:00:1c.1: PME# disabled > >> [ 1.572618] pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold > >> [ 1.572623] pci 0000:00:1c.3: PME# disabled > >> [ 1.572826] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold > >> [ 1.572832] pci 0000:00:1c.4: PME# disabled > >> [ 1.573042] pci 0000:00:1c.7: PME# supported from D0 D3hot D3cold > >> [ 1.573047] pci 0000:00:1c.7: PME# disabled > >> [ 1.573292] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold > >> [ 1.573297] pci 0000:00:1d.0: PME# disabled > >> [ 1.573765] pci 0000:00:1f.2: PME# supported from D3hot > >> [ 1.573770] pci 0000:00:1f.2: PME# disabled > >> [ 1.574521] pci 0000:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold > >> [ 1.574528] pci 0000:05:00.0: PME# disabled > >> [ 1.587449] pci 0000:09:00.0: PME# supported from D0 D3hot D3cold > >> [ 1.587500] pci 0000:09:00.0: PME# disabled > >> [ 1.605568] pci 0000:0b:00.0: PME# supported from D0 D1 D2 D3hot D3cold > >> [ 1.605575] pci 0000:0b:00.0: PME# disabled > >> [ 362.712584] sata_sil24 0000:11:00.0: PME# disabled > >> [ 1069.949732] sata_sil24 0000:11:00.0: PME# disabled > >> [ 1083.878783] sata_sil24 0000:11:00.0: PME# disabled > >> [ 1096.679536] sata_sil24 0000:11:00.0: PME# disabled > >> [ 1107.503274] sata_sil24 0000:11:00.0: PME# disabled > >> # > > > > The part above is totally irrelevant. It's just the initial configuration. > > > >> Seems the sata_sil24 does not report an equivalent of, for example: > >> [ 1.605568] pci 0000:0b:00.0: PME# supported from D0 D1 D2 D3hot D3cold > > > > Apparently, they don't support PME and pci_pme_active() should check > > dev->pme_support, but it doesn't. Still not relevant, though. > > > >> The states before/after tests (did not change): > > > > What tests? > > Tests with express card plugged in, unloaded, but also USB devices bing plugged > into the xHCI port to test whether it detects the change or not. > > > > > And why would you expect them to change? > > It is my impression the xHCI port can be suspended after a device is unplugged. > I might be wrong but doing just echo "auto" > /sys/.../control does not > cause a device suspend in a few seconds. I have to plugin a device and only > its unplug the "new setting" kicks in. Whether am right or not, I just wanted > to know whether any of them felt a sleep, etc. So "no change" was a good news > for me. ;-) > > > > >> /sys/bus/pci/devices/0000:00:00.0/power/control:on > >> /sys/bus/pci/devices/0000:00:02.0/power/control:on > >> /sys/bus/pci/devices/0000:00:16.0/power/control:on > >> /sys/bus/pci/devices/0000:00:1a.0/power/control:on > >> /sys/bus/pci/devices/0000:00:1b.0/power/control:on > >> /sys/bus/pci/devices/0000:00:1c.0/power/control:on > >> /sys/bus/pci/devices/0000:00:1c.1/power/control:on > >> /sys/bus/pci/devices/0000:00:1c.3/power/control:on > >> /sys/bus/pci/devices/0000:00:1c.4/power/control:on > >> /sys/bus/pci/devices/0000:00:1c.7/power/control:on > >> /sys/bus/pci/devices/0000:00:1d.0/power/control:on > >> /sys/bus/pci/devices/0000:00:1f.0/power/control:on > >> /sys/bus/pci/devices/0000:00:1f.2/power/control:on > >> /sys/bus/pci/devices/0000:00:1f.3/power/control:on > >> /sys/bus/pci/devices/0000:05:00.0/power/control:on > >> /sys/bus/pci/devices/0000:09:00.0/power/control:on > >> /sys/bus/pci/devices/0000:0b:00.0/power/control:on > >> /sys/bus/pci/devices/0000:11:00.0/power/control:on > > > > Sure, all of these devices are always on. You need to write "auto" to their > > power/control files to change that, which still doesn't mean they will be > > runtime-suspended. > > That's what I learned. ;-) > > > > > The patch in question doesn't have any effect on those settings. > > Oh it does! There are "active" values instead of "on" or "auto". This actually isn't even possible, because "on" or "auto" are values for one sysfs attribute, while "active" is for another. And I really know what I'm talking about in case you had any doubts. I know what the patch does. I'm not sure, though, if we're talking about the same patch. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
