On Mon, 2008-12-22 at 23:52 +0800, Alan Stern wrote: > On Mon, 22 Dec 2008, Zhang Rui wrote: > > > On Fri, 2008-12-19 at 23:09 +0800, Alan Stern wrote: > > > On Fri, 19 Dec 2008, Zhang Rui wrote: > > > > > > > device parallel resume support for PCI devices > > > > > > There are some PCI devices which won't work right if they are resumed > > > in parallel. The example I have in mind is a USB host controller > > > device with both a high-speed EHCI controller function and some > > > companion low/full-speed UHCI or OHCI controller functions. The EHCI > > > driver relies on the fact that the EHCI controller has a higher > > > function number and therefore is resumed _after_ the companion > > > controllers. > > > > > well, I never got this problem before. > > is this normal? does this exist on the Intel hardware? > > I'd like to do some test if I have chance. > > Yes, it is normal, and it does exist on Intel hardware. It isn't a > _problem_ (or at least, it hasn't been a problem up until now) because > the order of resuming devices is always the same as the order of > registration, which in turn is the same as the order of discovery. > > You can see this on any Intel ICHx chipset. I don't have an example > right here, but take a look at the machines you have lying around. > There are PCI UHCI controllers at 1d.0, 1d.1, ... and a PCI EHCI > controller at 1d.7. > > The issue arises when you have a low-speed or full-speed device plugged > in. The device is handed over from the EHCI controller to one of the > companion UHCI controllers, because EHCI manages only high-speed > devices. > > Now consider what happens when the system wakes up from hibernation. > The controllers are re-initialized, and when ehci-hcd sees the > low/full-speed device, it tries to hand the device over to the > companion controller again. But if the EHCI controller's resume method > runs first then the handover will fail, because the companion > controller has not yet been initialized. As a result, the device will > be lost and will have to go through rediscovery and re-enumeration. > This could be very annoying if, for example, the device contains a > mounted filesystem. > > > Just like the case above, can you give me a lspci output and show me > > what exactly the dependency is? > > The dependency is simple: The 1d.7 device must be resumed _after_ 1d.0, > 1d.1, ..., 1d.6. Then I have a question, what if the uchi_hcd is not loaded? the ehci host controller doesn't work in this case? thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
