[GIT PULL] On-demand device probing

[Frank Rowand]

On 10/21/2015 9:27 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> 
>>> To be clear, I was saying that this series should NOT affect total
>>> boot times much.
> 
>> I'm confused.  If I understood correctly, improving boot time was
>> the key justification for accepting this patch set.  For example,
>> from "[PATCH v7 0/20] On-demand device probing":
>>
>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>    is basically the same issue in [0]), and have looked into ordered
>>    probing as a better way of solving this than moving nodes around in the
>>    DT or playing with initcall levels and linking order.
>>
>>    ...
>>
>>    With this series I get the kernel to output to the panel in 0.5s,
>>    instead of 2.8s.
> 
> Overall boot time and time to get some individual built in component up
> and running aren't the same thing - what this'll do is get things up
> more in the link order of the leaf consumers rather than deferring those
> leaf consumers when their dependencies aren't ready yet.

Thanks!  I read too much into what was being improved.

So this patch series, which on other merits may be a good idea, is as
a by product solving a specific ordering issue, moving successful panel
initialization to an earlier point in the boot sequence, if I now
understand more correctly.

In that context, this seems like yet another ad hoc way of causing the
probe order to change in a way to solves one specific issue?  Could
it just as likely move the boot order of some other driver on some
other board later, to the detriment of somebody else?


> 
>> While not as dramatic as your results, they are somewhat supportive.
>> What has changed your assessment that the on-demand device probing
>> patches will give a big boot performance increase?  Do you have
>> new data or analysis?
> 
> See above, my understanding was that the performance improvements were
> more around improved control/predictability/handwave of the boot
> ordering rather than total time.
>