lkml.org 
[lkml]   [2013]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Ksummit-2013-discuss] Defining schemas for Device Tree
On Tue, Jul 30, 2013 at 11:50:31AM +1000, David Gibson wrote:
> On Mon, Jul 29, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> > On Mon, Jul 29, 2013 at 05:49:05PM +0100, Dave Martin wrote:
> > > On Mon, Jul 29, 2013 at 11:01:24AM -0400, Jason Cooper wrote:
> > > > On Mon, Jul 29, 2013 at 02:21:52AM +0200, Tomasz Figa wrote:
> >
> > > > > b) What information should be specified in schemas? What level of
> > > > > granularity is required?
> > > >
> > > > One item I don't see in this list is node ordering. There's been some
> > > > discussion lately on deferred probing (re boot times). If we were to
> > > > intentionally declare that DT are parsed in the order written, then a
> > > > lot of deferred probes could be avoided by moving eg the pinctrl node to
> > > > near the top of the tree.
> > > >
> > > > This doesn't impact buses as much, since the nodes needing the bus are
> > > > already children. However, anything accessed via phandles: pins,
> > > > clocks, regulators, etc could benefit from declaring and enforcing this.
> > > > Eg having the dtc warn when a phandle is used before it's corresponding
> > > > node is declared.
> > > >
> > > > Not critical though, just a thought.
> > >
> > > I don't think that siblings have any defined order in DT. If reading a
> > > device tree, there's no guarantee you get nodes or properties out in the
> > > same order as the original .dts file.
> >
> > That's why I raised the point. If people think encoding initialization
> > order in the DT is a good idea, then we should change the dtc so it
> > compiles/decompiles in the same order.
>
> I'm not actually sure what you mean by this. dtc already preserves
> order between input and output.

This is an old comment (~ 1d, wow). My position has evolved to seeing
if we can allow dtc to topsort nodes it can easily tell are needed first
as an optimization. *Not* a requirement. Deferred probing would still
be a fall back.

thx,

Jason.


\
 
 \ /
  Last update: 2013-07-30 14:41    [W:0.064 / U:0.972 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site