[PATCH v7 00/12] drm: sun4i: Convert Allwinner DSI to bridge

[PATCH v7 00/12] drm: sun4i: Convert Allwinner DSI to bridge

[Jagan Teki]

This is v7 revision of converting Allwinner DSI to brige driver.

Patch 1 and 2 implements drmm_of_dsi_get_bridge which is required to
lookup the DSI sink device represented either child or OF-graph port or
ports node. This is essential as not to break the existing bindings
which indeed uses child node represention for DSI sink devices.

Patch 3 to 7 enables the prepare_prev_first flag for essential panels
which effects sun6i-mipi-dsi host init order sequencing.

Patch 8 and 9 added endpoint 0 to dsi_in_tcon0 of A33 and A64 which is
required for I2C-Configured bridges to represent.

Patch 10 and 11 implements enable_next_first flag, which is essential
If the DSI host enables with the @enable_next_first flag then the
@enable for the DSI sink will be called first before the @enable of
the DSI host. This alter bridge init order makes sure that the MIPI-DCS
commands send first and then switch to the HS mode properly by DSI host.

Patch 12 is final patch bridge conversion.

Series has been tested in DSI Panel, DSI Bridge and I2C-Configured DSI
Bridge.

v6:
https://lore.kernel.org/all/20211210111711.2072660-1-jagan@amarulasolutions.com/
v5:
https://lore.kernel.org/all/20211122065223.88059-4-jagan@amarulasolutions.com/

Any inputs?
Jagan.

Jagan Teki (12):
  drm: of: Lookup if child node has DSI panel or bridge
  drm: bridge: panel: Implement drmm_of_dsi_get_bridge helper
  drm: panel: feiyang-fy07024di26a30d: Enable prepare_prev_first flag
  drm: panel: sitronix-st7701: Enable prepare_prev_first for ts8550b
  drm: panel: sitronix-st7703: Enable prepare_prev_first for xbd599
  drm: panel: feixin-k101-im2ba02: Enable prepare_prev_first flag
  drm: panel: ilitek-ili9881c: Enable prepare_prev_first for k101_im2byl02
  ARM: dts: sun8i: a33: Add endpoint@0 to dsi_in_tcon0
  arm64: dts: rockchip: a64: Add endpoint@0 to dsi_in_tcon0
  drm/bridge: Implement enable_next_first to alter bridge init order
  drm/bridge: Document bridge init order with enable_next_first
  drm: sun4: dsi: Convert to bridge driver

 arch/arm/boot/dts/sun8i-a33.dtsi              |   6 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |   6 +-
 drivers/gpu/drm/bridge/panel.c                |  34 ++++
 drivers/gpu/drm/drm_bridge.c                  | 186 +++++++++++++++---
 drivers/gpu/drm/drm_of.c                      | 112 +++++++++--
 .../gpu/drm/panel/panel-feixin-k101-im2ba02.c |   1 +
 .../drm/panel/panel-feiyang-fy07024di26a30d.c |   1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c |   3 +
 drivers/gpu/drm/panel/panel-sitronix-st7701.c |   3 +
 drivers/gpu/drm/panel/panel-sitronix-st7703.c |   3 +
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c        | 143 ++++++--------
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h        |  10 +-
 include/drm/drm_bridge.h                      |  18 ++
 include/drm/drm_of.h                          |  12 ++
 14 files changed, 399 insertions(+), 139 deletions(-)

-- 
2.25.1

[PATCH v7 01/12] drm: of: Lookup if child node has DSI panel or bridge

[Jagan Teki]

Devices can also be child nodes when we also control that device
through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).

Unlike the drm_of_find_panel_or_bridge helper it requires a special
case to lookup a child node of the given parent that isn't either
port or ports.

Lookup for a child DSI node of the given parent that isn't either
port or ports. If it is found then it will directly find the panel
or bridge otherwise lookup for the child node with a given port and
endpoint number as drm_of_find_panel_or_bridge does.

Supporting this feature via existing drm_of_find_panel_or_bridge
found several issues while handling usecases.

Here is the previously failed attempt of similar and the same has
been reverted later.

commit <80253168dbfd> ("drm: of: Lookup if child node has panel or bridge")

So, add a separate helper to handle this DSI use case.

An example of the downstream panel represented as a child node:

dsi {
	compatible = "allwinner,sun6i-a31-mipi-dsi";

	port {
	     dsi_in_tcon0: endpoint {
	          remote-endpoint = <tcon0_out_dsi>;
	     };
	};

	panel@0 {
	     compatible = "feixin,k101-im2ba02";
	     reg = <0>;
	};
};

An example of the downstream bridge represented as a port node:

