Messages in this thread | | | From | David Brownell <> | Subject | Re: [linux-usb-devel] Re: Scheduling while atomic (2.6.10-rc3-bk13) | Date | Mon, 20 Dec 2004 13:31:35 -0800 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |