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

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

[Philipp Zabel]

Hi Mauro, Russell,

I have temporarily removed the simplified bindings at Sylwester's
request and updated the branch with the acks. The following changes
since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:

  Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git topic/of-graph

for you to fetch changes up to d484700a36952c6675aa47dec4d7a536929aa922:

  of: Warn if of_graph_parse_endpoint is called with the root node (2014-03-06 17:41:54 +0100)

----------------------------------------------------------------
Philipp Zabel (6):
      [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
      Documentation: of: Document graph bindings
      of: Warn if of_graph_get_next_endpoint is called with the root node
      of: Reduce indentation in of_graph_get_next_endpoint
      [media] of: move common endpoint parsing to drivers/of
      of: Warn if of_graph_parse_endpoint is called with the root node

 Documentation/devicetree/bindings/graph.txt   | 129 ++++++++++++++++++++++
 drivers/media/i2c/adv7343.c                   |   4 +-
 drivers/media/i2c/mt9p031.c                   |   4 +-
 drivers/media/i2c/s5k5baf.c                   |   3 +-
 drivers/media/i2c/tvp514x.c                   |   3 +-
 drivers/media/i2c/tvp7002.c                   |   3 +-
 drivers/media/platform/exynos4-is/fimc-is.c   |   6 +-
 drivers/media/platform/exynos4-is/media-dev.c |  13 ++-
 drivers/media/platform/exynos4-is/mipi-csis.c |   5 +-
 drivers/media/v4l2-core/v4l2-of.c             | 133 +----------------------
 drivers/of/base.c                             | 151 ++++++++++++++++++++++++++
 include/linux/of_graph.h                      |  66 +++++++++++
 include/media/v4l2-of.h                       |  33 +-----
 13 files changed, 375 insertions(+), 178 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/graph.txt
 create mode 100644 include/linux/of_graph.h

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

[Russell King - ARM Linux]

On Thu, Mar 06, 2014 at 06:13:20PM +0100, Philipp Zabel wrote:
> Hi Mauro, Russell,
> 
> I have temporarily removed the simplified bindings at Sylwester's
> request and updated the branch with the acks. The following changes
> since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
> 
>   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/pza/linux.git topic/of-graph

Okay, this has all gone wrong.  Mauro has applied your changes as patches,
and I've pulled this set of changes.  So we're going to be all set for
merge conflicts....... just fscking great.

I really don't know why I bother trying to do the right thing sometimes.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

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

[Mauro Carvalho Chehab]

Em Fri, 07 Mar 2014 11:55:17 +0000
Russell King - ARM Linux <linux@arm.linux.org.uk> escreveu:

> On Thu, Mar 06, 2014 at 06:13:20PM +0100, Philipp Zabel wrote:
> > Hi Mauro, Russell,
> > 
> > I have temporarily removed the simplified bindings at Sylwester's
> > request and updated the branch with the acks. The following changes
> > since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
> > 
> >   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.pengutronix.de/git/pza/linux.git topic/of-graph
> 
> Okay, this has all gone wrong.  Mauro has applied your changes as patches,
> and I've pulled this set of changes.  So we're going to be all set for
> merge conflicts....... just fscking great.
> 
> I really don't know why I bother trying to do the right thing sometimes.
> 

I just reverted my tree to the previous state before applying the patches
and did a git pull instead, in order to avoid merge conflicts when the
imx-drm patches arrive via staging tree.

Regards,
Mauro

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

[Russell King - ARM Linux]

On Fri, Mar 07, 2014 at 09:20:31AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 07 Mar 2014 11:55:17 +0000
> Russell King - ARM Linux <linux@arm.linux.org.uk> escreveu:
> 
> > On Thu, Mar 06, 2014 at 06:13:20PM +0100, Philipp Zabel wrote:
> > > Hi Mauro, Russell,
> > > 
> > > I have temporarily removed the simplified bindings at Sylwester's
> > > request and updated the branch with the acks. The following changes
> > > since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
> > > 
> > >   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.pengutronix.de/git/pza/linux.git topic/of-graph
> > 
> > Okay, this has all gone wrong.  Mauro has applied your changes as patches,
> > and I've pulled this set of changes.  So we're going to be all set for
> > merge conflicts....... just fscking great.
> > 
> > I really don't know why I bother trying to do the right thing sometimes.
> > 
> 
> I just reverted my tree to the previous state before applying the patches
> and did a git pull instead, in order to avoid merge conflicts when the
> imx-drm patches arrive via staging tree.

Thank you, that will work much better, and will avoid flames from Linus
at the next merge window.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

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

[Grant Likely]

On Thu, 06 Mar 2014 18:13:20 +0100, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Hi Mauro, Russell,
> 
> I have temporarily removed the simplified bindings at Sylwester's
> request and updated the branch with the acks. The following changes
> since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
> 
>   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/pza/linux.git topic/of-graph
> 
> for you to fetch changes up to d484700a36952c6675aa47dec4d7a536929aa922:
> 
>   of: Warn if of_graph_parse_endpoint is called with the root node (2014-03-06 17:41:54 +0100)

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.

g.

> 
> ----------------------------------------------------------------
> Philipp Zabel (6):
>       [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
>       Documentation: of: Document graph bindings
>       of: Warn if of_graph_get_next_endpoint is called with the root node
>       of: Reduce indentation in of_graph_get_next_endpoint
>       [media] of: move common endpoint parsing to drivers/of
>       of: Warn if of_graph_parse_endpoint is called with the root node
> 
>  Documentation/devicetree/bindings/graph.txt   | 129 ++++++++++++++++++++++
>  drivers/media/i2c/adv7343.c                   |   4 +-
>  drivers/media/i2c/mt9p031.c                   |   4 +-
>  drivers/media/i2c/s5k5baf.c                   |   3 +-
>  drivers/media/i2c/tvp514x.c                   |   3 +-
>  drivers/media/i2c/tvp7002.c                   |   3 +-
>  drivers/media/platform/exynos4-is/fimc-is.c   |   6 +-
>  drivers/media/platform/exynos4-is/media-dev.c |  13 ++-
>  drivers/media/platform/exynos4-is/mipi-csis.c |   5 +-
>  drivers/media/v4l2-core/v4l2-of.c             | 133 +----------------------
>  drivers/of/base.c                             | 151 ++++++++++++++++++++++++++
>  include/linux/of_graph.h                      |  66 +++++++++++
>  include/media/v4l2-of.h                       |  33 +-----
>  13 files changed, 375 insertions(+), 178 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/graph.txt
>  create mode 100644 include/linux/of_graph.h
> 
> 

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

[Mauro Carvalho Chehab]

Em Fri, 07 Mar 2014 18:23:30 +0000
Grant Likely <grant.likely@linaro.org> escreveu:

> On Thu, 06 Mar 2014 18:13:20 +0100, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > Hi Mauro, Russell,
> > 
> > I have temporarily removed the simplified bindings at Sylwester's
> > request and updated the branch with the acks. The following changes
> > since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
> > 
> >   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.pengutronix.de/git/pza/linux.git topic/of-graph
> > 
> > for you to fetch changes up to d484700a36952c6675aa47dec4d7a536929aa922:
> > 
> >   of: Warn if of_graph_parse_endpoint is called with the root node (2014-03-06 17:41:54 +0100)
> 
> 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.

If I understood well, you're requesting to revert all those six patches
that were imported via git pull from my tree (and from Greg and Russell),
right?

E. g. reverting those changesets:
	d484700a3695 f2a575f67695 4329b93b283c 6ff60d397b17 4d56ed5a009b fd9fdb78a9bf

as it seems that there's no easy way to revert a git pull.

I suspect that this will likely cause some harm when merging from our
trees upstream.

Regards,
Mauro

> 
> g.
> 
> > 
> > ----------------------------------------------------------------
> > Philipp Zabel (6):
> >       [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
> >       Documentation: of: Document graph bindings
> >       of: Warn if of_graph_get_next_endpoint is called with the root node
> >       of: Reduce indentation in of_graph_get_next_endpoint
> >       [media] of: move common endpoint parsing to drivers/of
> >       of: Warn if of_graph_parse_endpoint is called with the root node
> > 
> >  Documentation/devicetree/bindings/graph.txt   | 129 ++++++++++++++++++++++
> >  drivers/media/i2c/adv7343.c                   |   4 +-
> >  drivers/media/i2c/mt9p031.c                   |   4 +-
> >  drivers/media/i2c/s5k5baf.c                   |   3 +-
> >  drivers/media/i2c/tvp514x.c                   |   3 +-
> >  drivers/media/i2c/tvp7002.c                   |   3 +-
> >  drivers/media/platform/exynos4-is/fimc-is.c   |   6 +-
> >  drivers/media/platform/exynos4-is/media-dev.c |  13 ++-
> >  drivers/media/platform/exynos4-is/mipi-csis.c |   5 +-
> >  drivers/media/v4l2-core/v4l2-of.c             | 133 +----------------------
> >  drivers/of/base.c                             | 151 ++++++++++++++++++++++++++
> >  include/linux/of_graph.h                      |  66 +++++++++++
> >  include/media/v4l2-of.h                       |  33 +-----
> >  13 files changed, 375 insertions(+), 178 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/graph.txt
> >  create mode 100644 include/linux/of_graph.h
> > 
> > 
> 


-- 

Regards,
Mauro

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

[Grant Likely]

On Mon, 10 Mar 2014 10:26:30 -0300, Mauro Carvalho Chehab <m.chehab@samsung.com> wrote:
> Em Fri, 07 Mar 2014 18:23:30 +0000
> Grant Likely <grant.likely@linaro.org> escreveu:
> 
> > On Thu, 06 Mar 2014 18:13:20 +0100, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > > Hi Mauro, Russell,
> > > 
> > > I have temporarily removed the simplified bindings at Sylwester's
> > > request and updated the branch with the acks. The following changes
> > > since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
> > > 
> > >   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.pengutronix.de/git/pza/linux.git topic/of-graph
> > > 
> > > for you to fetch changes up to d484700a36952c6675aa47dec4d7a536929aa922:
> > > 
> > >   of: Warn if of_graph_parse_endpoint is called with the root node (2014-03-06 17:41:54 +0100)
> > 
> > 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.
> 
> If I understood well, you're requesting to revert all those six patches
> that were imported via git pull from my tree (and from Greg and Russell),
> right?
> 
> E. g. reverting those changesets:
> 	d484700a3695 f2a575f67695 4329b93b283c 6ff60d397b17 4d56ed5a009b fd9fdb78a9bf
> 
> as it seems that there's no easy way to revert a git pull.

All trees containing the branch would need to be reverted.

> I suspect that this will likely cause some harm when merging from our
> trees upstream.

It means any tree containing that branch *must* be rewound. See my reply
to rmk. I've made a proposal on how I could be happy with leaving the
branches alone. I'm not particularly happy, but there is a way to
resolve things without reverts or rewinds.

g.

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

[Mauro Carvalho Chehab]

Em Mon, 10 Mar 2014 14:37:58 +0000
Grant Likely <grant.likely@linaro.org> escreveu:

> On Mon, 10 Mar 2014 10:26:30 -0300, Mauro Carvalho Chehab <m.chehab@samsung.com> wrote:
> > Em Fri, 07 Mar 2014 18:23:30 +0000
> > Grant Likely <grant.likely@linaro.org> escreveu:
> > 
> > > On Thu, 06 Mar 2014 18:13:20 +0100, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > > > Hi Mauro, Russell,
> > > > 
> > > > I have temporarily removed the simplified bindings at Sylwester's
> > > > request and updated the branch with the acks. The following changes
> > > > since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
> > > > 
> > > >   Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > >   git://git.pengutronix.de/git/pza/linux.git topic/of-graph
> > > > 
> > > > for you to fetch changes up to d484700a36952c6675aa47dec4d7a536929aa922:
> > > > 
> > > >   of: Warn if of_graph_parse_endpoint is called with the root node (2014-03-06 17:41:54 +0100)
> > > 
> > > 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.
> > 
> > If I understood well, you're requesting to revert all those six patches
> > that were imported via git pull from my tree (and from Greg and Russell),
> > right?
> > 
> > E. g. reverting those changesets:
> > 	d484700a3695 f2a575f67695 4329b93b283c 6ff60d397b17 4d56ed5a009b fd9fdb78a9bf
> > 
> > as it seems that there's no easy way to revert a git pull.
> 
> All trees containing the branch would need to be reverted.
> 
> > I suspect that this will likely cause some harm when merging from our
> > trees upstream.
> 
> It means any tree containing that branch *must* be rewound. 

Grr...

Done. I really preferred not doing that.

>From my side, it became too late to apply those OF changes on my tree 
for 3.15, as I will not prevent other patches to be applied on my tree
due to that.

Mauro

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

[Philipp Zabel]

Hi,

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

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.

There's also no consensus about the simplified bindings, but this is an
issue I'd like to separate from this series.

> > If I understood well, you're requesting to revert all those six patches
> > that were imported via git pull from my tree (and from Greg and Russell),
> > right?
> > 
> > E. g. reverting those changesets:
> > 	d484700a3695 f2a575f67695 4329b93b283c 6ff60d397b17 4d56ed5a009b fd9fdb78a9bf
> > 
> > as it seems that there's no easy way to revert a git pull.
> 
> All trees containing the branch would need to be reverted.
>
> > I suspect that this will likely cause some harm when merging from our
> > trees upstream.
> 
> It means any tree containing that branch *must* be rewound. See my reply
> to rmk.

> I've made a proposal on how I could be happy with leaving the
> branches alone. I'm not particularly happy, but there is a way to
> resolve things without reverts or rewinds.

I'm not sure if maybe I misunderstood or missed a mail, but I haven't
seen a proposal to resolve the situation without rewinds. Given that
Mauro already reverted the media tree and applied conflicting changes,
that's probably not going to happen?

regards
Philipp

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

[Russell King - ARM Linux]

On Thu, Mar 13, 2014 at 12:08:16PM +0100, Philipp Zabel wrote:
> I'm not sure if maybe I misunderstood or missed a mail, but I haven't
> seen a proposal to resolve the situation without rewinds. Given that
> Mauro already reverted the media tree and applied conflicting changes,
> that's probably not going to happen?

Grant and myself have exchanged emails in private on this discussing what
should happen - essentially Grant's position is that he's happy to leave
this stuff queued provided a resolution to his concerns are forthcoming.

However, what I find incredibly unfair is that we're taking the rap for
these bad bindings.  From what I can see, these bad bindings were merged
into the V4L2 code with _zero_ review by DT maintainers.  It's quite
clear that DT maintainers would have objected to them had they seen them,
but they didn't.  And the lack of documentation of the bindings which
has been something that's been insisted on is also disgusting.

And now we're now taking the pain for that oversight.

So... frankly, I've walked away from this dysfunctional situation.  I
don't see imx-drm moving out of drivers/staging due to this debacle for
many months - possibly never now given that no one can agree on this
stuff.  This just goes to show what a fscking joke mainline kernels are,
and why people just give up and go to vendor kernels which offer /much/
better support all round.

As far as I can see, it's proved impossible to define a set of bindings
for display devices which satisfy everyone.  So, rather than doing
/something/ so we can move forward, we end up doing /nothing/.

It's times like this where I start believing that /board files/ were the
best solution for ARM, because DT just carries soo many thorny issues
(such as these) and is a continual blocker.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

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

[Sylwester Nawrocki]

On 13/03/14 12:35, Russell King - ARM Linux wrote:
[...]
> Grant and myself have exchanged emails in private on this discussing what
> should happen - essentially Grant's position is that he's happy to leave
> this stuff queued provided a resolution to his concerns are forthcoming.
> 
> However, what I find incredibly unfair is that we're taking the rap for
> these bad bindings.  From what I can see, these bad bindings were merged
> into the V4L2 code with _zero_ review by DT maintainers.  It's quite
> clear that DT maintainers would have objected to them had they seen them,

Russell, it's just unfair what you're trying to impute here.  These 
bindings were floating on the mailing list for _several_ months before 
getting merged.
They were finally acked by Rob and Grant [1], [2], however it cannot be 
seen from the commits as the Ack come late, after I sent a pull request.

> but they didn't.  And the lack of documentation of the bindings which
> has been something that's been insisted on is also disgusting.
>
> And now we're now taking the pain for that oversight.
> 
> So... frankly, I've walked away from this dysfunctional situation.  I
> don't see imx-drm moving out of drivers/staging due to this debacle for
> many months - possibly never now given that no one can agree on this
> stuff.  This just goes to show what a fscking joke mainline kernels are,
> and why people just give up and go to vendor kernels which offer /much/
> better support all round.
> 
> As far as I can see, it's proved impossible to define a set of bindings
> for display devices which satisfy everyone.  So, rather than doing
> /something/ so we can move forward, we end up doing /nothing/.
> 
> It's times like this where I start believing that /board files/ were the
> best solution for ARM, because DT just carries soo many thorny issues
> (such as these) and is a continual blocker.

My experience and feelings are similar, I started to treat mainline
kernel much less seriously after similar DT related blocking issues.
An example is a simple patch series for couple drivers that was first 
posted in July 2013 and is still not merged, because the subsystem 
maintainer requires a DT binding maintainer Ack for everything and you
can wait to death to get one, specially if there are multiple iterations,
each needing attention of a DT binding maintainer. I remember opinions, 
when the process was being defined during one of the last kernel summits, 
that things may get longer to merge upstream, due to DT binding reviews. 
And that we must live with that. But these latencies are getting so 
ridiculously large that there is nothing left but to move to an 
alternative process.

Regarding moving forward doing /something/, rather than ending up
doing nothing - IMO it's the worst thing to rush DT binding being
merged upstream. I don't think an agreement can't be achieved soon, 
if not for this release then hopefully for next one.

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

[Sylwester Nawrocki]

On 13/03/14 16:13, Sylwester Nawrocki wrote:
> On 13/03/14 12:35, Russell King - ARM Linux wrote:
> [...]
>> > Grant and myself have exchanged emails in private on this discussing what
>> > should happen - essentially Grant's position is that he's happy to leave
>> > this stuff queued provided a resolution to his concerns are forthcoming.
>> > 
>> > However, what I find incredibly unfair is that we're taking the rap for
>> > these bad bindings.  From what I can see, these bad bindings were merged
>> > into the V4L2 code with _zero_ review by DT maintainers.  It's quite
>> > clear that DT maintainers would have objected to them had they seen them,
>
> Russell, it's just unfair what you're trying to impute here.  These 
> bindings were floating on the mailing list for _several_ months before 
> getting merged.
> They were finally acked by Rob and Grant [1], [2], however it cannot be 
> seen from the commits as the Ack come late, after I sent a pull request.
> 
>> > but they didn't.  And the lack of documentation of the bindings which
>> > has been something that's been insisted on is also disgusting.
>> >
>> > And now we're now taking the pain for that oversight.
>> > 
>> > So... frankly, I've walked away from this dysfunctional situation.  I
>> > don't see imx-drm moving out of drivers/staging due to this debacle for
>> > many months - possibly never now given that no one can agree on this
>> > stuff.  This just goes to show what a fscking joke mainline kernels are,
>> > and why people just give up and go to vendor kernels which offer /much/
>> > better support all round.
>> > 
>> > As far as I can see, it's proved impossible to define a set of bindings
>> > for display devices which satisfy everyone.  So, rather than doing
>> > /something/ so we can move forward, we end up doing /nothing/.
>> > 
>> > It's times like this where I start believing that /board files/ were the
>> > best solution for ARM, because DT just carries soo many thorny issues
>> > (such as these) and is a continual blocker.
>
> My experience and feelings are similar, I started to treat mainline
> kernel much less seriously after similar DT related blocking issues.
> An example is a simple patch series for couple drivers that was first 
> posted in July 2013 and is still not merged, because the subsystem 
> maintainer requires a DT binding maintainer Ack for everything and you
> can wait to death to get one, specially if there are multiple iterations,
> each needing attention of a DT binding maintainer. I remember opinions, 
> when the process was being defined during one of the last kernel summits, 
> that things may get longer to merge upstream, due to DT binding reviews. 
> And that we must live with that. But these latencies are getting so 
> ridiculously large that there is nothing left but to move to an 
> alternative process.
> 
> Regarding moving forward doing /something/, rather than ending up
> doing nothing - IMO it's the worst thing to rush DT binding being
> merged upstream. I don't think an agreement can't be achieved soon, 
> if not for this release then hopefully for next one.

Sorry about the missing links:

[1] http://www.spinics.net/lists/linux-media/msg61899.html
[2] http://www.spinics.net/lists/linux-media/msg62458.html

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

[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.

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

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.

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

> There's also no consensus about the simplified bindings, but this is an
> issue I'd like to separate from this series.
> 
> > > If I understood well, you're requesting to revert all those six patches
> > > that were imported via git pull from my tree (and from Greg and
> > > Russell), right?
> > > 
> > > E. g. reverting those changesets:
> > > 	d484700a3695 f2a575f67695 4329b93b283c 6ff60d397b17 4d56ed5a009b
> > > 	fd9fdb78a9bf
> > > as it seems that there's no easy way to revert a git pull.
> > 
> > All trees containing the branch would need to be reverted.
> > 
> > > I suspect that this will likely cause some harm when merging from our
> > > trees upstream.
> > 
> > It means any tree containing that branch *must* be rewound. See my reply
> > to rmk.
> > 
> > I've made a proposal on how I could be happy with leaving the branches
> > alone. I'm not particularly happy, but there is a way to resolve things
> > without reverts or rewinds.
> 
> I'm not sure if maybe I misunderstood or missed a mail, but I haven't seen a
> proposal to resolve the situation without rewinds. Given that Mauro already
> reverted the media tree and applied conflicting changes, that's probably not
> going to happen?

-- 
Regards,

Laurent Pinchart

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

[Robert Schwebel]

Hi,

On Thu, Mar 13, 2014 at 04:13:08PM +0100, Sylwester Nawrocki wrote:
> My experience and feelings are similar, I started to treat mainline
> kernel much less seriously after similar DT related blocking issues.

So how do we proceed now? Philipp implemented any of the suggested
variants now; nevertheless, there doesn't seem to be a consensus.

However, we really need a decision of the oftree maintainers. I think we
are fine with almost any of the available variants, as long as there is
a decision. 

It would be great if we could soon continue to address the technical
issues with the IPU, instead of turning around oftree bindings. There
is really enough complexity left :-)

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

[Philipp Zabel]

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

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

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

Hi Philipp, Grant,

On 14/03/14 14:19, Philipp Zabel wrote:

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

Yes, I'd like to reserve the possibility for double-linking. If the
endpoint links are used to tell the dataflow direction, then
double-linking could be used for bi-directional dataflows.

But this doesn't help much for the video drivers under work, which I
think we are all most interested in at the moment. We still need to
decide how we link the endpoint for those.

I'd like to go forward with the mainline v4l2 style double-linking, as
that is already in use. It would allow us to proceed _now_, and maybe
even get display support to 3.15. Otherwise this all gets delayed for
who knows how long, and the displays in question cannot be used by the
users.

Deprecating the other link later from the existing video bindings would
be trivial, as there would basically be nothing to do except remove the
other link.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Laurent Pinchart]

Hi Robert,

On Friday 14 March 2014 08:05:05 Robert Schwebel wrote:
> On Thu, Mar 13, 2014 at 04:13:08PM +0100, Sylwester Nawrocki wrote:
> > My experience and feelings are similar, I started to treat mainline
> > kernel much less seriously after similar DT related blocking issues.
> 
> So how do we proceed now? Philipp implemented any of the suggested variants
> now; nevertheless, there doesn't seem to be a consensus.
> 
> However, we really need a decision of the oftree maintainers. I think we are
> fine with almost any of the available variants, as long as there is a
> decision.
> 
> It would be great if we could soon continue to address the technical issues
> with the IPU, instead of turning around oftree bindings. There is really
> enough complexity left :-)

I agree with you. I know that DT bindings review takes too much time, slows 
development down and is just generally painful. I'm trying to reply to this e-
mail thread as fast as possible, but I'm also busy with other tasks :-/

The lack of formal consensus comes partly from the fact that people are busy 
and that the mail thread is growing big. There's still two open questions from 
my view of the whole discussion:

- Do we really want to drop bidirectional links ? Grant has been pretty vocal 
about that, but there has been several replies with arguments for 
bidirectional links, and no reply from him afterwards. Even though that 
wouldn't be the preferred solution for everybody, there doesn't seem to be a 
strong disagreement about dropping bidirectional links, as long as we can come 
up with a reasonable implementation.

- If we drop bidirectional links, what link direction do we use ? There has 
been several proposals (including "north", which I think isn't future-proof as 
it assumes an earth-centric model) and no real agreement, although there seems 
to be a consensus among several developers that the core OF graph bindings 
could leave that to be specified by subsystem bindings. We would still have to 
agree on a direction for the display subsystem of course.

If my above explanation isn't too far from the reality the next step could be 
to send a new version of the DT bindings proposal as a ping.

-- 
Regards,

Laurent Pinchart

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

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

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]

