Hi,
There are known issues with USB after suspend/resume (D3 hot) on
powerpc. For example, plugging or unplugging devices during sleep
results in oopses at resume; and one time out of two, the USB ports are
unpowered on resume (because the registers think they are, and
linux doesn't repower them. but they're not).
Both of these issues have patches available, patches that can be found
there for example:
http://colino.net/ibookg4/usb-ohci-fixes.patch
http://colino.net/ibookg4/usb-ehci-power.patch
What kind of work on these is needed so that they get in?
Thanks,
--
Colin
On Tuesday 05 April 2005 11:44 am, Colin Leroy wrote:
> Hi,
>
> There are known issues with USB after suspend/resume (D3 hot) on
> powerpc.
Also known fixes to some of them, which haven't yet been merged.
I'll repost these as followups to this message, to linux-usb-devel
and CC Colin. They're in the 2.6.12-rc2-mm1 patchset.
To my understanding, such issues have been around for some time
now, although recent kernels have tossed monkey wrenches into
several other cases that previously worked just fine. (Ergo those
nyet-merged patches...)
> For example, plugging or unplugging devices during sleep
> results in oopses at resume; and one time out of two, the USB ports are
> unpowered on resume (because the registers think they are, and
> linux doesn't repower them. but they're not).
>
> Both of these issues have patches available, patches that can be found
> there for example:
>
> http://colino.net/ibookg4/usb-ohci-fixes.patch
> http://colino.net/ibookg4/usb-ehci-power.patch
>
> What kind of work on these is needed so that they get in?
Briefly, given 2.6.12-rc2 plus the patches mentioned above,
find out what else is needed.
* The first of them is Paul's patch, and I never got a
response to the questions I asked him about it.
- 2.6.12-rc2 does have the fix to check for HC_STATE_QUIESCING,
which should supplant the need for a new "suspending" quirk.
- And the first of those patches waiting merge does update the
handling of IRQs in the PCI-to-USB glue.
- So the main change from that patch which is unresolved is
moving the PMAC-specific stuff up from the OHCI code into
into the the usb/core/hcd-pci code. Presumably you could
do that? I assume that it really is needed at that layer,
though it'll only relate to OHCI cells on Apple ASICs.
* As for the second, that looks to be a hardware-specfic issue
that just wouldn't reproduce with the controllers I was using
for PM testing. What I'll do is wrap up an equivalent fix with
some related EHCI updates for power switching, post that, and
ask you to verify that it works (probably simplest to do that
with OHCI non-modular and not loaded).
How's that sound?
- Dave
On 05 Apr 2005 at 13h04, David Brownell wrote:
Hi,
> > There are known issues with USB after suspend/resume (D3 hot) on
> > powerpc.
>
> Also known fixes to some of them, which haven't yet been merged.
> I'll repost these as followups to this message, to linux-usb-devel
> and CC Colin. They're in the 2.6.12-rc2-mm1 patchset.
>
> To my understanding, such issues have been around for some time
> now, although recent kernels have tossed monkey wrenches into
> several other cases that previously worked just fine. (Ergo those
> nyet-merged patches...)
>
>
> > For example, plugging or unplugging devices during sleep
> > results in oopses at resume; and one time out of two, the USB ports
> > are unpowered on resume (because the registers think they are, and
> > linux doesn't repower them. but they're not).
> >
> > Both of these issues have patches available, patches that can be
> > found there for example:
> >
> > http://colino.net/ibookg4/usb-ohci-fixes.patch
> > http://colino.net/ibookg4/usb-ehci-power.patch
> >
> > What kind of work on these is needed so that they get in?
>
> Briefly, given 2.6.12-rc2 plus the patches mentioned above,
> find out what else is needed.
>
> * The first of them is Paul's patch, and I never got a
> response to the questions I asked him about it.
>
> - 2.6.12-rc2 does have the fix to check for HC_STATE_QUIESCING,
> which should supplant the need for a new "suspending" quirk.
>
> - And the first of those patches waiting merge does update the
> handling of IRQs in the PCI-to-USB glue.
>
> - So the main change from that patch which is unresolved is
> moving the PMAC-specific stuff up from the OHCI code into
> into the the usb/core/hcd-pci code. Presumably you could
> do that? I assume that it really is needed at that layer,
> though it'll only relate to OHCI cells on Apple ASICs.
>
> * As for the second, that looks to be a hardware-specfic issue
> that just wouldn't reproduce with the controllers I was using
> for PM testing. What I'll do is wrap up an equivalent fix with
> some related EHCI updates for power switching, post that, and
> ask you to verify that it works (probably simplest to do that
> with OHCI non-modular and not loaded).
>
> How's that sound?
Nice :)
Ok, here are the results of my tests with 2.6.12-rc2 and the patches
you sent me applied:
- plug USB device, sleep, unplug USB device, resume: no more oops
- sleep, plug in USB device: no oops, but it wakes the laptop up for a
few seconds; then, it goes back to sleep. No oops on second resume. I
can live with that :)
- once out of two resumes, resume leaves the ports unpowered; so I still
need my usb-ehci-power.patch that re-powers ports unconditionnaly.
--
Colin
On Wednesday 06 April 2005 10:20 am, Colin Leroy wrote:
> On 05 Apr 2005 at 13h04, David Brownell wrote:
> > >
> > > What kind of work on these is needed so that they get in?
> >
> > Briefly, given 2.6.12-rc2 plus the patches mentioned above,
> > find out what else is needed.
> > ...
> > How's that sound?
>
> Nice :)
>
> Ok, here are the results of my tests with 2.6.12-rc2 and the patches
> you sent me applied:
>
> - plug USB device, sleep, unplug USB device, resume: no more oops
> - sleep, plug in USB device: no oops, but it wakes the laptop up for a
> few seconds; then, it goes back to sleep. No oops on second resume. I
> can live with that :)
Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually
disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if
not, then it's odd that the system went back to sleep!) Do you think
that might be related to those calls manipulating the Apple ASICs being
in the OHCI layer rather than up nearer the generic PCI glue? (I still
think they don't belong in USB code -- ohci or usbcore -- at all. If
the platform-specific PCI hooks don't suffice, they need fixing.)
Thanks for the testing update. I'm glad to know that there seems to
be only one (minor) glitch that's PPC-specific!
> - once out of two resumes, resume leaves the ports unpowered; so I still
> need my usb-ehci-power.patch that re-powers ports unconditionnaly.
OK, I just posted the patch cleaning up EHCI port power switching;
that should remove the need for that separate patch. (As well as
fixing some minor annoyances.)
- Dave
> Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually
> disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if
> not, then it's odd that the system went back to sleep!) Do you think
> that might be related to those calls manipulating the Apple ASICs being
> in the OHCI layer rather than up nearer the generic PCI glue? (I still
> think they don't belong in USB code -- ohci or usbcore -- at all. If
> the platform-specific PCI hooks don't suffice, they need fixing.)
There are no platform hooks in the right place for now afaik. Anyway, I
think Colin's controller is an OHCI/EHCI NEC chip, so not an Apple ASIC,
it's not doing anything in those calls.
> Thanks for the testing update. I'm glad to know that there seems to
> be only one (minor) glitch that's PPC-specific!
Which is just an off-the-shelves NEC EHCI chip.
> > - once out of two resumes, resume leaves the ports unpowered; so I still
> > need my usb-ehci-power.patch that re-powers ports unconditionnaly.
>
> OK, I just posted the patch cleaning up EHCI port power switching;
> that should remove the need for that separate patch. (As well as
> fixing some minor annoyances.)
>
> - Dave
>
>
--
Benjamin Herrenschmidt <[email protected]>
On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote:
>
> > Thanks for the testing update. I'm glad to know that there seems to
> > be only one (minor) glitch that's PPC-specific!
>
> Which is just an off-the-shelves NEC EHCI chip.
The wakeup-after-suspend hasn't been reported by anyone else.
On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote:
> On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote:
> >
> > > Thanks for the testing update. I'm glad to know that there seems to
> > > be only one (minor) glitch that's PPC-specific!
> >
> > Which is just an off-the-shelves NEC EHCI chip.
>
> The wakeup-after-suspend hasn't been reported by anyone else.
Looks like the root hub is set for triggering wakeups on connect, isn't
that just a setting in there ? The old Apple ASIC had a bit somewhere to
control that, but I don't know about the NEC
Ben.
On Wednesday 06 April 2005 4:50 pm, Benjamin Herrenschmidt wrote:
> On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote:
> > On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote:
> > >
> > > > Thanks for the testing update. I'm glad to know that there seems to
> > > > be only one (minor) glitch that's PPC-specific!
> > >
> > > Which is just an off-the-shelves NEC EHCI chip.
> >
> > The wakeup-after-suspend hasn't been reported by anyone else.
>
> Looks like the root hub is set for triggering wakeups on connect, isn't
> that just a setting in there ? The old Apple ASIC had a bit somewhere to
> control that, but I don't know about the NEC
The NEC chip uses PME# for PCI wakeup, which pci_enable_wake(..., 0)
is supposed to have disabled. If it's not disabling PME#, that's a
bug in the PCI infrastructure on that platform. If some other signal
is causing a wakeup, that's a different platform-specific issue. :)
On Wed, 6 Apr 2005 13:11:53 -0700
David Brownell <[email protected]> wrote:
> Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually
> disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if
> not, then it's odd that the system went back to sleep!)
Yes, CONFIG_USB_SUSPEND is disabled here.
> Do you think
> that might be related to those calls manipulating the Apple ASICs
> being in the OHCI layer rather than up nearer the generic PCI glue?
To be honest, I don't really know :)
> Thanks for the testing update. I'm glad to know that there seems to
> be only one (minor) glitch that's PPC-specific!
Yup, me too, I consider it working quite well now :)
> OK, I just posted the patch cleaning up EHCI port power switching;
> that should remove the need for that separate patch. (As well as
> fixing some minor annoyances.)
Seen that, thanks.
--
Colin
On Thu, 07 Apr 2005 09:02:57 +1000
Benjamin Herrenschmidt <[email protected]> wrote:
> > Interesting. Looks like pci_enable_wake(dev, state, 0) isn't
> > actually disabling wakeup on your hardware. (Assuming
> > CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went
> > back to sleep!) Do you think that might be related to those calls
> > manipulating the Apple ASICs being in the OHCI layer rather than up
> > nearer the generic PCI glue? (I still think they don't belong in
> > USB code -- ohci or usbcore -- at all. If the platform-specific
> > PCI hooks don't suffice, they need fixing.)
>
> There are no platform hooks in the right place for now afaik.
Nope, not in upstream, but I used the ohci patch from Paul Mackerras
previously.
> Anyway, I think Colin's controller is an OHCI/EHCI NEC chip, so not
> an Apple ASIC, it's not doing anything in those calls.
--
Colin