On Thu, 6 Jan 2005, Oliver Neukum wrote:
> > I'm just suggesting that in ehci-hub.c, you add code to ehci_hub_suspend
> > to print the values of port and t1 inside the loop. Similarly, in
> > ehci_hub_resume print the values of i and temp in the two loops.
>
> Here we go:
> Jan 6 23:42:52 macbeth kernel: usb usb4: no poweroff yet, suspending instead
> Jan 6 23:42:52 macbeth kernel: Port is 5. t1 is 00001000
> Jan 6 23:42:52 macbeth kernel: Port is 4. t1 is 00001000
> Jan 6 23:42:52 macbeth kernel: Port is 3. t1 is 00001000
> Jan 6 23:42:52 macbeth kernel: Port is 2. t1 is 00001000
> Jan 6 23:42:52 macbeth kernel: Port is 1. t1 is 00001000
> Jan 6 23:42:52 macbeth kernel: Port is 0. t1 is 00003002
So before the suspend, PORT_OWNER is on for port 0 (the bit value is
0x2000). As we expect since the companion controller owns the port.
I'm not clear on why the 0x0002 bit (connect status change) is set.
> Jan 6 23:42:53 macbeth kernel: ehci_hcd 0000:00:1d.7: resume root hub
> Jan 6 23:42:53 macbeth kernel: Port: 5, Status: 00001000
> Jan 6 23:42:53 macbeth kernel: Port: 4, Status: 00001000
> Jan 6 23:42:53 macbeth kernel: Port: 3, Status: 00001000
> Jan 6 23:42:53 macbeth kernel: Port: 2, Status: 00001000
> Jan 6 23:42:53 macbeth kernel: Port: 1, Status: 00001000
> Jan 6 23:42:53 macbeth kernel: Port: 0, Status: 00001403
And during the resume, PORT_OWNER is off, thus changing the flip-flop.
Confirmed by 0x0400 (full/low speed device) and 0x0001 (device connected).
Someone, probably the BIOS, must have made this change.
> lspci:
> 0000:00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 03)
> c0: 00 2f 00 00 03 00 00 00 00 00 00 00 00 00 00 00
The LEGSUP register is 16 bits (little-endian) at offset 0xc0, so its
value is 0x2f00. The default value is 0x2000, and that's the value
written by uhci-hcd during initialization. So again, someone (presumably
the BIOS) has changed it.
It looks like Dave and I were both right! :-)
Just to be certain, you could try verifying the LEGSUP value:
After loading uhci-hcd and before doing the suspend (should
be 0x2000),
After the resume with BIOS legacy support turned off; maybe the
BIOS won't change the value. Although the log of your test
with legacy support off indicates that nothing much changes.
> I've noticed during writing out the image there are several wake_up,resume
> cycles from uhci.
They don't show up in your log, for obvious reasons. It may be perfectly
innocuous; before writing out the image the PM core awakens every device.
So you would expect to see some activity. Does it look like anything more
than that?
Alan Stern
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
