> > Hi Greg, > > > > > > > > we are working on making the Linux Kernel (2.6.34) boot faster on > an > > > > > > embedded ARM machine. One significant delay is caused by the 50ms > > > > > > > TDRSTR minimum reset time required by USB spec. Starting both OHCI > > > > > > > and EHCI creates a 100ms sleep in total. Running them in threads > e.g. > > > > > > > > Some more details: > > > > > > > > The 50ms delay we talk about here is caused by msleep() in the > > > > (ECHI-/OHCI-) driver initializations. These are called while the > kernel > > > > starts, even before the root file system is mounted. > > > > > > That's fine, you should be off doing other things while this sleep > > > happens, right? Like probing your disk drive, bringing your video card > > > up and other fun things. > > > > Maybe that is an issue with our ARM system. The USB EHCI/OHCI init > > happens pretty much towards the end of the boot sequence. Seems there > > is nothing left to parallelize that runs in threads. If that is the > > case would it be smart to put EHCI/OHCI init earlier into the boot > > process to have it wait in parallel or put it into threads itself? > > At minimum both could wait 50ms in parallel instead of serial. > > What kicks off the ehci/ohci startup sequence on your board? Is it a > PCI device or a platform on? If platform, any chance you can start it > earlier before other platform devices? It is started as a standard PCI device. > Also, is this really stopping init from starting? That seems odd to me, > but it might be a platform specific thing. > > Worse case, do your init in a new thread, like Arjan showed is possible. > If you do that, does it solve the issue? Yes, applying Arjans patch solves it, the 100ms (2x 50ms) delay is gone. But we are concerned using that rejected patch. Therefore we ask for another way of running the EHCI/OHCI init in parallel. > Care to post the kernel boot chart svg graph for what you see today? See attachment. Thanks, Martin
Attachment:
initcall_debug.svg
Description: image/svg
