Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of

[Laurent Pinchart]

Hi Philipp,

On Friday 14 March 2014 13:19:39 Philipp Zabel wrote:
> Am Donnerstag, den 13.03.2014, 18:13 +0100 schrieb Laurent Pinchart:
> > On Thursday 13 March 2014 12:08:16 Philipp Zabel wrote:
> > > Am Montag, den 10.03.2014, 14:37 +0000 schrieb Grant Likely:
> > > > > > Nak. I made comments that haven't been resolved yet. I've replied
> > > > > > with more detail tonight. The big issues are how drivers handle
> > > > > > the optional 'ports' node and I do not agree to the double-linkage
> > > > > > in the binding description.
> > > 
> > > so as I understand it, nobody is against dropping the double-linkage
> > > *if* we can agree on a way to recreate the backlinks in the kernel.
> > 
> > I'm not sure about "nobody", but even though it might not be my favorite
> > option I'd be OK with that.
> 
> Ok, I make that assumption going by the discussion about link direction that
> ensued.
> 
> > > My current suggestion would be to parse the complete device tree into an
> > > internal graph structure once, at boot to achieve this. This code could
> > > look for the optional 'ports' node if and only if the parent device node
> > > contains #address-cells != <1> or #size-cells != <0> properties.
> > 
> > With backlinks in DT we can assume that, if a node is the target of a
> > link, it will be compatible with the of-graph bindings, and thus parse
> > the node to locate other ports and other links. This allows parsing the
> > full graph without help of individual drivers.
> 
> Yes.
> 
> > Without backlinks in DT we need to parse the full DT to reconstruct
> > backlinks in the kernel. One possible issue with that is that we can't
> > know whether a node implements the of-graph bindings. We can use the
> > heuristic you've described above, but I wonder if it could lead to
> > problems. Grant pointed out that the compatibility string defines what
> > binding a node uses, and that we can't thus look for properties randomly.
> > I don't think there's a risk to interpret an unrelated node as part of a
> > graph though.
> 
> False positives would just take up a bit of space in the endpoint lists, but
> otherwise should be no problem, as they would only be used when either a
> driver implementing the bindings is bound, or when they are connected to
> other endpoints. Whether or not we scan the whole tree, using this
> heuristic, is more a matter of principle.

That is my understanding as well, so we should be good there.

> > > People completely disagree about the direction the phandle links should
> > > point in. I am still of the opinion that the generic binding should
> > > describe just the topology, that the endpoint links in the kernel
> > > should represent an undirected graph and the direction of links should
> > > not matter at all for the generic graph bindings.
> > 
> > I would also not mandate a specific direction at the of-graph level and
> > leave it to subsystems (or possibly drivers) to specify the direction.
> 
> Thank you. Can everybody live with this?

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/