Re: [linux-usb-devel] Re: Scheduling while atomic (2.6.10-rc3-bk13)

[David Brownell <david-b@pacbell.net>]

On Monday 20 December 2004 12:57 pm, Lee Revell wrote:
> On Mon, 2004-12-20 at 11:52 -0800, David Brownell wrote:
> > Here's a quick'n'dirty patch, msleep --> mdelay.  I'd rather
> > not mdelay for that long, but this late in 2.6.10 it's safer.
> > (And this is also what OHCI does in that same code path.)
> 
> Ugh.  20ms is WAY too long to hold a spinlock.  That's guaranteed to
> cause audio skips.

During system resume?  :)

Anyone trying to use audio devices during system resume
probably deserves what they get, just now.  Best for them
to wait until after the system finishes resuming before
they start playing audio again.  (Over for example the
USB speaker hookup they were using... which has been
suspended for more than 20msec already!)


> Isn't there another way?
> 
> If OHCI calls mdelay(20) while holding a spinlock that needs to be
> fixed.

Eventually this is worth fixing ... after Linux behaves
sanely with selective device suspend/resume.

So for example, with PCI devices it sure _ought_ to be
reasonable to put devices into PCI_D3hot state, with
other active devices in PCI_D0 state and the CPU running
in C0 (or C1, C2, C3 as appropriate) ... and then rely
on ACPI to handle the device signaling PME# sanely,
by resuming the device issuing that signal.  (And to
do similar things for non-PCI/non-ACPI systems, too.)

Until then, there's no real point in trying to rework
those parts of usbcore to support selective resume
of HCDs.  Such code would never be used, and those
changes would conflict with more important work that's
going on.  (Both in terms of lines-of-code changing,
and in terms of opportunity costs.)

On the other hand, if you want to help fix all that,
we'd sure like to see your patches!

- Dave