Thread (101 messages) 101 messages, 22 authors, 2015-10-27

Re: [GIT PULL] On-demand device probing

From: Rob Clark <hidden>
Date: 2015-10-17 17:55:14
Also in: dri-devel, linux-clk, linux-devicetree, linux-gpio, linux-i2c, linux-pm, linux-pwm, linux-tegra, lkml

On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
[off-list ref] wrote:
quoted
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..

BR,
-R
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help