> My hypothesis is that the Synopsys host doesn't go into L1 if the device > NAKs a transfer, only when the bus is idle. That way, it doesn't have > to depend on L1 remote wakeup, which is broken for these devices. I > don't have a way to confirm that though. Paul, is the Synopsys host > working around these broken devices? I think the device actually NAKs the IN transfer of the MSC command in my test, the same way it does on Haswell. It does go into L1, but then there is a resume just a few dozen microseconds later. Unfortunately its very hard to differentiate between device and host-initiated resume in USB 2.0... but maybe the Synopsys controller just wakes stuff up on its own in some circumstances? There doesn't seem to be a clear guideline in the spec for when to trigger a host-initiated resume, so maybe they just do it whenever there are transfers queued up for a slot or something. Also, I only know that the device doesn't fail, I'm not that convinced that the LPM really works as it should. I see a lot of L1-suspends that only last for a few dozen microseconds (and the resume signalling after that takes more than a millisecond), which probably doesn't really save power. In some of those cases the host waits a few frames before scheduling a new command after resume, which suggests that the wakeup was earlier than necessary. > I do want to allow the Synopsys host to have USB 2.0 Link PM enabled if > the host has a way to work around these broken devices. Paul and > Julius, let's work out a solution to do this on top of these patches. > I suspect that the solution may be to add an update_device method to > xhci-plat that sets udev->usb2_hw_lpm_allowed, calls xhci_update_device, > and then calls usb_set_usb2_hardware_lpm(). We'll have to wait for the > updated patches from Mathias though. I'm not sure if it's necessary to make this decision in the kernel, since this seems to be very specific to a particular controller (we maybe should try out some external PCI controllers if anyone has one). I would be fine with just turning this on from user-space as we already do with autosuspend, where we can implement arbitrary policies for any particular HC/device combination. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
