On Tue, 14 Oct 2008 11:48:37 -0400
Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> On Tue, Oct 14, 2008 at 11:37:49AM -0400, Arjan van de Ven wrote:
> > On Tue, 14 Oct 2008 11:29:55 -0400
> > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> >
> > > On Tue, Oct 14, 2008 at 11:12:36AM -0400, Arjan van de Ven wrote:
> > > > On Tue, 14 Oct 2008 10:54:36 -0400
> > > > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
> > > > > On Tue, Oct 14, 2008 at 03:19:28PM +0100, Phil Endecott wrote:
> > > > > > What can be done about this? Is it unreasonable for the
> > > > > > mouse probing to take 2 seconds? Should it not be holding
> > > > > > the conflicting lock while it is probing? Does the platform
> > > > > > matching code really need to hold the lock when it's just
> > > > > > comparing the string names of the device and driver?
> > > > > >
> > > >
> > > > the real thing is to not wait on this while booting;
> > > > my fastboot git tree has the patches to fix that part..
> > > >
> > >
> > > Could you please be more specific?
> > \
> > oh btw you could make the mouse be exempt from this waiting that'd
> > be a much simpler/nicer solution ;-)
> >
>
> Like I said, mouse probing is done in kseriod which is a separate
> thread. If you look at the trace psmouse_init returned way way before,
> its pcspkr got stuck for some reason (after completing
> pcspkr_probe)...
but without that locking issue we still have the delay.
Because you run as a probe, and the kernel code waits until ALL probes
are done:
/* wait for the known devices to complete their probing */
while (driver_probe_done() != 0)
msleep(100);
if the serio stuff wouldn't run as a "probe"... we wouldn't wait on it
before mounting the root fs.
(and whoever comes up with "but I have my root fs on my mouse....
"LALALALALALA" <fingers in ears>)
>
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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
