This patch series considers a port node outbound for panel device node, including dt binding for it. And also it fixes a wrong error type.
P.s., I already posted relevant patch series[1] before but missed dt binding. So please, ignore the patch series - I couldn't search the patch series on google.com so couldn't link it.
Thanks, Inki Dae
[1] [PATCH 0/2] drm/exynos: dp: add of_graph dt binding for panel device
Inki Dae (3): drm/exynos: dp: add of_graph dt binding support for panel drm/exynos: dp: fix wrong return type dt-bindings: exynos-dp: update ports node binding for panel
.../bindings/display/exynos/exynos_dp.txt | 28 ++++++++++++++++++---- drivers/gpu/drm/exynos/exynos_dp_core.c | 27 ++++++++++++++++++--- 2 files changed, 48 insertions(+), 7 deletions(-)
This patch adds of_graph dt binding support for panel device and also keeps the backward compatibility.
i.e., The dts file for Exynos5800 based peach pi board has a panel property so we need to keep the backward compatibility.
Changelog v3: - bind only one of two nodes outbound - panel or bridge.
Changelog v2: - return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae inki.dae@samsung.com --- drivers/gpu/drm/exynos/exynos_dp_core.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index 94f02a0..60260a0 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = { static int exynos_dp_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; - struct device_node *panel_node, *bridge_node, *endpoint; + struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL; struct exynos_dp_device *dp; int ret;
@@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dp);
+ /* This is for the backward compatibility. */ panel_node = of_parse_phandle(dev->of_node, "panel", 0); if (panel_node) { dp->panel = of_drm_find_panel(panel_node); of_node_put(panel_node); if (!dp->panel) return -EPROBE_DEFER; + } else { + endpoint = of_graph_get_next_endpoint(dev->of_node, NULL); + if (endpoint) { + panel_node = of_graph_get_remote_port_parent(endpoint); + if (panel_node) { + dp->panel = of_drm_find_panel(panel_node); + of_node_put(panel_node); + if (!dp->panel) + return -EPROBE_DEFER; + } else { + DRM_ERROR("no port node for panel device.\n"); + return -EINVAL; + } + } }
+ if (endpoint) + goto out; + endpoint = of_graph_get_next_endpoint(dev->of_node, NULL); if (endpoint) { bridge_node = of_graph_get_remote_port_parent(endpoint); @@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device *pdev) return -EPROBE_DEFER; }
+out: pm_runtime_enable(dev);
ret = component_add(&pdev->dev, &exynos_dp_ops);
Hello Inki,
I found that v2 of this patch is alredy in your exynos-drm for-next branch so so I had to revert it in linux-next to apply this one to test. You shouldn't push patches that were still not reviewed (specially the ones that weren't tested like this one) to your branch that gets pulled by -next. The idea of -next is to have some test coverage but it should be as stable as possible.
On 12/03/2015 06:30 AM, Inki Dae wrote:
This patch adds of_graph dt binding support for panel device and also keeps the backward compatibility.
i.e., The dts file for Exynos5800 based peach pi board has a panel property so we need to keep the backward compatibility.
Changelog v3:
- bind only one of two nodes outbound - panel or bridge.
This patch fixes one of the comments I had for v2 but I've another comment below.
Changelog v2:
- return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae inki.dae@samsung.com
drivers/gpu/drm/exynos/exynos_dp_core.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index 94f02a0..60260a0 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = { static int exynos_dp_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev;
- struct device_node *panel_node, *bridge_node, *endpoint;
- struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL; struct exynos_dp_device *dp; int ret;
@@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dp);
- /* This is for the backward compatibility. */ panel_node = of_parse_phandle(dev->of_node, "panel", 0); if (panel_node) { dp->panel = of_drm_find_panel(panel_node); of_node_put(panel_node); if (!dp->panel) return -EPROBE_DEFER;
- } else {
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);if (endpoint) {panel_node = of_graph_get_remote_port_parent(endpoint);
Here is asssumed that the endpoint will be a panel but it could be that there is no "panel" phandle but the port is for a bridge chip (i.e: Peach Pit) so this assumption seems fragile to me.
That's what I meant when I said "Assuming you can make a distinction if the endpoint is a panel or a bridge" in the other thread.
if (panel_node) {dp->panel = of_drm_find_panel(panel_node);of_node_put(panel_node);if (!dp->panel)return -EPROBE_DEFER;} else {DRM_ERROR("no port node for panel device.\n");return -EINVAL;}}}
if (endpoint)
goto out;
Ok, so IIUC what's done here is to test if the panel lookup failed, then the endpoint is looked up again but this time a call to of_drm_find_bridge() is made instead of a call to of_drm_find_panel(). I wonder if there is a better way to do this...
In any case then I think you should test if (panel_node) instead of endpoint.
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL); if (endpoint) { bridge_node = of_graph_get_remote_port_parent(endpoint); @@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device *pdev) return -EPROBE_DEFER; }
+out: pm_runtime_enable(dev);
ret = component_add(&pdev->dev, &exynos_dp_ops);
I can't think of a better way to lookup either a panel or a bridge though and I'm not that familiar with DRM so with the correct check, the patch looks good to me.
Reviewed-by: Javier Martinez Canillas javier@osg.samsung.com
Also on an Exynos5800 Peach Pi with the DTS patch I shared, the display is working correctly and also I tested without the DTS patch to make sure that it does not cause a regression for older DTBs.
Tested-by: Javier Martinez Canillas javier@osg.samsung.com
Best regards,
Hi Javier,
2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
Hello Inki,
I found that v2 of this patch is alredy in your exynos-drm for-next branch so so I had to revert it in linux-next to apply this one to test. You shouldn't push patches that were still not reviewed (specially the ones that weren't tested like this one) to your branch that gets pulled by -next. The idea of -next is to have some test coverage but it should be as stable as possible.
exynos-drm/for-next branch is not really for-next branch. This branch is used only for integration test. As you know, there are many exynos maintainers and they have their own repository. So we would need to test the integration. For this, exynos-drm/for-next is merged to linux-next not Dave's tree. Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and tested patches will be merged to exynos-drm-next.
On 12/03/2015 06:30 AM, Inki Dae wrote:
This patch adds of_graph dt binding support for panel device and also keeps the backward compatibility.
i.e., The dts file for Exynos5800 based peach pi board has a panel property so we need to keep the backward compatibility.
Changelog v3:
- bind only one of two nodes outbound - panel or bridge.
This patch fixes one of the comments I had for v2 but I've another comment below.
Changelog v2:
- return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae inki.dae@samsung.com
drivers/gpu/drm/exynos/exynos_dp_core.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index 94f02a0..60260a0 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = { static int exynos_dp_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev;
- struct device_node *panel_node, *bridge_node, *endpoint;
- struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL; struct exynos_dp_device *dp; int ret;
@@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dp);
- /* This is for the backward compatibility. */ panel_node = of_parse_phandle(dev->of_node, "panel", 0); if (panel_node) { dp->panel = of_drm_find_panel(panel_node); of_node_put(panel_node); if (!dp->panel) return -EPROBE_DEFER;
- } else {
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);if (endpoint) {panel_node = of_graph_get_remote_port_parent(endpoint);Here is asssumed that the endpoint will be a panel but it could be that there is no "panel" phandle but the port is for a bridge chip (i.e: Peach Pit) so this assumption seems fragile to me.
That's what I meant when I said "Assuming you can make a distinction if the endpoint is a panel or a bridge" in the other thread.
if (panel_node) {dp->panel = of_drm_find_panel(panel_node);of_node_put(panel_node);if (!dp->panel)return -EPROBE_DEFER;} else {DRM_ERROR("no port node for panel device.\n");return -EINVAL;}}}
if (endpoint)
goto out;Ok, so IIUC what's done here is to test if the panel lookup failed, then the endpoint is looked up again but this time a call to of_drm_find_bridge() is made instead of a call to of_drm_find_panel(). I wonder if there is a better way to do this...
In any case then I think you should test if (panel_node) instead of endpoint.
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL); if (endpoint) { bridge_node = of_graph_get_remote_port_parent(endpoint); @@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device *pdev) return -EPROBE_DEFER; }
+out: pm_runtime_enable(dev);
ret = component_add(&pdev->dev, &exynos_dp_ops);
I can't think of a better way to lookup either a panel or a bridge though and I'm not that familiar with DRM so with the correct check, the patch looks good to me.
Reviewed-by: Javier Martinez Canillas javier@osg.samsung.com
Also on an Exynos5800 Peach Pi with the DTS patch I shared, the display is working correctly and also I tested without the DTS patch to make sure that it does not cause a regression for older DTBs.
Tested-by: Javier Martinez Canillas javier@osg.samsung.com
Thanks, Inki Dae
Best regards,
Hello Inki,
On 12/04/2015 06:00 AM, Inki Dae wrote:
Hi Javier,
2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
Hello Inki,
I found that v2 of this patch is alredy in your exynos-drm for-next branch so so I had to revert it in linux-next to apply this one to test. You shouldn't push patches that were still not reviewed (specially the ones that weren't tested like this one) to your branch that gets pulled by -next. The idea of -next is to have some test coverage but it should be as stable as possible.
exynos-drm/for-next branch is not really for-next branch. This branch is used
Well, it is a for-next branch because is pulled by -next. It is listed in: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Tr...
drm-exynos git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next
only for integration test. As you know, there are many exynos maintainers and they have their own repository. So we would need to test the integration.
Integration testing is of course very needed and linux-next is for that but what should be tested are the patches that are targeted to mainline.
For this, exynos-drm/for-next is merged to linux-next not Dave's tree. Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and tested patches will be merged to exynos-drm-next.
In that case, exynos-drm-next is what should be pulled by linux-next, no the for-next branch. Linux-next is a simulation of what Torvalds would do next so problems are found earlier, ideally before the patches land into mainline.
Best regards,
Hi Javier,
2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas javier@osg.samsung.com:
Hello Inki,
On 12/04/2015 06:00 AM, Inki Dae wrote:
Hi Javier,
2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
Hello Inki,
I found that v2 of this patch is alredy in your exynos-drm for-next branch so so I had to revert it in linux-next to apply this one to test. You shouldn't push patches that were still not reviewed (specially the ones that weren't tested like this one) to your branch that gets pulled by -next. The idea of -next is to have some test coverage but it should be as stable as possible.
exynos-drm/for-next branch is not really for-next branch. This branch is used
Well, it is a for-next branch because is pulled by -next. It is listed in: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Tr...
drm-exynos git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next
only for integration test. As you know, there are many exynos maintainers and they have their own repository. So we would need to test the integration.
Integration testing is of course very needed and linux-next is for that but what should be tested are the patches that are targeted to mainline.
For this, exynos-drm/for-next is merged to linux-next not Dave's tree. Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and tested patches will be merged to exynos-drm-next.
In that case, exynos-drm-next is what should be pulled by linux-next, no the for-next branch. Linux-next is a simulation of what Torvalds would do next so problems are found earlier, ideally before the patches land into mainline.
Seems I didn't comment enough. exynos-drm/for-next branch includes all patches of exynos-drm-next and actually, they keep same patches for most time but sometimes, I merge additional patches only to exynos-drm/for-next, which should be more tested with other trees before going to Dave's tree.
One more thing, there is other difference between exynos-drm-next and exynos-drm/for-next. That is all patches of exynos-drm-next are merged on top of based on Dave's drm-next branch. On the other hand, all of exynos-drm/for-next are merged on top of mainline. So if exynos-drm-next is merged to linux-next then all patches will be conflicted with Dave's tree because his branch is also merged to linux-next.
I'm not sure that other maintainers always keep only the for-next branch in their repository but in my case, I use exynos-drm/for-next branch for the test before going to drm-next. Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree will also be pulled by linux-next, which would allow exynos-drm-next to be tested altogether again before going to mainline.
Thanks, Inki Dae
Best regards,
Javier Martinez Canillas Open Source Group Samsung Research America _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hello Inki,
On 12/04/2015 11:57 AM, Inki Dae wrote:
Hi Javier,
2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas javier@osg.samsung.com:
Hello Inki,
On 12/04/2015 06:00 AM, Inki Dae wrote:
Hi Javier,
2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
Hello Inki,
I found that v2 of this patch is alredy in your exynos-drm for-next branch so so I had to revert it in linux-next to apply this one to test. You shouldn't push patches that were still not reviewed (specially the ones that weren't tested like this one) to your branch that gets pulled by -next. The idea of -next is to have some test coverage but it should be as stable as possible.
exynos-drm/for-next branch is not really for-next branch. This branch is used
Well, it is a for-next branch because is pulled by -next. It is listed in: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Tr...
drm-exynos git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next
only for integration test. As you know, there are many exynos maintainers and they have their own repository. So we would need to test the integration.
Integration testing is of course very needed and linux-next is for that but what should be tested are the patches that are targeted to mainline.
For this, exynos-drm/for-next is merged to linux-next not Dave's tree. Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and tested patches will be merged to exynos-drm-next.
In that case, exynos-drm-next is what should be pulled by linux-next, no the for-next branch. Linux-next is a simulation of what Torvalds would do next so problems are found earlier, ideally before the patches land into mainline.
Seems I didn't comment enough. exynos-drm/for-next branch includes all patches of exynos-drm-next and actually, they keep same patches for most time but sometimes, I merge additional patches only to exynos-drm/for-next, which should be more tested with other trees before going to Dave's tree.
Ok, but unreviewed and more importantly untested patches should not go to to exynos-drm/for-next because those will be made available in linux-next and can cause issues.
Only patches that are known to be good and have been reviewed/acked should go there.
One more thing, there is other difference between exynos-drm-next and exynos-drm/for-next. That is all patches of exynos-drm-next are merged on top of based on Dave's drm-next branch. On the other hand, all of exynos-drm/for-next are merged on top of mainline. So if exynos-drm-next
It's OK if you keep a different branch because you need a different base before sending your pull request but IMHO the patches in both branches should always be the same.
is merged to linux-next then all patches will be conflicted with Dave's tree because his branch is also merged to linux-next.
I'm not sure that other maintainers always keep only the for-next branch in their repository but in my case, I use exynos-drm/for-next branch for the test before going to drm-next. Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree will also be pulled by linux-next, which would allow exynos-drm-next to be tested altogether again before going to mainline.
This should be a common problem for subsystems with different levels of maintainership. I'm not a subsystem maintainer so I don't know how this should be solved but I thought that git merge would take care of this when both trees are pulled by linux-next.
Maybe Krzysztof can comment on this since he has to do the same for the Exynos SoC support? He maintains a for-next branch and has to send pull request to Kukjin (and sometimes may need to rebase on top of Kukjin's tree) but both trees are pulled by linux-next to test.
Thanks, Inki Dae
Best regards,
This patch fixes wrong return type when dt binding of bridge device failed.
If a board has a bridge device then of_graph_get_remote_port_parent function shouldn't be NULL. So this patch will return a proper error type so that the deferred probe isn't triggered.
Changelog v2: - return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae inki.dae@samsung.com Reviewed-by: Javier Martinez Canillas javier@osg.samsung.com --- drivers/gpu/drm/exynos/exynos_dp_core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index 60260a0..aeee60a 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1437,8 +1437,10 @@ static int exynos_dp_probe(struct platform_device *pdev) of_node_put(bridge_node); if (!dp->ptn_bridge) return -EPROBE_DEFER; - } else - return -EPROBE_DEFER; + } else { + DRM_ERROR("no port node for bridge device.\n"); + return -EINVAL; + } }
out:
This patch updates a ports node binding for panel.
With this, dp node can have a ports node which describes a remote endpoint node that can be connected to panel or bridge node.
Signed-off-by: Inki Dae inki.dae@samsung.com --- .../bindings/display/exynos/exynos_dp.txt | 28 ++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt index 64693f2..15b52cb 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt @@ -66,8 +66,15 @@ Optional properties for dp-controller: Hotplug detect GPIO. Indicates which GPIO should be used for hotplug detection - -video interfaces: Device node can contain video interface port - nodes according to [1]. +Video interfaces: + Device node can contain video interface port nodes according to [1]. + The following are properties specific to those nodes: + + endpoint node connected to bridge or panel node: + - remote-endpoint: specifies the endpoint in panel or bridge node. + This node is required in all kinds of exynos dp + to represent the connection between dp and bridge + ,or dp and panel.
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -111,9 +118,22 @@ Board Specific portion: };
ports { - port@0 { + #address-cells = <1>; + #size-cells = <0>; + + port { dp_out: endpoint { - remote-endpoint = <&bridge_in>; + remote-endpoint = <&dp_in>; + }; + }; + }; + + panel@0 { + reg = <0>; + ... + port { + dp_in: endpoint { + remote-endpoint = <&dp_out>; }; }; };
Hello Inki,
On 12/03/2015 06:30 AM, Inki Dae wrote:
This patch updates a ports node binding for panel.
With this, dp node can have a ports node which describes a remote endpoint node that can be connected to panel or bridge node.
Signed-off-by: Inki Dae inki.dae@samsung.com
.../bindings/display/exynos/exynos_dp.txt | 28 ++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt index 64693f2..15b52cb 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt @@ -66,8 +66,15 @@ Optional properties for dp-controller: Hotplug detect GPIO. Indicates which GPIO should be used for hotplug detection
- -video interfaces: Device node can contain video interface port
nodes according to [1].+Video interfaces:
- Device node can contain video interface port nodes according to [1].
- The following are properties specific to those nodes:
- endpoint node connected to bridge or panel node:
- remote-endpoint: specifies the endpoint in panel or bridge node.
This node is required in all kinds of exynos dpto represent the connection between dp and bridge,or dp and panel.
This is nice but I think the DT binding should also document that it uses a phandle to define the connection with the panel (but explain that is deprecated). If only so people looking at a DTS and then going to the DT binding can understand why there is two ways to define the same.
@@ -111,9 +118,22 @@ Board Specific portion: };
ports {
port@0 {
#address-cells = <1>;#size-cells = <0>;
These two properties are only needed when there is more than 2 ports and a reg property is used to number the port nodes but I don't think that's the case for Exynos DP and certainly is not the case in this example so I think you should just remove them.
port { dp_out: endpoint {
remote-endpoint = <&bridge_in>;
remote-endpoint = <&dp_in>;};};};panel@0 {reg = <0>;...port {dp_in: endpoint {remote-endpoint = <&dp_out>; }; };
The rest looks good to me so with the two changes feel free to add:
Reviewed-by: Javier Martinez Canillas javier@osg.samsung.com
Best regards,
Hi Javier,
2015년 12월 03일 22:29에 Javier Martinez Canillas 이(가) 쓴 글:
Hello Inki,
On 12/03/2015 06:30 AM, Inki Dae wrote:
This patch updates a ports node binding for panel.
With this, dp node can have a ports node which describes a remote endpoint node that can be connected to panel or bridge node.
Signed-off-by: Inki Dae inki.dae@samsung.com
.../bindings/display/exynos/exynos_dp.txt | 28 ++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt index 64693f2..15b52cb 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt @@ -66,8 +66,15 @@ Optional properties for dp-controller: Hotplug detect GPIO. Indicates which GPIO should be used for hotplug detection
- -video interfaces: Device node can contain video interface port
nodes according to [1].+Video interfaces:
- Device node can contain video interface port nodes according to [1].
- The following are properties specific to those nodes:
- endpoint node connected to bridge or panel node:
- remote-endpoint: specifies the endpoint in panel or bridge node.
This node is required in all kinds of exynos dpto represent the connection between dp and bridge,or dp and panel.This is nice but I think the DT binding should also document that it uses a phandle to define the connection with the panel (but explain that is deprecated). If only so people looking at a DTS and then going to the DT binding can understand why there is two ways to define the same.
@@ -111,9 +118,22 @@ Board Specific portion: };
ports {
port@0 {
#address-cells = <1>;#size-cells = <0>;These two properties are only needed when there is more than 2 ports and a reg property is used to number the port nodes but I don't think that's the case for Exynos DP and certainly is not the case in this example so I think you should just remove them.
Right. I found out that the dp can have only one port outbound. Will remove them.
port { dp_out: endpoint {
remote-endpoint = <&bridge_in>;
remote-endpoint = <&dp_in>;};};};panel@0 {reg = <0>;...port {dp_in: endpoint {remote-endpoint = <&dp_out>; }; };The rest looks good to me so with the two changes feel free to add:
Reviewed-by: Javier Martinez Canillas javier@osg.samsung.com
Thanks, Inki Dae
Best regards,
On Thu, Dec 03, 2015 at 06:30:10PM +0900, Inki Dae wrote:
This patch updates a ports node binding for panel.
With this, dp node can have a ports node which describes a remote endpoint node that can be connected to panel or bridge node.
Signed-off-by: Inki Dae inki.dae@samsung.com
.../bindings/display/exynos/exynos_dp.txt | 28 ++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt index 64693f2..15b52cb 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt @@ -66,8 +66,15 @@ Optional properties for dp-controller: Hotplug detect GPIO. Indicates which GPIO should be used for hotplug detection
- -video interfaces: Device node can contain video interface port
nodes according to [1].+Video interfaces:
- Device node can contain video interface port nodes according to [1].
- The following are properties specific to those nodes:
- endpoint node connected to bridge or panel node:
- remote-endpoint: specifies the endpoint in panel or bridge node.
This node is required in all kinds of exynos dpto represent the connection between dp and bridge,or dp and panel.
Fix your punctuation.
@@ -111,9 +118,22 @@ Board Specific portion: };
ports {
port@0 {
#address-cells = <1>;#size-cells = <0>;
You don't need these.
port { dp_out: endpoint {
remote-endpoint = <&bridge_in>;
remote-endpoint = <&dp_in>;};};};panel@0 {reg = <0>;
Drop the @0 and reg as you only have 1.
...port {dp_in: endpoint {remote-endpoint = <&dp_out>; }; };-- 1.9.1
Hi Rob,
2015년 12월 04일 08:38에 Rob Herring 이(가) 쓴 글:
On Thu, Dec 03, 2015 at 06:30:10PM +0900, Inki Dae wrote:
This patch updates a ports node binding for panel.
With this, dp node can have a ports node which describes a remote endpoint node that can be connected to panel or bridge node.
Signed-off-by: Inki Dae inki.dae@samsung.com
.../bindings/display/exynos/exynos_dp.txt | 28 ++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt index 64693f2..15b52cb 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt @@ -66,8 +66,15 @@ Optional properties for dp-controller: Hotplug detect GPIO. Indicates which GPIO should be used for hotplug detection
- -video interfaces: Device node can contain video interface port
nodes according to [1].+Video interfaces:
- Device node can contain video interface port nodes according to [1].
- The following are properties specific to those nodes:
- endpoint node connected to bridge or panel node:
- remote-endpoint: specifies the endpoint in panel or bridge node.
This node is required in all kinds of exynos dpto represent the connection between dp and bridge,or dp and panel.Fix your punctuation.
Right.
@@ -111,9 +118,22 @@ Board Specific portion: };
ports {
port@0 {
#address-cells = <1>;#size-cells = <0>;You don't need these.
Ditto.
port { dp_out: endpoint {
remote-endpoint = <&bridge_in>;
remote-endpoint = <&dp_in>;};};};panel@0 {reg = <0>;Drop the @0 and reg as you only have 1.
Ditto.
Thanks, Inki Dae
...port {dp_in: endpoint {remote-endpoint = <&dp_out>; }; };-- 1.9.1
-- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dri-devel@lists.freedesktop.org
-
Inki Dae -
Inki Dae -
Javier Martinez Canillas -
Rob Herring