Phil Endecott wrote:
Arjan van de Ven wrote:
On Wed, 15 Oct 2008 00:17:29 +0100
"Phil Endecott" <phil_dubhl_endecott@xxxxxxxxxxxx> wrote:
It looks to me as if uhci holds some lock that 8250 needs before it
can complete. Now those are both PCI drivers in the same way that
the last two that seemed to contend were both input drivers (touchpad
and speaker) [hmm, except that as Dmitry pointed out there's a
distinction between the platform bus and the serio bus]. Anyway, my
ignorant suspicion is that there's some lock related to the bus or
subsystem that they both need. Maybe something in sysfs?
it does do this. And I know which lock... and I fixed it ;)
Just the patch for this is in Gregkh's tree since it's a change to the
device/sysfs layer and he wanted to carry it via that way.
I can dig that patch out if you want
Yes please!
Google eventually found this for me:
http://thread.gmane.org/gmane.linux.usb.general/9923
I presume that this is what Arjan was referring to. It causes the
device-to-driver matching loop to not take the device lock unless the
match function succeeds. In my case, the need to take this look was
preventing the pcspkr initialisation from terminating until the mouse
initialisation was done, even though the mouse initialisation is in a
different thread, because the pcspkr init wanted to lock the mouse to
check if it was actually a speaker.
Fixing it has halved my boot time.
Phil.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