On 18/03/14 01:30, Laurent Pinchart wrote:

> I agree with you. I know that DT bindings review takes too much time, slows 
> development down and is just generally painful. I'm trying to reply to this e-
> mail thread as fast as possible, but I'm also busy with other tasks :-/
> 
> The lack of formal consensus comes partly from the fact that people are busy 
> and that the mail thread is growing big. There's still two open questions from 
> my view of the whole discussion:
> 
> - Do we really want to drop bidirectional links ? Grant has been pretty vocal 
> about that, but there has been several replies with arguments for 
> bidirectional links, and no reply from him afterwards. Even though that 
> wouldn't be the preferred solution for everybody, there doesn't seem to be a 
> strong disagreement about dropping bidirectional links, as long as we can come 
> up with a reasonable implementation.
> 
> - If we drop bidirectional links, what link direction do we use ? There has 
> been several proposals (including "north", which I think isn't future-proof as 
> it assumes an earth-centric model) and no real agreement, although there seems 
> to be a consensus among several developers that the core OF graph bindings 
> could leave that to be specified by subsystem bindings. We would still have to 
> agree on a direction for the display subsystem of course.
> 
> If my above explanation isn't too far from the reality the next step could be 
> to send a new version of the DT bindings proposal as a ping.

I agree with the above.

