Date:	Fri, 14 Mar 2014 13:19:39 +0100
From:	Philipp Zabel <p.zabel@...gutronix.de>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:	Grant Likely <grant.likely@...aro.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Rob Herring <robh+dt@...nel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	devicetree@...r.kernel.org,
	Sylwester Nawrocki <s.nawrocki@...sung.com>
Subject: Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of

Hi Laurent,

Am Donnerstag, den 13.03.2014, 18:13 +0100 schrieb Laurent Pinchart:
> Hi Philipp,
> 
> 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.

> > 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
Philipp

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

Powered by blists - more mailing lists