On Mon, 26 Jul 2010, Andiry Xu wrote:
> Hi Sarah,
>
> This is xHCI pm patchset v5.
>
> Changelog from v4:
>
> 1. Remove atomic operation in port pm and remote wakeup patch.
> 2. Refine xhci_cmd_ring_init() and xhci_event_ring_init().
> 3. Free all virt devices if the xHC restore error and reset.
> 4. Remove redundant changes to xhci.h.
> 5. Some semantic refine.
>
> The patchset is based on your master branch, but I cannot enter S3 with
> 2.6.35-rc4, even with xhci-hcd unloaded. so I use 2.6.34 for test.
>
> I have tested port PM, remote wakeup and S3. I've tested USB3.0/2.0/1.1
> device, plug in before/during S3 suspend and after S3 resume, and run S3
> for several times. In most cases the devices will be recognized
> successfully and work fine. But there are some issues listed below.
>
> 1. Every time the system resume from S3, the STS_SRE bit is set, which
> indicates the xHC restore error, so the xHC should be reset. The hub
> driver will try to resume the devices, but it will found the devices
> lost and then free and re-initialize them.
That's not quite right. It tries to reset the device first. Only if
the reset fails does it free and re-initialize the device.
At least, that's what is supposed to happen. It might not work right
with USB-3. You may need to change the hub_activate() routine in
core/hub.c: Replace the line
} else if (portstatus & USB_PORT_STAT_ENABLE) {
with
} else if ((portstatus & USB_PORT_STAT_ENABLE) &&
type == HUB_RESUME) {
> It will show "cannot reset
> HCD device state" in the dmesg. I'm not quite sure how to fix this.
>
> 2. If you plug an USB3.0 device before S3 suspend, After S3 resume, the
> device will failed to be recognized. To make it work, the disabling of
> USB3 port should be skipped, then the USB3.0 device will be initialized
> successfully and work properly. I think you already know about this.
> Since it's not related to PM, I did not include the skip disabling of
> USB3 port in the patchset.
This is probably the reason you get those "cannot reset HCD device
state" errors.
> 3. There is an issue related with plugin sequence when there are several
> char devices plugged in before S3 suspend. If first plug in a device to
> a port with bigger number (for example, port 4), then plug in a device
> to a port with smaller number (for example, port 2), the devices will be
> registered like this:
>
> Device Slot id port number /dev/char
> Dev1 Slot 1 port 4 189:897
> Dev2 Slot 2 port 2 189:898
>
> After resume, Dev2 on port 2 will be first resumed. Since the xHC is
> reset, the device resume will fail, Dev2 will be freed and
> re-initialized. Then it will fail in sysfs_add_one(), dmesg shows
> "sysfs: cannot create duplicate filename '/dev/char/189:897'", because
> the filename is still possessed by Dev1, and the initialization of Dev2
> fails. Dev1 on port 1 will be resumed next and it will be initialized
> successfully. Check the dmesg attached.
The reason for this is not clear. It may go away when the other
problems are fixed.
> If you change the ports the two devices plug in, like this:
>
> Device Slot id port number /dev/char
> Dev1 Slot 1 port 2 189:897
> Dev2 Slot 2 port 4 189:898
>
> Then two devices will be re-initialized successfully. In this case, Dev1
> will be freed and re-added as 189:897. no conflict happens and it goes
> well.
>
> I tried EHCI controller and found something different with xHCI: every
> time when I unplug a device and re-plug in to a EHCI USB2 port, the
> minor number of the device will increase. For example, plug in a USB2.0
> HDD, it will appear as /dev/char/189:15; then unplug it and re-plug in,
> it will be /dev/char/189:16. But for xHCI port, it will always be the
> same. I've no idea what causes this difference, but it may causes the
> initialization fail in my case. Is this a bug?
The minor number is constructed from the bus number and device address.
When you get a conflict, it's because the new device is assigned an
address already held by the old device. I don't know why this happens.
Alan Stern
--
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
