lkml.org 
[lkml]   [2015]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] On-demand device probing
On 10/21/2015 2:12 PM, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> 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?
>
> Time to display on is important for many products. Having the console
> up as early as possible is another case. CAN bus is another. This is a
> real problem that is not just bad drivers.

Yes, I agree.

What I am seeing is that there continues to be a need for the ability
to explicitly order at least some driver initialization (at some
granularity), despite the push back against explicit ordering that
has been present in the past.


> I don't think it is completely ad hoc. Given all devices are
> registered after drivers, drivers will still probe first in initcall
> level order and then link order AFAIK. We may not take (more) initcall
> level tweak hacks, but that is a much more simple change for
> downstream. Don't get me wrong, I'd really like to see a way to
> control order independent of initcall level.
>
> Rob

Yep, it is not directly ad hoc, just a fortunate side effect in
this case. So just accidently ad hoc. :-)

-Frank



\
 
 \ /
  Last update: 2015-10-22 00:01    [W:1.938 / U:1.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site