All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 0/3] Support DRM bridges on NVIDIA Tegra
@ 2020-04-17 17:52 ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 17:52 UTC (permalink / raw)
  To: Thierry Reding, Sam Ravnborg, Laurent Pinchart
  Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

Hello,

This small series adds initial support for the DRM bridges to NVIDIA Tegra
DRM driver. This is required by newer device-trees where we model the LVDS
encoder bridge properly.

Changelog:

v4: - Following review comments that were made by Laurent Pinchart to the v3,
      we now create and use the "bridge connector".

v3: - Following recommendation from Sam Ravnborg, the new bridge attachment
      model is now being used, i.e. we ask bridge to *not* create a connector
      using the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.

    - The bridge is now created only for the RGB (LVDS) output, and only
      when necessary. For now we don't need bridges for HDMI or DSI outputs.

    - I noticed that we're leaking OF node in the panel's error code path,
      this is fixed now by the new patch "Don't leak OF node on error".

v2: - Added the new "rgb: Don't register connector if bridge is used"
      patch, which hides the unused connector provided by the Tegra DRM
      driver when bridge is used, since bridge provides its own connector
      to us.

    - Please notice that the first "Support DRM bridges" patch was previously
      sent out as a standalone v1 change.

Dmitry Osipenko (3):
  drm/tegra: output: Don't leak OF node on error
  drm/tegra: output: Support DRM bridges
  drm/tegra: output: rgb: Support LVDS encoder bridge

 drivers/gpu/drm/tegra/drm.h    |  2 ++
 drivers/gpu/drm/tegra/output.c | 22 +++++++++----
 drivers/gpu/drm/tegra/rgb.c    | 58 ++++++++++++++++++++++++++++------
 3 files changed, 67 insertions(+), 15 deletions(-)

-- 
2.26.0

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v4 0/3] Support DRM bridges on NVIDIA Tegra
@ 2020-04-17 17:52 ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 17:52 UTC (permalink / raw)
  To: Thierry Reding, Sam Ravnborg, Laurent Pinchart; +Cc: linux-tegra, dri-devel

Hello,

This small series adds initial support for the DRM bridges to NVIDIA Tegra
DRM driver. This is required by newer device-trees where we model the LVDS
encoder bridge properly.

Changelog:

v4: - Following review comments that were made by Laurent Pinchart to the v3,
      we now create and use the "bridge connector".

v3: - Following recommendation from Sam Ravnborg, the new bridge attachment
      model is now being used, i.e. we ask bridge to *not* create a connector
      using the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.

    - The bridge is now created only for the RGB (LVDS) output, and only
      when necessary. For now we don't need bridges for HDMI or DSI outputs.

    - I noticed that we're leaking OF node in the panel's error code path,
      this is fixed now by the new patch "Don't leak OF node on error".

v2: - Added the new "rgb: Don't register connector if bridge is used"
      patch, which hides the unused connector provided by the Tegra DRM
      driver when bridge is used, since bridge provides its own connector
      to us.

    - Please notice that the first "Support DRM bridges" patch was previously
      sent out as a standalone v1 change.

Dmitry Osipenko (3):
  drm/tegra: output: Don't leak OF node on error
  drm/tegra: output: Support DRM bridges
  drm/tegra: output: rgb: Support LVDS encoder bridge

 drivers/gpu/drm/tegra/drm.h    |  2 ++
 drivers/gpu/drm/tegra/output.c | 22 +++++++++----
 drivers/gpu/drm/tegra/rgb.c    | 58 ++++++++++++++++++++++++++++------
 3 files changed, 67 insertions(+), 15 deletions(-)

-- 
2.26.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v4 1/3] drm/tegra: output: Don't leak OF node on error
  2020-04-17 17:52 ` Dmitry Osipenko
@ 2020-04-17 17:52     ` Dmitry Osipenko
  -1 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 17:52 UTC (permalink / raw)
  To: Thierry Reding, Sam Ravnborg, Laurent Pinchart
  Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

The OF node should be put before returning error in tegra_output_probe(),
otherwise node's refcount will be leaked.

Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/gpu/drm/tegra/output.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index e36e5e7c2f69..a6a711d54e88 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -102,10 +102,10 @@ int tegra_output_probe(struct tegra_output *output)
 	panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
 	if (panel) {
 		output->panel = of_drm_find_panel(panel);
+		of_node_put(panel);
+
 		if (IS_ERR(output->panel))
 			return PTR_ERR(output->panel);
-
-		of_node_put(panel);
 	}
 
 	output->edid = of_get_property(output->of_node, "nvidia,edid", &size);
@@ -113,13 +113,12 @@ int tegra_output_probe(struct tegra_output *output)
 	ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
 	if (ddc) {
 		output->ddc = of_find_i2c_adapter_by_node(ddc);
+		of_node_put(ddc);
+
 		if (!output->ddc) {
 			err = -EPROBE_DEFER;
-			of_node_put(ddc);
 			return err;
 		}
-
-		of_node_put(ddc);
 	}
 
 	output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev,
-- 
2.26.0

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v4 1/3] drm/tegra: output: Don't leak OF node on error
@ 2020-04-17 17:52     ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 17:52 UTC (permalink / raw)
  To: Thierry Reding, Sam Ravnborg, Laurent Pinchart; +Cc: linux-tegra, dri-devel

The OF node should be put before returning error in tegra_output_probe(),
otherwise node's refcount will be leaked.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
 drivers/gpu/drm/tegra/output.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index e36e5e7c2f69..a6a711d54e88 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -102,10 +102,10 @@ int tegra_output_probe(struct tegra_output *output)
 	panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
 	if (panel) {
 		output->panel = of_drm_find_panel(panel);
+		of_node_put(panel);
+
 		if (IS_ERR(output->panel))
 			return PTR_ERR(output->panel);
-
-		of_node_put(panel);
 	}
 
 	output->edid = of_get_property(output->of_node, "nvidia,edid", &size);
@@ -113,13 +113,12 @@ int tegra_output_probe(struct tegra_output *output)
 	ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
 	if (ddc) {
 		output->ddc = of_find_i2c_adapter_by_node(ddc);
+		of_node_put(ddc);
+
 		if (!output->ddc) {
 			err = -EPROBE_DEFER;
-			of_node_put(ddc);
 			return err;
 		}
-
-		of_node_put(ddc);
 	}
 
 	output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev,
-- 
2.26.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
  2020-04-17 17:52 ` Dmitry Osipenko
@ 2020-04-17 17:52     ` Dmitry Osipenko
  -1 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 17:52 UTC (permalink / raw)
  To: Thierry Reding, Sam Ravnborg, Laurent Pinchart
  Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

Newer Tegra device-trees will specify a video output graph which involves
a bridge. This patch adds initial support for the DRM bridges to the
Tegra's DRM output.

Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/gpu/drm/tegra/drm.h    |  2 ++
 drivers/gpu/drm/tegra/output.c | 13 ++++++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 804869799305..cccd368b6752 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -12,6 +12,7 @@
 #include <linux/of_gpio.h>
 
 #include <drm/drm_atomic.h>
+#include <drm/drm_bridge.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_encoder.h>
 #include <drm/drm_fb_helper.h>
