On Mon, Jan 10, 2011 at 01:37:00PM +0100, Martin Mueller wrote: > 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? 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? Care to post the kernel boot chart svg graph for what you see today? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