dsi {
       compatible = "allwinner,sun6i-a31-mipi-dsi";

       port {
             dsi_in_tcon0: endpoint@0 {
	          reg = <0>;
		  remote-endpoint = <tcon0_out_dsi>;
	     };

	     dsi_out_bridge: endpoint@1 {
	   	  reg = <1>;
		  remote-endpoint = <&bridge_in_dsi>;
	     };
	};

	bridge: bridge@0 {
             compatible = "chipone,icn6211";
             reg = <0>;

	     ports {
	 	  bridge_in: port@0 {
                         reg = <0>;

                         bridge_in_dsi: endpoint {
                                remote-endpoint = <&dsi_out_bridge>;
                         };
                  };

                  bridge_out: port@1 {
                         reg = <1>;

                         bridge_out_panel: endpoint {
                                remote-endpoint = <&panel_out_bridge>;
                         };
                  };
             };
       };
};

An example of the downstream bridge represented as a ports node:

i2c4 {
       bridge@2c {
	     compatible = "ti,sn65dsi84";

             ports {
                  port@0 {
                         reg = <0>;

                         bridge_in_dsi: endpoint {
                                remote-endpoint = <&dsi_out_bridge>;
                                data-lanes = <1 2>;
                         };
                  };

	          port@2 {
	                 reg = <2>;

                         bridge_out_panel: endpoint {
                                remote-endpoint = <&panel_out_bridge>;
                         };
                  };
             };
       };
};

dsi {
       compatible = "fsl,imx8mm-mipi-dsim";

       ports {
	     port@0 {
	          reg = <0>;

	          dsi_in_lcdif: endpoint@0 {
		         reg = <0>;
		         remote-endpoint = <&lcdif_out_dsi>;
	          };
	     };

	     port@1 {
	          reg = <1>;

	          dsi_out_bridge: endpoint {
		         remote-endpoint = <&bridge_in_dsi>;
	          };
	     };
      };
};

An example of the downstream bridge represented as a child node, but
whose host neither a port nor a ports:

dsi0 {
       compatible = "ste,mcde-dsi";

       panel@0 {
             reg = <0>;
       };
};

In, summary the DSI downstream devices are likely to be Panel, Bridge
and I2C-Configured Bridge.

It is possible to connect all three devices using upstream OF-graph port
or ports node however only Panel and Bridge are possible to connect via
child node but not possible to connect I2C-Configured Bridge via child
node since I2C-Configure bridges are child of I2C not upstream DSI hosts
and it must represent them via port or ports with endpoint linking.

This indeed means, the OF-graph port or ports representation is
mandatory for I2C-Configured DSI bridges.

This patch tries to add an OF-graph port or ports representation
detection code on top of existing child node detection.

Overall, this patch makes use of a single standardized DRM helper
for a given DSI pipeline representing downstream devices as child
or OF-graph port or OF-graph ports node.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v7:
- new patch

 drivers/gpu/drm/drm_of.c | 112 ++++++++++++++++++++++++++++++++-------
 include/drm/drm_of.h     |  12 +++++
 2 files changed, 104 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 177b600895d3..87cfd685318a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -217,6 +217,35 @@ int drm_of_encoder_active_endpoint(struct device_node *node,
 }
 EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
 
