Re: [PATCH 0/4 v5] xHCI: PM patchset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux