lkml.org 
[lkml]   [2014]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 25.08.2014 15:08, schrieb Jon Loeliger:
>>
>
>> Anyway, instead of going back and forth between "deferred probe is good"
>> and "deferred probe is bad", how about we do something useful now and
>> concentrate on how to make use of the information we have in DT with the
>> goal to reduce the number of cases where deferred probing is required?
>
> Good idea.
>
> The proposal on the table is to allow the probe code
> to make a topological sort of the devices based on
> dependency information either implied, explicitly stated
> or both. That is likely a fundamentally correct approach.
>
> I believe some of the issues that need to be resolved are:
>
> 1) What constitutes a dependency?

In my patches phandles are used. That works pretty good for almost all
DTs. So almost all dependencies are already declared in a DT and almost
no changes to the DT are necessary. The only binding I've seen where it
doesn't work is remote-endpoint, because that binding isn't a directed
dependency. So one of the two places where such a binding occurs needs a
"no-dependencies = <phandle>" to avoid circular dependencies which can
be solved.

> 2) How is that dependency expressed?

Already there in form of phandles.

> 3) How do we add missing dependencies?

My patches offer the possibility to extend or reduce the list of
(automatically generated) dependencies by using "[no-]dependencies = <
list of phandles >;"

> 4) Backward compatability problems.

None in my approach. The DT just includes an additional binding to
circumvent the missing but needed type information for phandles.

Regards,

Alexander Holler


\
 
 \ /
  Last update: 2014-08-26 10:21    [W:0.430 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site