However, I also think we should just go forward with the bidirectional
links for now. The bindings for bidir links are already in the mainline
kernel, so they can't be seen as broken.

When we have an agreement about the direction, and we've got common
parsing code, it's trivial to convert the existing links to single
direction links, and the old dts files with bidir links continue to work
fine.

This is what I'm planning to do with OMAP display subsystem, as I
_really_ want to get the DT support merged for 3.15. The current mix of
pdata + DT that we have for OMAP display is an unmaintainable mess.

So unless I get a nack from someone (I've pinged Grant twice about
this), or someone explains why it's a bad idea, I'll push the OMAP
display bindings [1] for 3.15 with bidir bindings, and change them to
single-dir later.

Note that I did remove the abbreviated endpoint format that I had there
earlier, so now the bindings are fully compatible with the v4l2 bindings.

 Tomi

[1] http://article.gmane.org/gmane.linux.drivers.devicetree/63885



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Grant Likely]

On Thu, 13 Mar 2014 11:35:28 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Mar 13, 2014 at 12:08:16PM +0100, Philipp Zabel wrote:
> > I'm not sure if maybe I misunderstood or missed a mail, but I haven't
> > seen a proposal to resolve the situation without rewinds. Given that
> > Mauro already reverted the media tree and applied conflicting changes,
> > that's probably not going to happen?
> 
> Grant and myself have exchanged emails in private on this discussing what
> should happen - essentially Grant's position is that he's happy to leave
> this stuff queued provided a resolution to his concerns are forthcoming.
> 
> However, what I find incredibly unfair is that we're taking the rap for
> these bad bindings.  From what I can see, these bad bindings were merged
> into the V4L2 code with _zero_ review by DT maintainers.  It's quite
> clear that DT maintainers would have objected to them had they seen them,
> but they didn't.  And the lack of documentation of the bindings which
> has been something that's been insisted on is also disgusting.

When a binding is limited to a single driver, review isn't critical.
When it is local to a single subsystem the bar is a little higher. Yes,
it should have had more review, but the surface area is still minimal.
By turning the binding into a generic pattern that all subsystems are
welcome to use the bar becomes higher still. It is not unreasonable for
a binding a new round of review when it is being adapted to become more
generic.

V4L2 can and should continue to use what it has. It certainly is not
okay to break existing platforms. All of my issues are directed toward
new users.

Despite my concerns, I do want this series to get merged in the next
merge window.

g.