Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
On Thu, 13 Mar 2014 11:35:28 +, Russell King - ARM Linux li...@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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
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 signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
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 + 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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
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- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 + 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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
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 signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
Hi, Am Montag, den 10.03.2014, 14:37 + 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
Hi Philipp, On Thursday 13 March 2014 12:08:16 Philipp Zabel wrote: Am Montag, den 10.03.2014, 14:37 + 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
Em Mon, 10 Mar 2014 14:37:58 + Grant Likely grant.lik...@linaro.org escreveu: On Mon, 10 Mar 2014 10:26:30 -0300, Mauro Carvalho Chehab m.che...@samsung.com wrote: Em Fri, 07 Mar 2014 18:23:30 + Grant Likely grant.lik...@linaro.org escreveu: On Thu, 06 Mar 2014 18:13:20 +0100, Philipp Zabel p.za...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
Em Fri, 07 Mar 2014 18:23:30 + Grant Likely grant.lik...@linaro.org escreveu: On Thu, 06 Mar 2014 18:13:20 +0100, Philipp Zabel p.za...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
On Mon, 10 Mar 2014 10:26:30 -0300, Mauro Carvalho Chehab m.che...@samsung.com wrote: Em Fri, 07 Mar 2014 18:23:30 + Grant Likely grant.lik...@linaro.org escreveu: On Thu, 06 Mar 2014 18:13:20 +0100, Philipp Zabel p.za...@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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
Em Fri, 07 Mar 2014 11:55:17 + Russell King - ARM Linux li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
On Fri, Mar 07, 2014 at 09:20:31AM -0300, Mauro Carvalho Chehab wrote: Em Fri, 07 Mar 2014 11:55:17 + Russell King - ARM Linux li...@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. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of
On Thu, 06 Mar 2014 18:13:20 +0100, Philipp Zabel p.za...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Move device tree graph parsing helpers to drivers/of
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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