+static int of_drm_find_panel_or_bridge(struct device_node *remote,
+				       struct drm_panel **panel,
+				       struct drm_bridge **bridge)
+{
+	int ret = -EPROBE_DEFER;
+
+	if (panel) {
+		*panel = of_drm_find_panel(remote);
+		if (!IS_ERR(*panel))
+			ret = 0;
+		else
+			*panel = NULL;
+	}
+
+	/* No panel found yet, check for a bridge next. */
+	if (bridge) {
+		if (ret) {
+			*bridge = of_drm_find_bridge(remote);
+			if (*bridge)
+				ret = 0;
+		} else {
+			*bridge = NULL;
+		}
+	}
+
+	of_node_put(remote);
+	return ret;
+}
+
 /**
  * drm_of_find_panel_or_bridge - return connected panel or bridge device
  * @np: device tree node containing encoder output ports
@@ -239,7 +268,6 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
 				struct drm_panel **panel,
 				struct drm_bridge **bridge)
 {
-	int ret = -EPROBE_DEFER;
 	struct device_node *remote;
 
 	if (!panel && !bridge)
@@ -260,30 +288,74 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
 	if (!remote)
 		return -ENODEV;
 
-	if (panel) {
-		*panel = of_drm_find_panel(remote);
-		if (!IS_ERR(*panel))
-			ret = 0;
-		else
-			*panel = NULL;
-	}
+	return of_drm_find_panel_or_bridge(remote, panel, bridge);
+}
+EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
 
-	/* No panel found yet, check for a bridge next. */
-	if (bridge) {
-		if (ret) {
-			*bridge = of_drm_find_bridge(remote);
-			if (*bridge)
-				ret = 0;
-		} else {
-			*bridge = NULL;
-		}
+/**
+ * drm_of_dsi_find_panel_or_bridge - return connected DSI panel or bridge device
+ * @np: device tree node containing encoder output ports
+ * @port: port in the device tree node
+ * @endpoint: endpoint in the device tree node
+ * @panel: pointer to hold returned drm_panel
+ * @bridge: pointer to hold returned drm_bridge
+ *
+ * Lookup for a child DSI node of the given parent that isn't either port
+ * or ports. If it is found then it will directly find the panel or bridge
+ * otherwise lookup for the child node with a given port and endpoint number
+ * as drm_of_find_panel_or_bridge does.
+ *
+ * Lookup a given child DSI node or a DT node's port and endpoint number,
+ * find the connected node and return either the associated struct drm_panel
+ * or drm_bridge device. Either @panel or @bridge must not be NULL.
+ *
+ * Returns zero if successful, or one of the standard error codes if it fails.
+ */
+int drm_of_dsi_find_panel_or_bridge(const struct device_node *np,
+				    int port, int endpoint,
+				    struct drm_panel **panel,
+				    struct drm_bridge **bridge)
+{
+	struct device_node *remote;
+
+	if (!panel && !bridge)
+		return -EINVAL;
+	if (panel)
+		*panel = NULL;
 
+	/**
+	 * Devices can also be child nodes when we also control that device
+	 * through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
+	 *
+	 * Lookup for a child node of the given parent that isn't either port
+	 * or ports.
+	 */
+	for_each_available_child_of_node(np, remote) {
+		if (of_node_name_eq(remote, "port") ||
+		    of_node_name_eq(remote, "ports"))
+			continue;
+
+		goto of_find_panel_or_bridge;
 	}
 
-	of_node_put(remote);
-	return ret;
+	/*
+	 * of_graph_get_remote_node() produces a noisy error message if port
+	 * node isn't found and the absence of the port is a legit case here,
+	 * so at first we silently check whether graph presents in the
+	 * device-tree node.
+	 */
+	if (!of_graph_is_present(np))
+		return -ENODEV;
+
+	remote = of_graph_get_remote_node(np, port, endpoint);
+
+of_find_panel_or_bridge:
+	if (!remote)
+		return -ENODEV;
+
+	return of_drm_find_panel_or_bridge(remote, panel, bridge);
 }
-EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+EXPORT_SYMBOL_GPL(drm_of_dsi_find_panel_or_bridge);
 
 enum drm_of_lvds_pixels {
 	DRM_OF_LVDS_EVEN = BIT(0),
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 082a6e980d01..5e0d958121ce 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -49,6 +49,10 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
 				int port, int endpoint,
 				struct drm_panel **panel,
 				struct drm_bridge **bridge);
+int drm_of_dsi_find_panel_or_bridge(const struct device_node *np,
+				    int port, int endpoint,
+				    struct drm_panel **panel,
+				    struct drm_bridge **bridge);
 int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
 					  const struct device_node *port2);
 int drm_of_lvds_get_data_mapping(const struct device_node *port);
@@ -101,6 +105,14 @@ static inline int drm_of_find_panel_or_bridge(const struct device_node *np,
 	return -EINVAL;
 }
 
+static inline int drm_of_dsi_find_panel_or_bridge(const struct device_node *np,
+						  int port, int endpoint,
+						  struct drm_panel **panel,
+						  struct drm_bridge **bridge)
+{
+	return -EINVAL;
+}
+
 static inline int
 drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
 				      const struct device_node *port2)
-- 
2.25.1

[PATCH v7 02/12] drm: bridge: panel: Implement drmm_of_dsi_get_bridge helper

[Jagan Teki]

Implement a DRM-managed action helper that returns the next DSI bridge
in the chain.

Unlike general bridge return helper drmm_of_get_bridge, this helper
uses the dsi specific panel_or_bridge helper to find the next DSI
device in the pipeline.

Helper lookup a given downstream DSI device that has been added via
child or OF-graph port or ports node.

Upstream DSI looks for downstream devices using drm pointer, port and
endpoint number. Downstream devices added via child node don't affect
the port and endpoint number arguments.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v7:
- new patch

 drivers/gpu/drm/bridge/panel.c | 34 ++++++++++++++++++++++++++++++++++
 include/drm/drm_bridge.h       | 10 ++++++++++
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index d4b112911a99..d047c7d9551d 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -501,4 +501,38 @@ struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm,
 }
 EXPORT_SYMBOL(drmm_of_get_bridge);
 
+/**
+ * drmm_of_dsi_get_bridge - Return next DSI bridge in the chain
+ * @drm: device to tie the bridge lifetime to
+ * @np: device tree node containing DSI output ports
+ * @port: port in the device tree node
+ * @endpoint: endpoint in the device tree node
+ *
+ * Given a DT node's port and endpoint number, finds the connected node
+ * and returns the associated DSI bridge if any, or creates and returns
+ * a DSI panel bridge instance if a panel is connected.
+ *
+ * Returns a drmm managed pointer to the DSI bridge if successful, or
+ * an error pointer otherwise.
+ */
+struct drm_bridge *drmm_of_dsi_get_bridge(struct drm_device *drm,
+					  struct device_node *np,
+					  u32 port, u32 endpoint)
+{
+	struct drm_bridge *bridge;
+	struct drm_panel *panel;
+	int ret;
+
+	ret = drm_of_dsi_find_panel_or_bridge(np, port, endpoint,
+					      &panel, &bridge);
+	if (ret)
+		return ERR_PTR(ret);
+
+	if (panel)
+		bridge = drmm_panel_bridge_add(drm, panel);
+
+	return bridge;
+}
+EXPORT_SYMBOL(drmm_of_dsi_get_bridge);
+
 #endif
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 42f86327b40a..a1a31704b917 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -931,6 +931,9 @@ struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct device_node
 					  u32 port, u32 endpoint);
 struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm, struct device_node *node,
 					  u32 port, u32 endpoint);
