On Thu, Jan 13, 2011 at 11:21:59AM +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? > > 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. There has to be a way, as I see it happening on my systems here. > > Care to post the kernel boot chart svg graph for what you see today? > > See attachment. That is completely single-threaded, very wierd. I really don't know. You should try measuring the same thing on a x86 box and see the multi-threads happening, and try to figure out what on ARM is not creating them properly. It must be something in the system startup. odd, 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
