On Tue, Sep 24, 2013 at 08:22:31PM -0700, Julius Werner wrote:
> > 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.
That behavior was seen on the Synopsys host, not the Intel host,
correct?
> > 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.
Ok. Mathias has a patch to enable it for internal devices and BESL
devices. I'll send out the updated patchset shortly. Can you run lsusb
on your Intel system, and see if the webcam supports Link PM? If so, it
would be great if you could add the patches, disable auto-suspend, and
double check that the latest version of lsusb shows that the device goes
into L1. I don't have access to a system today or tomorrow, but I can
check next week if necessary.
The lsusb you use to check L1 status should have this commit, which was
recently added:
commit 781622ddaf99b5071eace2850b4359cba6ccb299
Author: Alexandra Yates <alexandra.yates@xxxxxxxxxxxxxxx>
Date: Wed Aug 7 16:45:50 2013 -0700
lsusb: Reports if USB2.0 port is on L1 state
This patch reports the low power state L1 for ports with attahced USB2
devices. The output will be part of the roothub port status as follows:
ayates@magd:~$ sudo lsusb -v -s 001:001
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
...
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 9
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x68 0x02
PortPwrCtrlMask 0xff 0xff
Hub Port Status:
Port 1: 0000.0103 power enable
Port 2: 0000.0523 highspeed power L1 enable
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0503 highspeed power enable
Port 6: 0000.0100 power
Port 7: 0000.0100 power
Port 8: 0000.0100 power
Port 9: 0000.0100 power
Device Status: 0x0001
In this example port id: 0000.0523 is in L1 status.
This output is collected from testing the change on a HSWULT platform.
Signed-off-by: Alexandra Yates <alexandra.yates@xxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Sarah Sharp
--
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