+struct drm_bridge *drmm_of_dsi_get_bridge(struct drm_device *drm,
+					  struct device_node *node,
+					  u32 port, u32 endpoint);
 #else
 static inline struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
 							struct device_node *node,
@@ -947,6 +950,13 @@ static inline struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm,
 {
 	return ERR_PTR(-ENODEV);
 }
+
+static inline struct drm_bridge *drmm_of_dsi_get_bridge(struct drm_device *drm,
+							struct device_node *node,
+							u32 port, u32 endpoint)
+{
+	return ERR_PTR(-ENODEV);
+}
 #endif
 
 #endif
-- 
2.25.1

Re: [PATCH v7 02/12] drm: bridge: panel: Implement drmm_of_dsi_get_bridge helper

[Maxime Ripard]

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

On Wed, Mar 29, 2023 at 06:46:08PM +0530, Jagan Teki wrote:
> Implement a DRM-managed action helper that returns the next DSI bridge
> in the chain.
> 
> Unlike general bridge return helper drmm_of_get_bridge, this helper
> uses the dsi specific panel_or_bridge helper to find the next DSI
> device in the pipeline.
> 
> Helper lookup a given downstream DSI device that has been added via
> child or OF-graph port or ports node.
> 
> Upstream DSI looks for downstream devices using drm pointer, port and
> endpoint number. Downstream devices added via child node don't affect
> the port and endpoint number arguments.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

If you intend to use it with the sun4i driver, then don't. The sun4i
driver is barely using drm-managed resources, so chances are all its
resources will be freed by the time this action will run.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 02/12] drm: bridge: panel: Implement drmm_of_dsi_get_bridge helper

[Jagan Teki]

On Wed, Mar 29, 2023 at 8:33 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Wed, Mar 29, 2023 at 06:46:08PM +0530, Jagan Teki wrote:
> > Implement a DRM-managed action helper that returns the next DSI bridge
> > in the chain.
> >
> > Unlike general bridge return helper drmm_of_get_bridge, this helper
> > uses the dsi specific panel_or_bridge helper to find the next DSI
> > device in the pipeline.
> >
> > Helper lookup a given downstream DSI device that has been added via
> > child or OF-graph port or ports node.
> >
> > Upstream DSI looks for downstream devices using drm pointer, port and
> > endpoint number. Downstream devices added via child node don't affect
> > the port and endpoint number arguments.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> If you intend to use it with the sun4i driver, then don't. The sun4i
> driver is barely using drm-managed resources, so chances are all its
> resources will be freed by the time this action will run.

Any idea how to check all resources will be freed before this
DRM-managed action helper runs? I did test the panel insertion and
removal at runtime and I can see that the action helper
(drmm_drm_panel_bridge_release) is triggered at removal time.

Here is the log for it.
# insmod panel-bananapi-s070wv20-icn6211.ko
[   11.411894] sun4i-drm display-engine: bound
1e00000.display-frontend (ops 0xc0951eb4)
[   11.420253] sun4i-drm display-engine: bound 1e60000.display-backend
(ops 0xc0951620)
[   11.428128] sun4i-drm display-engine: bound 1e70000.drc (ops 0xc0951150)
[   11.435574] sun4i-drm display-engine: No panel or bridge found...
RGB output disabled
[   11.443484] sun4i-drm display-engine: bound 1c0c000.lcd-controller
(ops 0xc094fdb0)
[   11.451264] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xc0952f04)
[   11.462479] [drm] Initialized sun4i-drm 1.0.0 20150629 for
display-engine on minor 1
[   11.963246] Console: switching to colour frame buffer device 100x30
[   12.046329] sun4i-drm display-engine: [drm] fb0: sun4i-drmdrmfb
frame buffer device
[   12.082641] sun6i-mipi-dsi 1ca0000.dsi: Attached device s070wv20-ct16-icn62
# rmmod panel-bananapi-s070wv20-icn6211.ko
[   16.306388] Console: switching to colour dummy device 80x30
[   16.466963] drmm_drm_panel_bridge_release: In

Thanks,
Jagan.

Re: [PATCH v7 02/12] drm: bridge: panel: Implement drmm_of_dsi_get_bridge helper

[Maxime Ripard]

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

