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?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