@@ -116,6 +117,7 @@ struct tegra_output {
 	struct device_node *of_node;
 	struct device *dev;
 
+	struct drm_bridge *bridge;
 	struct drm_panel *panel;
 	struct i2c_adapter *ddc;
 	const struct edid *edid;
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index a6a711d54e88..ec0cd4a1ced1 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -5,6 +5,7 @@
  */
 
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_of.h>
 #include <drm/drm_panel.h>
 #include <drm/drm_simple_kms_helper.h>
 
@@ -92,13 +93,23 @@ static irqreturn_t hpd_irq(int irq, void *data)
 
 int tegra_output_probe(struct tegra_output *output)
 {
-	struct device_node *ddc, *panel;
+	struct device_node *ddc, *panel, *port;
 	unsigned long flags;
 	int err, size;
 
 	if (!output->of_node)
 		output->of_node = output->dev->of_node;
 
+	port = of_get_child_by_name(output->of_node, "port");
+	if (port) {
+		err = drm_of_find_panel_or_bridge(output->of_node, 0, 0, NULL,
+						  &output->bridge);
+		of_node_put(port);
+
+		if (err)
+			return err;
+	}
+
 	panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
 	if (panel) {
 		output->panel = of_drm_find_panel(panel);
-- 
2.26.0

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
@ 2020-04-17 17:52     ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 17:52 UTC (permalink / raw)
  To: Thierry Reding, Sam Ravnborg, Laurent Pinchart; +Cc: linux-tegra, dri-devel

Newer Tegra device-trees will specify a video output graph which involves
a bridge. This patch adds initial support for the DRM bridges to the
Tegra's DRM output.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
 drivers/gpu/drm/tegra/drm.h    |  2 ++
 drivers/gpu/drm/tegra/output.c | 13 ++++++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 804869799305..cccd368b6752 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -12,6 +12,7 @@
 #include <linux/of_gpio.h>
 
 #include <drm/drm_atomic.h>
+#include <drm/drm_bridge.h>
 #include <drm/drm_edid.h>
 #include <drm/drm_encoder.h>
 #include <drm/drm_fb_helper.h>
@@ -116,6 +117,7 @@ struct tegra_output {
 	struct device_node *of_node;
 	struct device *dev;
 
+	struct drm_bridge *bridge;
 	struct drm_panel *panel;
 	struct i2c_adapter *ddc;
 	const struct edid *edid;
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index a6a711d54e88..ec0cd4a1ced1 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -5,6 +5,7 @@
  */
 
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_of.h>
 #include <drm/drm_panel.h>
 #include <drm/drm_simple_kms_helper.h>
 
@@ -92,13 +93,23 @@ static irqreturn_t hpd_irq(int irq, void *data)
 
 int tegra_output_probe(struct tegra_output *output)
 {
-	struct device_node *ddc, *panel;
+	struct device_node *ddc, *panel, *port;
 	unsigned long flags;
 	int err, size;
 
 	if (!output->of_node)
 		output->of_node = output->dev->of_node;
 
+	port = of_get_child_by_name(output->of_node, "port");
+	if (port) {
+		err = drm_of_find_panel_or_bridge(output->of_node, 0, 0, NULL,
+						  &output->bridge);
+		of_node_put(port);
+
+		if (err)
+			return err;
+	}
+
 	panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
 	if (panel) {
 		output->panel = of_drm_find_panel(panel);
-- 
2.26.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
  2020-04-17 17:52 ` Dmitry Osipenko
@ 2020-04-17 17:52     ` Dmitry Osipenko
  -1 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 17:52 UTC (permalink / raw)
  To: Thierry Reding, Sam Ravnborg, Laurent Pinchart
  Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

Newer Tegra device-trees will specify a video output graph, which involves
LVDS encoder bridge. This patch adds support for the LVDS encoder bridge
to the RGB output, allowing us to model the display hardware properly.

Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/gpu/drm/tegra/rgb.c | 58 +++++++++++++++++++++++++++++++------
 1 file changed, 49 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 0562a7eb793f..f28a226914c0 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -7,6 +7,7 @@
 #include <linux/clk.h>
 
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_bridge_connector.h>
 #include <drm/drm_panel.h>
 #include <drm/drm_simple_kms_helper.h>
 
@@ -267,24 +268,63 @@ int tegra_dc_rgb_remove(struct tegra_dc *dc)
 int tegra_dc_rgb_init(struct drm_device *drm, struct tegra_dc *dc)
 {
 	struct tegra_output *output = dc->rgb;
+	struct drm_connector *connector;
 	int err;
 
 	if (!dc->rgb)
 		return -ENODEV;
 
-	drm_connector_init(drm, &output->connector, &tegra_rgb_connector_funcs,
-			   DRM_MODE_CONNECTOR_LVDS);
-	drm_connector_helper_add(&output->connector,
-				 &tegra_rgb_connector_helper_funcs);
-	output->connector.dpms = DRM_MODE_DPMS_OFF;
-
 	drm_simple_encoder_init(drm, &output->encoder, DRM_MODE_ENCODER_LVDS);
 	drm_encoder_helper_add(&output->encoder,
 			       &tegra_rgb_encoder_helper_funcs);
 
-	drm_connector_attach_encoder(&output->connector,
-					  &output->encoder);
-	drm_connector_register(&output->connector);
+	/*
+	 * Tegra devices that have LVDS panel utilize LVDS encoder bridge
+	 * for converting up to 28 LCD LVTTL lanes into 5/4 LVDS lanes that
+	 * go to display panel's receiver.
+	 *
+	 * Encoder usually have a power-down control which needs to be enabled
+	 * in order to transmit data to the panel. Historically devices that
+	 * use an older device-tree version didn't model the bridge, assuming
+	 * that encoder is turned ON by default, while today's DRM allows us
+	 * to model LVDS encoder properly.
+	 *
+	 * Newer device-trees utilize LVDS encoder bridge, which provides
+	 * us with a connector and handles the display panel.
+	 *
+	 * For older device-trees we fall back to our own connector and use
+	 * nvidia,panel phandle.
+	 */
+	if (output->bridge) {
+		err = drm_bridge_attach(&output->encoder, output->bridge,
+					NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+		if (err) {
+			dev_err(output->dev, "failed to attach bridge: %d\n",
+				err);
+			return err;
+		}
+
+		connector = drm_bridge_connector_init(drm, &output->encoder);
+		if (IS_ERR(connector)) {
+			dev_err(output->dev,
+				"failed to initialize bridge connector: %pe\n",
+				connector);
+			return PTR_ERR(connector);
+		}
+
+		drm_connector_attach_encoder(connector, &output->encoder);
+	} else {
+		drm_connector_init(drm, &output->connector,
+				   &tegra_rgb_connector_funcs,
+				   DRM_MODE_CONNECTOR_LVDS);
+		drm_connector_helper_add(&output->connector,
+					 &tegra_rgb_connector_helper_funcs);
+		output->connector.dpms = DRM_MODE_DPMS_OFF;
+
+		drm_connector_attach_encoder(&output->connector,
+					     &output->encoder);
+		drm_connector_register(&output->connector);
+	}
 
 	err = tegra_output_init(drm, output);
 	if (err < 0) {
-- 
2.26.0

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
@ 2020-04-17 17:52     ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 17:52 UTC (permalink / raw)
  To: Thierry Reding, Sam Ravnborg, Laurent Pinchart; +Cc: linux-tegra, dri-devel

Newer Tegra device-trees will specify a video output graph, which involves
LVDS encoder bridge. This patch adds support for the LVDS encoder bridge
to the RGB output, allowing us to model the display hardware properly.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
 drivers/gpu/drm/tegra/rgb.c | 58 +++++++++++++++++++++++++++++++------
 1 file changed, 49 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 0562a7eb793f..f28a226914c0 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -7,6 +7,7 @@
 #include <linux/clk.h>
 
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_bridge_connector.h>
 #include <drm/drm_panel.h>
 #include <drm/drm_simple_kms_helper.h>
 
@@ -267,24 +268,63 @@ int tegra_dc_rgb_remove(struct tegra_dc *dc)
 int tegra_dc_rgb_init(struct drm_device *drm, struct tegra_dc *dc)
 {
 	struct tegra_output *output = dc->rgb;
+	struct drm_connector *connector;
 	int err;
 
 	if (!dc->rgb)
 		return -ENODEV;
 
-	drm_connector_init(drm, &output->connector, &tegra_rgb_connector_funcs,
-			   DRM_MODE_CONNECTOR_LVDS);
-	drm_connector_helper_add(&output->connector,
-				 &tegra_rgb_connector_helper_funcs);
-	output->connector.dpms = DRM_MODE_DPMS_OFF;
-
 	drm_simple_encoder_init(drm, &output->encoder, DRM_MODE_ENCODER_LVDS);
 	drm_encoder_helper_add(&output->encoder,
 			       &tegra_rgb_encoder_helper_funcs);
 
-	drm_connector_attach_encoder(&output->connector,
-					  &output->encoder);
-	drm_connector_register(&output->connector);
+	/*
+	 * Tegra devices that have LVDS panel utilize LVDS encoder bridge
+	 * for converting up to 28 LCD LVTTL lanes into 5/4 LVDS lanes that
+	 * go to display panel's receiver.
+	 *
+	 * Encoder usually have a power-down control which needs to be enabled
+	 * in order to transmit data to the panel. Historically devices that
+	 * use an older device-tree version didn't model the bridge, assuming
+	 * that encoder is turned ON by default, while today's DRM allows us
+	 * to model LVDS encoder properly.
+	 *
+	 * Newer device-trees utilize LVDS encoder bridge, which provides
+	 * us with a connector and handles the display panel.
+	 *
+	 * For older device-trees we fall back to our own connector and use
+	 * nvidia,panel phandle.
+	 */
+	if (output->bridge) {
+		err = drm_bridge_attach(&output->encoder, output->bridge,
+					NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+		if (err) {
+			dev_err(output->dev, "failed to attach bridge: %d\n",
+				err);
+			return err;
+		}
+
+		connector = drm_bridge_connector_init(drm, &output->encoder);
+		if (IS_ERR(connector)) {
+			dev_err(output->dev,
+				"failed to initialize bridge connector: %pe\n",
+				connector);
+			return PTR_ERR(connector);
+		}
+
+		drm_connector_attach_encoder(connector, &output->encoder);
+	} else {
+		drm_connector_init(drm, &output->connector,
+				   &tegra_rgb_connector_funcs,
+				   DRM_MODE_CONNECTOR_LVDS);
+		drm_connector_helper_add(&output->connector,
+					 &tegra_rgb_connector_helper_funcs);
+		output->connector.dpms = DRM_MODE_DPMS_OFF;
+
+		drm_connector_attach_encoder(&output->connector,
+					     &output->encoder);
+		drm_connector_register(&output->connector);
+	}
 
 	err = tegra_output_init(drm, output);
 	if (err < 0) {
-- 
2.26.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
  2020-04-17 17:52     ` Dmitry Osipenko
@ 2020-04-17 19:24         ` Laurent Pinchart
  -1 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 19:24 UTC (permalink / raw)
  To: Dmitry Osipenko
  Cc: Thierry Reding, Sam Ravnborg,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

Hi Dmitry,

Thank you for the patch.

On Fri, Apr 17, 2020 at 08:52:38PM +0300, Dmitry Osipenko wrote:
> Newer Tegra device-trees will specify a video output graph, which involves
> LVDS encoder bridge. This patch adds support for the LVDS encoder bridge
> to the RGB output, allowing us to model the display hardware properly.
> 
> Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/gpu/drm/tegra/rgb.c | 58 +++++++++++++++++++++++++++++++------
>  1 file changed, 49 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
> index 0562a7eb793f..f28a226914c0 100644
> --- a/drivers/gpu/drm/tegra/rgb.c
> +++ b/drivers/gpu/drm/tegra/rgb.c
> @@ -7,6 +7,7 @@
>  #include <linux/clk.h>
>  
>  #include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge_connector.h>
>  #include <drm/drm_panel.h>
>  #include <drm/drm_simple_kms_helper.h>
>  
> @@ -267,24 +268,63 @@ int tegra_dc_rgb_remove(struct tegra_dc *dc)
>  int tegra_dc_rgb_init(struct drm_device *drm, struct tegra_dc *dc)
>  {
>  	struct tegra_output *output = dc->rgb;
> +	struct drm_connector *connector;
>  	int err;
>  
>  	if (!dc->rgb)
>  		return -ENODEV;
>  
> -	drm_connector_init(drm, &output->connector, &tegra_rgb_connector_funcs,
> -			   DRM_MODE_CONNECTOR_LVDS);
> -	drm_connector_helper_add(&output->connector,
> -				 &tegra_rgb_connector_helper_funcs);
> -	output->connector.dpms = DRM_MODE_DPMS_OFF;
> -
>  	drm_simple_encoder_init(drm, &output->encoder, DRM_MODE_ENCODER_LVDS);
>  	drm_encoder_helper_add(&output->encoder,
>  			       &tegra_rgb_encoder_helper_funcs);
>  
> -	drm_connector_attach_encoder(&output->connector,
> -					  &output->encoder);
> -	drm_connector_register(&output->connector);
> +	/*
> +	 * Tegra devices that have LVDS panel utilize LVDS encoder bridge
> +	 * for converting up to 28 LCD LVTTL lanes into 5/4 LVDS lanes that
> +	 * go to display panel's receiver.
> +	 *
> +	 * Encoder usually have a power-down control which needs to be enabled
> +	 * in order to transmit data to the panel. Historically devices that
> +	 * use an older device-tree version didn't model the bridge, assuming
> +	 * that encoder is turned ON by default, while today's DRM allows us
> +	 * to model LVDS encoder properly.
> +	 *
> +	 * Newer device-trees utilize LVDS encoder bridge, which provides
> +	 * us with a connector and handles the display panel.
> +	 *
> +	 * For older device-trees we fall back to our own connector and use
> +	 * nvidia,panel phandle.

As I tried to explain before, if you wrap the panel in a bridge with
drm_panel_bridge_add() (or the devm_ variant), you will always have a
bridge associated with the output, and will be able to remove your
custom connector implementation. I thus recommend converting to
drm_panel_bridge_add() either as part of this patch series, or just
after it, to get full benefits.

With the assumption that this will be handled,

Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>

> +	 */
> +	if (output->bridge) {
> +		err = drm_bridge_attach(&output->encoder, output->bridge,
> +					NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> +		if (err) {
> +			dev_err(output->dev, "failed to attach bridge: %d\n",
> +				err);
> +			return err;
> +		}
> +
> +		connector = drm_bridge_connector_init(drm, &output->encoder);
> +		if (IS_ERR(connector)) {
> +			dev_err(output->dev,
> +				"failed to initialize bridge connector: %pe\n",
> +				connector);
> +			return PTR_ERR(connector);
> +		}
> +
> +		drm_connector_attach_encoder(connector, &output->encoder);
> +	} else {
> +		drm_connector_init(drm, &output->connector,
> +				   &tegra_rgb_connector_funcs,
> +				   DRM_MODE_CONNECTOR_LVDS);
> +		drm_connector_helper_add(&output->connector,
> +					 &tegra_rgb_connector_helper_funcs);
> +		output->connector.dpms = DRM_MODE_DPMS_OFF;
> +
> +		drm_connector_attach_encoder(&output->connector,
> +					     &output->encoder);
> +		drm_connector_register(&output->connector);
> +	}
>  
>  	err = tegra_output_init(drm, output);
>  	if (err < 0) {

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
@ 2020-04-17 19:24         ` Laurent Pinchart
  0 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 19:24 UTC (permalink / raw)
  To: Dmitry Osipenko; +Cc: linux-tegra, Thierry Reding, Sam Ravnborg, dri-devel

Hi Dmitry,

Thank you for the patch.

On Fri, Apr 17, 2020 at 08:52:38PM +0300, Dmitry Osipenko wrote:
> Newer Tegra device-trees will specify a video output graph, which involves
> LVDS encoder bridge. This patch adds support for the LVDS encoder bridge
> to the RGB output, allowing us to model the display hardware properly.
> 
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
>  drivers/gpu/drm/tegra/rgb.c | 58 +++++++++++++++++++++++++++++++------
>  1 file changed, 49 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
> index 0562a7eb793f..f28a226914c0 100644
> --- a/drivers/gpu/drm/tegra/rgb.c
> +++ b/drivers/gpu/drm/tegra/rgb.c
> @@ -7,6 +7,7 @@
>  #include <linux/clk.h>
>  
>  #include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge_connector.h>
>  #include <drm/drm_panel.h>
>  #include <drm/drm_simple_kms_helper.h>
>  
> @@ -267,24 +268,63 @@ int tegra_dc_rgb_remove(struct tegra_dc *dc)
>  int tegra_dc_rgb_init(struct drm_device *drm, struct tegra_dc *dc)
>  {
>  	struct tegra_output *output = dc->rgb;
> +	struct drm_connector *connector;
>  	int err;
>  
>  	if (!dc->rgb)
>  		return -ENODEV;
>  
> -	drm_connector_init(drm, &output->connector, &tegra_rgb_connector_funcs,
> -			   DRM_MODE_CONNECTOR_LVDS);
> -	drm_connector_helper_add(&output->connector,
> -				 &tegra_rgb_connector_helper_funcs);
> -	output->connector.dpms = DRM_MODE_DPMS_OFF;
> -
>  	drm_simple_encoder_init(drm, &output->encoder, DRM_MODE_ENCODER_LVDS);
>  	drm_encoder_helper_add(&output->encoder,
>  			       &tegra_rgb_encoder_helper_funcs);
>  
> -	drm_connector_attach_encoder(&output->connector,
> -					  &output->encoder);
> -	drm_connector_register(&output->connector);
> +	/*
> +	 * Tegra devices that have LVDS panel utilize LVDS encoder bridge
> +	 * for converting up to 28 LCD LVTTL lanes into 5/4 LVDS lanes that
> +	 * go to display panel's receiver.
> +	 *
> +	 * Encoder usually have a power-down control which needs to be enabled
> +	 * in order to transmit data to the panel. Historically devices that
> +	 * use an older device-tree version didn't model the bridge, assuming
> +	 * that encoder is turned ON by default, while today's DRM allows us
> +	 * to model LVDS encoder properly.
> +	 *
> +	 * Newer device-trees utilize LVDS encoder bridge, which provides
> +	 * us with a connector and handles the display panel.
> +	 *
> +	 * For older device-trees we fall back to our own connector and use
> +	 * nvidia,panel phandle.

As I tried to explain before, if you wrap the panel in a bridge with
drm_panel_bridge_add() (or the devm_ variant), you will always have a
bridge associated with the output, and will be able to remove your
custom connector implementation. I thus recommend converting to
drm_panel_bridge_add() either as part of this patch series, or just
after it, to get full benefits.

With the assumption that this will be handled,

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> +	 */
> +	if (output->bridge) {
> +		err = drm_bridge_attach(&output->encoder, output->bridge,
> +					NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> +		if (err) {
> +			dev_err(output->dev, "failed to attach bridge: %d\n",
> +				err);
> +			return err;
> +		}
> +
> +		connector = drm_bridge_connector_init(drm, &output->encoder);
> +		if (IS_ERR(connector)) {
> +			dev_err(output->dev,
> +				"failed to initialize bridge connector: %pe\n",
> +				connector);
> +			return PTR_ERR(connector);
> +		}
> +
> +		drm_connector_attach_encoder(connector, &output->encoder);
> +	} else {
> +		drm_connector_init(drm, &output->connector,
> +				   &tegra_rgb_connector_funcs,
> +				   DRM_MODE_CONNECTOR_LVDS);
> +		drm_connector_helper_add(&output->connector,
> +					 &tegra_rgb_connector_helper_funcs);
> +		output->connector.dpms = DRM_MODE_DPMS_OFF;
> +
> +		drm_connector_attach_encoder(&output->connector,
> +					     &output->encoder);
> +		drm_connector_register(&output->connector);
> +	}
>  
>  	err = tegra_output_init(drm, output);
>  	if (err < 0) {

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
  2020-04-17 17:52     ` Dmitry Osipenko
@ 2020-04-17 19:30         ` Laurent Pinchart
  -1 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 19:30 UTC (permalink / raw)
  To: Dmitry Osipenko
  Cc: Thierry Reding, Sam Ravnborg,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

Hi Dmitry,

Thank you for the patch.

On Fri, Apr 17, 2020 at 08:52:37PM +0300, Dmitry Osipenko wrote:
> Newer Tegra device-trees will specify a video output graph which involves
> a bridge. This patch adds initial support for the DRM bridges to the
> Tegra's DRM output.
> 
> Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/gpu/drm/tegra/drm.h    |  2 ++
>  drivers/gpu/drm/tegra/output.c | 13 ++++++++++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 804869799305..cccd368b6752 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -12,6 +12,7 @@
>  #include <linux/of_gpio.h>
>  
>  #include <drm/drm_atomic.h>
> +#include <drm/drm_bridge.h>

You could add a forward declaration of struct drm_bridge instead, that
can lower the compilation time a little bit.

>  #include <drm/drm_edid.h>
>  #include <drm/drm_encoder.h>
>  #include <drm/drm_fb_helper.h>
> @@ -116,6 +117,7 @@ struct tegra_output {
>  	struct device_node *of_node;
>  	struct device *dev;
>  
> +	struct drm_bridge *bridge;
>  	struct drm_panel *panel;
>  	struct i2c_adapter *ddc;
>  	const struct edid *edid;
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index a6a711d54e88..ec0cd4a1ced1 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -5,6 +5,7 @@
>   */
>  
>  #include <drm/drm_atomic_helper.h>
> +#include <drm/drm_of.h>
>  #include <drm/drm_panel.h>
>  #include <drm/drm_simple_kms_helper.h>
>  
> @@ -92,13 +93,23 @@ static irqreturn_t hpd_irq(int irq, void *data)
>  
>  int tegra_output_probe(struct tegra_output *output)
>  {
> -	struct device_node *ddc, *panel;
> +	struct device_node *ddc, *panel, *port;
>  	unsigned long flags;
>  	int err, size;
>  
>  	if (!output->of_node)
>  		output->of_node = output->dev->of_node;
>  
> +	port = of_get_child_by_name(output->of_node, "port");

Do you need to check for the presence of a port node first ? Can you
just check the return value of drm_of_find_panel_or_bridge(), and fall
back to "nvidia,panel" if it returns -ENODEV ?

> +	if (port) {
> +		err = drm_of_find_panel_or_bridge(output->of_node, 0, 0, NULL,
> +						  &output->bridge);
> +		of_node_put(port);
> +
> +		if (err)
> +			return err;
> +	}
> +
>  	panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
>  	if (panel) {
>  		output->panel = of_drm_find_panel(panel);

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
@ 2020-04-17 19:30         ` Laurent Pinchart
  0 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 19:30 UTC (permalink / raw)
  To: Dmitry Osipenko; +Cc: linux-tegra, Thierry Reding, Sam Ravnborg, dri-devel

Hi Dmitry,

Thank you for the patch.

On Fri, Apr 17, 2020 at 08:52:37PM +0300, Dmitry Osipenko wrote:
> Newer Tegra device-trees will specify a video output graph which involves
> a bridge. This patch adds initial support for the DRM bridges to the
> Tegra's DRM output.
> 
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
>  drivers/gpu/drm/tegra/drm.h    |  2 ++
>  drivers/gpu/drm/tegra/output.c | 13 ++++++++++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 804869799305..cccd368b6752 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -12,6 +12,7 @@
>  #include <linux/of_gpio.h>
>  
>  #include <drm/drm_atomic.h>
> +#include <drm/drm_bridge.h>

You could add a forward declaration of struct drm_bridge instead, that
can lower the compilation time a little bit.

>  #include <drm/drm_edid.h>
>  #include <drm/drm_encoder.h>
>  #include <drm/drm_fb_helper.h>
> @@ -116,6 +117,7 @@ struct tegra_output {
>  	struct device_node *of_node;
>  	struct device *dev;
>  
> +	struct drm_bridge *bridge;
>  	struct drm_panel *panel;
>  	struct i2c_adapter *ddc;
>  	const struct edid *edid;
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index a6a711d54e88..ec0cd4a1ced1 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -5,6 +5,7 @@
>   */
>  
>  #include <drm/drm_atomic_helper.h>
> +#include <drm/drm_of.h>
>  #include <drm/drm_panel.h>
>  #include <drm/drm_simple_kms_helper.h>
>  
> @@ -92,13 +93,23 @@ static irqreturn_t hpd_irq(int irq, void *data)
>  
>  int tegra_output_probe(struct tegra_output *output)
>  {
> -	struct device_node *ddc, *panel;
> +	struct device_node *ddc, *panel, *port;
>  	unsigned long flags;
>  	int err, size;
>  
>  	if (!output->of_node)
>  		output->of_node = output->dev->of_node;
>  
> +	port = of_get_child_by_name(output->of_node, "port");

Do you need to check for the presence of a port node first ? Can you
just check the return value of drm_of_find_panel_or_bridge(), and fall
back to "nvidia,panel" if it returns -ENODEV ?

> +	if (port) {
> +		err = drm_of_find_panel_or_bridge(output->of_node, 0, 0, NULL,
> +						  &output->bridge);
> +		of_node_put(port);
> +
> +		if (err)
> +			return err;
> +	}
> +
>  	panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
>  	if (panel) {
>  		output->panel = of_drm_find_panel(panel);

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
  2020-04-17 19:30         ` Laurent Pinchart
@ 2020-04-17 19:41             ` Dmitry Osipenko
  -1 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 19:41 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Thierry Reding, Sam Ravnborg,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

Hello Laurent,

17.04.2020 22:30, Laurent Pinchart пишет:
...
>>  #include <drm/drm_atomic.h>
>> +#include <drm/drm_bridge.h>
> 
> You could add a forward declaration of struct drm_bridge instead, that
> can lower the compilation time a little bit.

This include is not only for the struct, but also for the
drm_bridge_attach(). It looks to me that it should be nicer to keep the
include here.

...
>> +	port = of_get_child_by_name(output->of_node, "port");
> 
> Do you need to check for the presence of a port node first ? Can you
> just check the return value of drm_of_find_panel_or_bridge(), and fall
> back to "nvidia,panel" if it returns -ENODEV ?

Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
error message about missing port node for every output that doesn't have
a graph specified in a device-tree (HDMI, DSI and etc).

https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
@ 2020-04-17 19:41             ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 19:41 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-tegra, Thierry Reding, Sam Ravnborg, dri-devel

Hello Laurent,

17.04.2020 22:30, Laurent Pinchart пишет:
...
>>  #include <drm/drm_atomic.h>
>> +#include <drm/drm_bridge.h>
> 
> You could add a forward declaration of struct drm_bridge instead, that
> can lower the compilation time a little bit.

This include is not only for the struct, but also for the
drm_bridge_attach(). It looks to me that it should be nicer to keep the
include here.

...
>> +	port = of_get_child_by_name(output->of_node, "port");
> 
> Do you need to check for the presence of a port node first ? Can you
> just check the return value of drm_of_find_panel_or_bridge(), and fall
> back to "nvidia,panel" if it returns -ENODEV ?

Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
error message about missing port node for every output that doesn't have
a graph specified in a device-tree (HDMI, DSI and etc).

https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
  2020-04-17 19:24         ` Laurent Pinchart
@ 2020-04-17 20:11             ` Dmitry Osipenko
  -1 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 20:11 UTC (permalink / raw)
  To: Laurent Pinchart, Thierry Reding
  Cc: Sam Ravnborg, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

17.04.2020 22:24, Laurent Pinchart пишет:
...
> As I tried to explain before, if you wrap the panel in a bridge with
> drm_panel_bridge_add() (or the devm_ variant), you will always have a
> bridge associated with the output, and will be able to remove your
> custom connector implementation. I thus recommend converting to
> drm_panel_bridge_add() either as part of this patch series, or just
> after it, to get full benefits.
> 
> With the assumption that this will be handled,
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>

Thanks you very much!

Yes, I got yours point about wrapping panel into the bridge. But I don't
think that it's worth the effort right now because each Tegra output has
it's own implantation of the connector and it should be cleaner not to
touch that code.

Secondly, I don't have hardware to test all available panel output types
on Tegra and the benefits of messing with all that code are a bit dim to me.

I can make a patch to wrap the RGB panel into a bridge, but this should
make code a bit inconsistent in regards to not having a common code path
for the "legacy" nvidia,panel. So perhaps it's better to leave it all
as-is for now.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
@ 2020-04-17 20:11             ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 20:11 UTC (permalink / raw)
  To: Laurent Pinchart, Thierry Reding; +Cc: linux-tegra, Sam Ravnborg, dri-devel

17.04.2020 22:24, Laurent Pinchart пишет:
...
> As I tried to explain before, if you wrap the panel in a bridge with
> drm_panel_bridge_add() (or the devm_ variant), you will always have a
> bridge associated with the output, and will be able to remove your
> custom connector implementation. I thus recommend converting to
> drm_panel_bridge_add() either as part of this patch series, or just
> after it, to get full benefits.
> 
> With the assumption that this will be handled,
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Thanks you very much!

Yes, I got yours point about wrapping panel into the bridge. But I don't
think that it's worth the effort right now because each Tegra output has
it's own implantation of the connector and it should be cleaner not to
touch that code.

Secondly, I don't have hardware to test all available panel output types
on Tegra and the benefits of messing with all that code are a bit dim to me.

I can make a patch to wrap the RGB panel into a bridge, but this should
make code a bit inconsistent in regards to not having a common code path
for the "legacy" nvidia,panel. So perhaps it's better to leave it all
as-is for now.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
  2020-04-17 19:41             ` Dmitry Osipenko
@ 2020-04-17 20:31                 ` Laurent Pinchart
  -1 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 20:31 UTC (permalink / raw)
  To: Dmitry Osipenko
  Cc: Thierry Reding, Sam Ravnborg,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

Hi Dmitry,

On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
> 17.04.2020 22:30, Laurent Pinchart пишет:
> ...
> >>  #include <drm/drm_atomic.h>
> >> +#include <drm/drm_bridge.h>
> > 
> > You could add a forward declaration of struct drm_bridge instead, that
> > can lower the compilation time a little bit.
> 
> This include is not only for the struct, but also for the
> drm_bridge_attach(). It looks to me that it should be nicer to keep the
> include here.

drm_bridge_attach() is called from .c files. In the .h file you can use
a forward declaration. It's entirely up to you, but as a general rule, I
personally try to use forward structure declarations in .h files as much
as possible.

> ...
> >> +	port = of_get_child_by_name(output->of_node, "port");
> > 
> > Do you need to check for the presence of a port node first ? Can you
> > just check the return value of drm_of_find_panel_or_bridge(), and fall
> > back to "nvidia,panel" if it returns -ENODEV ?
> 
> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
> error message about missing port node for every output that doesn't have
> a graph specified in a device-tree (HDMI, DSI and etc).
> 
> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621

Ah yes indeed. That's not very nice.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
@ 2020-04-17 20:31                 ` Laurent Pinchart
  0 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 20:31 UTC (permalink / raw)
  To: Dmitry Osipenko; +Cc: linux-tegra, Thierry Reding, Sam Ravnborg, dri-devel

Hi Dmitry,

On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
> 17.04.2020 22:30, Laurent Pinchart пишет:
> ...
> >>  #include <drm/drm_atomic.h>
> >> +#include <drm/drm_bridge.h>
> > 
> > You could add a forward declaration of struct drm_bridge instead, that
> > can lower the compilation time a little bit.
> 
> This include is not only for the struct, but also for the
> drm_bridge_attach(). It looks to me that it should be nicer to keep the
> include here.

drm_bridge_attach() is called from .c files. In the .h file you can use
a forward declaration. It's entirely up to you, but as a general rule, I
personally try to use forward structure declarations in .h files as much
as possible.

> ...
> >> +	port = of_get_child_by_name(output->of_node, "port");
> > 
> > Do you need to check for the presence of a port node first ? Can you
> > just check the return value of drm_of_find_panel_or_bridge(), and fall
> > back to "nvidia,panel" if it returns -ENODEV ?
> 
> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
> error message about missing port node for every output that doesn't have
> a graph specified in a device-tree (HDMI, DSI and etc).
> 
> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621

Ah yes indeed. That's not very nice.

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
  2020-04-17 20:11             ` Dmitry Osipenko
@ 2020-04-17 20:34                 ` Laurent Pinchart
  -1 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 20:34 UTC (permalink / raw)
  To: Dmitry Osipenko
  Cc: Thierry Reding, Sam Ravnborg,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

On Fri, Apr 17, 2020 at 11:11:06PM +0300, Dmitry Osipenko wrote:
> 17.04.2020 22:24, Laurent Pinchart пишет:
> ...
> > As I tried to explain before, if you wrap the panel in a bridge with
> > drm_panel_bridge_add() (or the devm_ variant), you will always have a
> > bridge associated with the output, and will be able to remove your
> > custom connector implementation. I thus recommend converting to
> > drm_panel_bridge_add() either as part of this patch series, or just
> > after it, to get full benefits.
> > 
> > With the assumption that this will be handled,
> > 
> > Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> 
> Thanks you very much!
> 
> Yes, I got yours point about wrapping panel into the bridge. But I don't
> think that it's worth the effort right now because each Tegra output has
> it's own implantation of the connector and it should be cleaner not to
> touch that code.
> 
> Secondly, I don't have hardware to test all available panel output types
> on Tegra and the benefits of messing with all that code are a bit dim to me.
> 
> I can make a patch to wrap the RGB panel into a bridge, but this should
> make code a bit inconsistent in regards to not having a common code path
> for the "legacy" nvidia,panel. So perhaps it's better to leave it all
> as-is for now.

I had a brief look at the code, converting the different output types
one by one would be a better way forward than not doing anything at all
in my opinion :-) Once you convert the first output it will also serve
as an example on how to do it, and hopefully other developers with
access to hardware could then do more conversions.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
@ 2020-04-17 20:34                 ` Laurent Pinchart
  0 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 20:34 UTC (permalink / raw)
  To: Dmitry Osipenko; +Cc: linux-tegra, Thierry Reding, Sam Ravnborg, dri-devel

On Fri, Apr 17, 2020 at 11:11:06PM +0300, Dmitry Osipenko wrote:
> 17.04.2020 22:24, Laurent Pinchart пишет:
> ...
> > As I tried to explain before, if you wrap the panel in a bridge with
> > drm_panel_bridge_add() (or the devm_ variant), you will always have a
> > bridge associated with the output, and will be able to remove your
> > custom connector implementation. I thus recommend converting to
> > drm_panel_bridge_add() either as part of this patch series, or just
> > after it, to get full benefits.
> > 
> > With the assumption that this will be handled,
> > 
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Thanks you very much!
> 
> Yes, I got yours point about wrapping panel into the bridge. But I don't
> think that it's worth the effort right now because each Tegra output has
> it's own implantation of the connector and it should be cleaner not to
> touch that code.
> 
> Secondly, I don't have hardware to test all available panel output types
> on Tegra and the benefits of messing with all that code are a bit dim to me.
> 
> I can make a patch to wrap the RGB panel into a bridge, but this should
> make code a bit inconsistent in regards to not having a common code path
> for the "legacy" nvidia,panel. So perhaps it's better to leave it all
> as-is for now.

I had a brief look at the code, converting the different output types
one by one would be a better way forward than not doing anything at all
in my opinion :-) Once you convert the first output it will also serve
as an example on how to do it, and hopefully other developers with
access to hardware could then do more conversions.

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
  2020-04-17 20:34                 ` Laurent Pinchart
@ 2020-04-17 20:51                     ` Dmitry Osipenko
  -1 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 20:51 UTC (permalink / raw)
  To: Laurent Pinchart, Thierry Reding
  Cc: Sam Ravnborg, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

17.04.2020 23:34, Laurent Pinchart пишет:
> On Fri, Apr 17, 2020 at 11:11:06PM +0300, Dmitry Osipenko wrote:
>> 17.04.2020 22:24, Laurent Pinchart пишет:
>> ...
>>> As I tried to explain before, if you wrap the panel in a bridge with
>>> drm_panel_bridge_add() (or the devm_ variant), you will always have a
>>> bridge associated with the output, and will be able to remove your
>>> custom connector implementation. I thus recommend converting to
>>> drm_panel_bridge_add() either as part of this patch series, or just
>>> after it, to get full benefits.
>>>
>>> With the assumption that this will be handled,
>>>
>>> Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>>
>> Thanks you very much!
>>
>> Yes, I got yours point about wrapping panel into the bridge. But I don't
>> think that it's worth the effort right now because each Tegra output has
>> it's own implantation of the connector and it should be cleaner not to
>> touch that code.
>>
>> Secondly, I don't have hardware to test all available panel output types
>> on Tegra and the benefits of messing with all that code are a bit dim to me.
>>
>> I can make a patch to wrap the RGB panel into a bridge, but this should
>> make code a bit inconsistent in regards to not having a common code path
>> for the "legacy" nvidia,panel. So perhaps it's better to leave it all
>> as-is for now.
> 
> I had a brief look at the code, converting the different output types
> one by one would be a better way forward than not doing anything at all
> in my opinion :-) Once you convert the first output it will also serve
> as an example on how to do it, and hopefully other developers with
> access to hardware could then do more conversions.
> 

Thierry, would you want to have RGB panel converted into a bridge? If
yes, I'll make a v5 with that change.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge
@ 2020-04-17 20:51                     ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 20:51 UTC (permalink / raw)
  To: Laurent Pinchart, Thierry Reding; +Cc: linux-tegra, Sam Ravnborg, dri-devel

17.04.2020 23:34, Laurent Pinchart пишет:
> On Fri, Apr 17, 2020 at 11:11:06PM +0300, Dmitry Osipenko wrote:
>> 17.04.2020 22:24, Laurent Pinchart пишет:
>> ...
>>> As I tried to explain before, if you wrap the panel in a bridge with
>>> drm_panel_bridge_add() (or the devm_ variant), you will always have a
>>> bridge associated with the output, and will be able to remove your
>>> custom connector implementation. I thus recommend converting to
>>> drm_panel_bridge_add() either as part of this patch series, or just
>>> after it, to get full benefits.
>>>
>>> With the assumption that this will be handled,
>>>
>>> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>
>> Thanks you very much!
>>
>> Yes, I got yours point about wrapping panel into the bridge. But I don't
>> think that it's worth the effort right now because each Tegra output has
>> it's own implantation of the connector and it should be cleaner not to
>> touch that code.
>>
>> Secondly, I don't have hardware to test all available panel output types
>> on Tegra and the benefits of messing with all that code are a bit dim to me.
>>
>> I can make a patch to wrap the RGB panel into a bridge, but this should
>> make code a bit inconsistent in regards to not having a common code path
>> for the "legacy" nvidia,panel. So perhaps it's better to leave it all
>> as-is for now.
> 
> I had a brief look at the code, converting the different output types
> one by one would be a better way forward than not doing anything at all
> in my opinion :-) Once you convert the first output it will also serve
> as an example on how to do it, and hopefully other developers with
> access to hardware could then do more conversions.
> 

Thierry, would you want to have RGB panel converted into a bridge? If
yes, I'll make a v5 with that change.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
  2020-04-17 20:31                 ` Laurent Pinchart
@ 2020-04-17 20:52                     ` Dmitry Osipenko
  -1 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 20:52 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Thierry Reding, Sam Ravnborg,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

17.04.2020 23:31, Laurent Pinchart пишет:
> Hi Dmitry,
> 
> On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
>> 17.04.2020 22:30, Laurent Pinchart пишет:
>> ...
>>>>  #include <drm/drm_atomic.h>
>>>> +#include <drm/drm_bridge.h>
>>>
>>> You could add a forward declaration of struct drm_bridge instead, that
>>> can lower the compilation time a little bit.
>>
>> This include is not only for the struct, but also for the
>> drm_bridge_attach(). It looks to me that it should be nicer to keep the
>> include here.
> 
> drm_bridge_attach() is called from .c files. In the .h file you can use
> a forward declaration. It's entirely up to you, but as a general rule, I
> personally try to use forward structure declarations in .h files as much
> as possible.

The current Tegra DRM code is a bit inconsistent in regards to having
forward declarations, it doesn't have them more than have.

I'll add a forward declaration if there will be need to make a v5, ok?

>> ...
>>>> +	port = of_get_child_by_name(output->of_node, "port");
>>>
>>> Do you need to check for the presence of a port node first ? Can you
>>> just check the return value of drm_of_find_panel_or_bridge(), and fall
>>> back to "nvidia,panel" if it returns -ENODEV ?
>>
>> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
>> error message about missing port node for every output that doesn't have
>> a graph specified in a device-tree (HDMI, DSI and etc).
>>
>> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621
> 
> Ah yes indeed. That's not very nice.
> 

Please let me know if you'll have a better idea about how this could be
handled.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
@ 2020-04-17 20:52                     ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-17 20:52 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-tegra, Thierry Reding, Sam Ravnborg, dri-devel

17.04.2020 23:31, Laurent Pinchart пишет:
> Hi Dmitry,
> 
> On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
>> 17.04.2020 22:30, Laurent Pinchart пишет:
>> ...
>>>>  #include <drm/drm_atomic.h>
>>>> +#include <drm/drm_bridge.h>
>>>
>>> You could add a forward declaration of struct drm_bridge instead, that
>>> can lower the compilation time a little bit.
>>
>> This include is not only for the struct, but also for the
>> drm_bridge_attach(). It looks to me that it should be nicer to keep the
>> include here.
> 
> drm_bridge_attach() is called from .c files. In the .h file you can use
> a forward declaration. It's entirely up to you, but as a general rule, I
> personally try to use forward structure declarations in .h files as much
> as possible.

The current Tegra DRM code is a bit inconsistent in regards to having
forward declarations, it doesn't have them more than have.

I'll add a forward declaration if there will be need to make a v5, ok?

>> ...
>>>> +	port = of_get_child_by_name(output->of_node, "port");
>>>
>>> Do you need to check for the presence of a port node first ? Can you
>>> just check the return value of drm_of_find_panel_or_bridge(), and fall
>>> back to "nvidia,panel" if it returns -ENODEV ?
>>
>> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
>> error message about missing port node for every output that doesn't have
>> a graph specified in a device-tree (HDMI, DSI and etc).
>>
>> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621
> 
> Ah yes indeed. That's not very nice.
> 

Please let me know if you'll have a better idea about how this could be
handled.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
  2020-04-17 20:52                     ` Dmitry Osipenko
@ 2020-04-17 20:58                         ` Laurent Pinchart
  -1 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 20:58 UTC (permalink / raw)
  To: Dmitry Osipenko
  Cc: Thierry Reding, Sam Ravnborg,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

Hi Dmitry,

On Fri, Apr 17, 2020 at 11:52:11PM +0300, Dmitry Osipenko wrote:
> 17.04.2020 23:31, Laurent Pinchart пишет:
> > On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
> >> 17.04.2020 22:30, Laurent Pinchart пишет:
> >> ...
> >>>>  #include <drm/drm_atomic.h>
> >>>> +#include <drm/drm_bridge.h>
> >>>
> >>> You could add a forward declaration of struct drm_bridge instead, that
> >>> can lower the compilation time a little bit.
> >>
> >> This include is not only for the struct, but also for the
> >> drm_bridge_attach(). It looks to me that it should be nicer to keep the
> >> include here.
> > 
> > drm_bridge_attach() is called from .c files. In the .h file you can use
> > a forward declaration. It's entirely up to you, but as a general rule, I
> > personally try to use forward structure declarations in .h files as much
> > as possible.
> 
> The current Tegra DRM code is a bit inconsistent in regards to having
> forward declarations, it doesn't have them more than have.
> 
> I'll add a forward declaration if there will be need to make a v5, ok?

It's up to you, you don't have to use a forward declaration if you don't
want to, I was just pointing out what I think is a best practice rule
:-)

> >> ...
> >>>> +	port = of_get_child_by_name(output->of_node, "port");
> >>>
> >>> Do you need to check for the presence of a port node first ? Can you
> >>> just check the return value of drm_of_find_panel_or_bridge(), and fall
> >>> back to "nvidia,panel" if it returns -ENODEV ?
> >>
> >> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
> >> error message about missing port node for every output that doesn't have
> >> a graph specified in a device-tree (HDMI, DSI and etc).
> >>
> >> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621
> > 
> > Ah yes indeed. That's not very nice.
> 
> Please let me know if you'll have a better idea about how this could be
> handled.

It should be good enough as-is I think. You may however want to support
both "port" and "ports", as even when there's a single port node, it
could be put inside a ports node.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
@ 2020-04-17 20:58                         ` Laurent Pinchart
  0 siblings, 0 replies; 28+ messages in thread
From: Laurent Pinchart @ 2020-04-17 20:58 UTC (permalink / raw)
  To: Dmitry Osipenko; +Cc: linux-tegra, Thierry Reding, Sam Ravnborg, dri-devel

Hi Dmitry,

On Fri, Apr 17, 2020 at 11:52:11PM +0300, Dmitry Osipenko wrote:
> 17.04.2020 23:31, Laurent Pinchart пишет:
> > On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
> >> 17.04.2020 22:30, Laurent Pinchart пишет:
> >> ...
> >>>>  #include <drm/drm_atomic.h>
> >>>> +#include <drm/drm_bridge.h>
> >>>
> >>> You could add a forward declaration of struct drm_bridge instead, that
> >>> can lower the compilation time a little bit.
> >>
> >> This include is not only for the struct, but also for the
> >> drm_bridge_attach(). It looks to me that it should be nicer to keep the
> >> include here.
> > 
> > drm_bridge_attach() is called from .c files. In the .h file you can use
> > a forward declaration. It's entirely up to you, but as a general rule, I
> > personally try to use forward structure declarations in .h files as much
> > as possible.
> 
> The current Tegra DRM code is a bit inconsistent in regards to having
> forward declarations, it doesn't have them more than have.
> 
> I'll add a forward declaration if there will be need to make a v5, ok?

It's up to you, you don't have to use a forward declaration if you don't
want to, I was just pointing out what I think is a best practice rule
:-)

> >> ...
> >>>> +	port = of_get_child_by_name(output->of_node, "port");
> >>>
> >>> Do you need to check for the presence of a port node first ? Can you
> >>> just check the return value of drm_of_find_panel_or_bridge(), and fall
> >>> back to "nvidia,panel" if it returns -ENODEV ?
> >>
> >> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
> >> error message about missing port node for every output that doesn't have
> >> a graph specified in a device-tree (HDMI, DSI and etc).
> >>
> >> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621
> > 
> > Ah yes indeed. That's not very nice.
> 
> Please let me know if you'll have a better idea about how this could be
> handled.

It should be good enough as-is I think. You may however want to support
both "port" and "ports", as even when there's a single port node, it
could be put inside a ports node.

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
  2020-04-17 20:58                         ` Laurent Pinchart
@ 2020-04-18 14:16                             ` Dmitry Osipenko
  -1 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-18 14:16 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Thierry Reding, Sam Ravnborg,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA

17.04.2020 23:58, Laurent Pinchart пишет:
> Hi Dmitry,
> 
> On Fri, Apr 17, 2020 at 11:52:11PM +0300, Dmitry Osipenko wrote:
>> 17.04.2020 23:31, Laurent Pinchart пишет:
>>> On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
>>>> 17.04.2020 22:30, Laurent Pinchart пишет:
>>>> ...
>>>>>>  #include <drm/drm_atomic.h>
>>>>>> +#include <drm/drm_bridge.h>
>>>>>
>>>>> You could add a forward declaration of struct drm_bridge instead, that
>>>>> can lower the compilation time a little bit.
>>>>
>>>> This include is not only for the struct, but also for the
>>>> drm_bridge_attach(). It looks to me that it should be nicer to keep the
>>>> include here.
>>>
>>> drm_bridge_attach() is called from .c files. In the .h file you can use
>>> a forward declaration. It's entirely up to you, but as a general rule, I
>>> personally try to use forward structure declarations in .h files as much
>>> as possible.
>>
>> The current Tegra DRM code is a bit inconsistent in regards to having
>> forward declarations, it doesn't have them more than have.
>>
>> I'll add a forward declaration if there will be need to make a v5, ok?
> 
> It's up to you, you don't have to use a forward declaration if you don't
> want to, I was just pointing out what I think is a best practice rule
> :-)

Alright, then I'll leave the include as-is in this patch since it should
be better to keep the code consistent even if it's a bit less optimal
than it could be, IMO.

We may return to cleaning up of driver includes later on.

>>>> ...
>>>>>> +	port = of_get_child_by_name(output->of_node, "port");
>>>>>
>>>>> Do you need to check for the presence of a port node first ? Can you
>>>>> just check the return value of drm_of_find_panel_or_bridge(), and fall
>>>>> back to "nvidia,panel" if it returns -ENODEV ?
>>>>
>>>> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
>>>> error message about missing port node for every output that doesn't have
>>>> a graph specified in a device-tree (HDMI, DSI and etc).
>>>>
>>>> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621
>>>
>>> Ah yes indeed. That's not very nice.
>>
>> Please let me know if you'll have a better idea about how this could be
>> handled.
> 
> It should be good enough as-is I think. You may however want to support
> both "port" and "ports", as even when there's a single port node, it
> could be put inside a ports node.
> 

I'll make a v5 that will have additional patches for making
drm_of_find_panel_or_bridge() to better handle that case.

While at it, I'll also add a patch that will wrap RGB panel into bridge.

Thank you very much for the reviews!

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
@ 2020-04-18 14:16                             ` Dmitry Osipenko
  0 siblings, 0 replies; 28+ messages in thread
From: Dmitry Osipenko @ 2020-04-18 14:16 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linux-tegra, Thierry Reding, Sam Ravnborg, dri-devel

17.04.2020 23:58, Laurent Pinchart пишет:
> Hi Dmitry,
> 
> On Fri, Apr 17, 2020 at 11:52:11PM +0300, Dmitry Osipenko wrote:
>> 17.04.2020 23:31, Laurent Pinchart пишет:
>>> On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
>>>> 17.04.2020 22:30, Laurent Pinchart пишет:
>>>> ...
>>>>>>  #include <drm/drm_atomic.h>
>>>>>> +#include <drm/drm_bridge.h>
>>>>>
>>>>> You could add a forward declaration of struct drm_bridge instead, that
>>>>> can lower the compilation time a little bit.
>>>>
>>>> This include is not only for the struct, but also for the
>>>> drm_bridge_attach(). It looks to me that it should be nicer to keep the
>>>> include here.
>>>
>>> drm_bridge_attach() is called from .c files. In the .h file you can use
>>> a forward declaration. It's entirely up to you, but as a general rule, I
>>> personally try to use forward structure declarations in .h files as much
>>> as possible.
>>
>> The current Tegra DRM code is a bit inconsistent in regards to having
>> forward declarations, it doesn't have them more than have.
>>
>> I'll add a forward declaration if there will be need to make a v5, ok?
> 
> It's up to you, you don't have to use a forward declaration if you don't
> want to, I was just pointing out what I think is a best practice rule
> :-)

Alright, then I'll leave the include as-is in this patch since it should
be better to keep the code consistent even if it's a bit less optimal
than it could be, IMO.

We may return to cleaning up of driver includes later on.

>>>> ...
>>>>>> +	port = of_get_child_by_name(output->of_node, "port");
>>>>>
>>>>> Do you need to check for the presence of a port node first ? Can you
>>>>> just check the return value of drm_of_find_panel_or_bridge(), and fall
>>>>> back to "nvidia,panel" if it returns -ENODEV ?
>>>>
>>>> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
>>>> error message about missing port node for every output that doesn't have
>>>> a graph specified in a device-tree (HDMI, DSI and etc).
>>>>
>>>> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621
>>>
>>> Ah yes indeed. That's not very nice.
>>
>> Please let me know if you'll have a better idea about how this could be
>> handled.
> 
> It should be good enough as-is I think. You may however want to support
> both "port" and "ports", as even when there's a single port node, it
> could be put inside a ports node.
> 

I'll make a v5 that will have additional patches for making
drm_of_find_panel_or_bridge() to better handle that case.

While at it, I'll also add a patch that will wrap RGB panel into bridge.

Thank you very much for the reviews!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2020-04-20  6:55 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-17 17:52 [PATCH v4 0/3] Support DRM bridges on NVIDIA Tegra Dmitry Osipenko
2020-04-17 17:52 ` Dmitry Osipenko
     [not found] ` <20200417175238.27154-1-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 17:52   ` [PATCH v4 1/3] drm/tegra: output: Don't leak OF node on error Dmitry Osipenko
2020-04-17 17:52     ` Dmitry Osipenko
2020-04-17 17:52   ` [PATCH v4 2/3] drm/tegra: output: Support DRM bridges Dmitry Osipenko
2020-04-17 17:52     ` Dmitry Osipenko
     [not found]     ` <20200417175238.27154-3-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 19:30       ` Laurent Pinchart
2020-04-17 19:30         ` Laurent Pinchart
     [not found]         ` <20200417193018.GI5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-17 19:41           ` Dmitry Osipenko
2020-04-17 19:41             ` Dmitry Osipenko
     [not found]             ` <0acc35fd-a74b-e726-7a16-55db13265c39-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 20:31               ` Laurent Pinchart
2020-04-17 20:31                 ` Laurent Pinchart
     [not found]                 ` <20200417203154.GK5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-17 20:52                   ` Dmitry Osipenko
2020-04-17 20:52                     ` Dmitry Osipenko
     [not found]                     ` <15002e6e-de36-899f-0d28-896c67a29a49-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 20:58                       ` Laurent Pinchart
2020-04-17 20:58                         ` Laurent Pinchart
     [not found]                         ` <20200417205828.GM5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-18 14:16                           ` Dmitry Osipenko
2020-04-18 14:16                             ` Dmitry Osipenko
2020-04-17 17:52   ` [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge Dmitry Osipenko
2020-04-17 17:52     ` Dmitry Osipenko
     [not found]     ` <20200417175238.27154-4-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 19:24       ` Laurent Pinchart
2020-04-17 19:24         ` Laurent Pinchart
     [not found]         ` <20200417192453.GH5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-17 20:11           ` Dmitry Osipenko
2020-04-17 20:11             ` Dmitry Osipenko
     [not found]             ` <598c81ef-ba22-a832-0822-e08023f3dff6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 20:34               ` Laurent Pinchart
2020-04-17 20:34                 ` Laurent Pinchart
     [not found]                 ` <20200417203435.GL5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-17 20:51                   ` Dmitry Osipenko
2020-04-17 20:51                     ` Dmitry Osipenko

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.