On Wed, Mar 29, 2023 at 08:56:29PM +0530, Jagan Teki wrote:
> On Wed, Mar 29, 2023 at 8:33 PM Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > On Wed, Mar 29, 2023 at 06:46:08PM +0530, Jagan Teki wrote:
> > > Implement a DRM-managed action helper that returns the next DSI bridge
> > > in the chain.
> > >
> > > Unlike general bridge return helper drmm_of_get_bridge, this helper
> > > uses the dsi specific panel_or_bridge helper to find the next DSI
> > > device in the pipeline.
> > >
> > > Helper lookup a given downstream DSI device that has been added via
> > > child or OF-graph port or ports node.
> > >
> > > Upstream DSI looks for downstream devices using drm pointer, port and
> > > endpoint number. Downstream devices added via child node don't affect
> > > the port and endpoint number arguments.
> > >
> > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >
> > If you intend to use it with the sun4i driver, then don't. The sun4i
> > driver is barely using drm-managed resources, so chances are all its
> > resources will be freed by the time this action will run.
> 
> Any idea how to check all resources will be freed before this
> DRM-managed action helper runs? I did test the panel insertion and
> removal at runtime and I can see that the action helper
> (drmm_drm_panel_bridge_release) is triggered at removal time.
> 
> Here is the log for it.
> # insmod panel-bananapi-s070wv20-icn6211.ko
> [   11.411894] sun4i-drm display-engine: bound
> 1e00000.display-frontend (ops 0xc0951eb4)
> [   11.420253] sun4i-drm display-engine: bound 1e60000.display-backend
> (ops 0xc0951620)
> [   11.428128] sun4i-drm display-engine: bound 1e70000.drc (ops 0xc0951150)
> [   11.435574] sun4i-drm display-engine: No panel or bridge found...
> RGB output disabled
> [   11.443484] sun4i-drm display-engine: bound 1c0c000.lcd-controller
> (ops 0xc094fdb0)
> [   11.451264] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xc0952f04)
> [   11.462479] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> display-engine on minor 1
> [   11.963246] Console: switching to colour frame buffer device 100x30
> [   12.046329] sun4i-drm display-engine: [drm] fb0: sun4i-drmdrmfb
> frame buffer device
> [   12.082641] sun6i-mipi-dsi 1ca0000.dsi: Attached device s070wv20-ct16-icn62
> # rmmod panel-bananapi-s070wv20-icn6211.ko
> [   16.306388] Console: switching to colour dummy device 80x30
> [   16.466963] drmm_drm_panel_bridge_release: In

Enable KASAN, unload the DSI controller module or unbind its device,
and watch things go boom :)

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v7 03/12] drm: panel: feiyang-fy07024di26a30d: Enable prepare_prev_first flag

[Jagan Teki]

Enable the drm panel prepare_prev_first flag for feiyang-fy07024di26a30d
so-that the previous controller should be prepared first before the
prepare for the panel is called.
       
This makes sure that the previous controller(sun6i-mipi-dsi), likely to
be a DSI host controller should be initialized to LP-11 before the panel
is powered up.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v7:
- new patch

 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index df493da50afe..77d66dbe01fe 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -198,6 +198,7 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
 
 	drm_panel_init(&ctx->panel, &dsi->dev, &feiyang_funcs,
 		       DRM_MODE_CONNECTOR_DSI);
+	ctx->panel.prepare_prev_first = true;
 
 	ctx->dvdd = devm_regulator_get(&dsi->dev, "dvdd");
 	if (IS_ERR(ctx->dvdd))
-- 
2.25.1

[PATCH v7 04/12] drm: panel: sitronix-st7701: Enable prepare_prev_first for ts8550b

[Jagan Teki]

Enable the drm panel prepare_prev_first flag for ts8550b panel so-that
the previous controller should be prepared first before the prepare for
the panel is called.
           
This makes sure that the previous controller(sun6i-mipi-dsi), likely to
be a DSI host controller should be initialized to LP-11 before the panel
is powered up.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v7:
- new patch

 drivers/gpu/drm/panel/panel-sitronix-st7701.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7701.c b/drivers/gpu/drm/panel/panel-sitronix-st7701.c
