On Thu, 17 Mar 2005, Bernard Blackham wrote:
> On Wed, Mar 16, 2005 at 10:45:57AM -0500, Alan Stern wrote:
> > The power_state.event change shouldn't affect the code's functioning.
> > Neither should the PCI_CAP_ID_PM check provided it still ends up deciding
> > to "suspend" to D0.
>
> Can you elaborate on '"suspend" to D0' ? If the PCI_CAP_ID_PM check
> is in place, the state variable in usb_hcd_pci_suspend is set to 0,
> which means the if statement here:
>
> case HCD_STATE_SUSPENDED:
> if (state <= dev->current_state)
> break;
>
> is hit, and pci_save_state, pci_disable_device, and free_irq are
> never called.
Yes, that's what was happening to me.
> If, on the other hand the PCI_CAP_ID_PM check is removed from
> pci_choose_state, "state" is D3hot, so the PCI disabling code *is*
> called, and the function bails out when it hits if (!has_pci_pm) {...
That's different then, and it should be less troublesome.
> > Below is a new version of my patch with the IRQ handling reinstated and
> > the missing pci_set_master included. I'll do some more testing and get
> > back to you...
>
> Needed an extra patch to compile, attached.
I didn't get your attachment.
> However, it still
> doesn't survive more than one suspend/resume with devices plugged
> in. On the second resume, USB is dead, and it enters the same
> suspend_hc/wakeup_hc loop. I traced this back to the hcd never
> really being resumed, as the pci power state never changes from D0
> as pci_set_power_state is never called here. The attached patch also
> addresses this - I'm not sure if it's the right way, but it
> works(ish):
Can _you_ elaborate on "never really being resumed"? Since the state
never changes from D0 much of the code in usb_hcd_pci_suspend never runs,
as you said above. In fact about the only thing that does happen is the
call to hcd->driver->suspend. However the reverse call to
hcd->driver->resume does get made in usb_hcd_pci_resume even though the
state upon entry is D0.
> Suspend and resume for S3 or suspend to disk, without devices
> plugged in, works fine. If my USB mouse is plugged in, it is resumed
> and powered up, but nothing is sent out /dev/input/mice until I
> unplug and replug the device (but USB is not dead :)
I'll try this out right now.
Alan Stern
