On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes <noralf@xxxxxxxxxxx> wrote: > > Den 17.10.2015 20:45, skrev Rob Clark: >> >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman >> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >>> >>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: >>>> >>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman >>>> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >>>>>> >>>>>> I'm guessing the time is a matter of probing and undoing the probes >>>>>> rather than slow h/w. We could maybe improve things by making sure >>>>>> drivers move what they defer on to the beginning of probe, but that >>>>>> seems like a horrible, fragile hack. >>>>> >>>>> How can calling probe and failing cause 2 seconds? How many different >>>>> probe calls are failing here? Again, a boot log graph would be great >>>>> to >>>>> see as it will show the root cause, not just guessing at this. >>>> >>>> >>>> just fwiw, but when you have a driver that depends on several other >>>> drivers (which in turn depend on other drivers and so on), the amount >>>> of probe-defer we end up seeing is pretty comical. Yeah, there >>>> probably is some room to optimize by juggling around order drivers do >>>> things in probe. But that doesn't solve the fundamental problem with >>>> the current state, about probe order having no clue about >>>> dependencies.. >>> >>> I can imagine it is a lot of iterations, but how long does it really >>> take? How many different devices are involved that it takes multiple >>> loops in order to finally work out the correct order? Where is the time >>> delays here, just calling probe() and having it instantly return >>> shouldn't take all that long. >> >> offhand, I think the dependencies go at *least* three levels deep.. >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to >> get all the way through requesting it's various different >> regulators/clks/gpios. I hadn't really paid attention to how many >> tries the drivers I depend on go through. (Of those, I take clks from >> two different clk drivers (which have dependency on a 3rd clk driver), >> and regulators and gpio's come from at least two places, which in turn >> have dependencies on clks, etc.) I don't have really good hard >> numbers handy (since my observations of this are w/ console over uart >> which effects timings, and so I see it taking much longer than 2sec).. >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to >> me. >> >> I can try to get better #'s... I should have my kernel hat on at least >> some of the time next week.. but the 2sec figure didn't seem >> unrealistic to me. > > > Are you saying that the total boot time is increased by 2 sec due to > deferred probing, or that display initialization is happening 2 sec > after it's first try? > The 2sec figure was from Tomeu, but I guess display should be probed in first pass through list of devices (and ofc deferring the first time), I'll say "probably both".. BR, -R -- 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