index 7eae83aa0ea1..dc7677412023 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7701.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7701.c
@@ -105,6 +105,7 @@ struct st7701_panel_desc {
 	unsigned int lanes;
 	enum mipi_dsi_pixel_format format;
 	unsigned int panel_sleep_delay;
+	bool prepare_prev_first;
 
 	/* TFT matrix driver configuration, panel specific. */
 	const u8	pv_gamma[16];	/* Positive voltage gamma control */
@@ -564,6 +565,7 @@ static const struct st7701_panel_desc ts8550b_desc = {
 	.lanes = 2,
 	.format = MIPI_DSI_FMT_RGB888,
 	.panel_sleep_delay = 80, /* panel need extra 80ms for sleep out cmd */
+	.prepare_prev_first = true,
 
 	.pv_gamma = {
 		CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
@@ -875,6 +877,7 @@ static int st7701_dsi_probe(struct mipi_dsi_device *dsi)
 
 	drm_panel_init(&st7701->panel, &dsi->dev, &st7701_funcs,
 		       DRM_MODE_CONNECTOR_DSI);
+	st7701->panel.prepare_prev_first = desc->prepare_prev_first;
 
 	/**
 	 * Once sleep out has been issued, ST7701 IC required to wait 120ms
-- 
2.25.1

[PATCH v7 05/12] drm: panel: sitronix-st7703: Enable prepare_prev_first for xbd599

[Jagan Teki]

Enable the drm panel prepare_prev_first flag for xbd599 panel so-that
the previous controller should be prepared first before the prepare for
the panel is called.
               
This makes sure that the previous controller(sun6i-mipi-dsi), likely to
be a DSI host controller should be initialized to LP-11 before the panel
is powered up.

Cc: Ondrej Jirman <megous@megous.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v7:
- new patch

 drivers/gpu/drm/panel/panel-sitronix-st7703.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index 6747ca237ced..6e6112f5d971 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -65,6 +65,7 @@ struct st7703_panel_desc {
 	unsigned int lanes;
 	unsigned long mode_flags;
 	enum mipi_dsi_pixel_format format;
+	bool prepare_prev_first;
 	int (*init_sequence)(struct st7703 *ctx);
 };
 
@@ -335,6 +336,7 @@ static const struct st7703_panel_desc xbd599_desc = {
 	.lanes = 4,
 	.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
 	.format = MIPI_DSI_FMT_RGB888,
+	.prepare_prev_first = true,
 	.init_sequence = xbd599_init_sequence,
 };
 
@@ -544,6 +546,7 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
 
 	drm_panel_init(&ctx->panel, dev, &st7703_drm_funcs,
 		       DRM_MODE_CONNECTOR_DSI);
+	ctx->panel.prepare_prev_first = ctx->desc->prepare_prev_first;
 
 	ret = drm_panel_of_backlight(&ctx->panel);
 	if (ret)
-- 
2.25.1

[PATCH v7 06/12] drm: panel: feixin-k101-im2ba02: Enable prepare_prev_first flag

[Jagan Teki]

Enable the drm panel prepare_prev_first flag for feixin-k101-im2ba02
so-that the previous controller should be prepared first before the
prepare for the panel is called.
                   
This makes sure that the previous controller(sun6i-mipi-dsi), likely to
be a DSI host controller should be initialized to LP-11 before the panel
is powered up.

Cc: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v7:
- new patch

 drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
index 76572c922983..77c936496eef 100644
--- a/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
+++ b/drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c
@@ -466,6 +466,7 @@ static int k101_im2ba02_dsi_probe(struct mipi_dsi_device *dsi)
 
 	drm_panel_init(&ctx->panel, &dsi->dev, &k101_im2ba02_funcs,
 		       DRM_MODE_CONNECTOR_DSI);
+	ctx->panel.prepare_prev_first = true;
 
 	ret = drm_panel_of_backlight(&ctx->panel);
 	if (ret)
-- 
2.25.1

[PATCH v7 07/12] drm: panel: ilitek-ili9881c: Enable prepare_prev_first for k101_im2byl02

[Jagan Teki]

Enable the drm panel prepare_prev_first flag for k101_im2byl02 panel
so-that the previous controller should be prepared first before the
prepare for the panel is called.
                   
This makes sure that the previous controller(sun6i-mipi-dsi), likely to
be a DSI host controller should be initialized to LP-11 before the panel
is powered up.

Cc: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v7:
- new patch

 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 1ec696adf9de..102a1df0cea0 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -42,6 +42,7 @@ struct ili9881c_desc {
 	const size_t init_length;
 	const struct drm_display_mode *mode;
 	const unsigned long mode_flags;
+	bool prepare_prev_first;
 };
 
 struct ili9881c {
@@ -891,6 +892,7 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
 
 	drm_panel_init(&ctx->panel, &dsi->dev, &ili9881c_funcs,
 		       DRM_MODE_CONNECTOR_DSI);
+	ctx->panel.prepare_prev_first = ctx->desc->prepare_prev_first;
 
 	ctx->power = devm_regulator_get(&dsi->dev, "power");
 	if (IS_ERR(ctx->power))
@@ -942,6 +944,7 @@ static const struct ili9881c_desc k101_im2byl02_desc = {
 	.init_length = ARRAY_SIZE(k101_im2byl02_init),
 	.mode = &k101_im2byl02_default_mode,
 	.mode_flags = MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
+	.prepare_prev_first = true,
 };
 
 static const struct ili9881c_desc w552946aba_desc = {
-- 
2.25.1

[PATCH v7 08/12] ARM: dts: sun8i: a33: Add endpoint@0 to dsi_in_tcon0

[Jagan Teki]

The DSI downstream devices are likely to be Panel, Bridge and
I2C-Configured Bridge.

It is possible to connect all three devices using upstream OF-graph port
or ports node however only Panel and Bridge are possible to connect via
child node but not possible to connect I2C-Configured Bridge via child
node since I2C-Configure bridges are child of I2C not upstream DSI hosts
and it must represent them via port or ports with endpoint linking.

Allwinner R33 DSI node already has a port so add endpoint 0 for input
tcon so that the downstream DSI devices can use endpoint 1 to connect
Panel or Bridge or I2C-Configured Bridge.

An example of the I2C-Configured downstream bridge representation is,

i2c1 {
       bridge@1b {
	     compatible = "ti,dlpc3433";

             ports {
                  port@0 {
                         reg = <0>;

                         bridge_in_dsi: endpoint {
                                remote-endpoint = <&dsi_out_bridge>;
                                data-lanes = <1 2 3 4>;
                         };
                  };

	          port@2 {
	                 reg = <2>;

                         bridge_out_dmd: endpoint {
                                remote-endpoint = <&dmd_out_bridge>;
                         };
                  };
             };
       };
};

dsi {
       compatible = "allwinner,sun6i-a31-mipi-dsi";

       port {
             dsi_in_tcon0: endpoint@0 {
	          reg = <0>;
		  remote-endpoint = <tcon0_out_dsi>;
	     };

	     dsi_out_bridge: endpoint@1 {
	   	  reg = <1>;
		  remote-endpoint = <&bridge_in_dsi>;
	     };
	};
};

Note that existing device bindings are untouched and still represent
the downstream devices via child nodes since the sun6i-mipi-dsi host
will migrate to a standardized single helper to lookup for a
downstream device via child or OF-graph port or port node.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v7:
- new patch

 arch/arm/boot/dts/sun8i-a33.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index b3d1bdfb5118..50c2424ec31e 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -269,7 +269,11 @@ dsi: dsi@1ca0000 {
 			#size-cells = <0>;
 
 			port {
-				dsi_in_tcon0: endpoint {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				dsi_in_tcon0: endpoint@0 {
+					reg = <0>;
 					remote-endpoint = <&tcon0_out_dsi>;
 				};
 			};
-- 
2.25.1

[PATCH v7 09/12] arm64: dts: rockchip: a64: Add endpoint@0 to dsi_in_tcon0

[Jagan Teki]

The DSI downstream devices are likely to be Panel, Bridge and
I2C-Configured Bridge.

It is possible to connect all three devices using upstream OF-graph port
or ports node however only Panel and Bridge are possible to connect via
child node but not possible to connect I2C-Configured Bridge via child
node since I2C-Configure bridges are child of I2C not upstream DSI hosts
and it must represent them via port or ports with endpoint linking.

Allwinner A64 DSI node already has a port so add endpoint 0 for input
tcon so that the downstream DSI devices can use endpoint 1 to connect
Panel or Bridge or I2C-Configured Bridge.

An example of the I2C-Configured downstream bridge representation is,

i2c1 {
       bridge@1b {
	     compatible = "ti,dlpc3433";

             ports {
                  port@0 {
                         reg = <0>;

                         bridge_in_dsi: endpoint {
                                remote-endpoint = <&dsi_out_bridge>;
                                data-lanes = <1 2 3 4>;
                         };
                  };

	          port@2 {
	                 reg = <2>;

                         bridge_out_dmd: endpoint {
                                remote-endpoint = <&dmd_out_bridge>;
                         };
                  };
             };
       };
};

dsi {
       compatible = "allwinner,sun50i-a64-mipi-dsi";

       port {
             dsi_in_tcon0: endpoint@0 {
	          reg = <0>;
		  remote-endpoint = <tcon0_out_dsi>;
	     };

	     dsi_out_bridge: endpoint@1 {
	   	  reg = <1>;
		  remote-endpoint = <&bridge_in_dsi>;
	     };
	};
};

Note that existing device bindings are untouched and still represent
the downstream devices via child nodes since the sun6i-mipi-dsi host
will migrate to a standardized single helper to lookup for a
downstream device via child or OF-graph port or port node.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v7:
- new patch

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 77b5349f6087..3ed566dc2172 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -1189,7 +1189,11 @@ dsi: dsi@1ca0000 {
 			#size-cells = <0>;
 
 			port {
-				dsi_in_tcon0: endpoint {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				dsi_in_tcon0: endpoint@0 {
+					reg = <0>;
 					remote-endpoint = <&tcon0_out_dsi>;
 				};
 			};
-- 
2.25.1

Re: [PATCH v7 09/12] arm64: dts: rockchip: a64: Add endpoint@0 to dsi_in_tcon0

[Maxime Ripard]

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

The commit title is wrong, it's not a rockchip device.

On Wed, Mar 29, 2023 at 06:46:15PM +0530, Jagan Teki wrote:
> The DSI downstream devices are likely to be Panel, Bridge and
> I2C-Configured Bridge.
> 
> It is possible to connect all three devices using upstream OF-graph port
> or ports node however only Panel and Bridge are possible to connect via
> child node but not possible to connect I2C-Configured Bridge via child
> node since I2C-Configure bridges are child of I2C not upstream DSI hosts
> and it must represent them via port or ports with endpoint linking.
> 
> Allwinner A64 DSI node already has a port so add endpoint 0 for input
> tcon so that the downstream DSI devices can use endpoint 1 to connect
> Panel or Bridge or I2C-Configured Bridge.
> 
> An example of the I2C-Configured downstream bridge representation is,
> 
> i2c1 {
>        bridge@1b {
> 	     compatible = "ti,dlpc3433";
> 
>              ports {
>                   port@0 {
>                          reg = <0>;
> 
>                          bridge_in_dsi: endpoint {
>                                 remote-endpoint = <&dsi_out_bridge>;
>                                 data-lanes = <1 2 3 4>;
>                          };
>                   };
> 
> 	          port@2 {
> 	                 reg = <2>;
> 
>                          bridge_out_dmd: endpoint {
>                                 remote-endpoint = <&dmd_out_bridge>;
>                          };
>                   };
>              };
>        };
> };
> 
> dsi {
>        compatible = "allwinner,sun50i-a64-mipi-dsi";
> 
>        port {
>              dsi_in_tcon0: endpoint@0 {
> 	          reg = <0>;
> 		  remote-endpoint = <tcon0_out_dsi>;
> 	     };
> 
> 	     dsi_out_bridge: endpoint@1 {
> 	   	  reg = <1>;
> 		  remote-endpoint = <&bridge_in_dsi>;
> 	     };
> 	};
> };
> 
> Note that existing device bindings are untouched and still represent
> the downstream devices via child nodes since the sun6i-mipi-dsi host
> will migrate to a standardized single helper to lookup for a
> downstream device via child or OF-graph port or port node.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v7:
> - new patch
> 
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 77b5349f6087..3ed566dc2172 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -1189,7 +1189,11 @@ dsi: dsi@1ca0000 {
>  			#size-cells = <0>;
>  
>  			port {
> -				dsi_in_tcon0: endpoint {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				dsi_in_tcon0: endpoint@0 {
> +					reg = <0>;
>  					remote-endpoint = <&tcon0_out_dsi>;
>  				};

That doesn't match the DT binding anymore, and why can't we add endpoint@1 there too?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 09/12] arm64: dts: rockchip: a64: Add endpoint@0 to dsi_in_tcon0

[Jagan Teki]

On Wed, Mar 29, 2023 at 8:32 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> The commit title is wrong, it's not a rockchip device.

Thanks for the note, I will fix it in the next version.

>
> On Wed, Mar 29, 2023 at 06:46:15PM +0530, Jagan Teki wrote:
> > The DSI downstream devices are likely to be Panel, Bridge and
> > I2C-Configured Bridge.
> >
> > It is possible to connect all three devices using upstream OF-graph port
> > or ports node however only Panel and Bridge are possible to connect via
> > child node but not possible to connect I2C-Configured Bridge via child
> > node since I2C-Configure bridges are child of I2C not upstream DSI hosts
> > and it must represent them via port or ports with endpoint linking.
> >
> > Allwinner A64 DSI node already has a port so add endpoint 0 for input
> > tcon so that the downstream DSI devices can use endpoint 1 to connect
> > Panel or Bridge or I2C-Configured Bridge.
> >
> > An example of the I2C-Configured downstream bridge representation is,
> >
> > i2c1 {
> >        bridge@1b {
> >            compatible = "ti,dlpc3433";
> >
> >              ports {
> >                   port@0 {
> >                          reg = <0>;
> >
> >                          bridge_in_dsi: endpoint {
> >                                 remote-endpoint = <&dsi_out_bridge>;
> >                                 data-lanes = <1 2 3 4>;
> >                          };
> >                   };
> >
> >                 port@2 {
> >                        reg = <2>;
> >
> >                          bridge_out_dmd: endpoint {
> >                                 remote-endpoint = <&dmd_out_bridge>;
> >                          };
> >                   };
> >              };
> >        };
> > };
> >
> > dsi {
> >        compatible = "allwinner,sun50i-a64-mipi-dsi";
> >
> >        port {
> >              dsi_in_tcon0: endpoint@0 {
> >                 reg = <0>;
> >                 remote-endpoint = <tcon0_out_dsi>;
> >            };
> >
> >            dsi_out_bridge: endpoint@1 {
> >                 reg = <1>;
> >                 remote-endpoint = <&bridge_in_dsi>;
> >            };
> >       };
> > };
> >
> > Note that existing device bindings are untouched and still represent
> > the downstream devices via child nodes since the sun6i-mipi-dsi host
> > will migrate to a standardized single helper to lookup for a
> > downstream device via child or OF-graph port or port node.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > Changes for v7:
> > - new patch
> >
> >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 77b5349f6087..3ed566dc2172 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -1189,7 +1189,11 @@ dsi: dsi@1ca0000 {
> >                       #size-cells = <0>;
> >
> >                       port {
> > -                             dsi_in_tcon0: endpoint {
> > +                             #address-cells = <1>;
> > +                             #size-cells = <0>;
> > +
> > +                             dsi_in_tcon0: endpoint@0 {
> > +                                     reg = <0>;
> >                                       remote-endpoint = <&tcon0_out_dsi>;
> >                               };
>
> That doesn't match the DT binding anymore, and why can't we add endpoint@1 there too?

Do you mean add endpoint@1 without any remote-endpoint like this?

dsi_out_bridge: endpoint@1 {
         reg = <1>;
};

I was supposed to add this, since dtbs_check doesn't give any error. I
have skipped this, as I thought it wouldn't be needed.

Thanks,
agan.