[PATCH v13 00/18] drm: Add Samsung MIPI DSIM bridge

[PATCH v13 00/18] drm: Add Samsung MIPI DSIM bridge

[Jagan Teki]

This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.

The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.

Patch 0001 - 0004: find child DSI bridge and panel

Patch 0005 - 0006: optional PHY, PMS_P offset

Patch 0007       : introduce hw_type

Patch 0008	 : fixing host init

Patch 0009	 : atomic_check

Patch 0010	 : input_bus_flags

Patch 0011	 : atomic_get_input_bus_fmts

Patch 0012 - 0013: component vs bridge

Patch 0014	 : DSIM bridge

Patch 0015 - 0016: i.MX8M Mini/Nano

Patch 0017 - 0018: i.MX8M Plus

Changes for v13:
- remove devm call for DSI panel or bridge finding
- rebased on drm-misc-next

Changes for v12:
- collect RB from Marek V
- add te_irq_handler hook
- fix comments from Marek V
- update atomic_get_input_bus_fmts logic

Changes for v11:
- collect RB from Frieder Schrempf
- collect ACK from Rob
- collect ACK from Robert
- fix BIT macro replacements
- fix checkpatch --strict warnings
- fix unneeded commit text
- drop extra lines

Changes for v10:
- rebase on drm-misc-next
- add drm_of_dsi_find_panel_or_bridge
- add devm_drm_of_dsi_get_bridge
- fix host initialization (Thanks to Marek Szyprowski)
- rearrange the tiny patches for easy to review
- update simple names for enum hw_type
- add is_hw_exynos macro
- rework on commit messages

Changes for v9:
- rebase on drm-misc-next
- drop drm bridge attach fix for Exynos
- added prepare_prev_first flag
- added pre_enable_prev_first flag
- fix bridge chain order for exynos
- added fix for Exynos host init for first DSI transfer
- added MEDIA_BUS_FMT_FIXED
- return MEDIA_BUS_FMT_RGB888_1X24 output_fmt if supported output_fmt
  list is unsupported.
- added MEDIA_BUS_FMT_YUYV10_1X20
- added MEDIA_BUS_FMT_YUYV12_1X24

Changes for v8:
* fixed comment lines
* fixed commit messages
* fixed video mode bits
* collect Marek Ack
* fixed video mode bit names
* update input formats logic
* added imx8mplus support

Changes for v7:
* fix the drm bridge attach chain for exynos drm dsi driver
* fix the hw_type checking logic

Changes for v6:
* handle previous bridge for exynos dsi while attaching bridge 

Changes for v5:
* bridge changes to support multi-arch
* updated and clear commit messages
* add hw_type via plat data
* removed unneeded quirk
* rebased on linux-next

Changes for v4:
* include Inki Dae in MAINTAINERS
* remove dsi_driver probe in exynos_drm_drv to support multi-arch build
* update init handling to ensure host init done on first cmd transfer

Changes for v3:
* fix the mult-arch build
* fix dsi host init
* updated commit messages

Changes for v2:
* fix bridge handling
* fix dsi host init
* correct the commit messages

Tested in Engicam i.Core MX8M Mini SoM.

Repo:
https://github.com/openedev/kernel/tree/imx8mm-dsi-v13

v11:
https://lore.kernel.org/all/20230126144427.607098-1-jagan@amarulasolutions.com/

Any inputs?
Jagan.

Jagan Teki (16):
  drm: of: Lookup if child node has DSI panel or bridge
  drm: bridge: panel: Support nodrm case for drmm_panel_bridge_add
  drm: exynos: dsi: Drop explicit call to bridge detach
  drm: exynos: dsi: Switch to DSI panel or bridge find helper
  drm: exynos: dsi: Mark PHY as optional
  drm: exynos: dsi: Add platform PLL_P (PMS_P) offset
  drm: exynos: dsi: Introduce hw_type platform data
  drm: exynos: dsi: Add atomic check
  drm: exynos: dsi: Add input_bus_flags
  drm: exynos: dsi: Add atomic_get_input_bus_fmts
  drm: exynos: dsi: Consolidate component and bridge
  drm: exynos: dsi: Add host helper for te_irq_handler
  drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support
  drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support
  dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support

Marek Szyprowski (1):
  drm: exynos: dsi: Handle proper host initialization

Marek Vasut (1):
  drm: bridge: samsung-dsim: Add i.MX8M Plus support

 .../bindings/display/exynos/exynos_dsim.txt   |    2 +
 MAINTAINERS                                   |    9 +
 drivers/gpu/drm/bridge/Kconfig                |   12 +
 drivers/gpu/drm/bridge/Makefile               |    1 +
 drivers/gpu/drm/bridge/panel.c                |    7 +
 drivers/gpu/drm/bridge/samsung-dsim.c         | 1933 +++++++++++++++++
 drivers/gpu/drm/drm_of.c                      |  112 +-
 drivers/gpu/drm/exynos/Kconfig                |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1819 +---------------
 include/drm/bridge/samsung-dsim.h             |  115 +
 include/drm/drm_of.h                          |   12 +
 11 files changed, 2271 insertions(+), 1752 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
2.25.1

[PATCH v13 01/18] 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.

Example OF graph representation of DSI host, which has port but
not has ports and has child panel node.

dsi {
	compatible = "allwinner,sun6i-a31-mipi-dsi";
	#address-cells = <1>;
	#size-cells = <0>;

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

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

Example OF graph representation of DSI host, which has ports but
not has port and has child panel node.

dsi {
        compatible = "samsung,exynos5433-mipi-dsi";
        #address-cells = <1>;
        #size-cells = <0>;

	ports {
		#address-cells = <1>;
		#size-cells = <0>;

		port@0 {
			reg = <0>;

                	dsi_to_mic: endpoint {
                        	remote-endpoint = <&mic_to_dsi>;
                	};
                };
        };

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

Example OF graph representation of DSI host, which has neither a port
nor a ports but has child panel node.

dsi0 {
	compatible = "ste,mcde-dsi";
	#address-cells = <1>;
	#size-cells = <0>;

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

Cc: Maxime Ripard <mripard@kernel.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13, v12:
- none
Changes for v11:
- drop extra line
Changes for v10:
- 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 v13 02/18] drm: bridge: panel: Support nodrm case for drmm_panel_bridge_add

[Jagan Teki]

drmm_panel_bridge_add DRM-managed action helper is useful for the bridge
which automatically removes the bridge when drm pointer is cleaned.

Supporting the same on non-component bridges like host DSI bridge requires
a drm pointer which is indeed available only when a panel-bridge is found.

For these use cases, the caller would call the drmm_panel_bridge_add by
passing NULL to drm pointer.

So, assign the bridge->dev to drm pointer for those cases.

Cc: Maxime Ripard <mripard@kernel.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- new patch

Note: use case on 
"[PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper"

 drivers/gpu/drm/bridge/panel.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index d4b112911a99..45a0c6671000 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -402,6 +402,13 @@ struct drm_bridge *drmm_panel_bridge_add(struct drm_device *drm,
 	if (IS_ERR(bridge))
 		return bridge;
 
+	/*
+	 * For non-component bridges, like host DSI bridge the DRM pointer
+	 * can be available only when a panel-bridge is found.
+	 */
+	if (!drm)
+		drm = bridge->dev;
+
 	ret = drmm_add_action_or_reset(drm, drmm_drm_panel_bridge_release,
 				       bridge);
 	if (ret)
-- 
2.25.1

[PATCH v13 03/18] drm: exynos: dsi: Drop explicit call to bridge detach

[Jagan Teki]

Exynos DSI already converted into a bridge driver, so bridge
detach will suppose happened during bridge chain removal done
by the bridge core.

Drop the explicit call chain to detach the bridge.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13, v12, v11:
- none
Changes for v10:
- new patch

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 06d6513ddaae..df15501b1075 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1531,8 +1531,6 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
 	struct exynos_dsi *dsi = host_to_dsi(host);
 	struct drm_device *drm = dsi->encoder.dev;
 
-	if (dsi->out_bridge->funcs->detach)
-		dsi->out_bridge->funcs->detach(dsi->out_bridge);
 	dsi->out_bridge = NULL;
 
 	if (drm->mode_config.poll_enabled)
-- 
2.25.1

[PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

drm_of_dsi_find_panel_or_bridge is capable of looking up the
downstream DSI bridge and panel and trying to add a panel bridge
if the panel is found.

Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
followed with drmm_panel_bridge_add.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13, v12, v11:
- none
Changes for v10:
- new patch

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index df15501b1075..12a6dd987e8f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -25,6 +25,7 @@
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_bridge.h>
 #include <drm/drm_mipi_dsi.h>
+#include <drm/drm_of.h>
 #include <drm/drm_panel.h>
 #include <drm/drm_print.h>
 #include <drm/drm_probe_helper.h>
@@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
 	struct device *dev = dsi->dev;
 	struct drm_encoder *encoder = &dsi->encoder;
 	struct drm_device *drm = encoder->dev;
+	struct drm_bridge *bridge;
 	struct drm_panel *panel;
 	int ret;
 
-	panel = of_drm_find_panel(device->dev.of_node);
-	if (!IS_ERR(panel)) {
-		dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
-	} else {
-		dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
-		if (!dsi->out_bridge)
-			dsi->out_bridge = ERR_PTR(-EINVAL);
-	}
+	ret = drm_of_dsi_find_panel_or_bridge(dev->of_node, 1, 0,
+					      &panel, &bridge);
+	if (ret)
+		return ret;
 
-	if (IS_ERR(dsi->out_bridge)) {
-		ret = PTR_ERR(dsi->out_bridge);
+	if (panel)
+		bridge = drmm_panel_bridge_add(NULL, panel);
+
+	if (IS_ERR(bridge)) {
+		ret = PTR_ERR(bridge);
 		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
 		return ret;
 	}
 
+	dsi->out_bridge = bridge;
+
 	DRM_DEV_INFO(dev, "Attached %s device\n", device->name);
 
 	drm_bridge_add(&dsi->bridge);
@@ -1531,8 +1534,6 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
 	struct exynos_dsi *dsi = host_to_dsi(host);
 	struct drm_device *drm = dsi->encoder.dev;
 
-	dsi->out_bridge = NULL;
-
 	if (drm->mode_config.poll_enabled)
 		drm_kms_helper_hotplug_event(drm);
 
-- 
2.25.1

[PATCH v13 05/18] drm: exynos: dsi: Mark PHY as optional

[Jagan Teki]

The same Samsung MIPI DSIM master can also be used in NXP's
i.MX8M Mini/Nano/Plus SoC.

In i.MX8M Mini/Nano/Plus SoC the DSI Phy requires a MIPI DPHY
bit to reset in order to activate the PHY and that can be done
via upstream i.MX8M blk-ctrl driver.

So, mark the phy get as optional.

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13, v12:
- none
Changes for v11:
- collect Frieder RB
Changes for v10:
- add Plus in commit message
- collect Marek RB
Changes for v9, v8, v7, v6, v5, v4, v3, v2:
- none
Changes for v1:
- new patch

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 12a6dd987e8f..529e010291c8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1699,7 +1699,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 	if (IS_ERR(dsi->reg_base))
 		return PTR_ERR(dsi->reg_base);
 
-	dsi->phy = devm_phy_get(dev, "dsim");
+	dsi->phy = devm_phy_optional_get(dev, "dsim");
 	if (IS_ERR(dsi->phy)) {
 		dev_info(dev, "failed to get dsim phy\n");
 		return PTR_ERR(dsi->phy);
-- 
2.25.1

[PATCH v13 06/18] drm: exynos: dsi: Add platform PLL_P (PMS_P) offset

[Jagan Teki]

Look like PLL PMS_P offset value varies between platforms that have
Samsung DSIM IP.

However, there is no clear evidence for it as both Exynos and i.MX
8M Mini Application Processor Reference Manual is still referring
the PMS_P offset as 13.

The offset 13 is not working for i.MX8M Mini SoCs but the downstream
NXP sec-dsim.c driver is using offset 14 for i.MX8M Mini SoC platforms
[1] [2].

PMS_P value set in sec_mipi_dsim_check_pll_out using PLLCTRL_SET_P()
with offset 13 and then an additional offset of one bit added in
sec_mipi_dsim_config_pll via PLLCTRL_SET_PMS().

Not sure whether it is reference manual documentation or something
else but this patch trusts the downstream code and handle PLL_P offset
via platform driver data so-that imx8mm driver data shall use
pll_p_offset to 14.

Similar to Mini the i.MX8M Nano/Plus also has P=14, unlike Exynos.

[1] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n210
[2] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5.4.47_2.2.0#n211

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13, v12, v11, v10, v9:
- none
Changes for v8:
- updated commit message for 8M Nano/Plus
Changes for v7, v6:
- none
Changes for v5:
- updated clear commit message
Changes for v4, v3, v2:
- none
Changes for v1:
- updated commit message
- add downstream driver link

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 529e010291c8..8eac1c6e35c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -195,7 +195,7 @@
 /* DSIM_PLLCTRL */
 #define DSIM_FREQ_BAND(x)		((x) << 24)
 #define DSIM_PLL_EN			(1 << 23)
-#define DSIM_PLL_P(x)			((x) << 13)
+#define DSIM_PLL_P(x, offset)		((x) << (offset))
 #define DSIM_PLL_M(x)			((x) << 4)
 #define DSIM_PLL_S(x)			((x) << 1)
 
@@ -264,6 +264,7 @@ struct exynos_dsi_driver_data {
 	unsigned int max_freq;
 	unsigned int wait_for_reset;
 	unsigned int num_bits_resol;
+	unsigned int pll_p_offset;
 	const unsigned int *reg_values;
 };
 
@@ -472,6 +473,7 @@ static const struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -484,6 +486,7 @@ static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -494,6 +497,7 @@ static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
 	.max_freq = 1000,
 	.wait_for_reset = 1,
 	.num_bits_resol = 11,
+	.pll_p_offset = 13,
 	.reg_values = reg_values,
 };
 
@@ -505,6 +509,7 @@ static const struct exynos_dsi_driver_data exynos5433_dsi_driver_data = {
 	.max_freq = 1500,
 	.wait_for_reset = 0,
 	.num_bits_resol = 12,
+	.pll_p_offset = 13,
 	.reg_values = exynos5433_reg_values,
 };
 
@@ -516,6 +521,7 @@ static const struct exynos_dsi_driver_data exynos5422_dsi_driver_data = {
 	.max_freq = 1500,
 	.wait_for_reset = 1,
 	.num_bits_resol = 12,
+	.pll_p_offset = 13,
 	.reg_values = exynos5422_reg_values,
 };
 
@@ -629,7 +635,8 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
 	writel(driver_data->reg_values[PLL_TIMER],
 			dsi->reg_base + driver_data->plltmr_reg);
 
-	reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+	reg = DSIM_PLL_EN | DSIM_PLL_P(p, driver_data->pll_p_offset) |
+	      DSIM_PLL_M(m) | DSIM_PLL_S(s);
 
 	if (driver_data->has_freqband) {
 		static const unsigned long freq_bands[] = {
-- 
2.25.1

[PATCH v13 07/18] drm: exynos: dsi: Introduce hw_type platform data

[Jagan Teki]

Samsung MIPI DSIM controller is common DSI IP that can be used
in various SoCs like Exynos, i.MX8M Mini/Nano/Plus.

Add hw_type enum via platform_data so that accessing the different
controller data between various platforms becomes easy and meaningful.

Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- collect RB from Marek
Changes for v11:
- collect RB from Frieder
- drop extra line
Changes for v10:
- split from previous series patch
"drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge"
- update enum type names

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 83 ++++++++++++++++++++-----
 1 file changed, 68 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 8eac1c6e35c2..9217b362224a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -255,6 +255,15 @@ struct exynos_dsi_transfer {
 #define DSIM_STATE_CMD_LPM		BIT(2)
 #define DSIM_STATE_VIDOUT_AVAILABLE	BIT(3)
 
+enum exynos_dsi_type {
+	DSIM_TYPE_EXYNOS3250,
+	DSIM_TYPE_EXYNOS4210,
+	DSIM_TYPE_EXYNOS5410,
+	DSIM_TYPE_EXYNOS5422,
+	DSIM_TYPE_EXYNOS5433,
+	DSIM_TYPE_COUNT,
+};
+
 struct exynos_dsi_driver_data {
 	const unsigned int *reg_ofs;
 	unsigned int plltmr_reg;
@@ -268,6 +277,10 @@ struct exynos_dsi_driver_data {
 	const unsigned int *reg_values;
 };
 
+struct exynos_dsi_plat_data {
+	enum exynos_dsi_type hw_type;
+};
+
 struct exynos_dsi {
 	struct drm_encoder encoder;
 	struct mipi_dsi_host dsi_host;
@@ -298,6 +311,7 @@ struct exynos_dsi {
 	struct list_head transfer_list;
 
 	const struct exynos_dsi_driver_data *driver_data;
+	const struct exynos_dsi_plat_data *plat_data;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -525,18 +539,13 @@ static const struct exynos_dsi_driver_data exynos5422_dsi_driver_data = {
 	.reg_values = exynos5422_reg_values,
 };
 
-static const struct of_device_id exynos_dsi_of_match[] = {
-	{ .compatible = "samsung,exynos3250-mipi-dsi",
-	  .data = &exynos3_dsi_driver_data },
-	{ .compatible = "samsung,exynos4210-mipi-dsi",
-	  .data = &exynos4_dsi_driver_data },
-	{ .compatible = "samsung,exynos5410-mipi-dsi",
-	  .data = &exynos5_dsi_driver_data },
-	{ .compatible = "samsung,exynos5422-mipi-dsi",
-	  .data = &exynos5422_dsi_driver_data },
-	{ .compatible = "samsung,exynos5433-mipi-dsi",
-	  .data = &exynos5433_dsi_driver_data },
-	{ }
+static const struct exynos_dsi_driver_data *
+exynos_dsi_types[DSIM_TYPE_COUNT] = {
+	[DSIM_TYPE_EXYNOS3250] = &exynos3_dsi_driver_data,
+	[DSIM_TYPE_EXYNOS4210] = &exynos4_dsi_driver_data,
+	[DSIM_TYPE_EXYNOS5410] = &exynos5_dsi_driver_data,
+	[DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
+	[DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
 };
 
 static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
@@ -1469,8 +1478,6 @@ static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
 	.attach				= exynos_dsi_attach,
 };
 
-MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
-
 static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
 				  struct mipi_dsi_device *device)
 {
@@ -1671,7 +1678,8 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 	dsi->dsi_host.dev = dev;
 
 	dsi->dev = dev;
-	dsi->driver_data = of_device_get_match_data(dev);
+	dsi->plat_data = of_device_get_match_data(dev);
+	dsi->driver_data = exynos_dsi_types[dsi->plat_data->hw_type];
 
 	dsi->supplies[0].supply = "vddcore";
 	dsi->supplies[1].supply = "vddio";
@@ -1829,6 +1837,51 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
 				pm_runtime_force_resume)
 };
 
+static const struct exynos_dsi_plat_data exynos3250_dsi_pdata = {
+	.hw_type = DSIM_TYPE_EXYNOS3250,
+};
+
+static const struct exynos_dsi_plat_data exynos4210_dsi_pdata = {
+	.hw_type = DSIM_TYPE_EXYNOS4210,
+};
+
+static const struct exynos_dsi_plat_data exynos5410_dsi_pdata = {
+	.hw_type = DSIM_TYPE_EXYNOS5410,
+};
+
+static const struct exynos_dsi_plat_data exynos5422_dsi_pdata = {
+	.hw_type = DSIM_TYPE_EXYNOS5422,
+};
+
+static const struct exynos_dsi_plat_data exynos5433_dsi_pdata = {
+	.hw_type = DSIM_TYPE_EXYNOS5433,
+};
+
+static const struct of_device_id exynos_dsi_of_match[] = {
+	{
+		.compatible = "samsung,exynos3250-mipi-dsi",
+		.data = &exynos3250_dsi_pdata,
+	},
+	{
+		.compatible = "samsung,exynos4210-mipi-dsi",
+		.data = &exynos4210_dsi_pdata,
+	},
+	{
+		.compatible = "samsung,exynos5410-mipi-dsi",
+		.data = &exynos5410_dsi_pdata,
+	},
+	{
+		.compatible = "samsung,exynos5422-mipi-dsi",
+		.data = &exynos5422_dsi_pdata,
+	},
+	{
+		.compatible = "samsung,exynos5433-mipi-dsi",
+		.data = &exynos5433_dsi_pdata,
+	},
+	{ /* sentinel. */ }
+};
+MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
+
 struct platform_driver dsi_driver = {
 	.probe = exynos_dsi_probe,
 	.remove = exynos_dsi_remove,
-- 
2.25.1

[PATCH v13 08/18] drm: exynos: dsi: Handle proper host initialization

[Jagan Teki]

From: Marek Szyprowski <m.szyprowski@samsung.com>

Host transfer() in the DSI master will invoke only when the DSI commands
are sent from DSI devices like DSI Panel or DSI bridges and this host
the transfer wouldn't invoke for I2C-based-DSI bridge drivers.

Handling DSI host initialization in transfer calls misses the controller
setup for I2C configured DSI bridges.

This patch updates the DSI host initialization by calling host to init
from bridge pre_enable as the bridge pre_enable API is invoked by core
as it is common across all classes of DSI device drivers.

The host init during pre_enable is conditional and not invoked for Exynos
as existing downstream drm panels and bridges in Exynos are expecting
the host initialization during DSI transfer.

Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none 
Changes for v12:
- collect RB from Marek
Changes for v11:
- collect RB from Frieder
Changes for v10:
- update the to simple logic to handle all platforms
Changs for v9 - v8:
- none
Changes for v2:
- check initialized state in samsung_dsim_init
Changes for v1:
- keep DSI init in host transfer

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 27 +++++++++++++++++++------
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 9217b362224a..5723d91ff686 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -255,6 +255,9 @@ struct exynos_dsi_transfer {
 #define DSIM_STATE_CMD_LPM		BIT(2)
 #define DSIM_STATE_VIDOUT_AVAILABLE	BIT(3)
 
+#define exynos_dsi_hw_is_exynos(hw) \
+	((hw) >= DSIM_TYPE_EXYNOS3250 && (hw) <= DSIM_TYPE_EXYNOS5433)
+
 enum exynos_dsi_type {
 	DSIM_TYPE_EXYNOS3250,
 	DSIM_TYPE_EXYNOS4210,
@@ -1344,6 +1347,9 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
 {
 	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
 
+	if (dsi->state & DSIM_STATE_INITIALIZED)
+		return 0;
+
 	exynos_dsi_reset(dsi);
 	exynos_dsi_enable_irq(dsi);
 
@@ -1356,6 +1362,8 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
 	exynos_dsi_set_phy_ctrl(dsi);
 	exynos_dsi_init_link(dsi);
 
+	dsi->state |= DSIM_STATE_INITIALIZED;
+
 	return 0;
 }
 
@@ -1411,6 +1419,16 @@ static void exynos_dsi_atomic_pre_enable(struct drm_bridge *bridge,
 	}
 
 	dsi->state |= DSIM_STATE_ENABLED;
+
+	/*
+	 * For Exynos-DSIM the downstream bridge, or panel are expecting
+	 * the host initialization during DSI transfer.
+	 */
+	if (!exynos_dsi_hw_is_exynos(dsi->plat_data->hw_type)) {
+		ret = exynos_dsi_init(dsi);
+		if (ret)
+			return;
+	}
 }
 
 static void exynos_dsi_atomic_enable(struct drm_bridge *bridge,
@@ -1568,12 +1586,9 @@ static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
 	if (!(dsi->state & DSIM_STATE_ENABLED))
 		return -EINVAL;
 
-	if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
-		ret = exynos_dsi_init(dsi);
-		if (ret)
-			return ret;
-		dsi->state |= DSIM_STATE_INITIALIZED;
-	}
+	ret = exynos_dsi_init(dsi);
+	if (ret)
+		return ret;
 
 	ret = mipi_dsi_create_packet(&xfer.packet, msg);
 	if (ret < 0)
-- 
2.25.1

[PATCH v13 09/18] drm: exynos: dsi: Add atomic check

[Jagan Teki]

Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.

At least the LCDIF + DSIM needs active low sync polarities in order
to correlate the correct sync flags of the surrounding components in
the chain to make sure the whole pipeline can work properly.

On the other hand the i.MX 8M Mini Applications Processor Reference Manual,
Rev. 3, 11/2020 says.
"13.6.3.5.2 RGB interface
 Vsync, Hsync, and VDEN are active high signals."

i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020
3.6.3.5.2 RGB interface
i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022
13.6.2.7.2 RGB interface
both claim "Vsync, Hsync, and VDEN are active high signals.", the
LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.

No clear evidence about whether it can be documentation issues or
something, so added proper comments on the code.

Comments are suggested by Marek Vasut.

Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- collect RB from Marek
Changes for v11:
- collect RB from Frieder
- fix commit message
Changes for v10, v9:
- none
Changes for v8:
- update the comments about sync signals polarities
- added clear commit message by including i.MX8M Nano details
Changes for v7:
- fix the hw_type checking logic
Changes for v6:
- none
Changes for v5:
- rebase based new bridge changes [mszyprow]
- remove DSIM_QUIRK_FIXUP_SYNC_POL
- add hw_type check for sync polarities change.
Changes for v4:
- none
Changes for v3:
- add DSIM_QUIRK_FIXUP_SYNC_POL to handle mode_flasg fixup
Changes for v2:
- none
Changes for v1:
- fix mode flags in atomic_check instead of mode_fixup

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 28 +++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5723d91ff686..22e3bdcf5494 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -264,6 +264,7 @@ enum exynos_dsi_type {
 	DSIM_TYPE_EXYNOS5410,
 	DSIM_TYPE_EXYNOS5422,
 	DSIM_TYPE_EXYNOS5433,
+	DSIM_TYPE_IMX8MM,
 	DSIM_TYPE_COUNT,
 };
 
@@ -1466,6 +1467,32 @@ static void exynos_dsi_atomic_post_disable(struct drm_bridge *bridge,
 	pm_runtime_put_sync(dsi->dev);
 }
 
+static int exynos_dsi_atomic_check(struct drm_bridge *bridge,
+				   struct drm_bridge_state *bridge_state,
+				   struct drm_crtc_state *crtc_state,
+				   struct drm_connector_state *conn_state)
+{
+	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
+	struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode;
+
+	/*
+	 * The i.MX8M Mini/Nano glue logic between LCDIF and DSIM
+	 * inverts HS/VS/DE sync signals polarity, therefore, while
+	 * i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020
+	 * 13.6.3.5.2 RGB interface
+	 * i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022
+	 * 13.6.2.7.2 RGB interface
+	 * both claim "Vsync, Hsync, and VDEN are active high signals.", the
+	 * LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.
+	 */
+	if (dsi->plat_data->hw_type == DSIM_TYPE_IMX8MM) {
+		adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+		adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+	}
+
+	return 0;
+}
+
 static void exynos_dsi_mode_set(struct drm_bridge *bridge,
 				const struct drm_display_mode *mode,
 				const struct drm_display_mode *adjusted_mode)
@@ -1488,6 +1515,7 @@ static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
 	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
 	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset			= drm_atomic_helper_bridge_reset,
+	.atomic_check			= exynos_dsi_atomic_check,
 	.atomic_pre_enable		= exynos_dsi_atomic_pre_enable,
 	.atomic_enable			= exynos_dsi_atomic_enable,
 	.atomic_disable			= exynos_dsi_atomic_disable,
-- 
2.25.1

[PATCH v13 10/18] drm: exynos: dsi: Add input_bus_flags

[Jagan Teki]

LCDIF-DSIM glue logic inverts the HS/VS/DE signals and expecting
the i.MX8M Mini/Nano DSI host to add additional Data Enable signal
active low (DE_LOW). This makes the valid data transfer on each
horizontal line.

So, add additional bus flags DE_LOW setting via input_bus_flags
for i.MX8M Mini/Nano platforms.

Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Suggested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- collect RB from Marek
Changes for v11:
- collect RB from Frieder
Changes for v10, v9:
- none
Changes for v8:
- add DE_LOW for i.MX8M Mini/Nano platforms.
Changes for v7, v6:
- none
Changes for v5:
- rebased based on updated bridge changes
Changes for v4 - v1:
- none

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 22e3bdcf5494..7f0703582506 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1703,6 +1703,10 @@ static const struct component_ops exynos_dsi_component_ops = {
 	.unbind	= exynos_dsi_unbind,
 };
 
+static const struct drm_bridge_timings dsim_bridge_timings_de_low = {
+	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
+};
+
 static int exynos_dsi_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1789,6 +1793,10 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 	dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
 	dsi->bridge.pre_enable_prev_first = true;
 
+	/* DE_LOW: i.MX8M Mini/Nano LCDIF-DSIM glue logic inverts HS/VS/DE */
+	if (dsi->plat_data->hw_type == DSIM_TYPE_IMX8MM)
+		dsi->bridge.timings = &dsim_bridge_timings_de_low;
+
 	ret = component_add(dev, &exynos_dsi_component_ops);
 	if (ret)
 		goto err_disable_runtime;
-- 
2.25.1

[PATCH v13 11/18] drm: exynos: dsi: Add atomic_get_input_bus_fmts

[Jagan Teki]

Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
proper input format from list of supported output formats.

This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component closer to pipeline
components.

List of Pixel formats are taken from,
AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
3.7.4 Pixel formats
Table 14. DSI pixel packing formats

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- update the logic suggested by Marek
Changes for v11:
- collect RB from Frieder
- drop extra line
Changes for v10:
- none
Changes for v9:
- added MEDIA_BUS_FMT_FIXED
- return MEDIA_BUS_FMT_RGB888_1X24 output_fmt if supported output_fmt
  list is unsupported.
- added MEDIA_BUS_FMT_YUYV10_1X20, MEDIA_BUS_FMT_YUYV12_1X24
Changes for v8:
- added pixel formats supported by NXP AN13573 i.MX 8/RT MIPI DSI/CSI-2
Changes for v7 - v4:
- none
Changes for v3:
- include media-bus-format.h
Changes for v2:
- none
Changes for v1:
- new patch

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 62 +++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7f0703582506..aea56b6fbf17 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -12,6 +12,7 @@
 #include <linux/component.h>
 #include <linux/gpio/consumer.h>
 #include <linux/irq.h>
+#include <linux/media-bus-format.h>
 #include <linux/of_device.h>
 #include <linux/of_graph.h>
 #include <linux/phy/phy.h>
@@ -1467,6 +1468,66 @@ static void exynos_dsi_atomic_post_disable(struct drm_bridge *bridge,
 	pm_runtime_put_sync(dsi->dev);
 }
 
+/*
+ * This pixel output formats list referenced from,
+ * AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
+ * 3.7.4 Pixel formats
+ * Table 14. DSI pixel packing formats
+ */
+static const u32 exynos_dsi_pixel_output_fmts[] = {
+	MEDIA_BUS_FMT_YUYV10_1X20,
+	MEDIA_BUS_FMT_YUYV12_1X24,
+	MEDIA_BUS_FMT_UYVY8_1X16,
+	MEDIA_BUS_FMT_RGB101010_1X30,
+	MEDIA_BUS_FMT_RGB121212_1X36,
+	MEDIA_BUS_FMT_RGB565_1X16,
+	MEDIA_BUS_FMT_RGB666_1X18,
+	MEDIA_BUS_FMT_RGB888_1X24,
+};
+
+static bool exynos_dsi_pixel_output_fmt_supported(u32 fmt)
+{
+	int i;
+
+	if (fmt == MEDIA_BUS_FMT_FIXED)
+		return false;
+
+	for (i = 0; i < ARRAY_SIZE(exynos_dsi_pixel_output_fmts); i++) {
+		if (exynos_dsi_pixel_output_fmts[i] == fmt)
+			return true;
+	}
+
+	return false;
+}
+
+static u32 *
+exynos_dsi_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+				     struct drm_bridge_state *bridge_state,
+				     struct drm_crtc_state *crtc_state,
+				     struct drm_connector_state *conn_state,
+				     u32 output_fmt,
+				     unsigned int *num_input_fmts)
+{
+	u32 *input_fmts;
+
+	input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	if (!exynos_dsi_pixel_output_fmt_supported(output_fmt))
+		/*
+		 * Some bridge/display drivers are still not able to pass the
+		 * correct format, so handle those pipelines by falling back
+		 * to the default format till the supported formats finalized.
+		 */
+		output_fmt = MEDIA_BUS_FMT_RGB888_1X24;
+
+	input_fmts[0] = output_fmt;
+	*num_input_fmts = 1;
+
+	return input_fmts;
+}
+
 static int exynos_dsi_atomic_check(struct drm_bridge *bridge,
 				   struct drm_bridge_state *bridge_state,
 				   struct drm_crtc_state *crtc_state,
@@ -1515,6 +1576,7 @@ static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
 	.atomic_duplicate_state		= drm_atomic_helper_bridge_duplicate_state,
 	.atomic_destroy_state		= drm_atomic_helper_bridge_destroy_state,
 	.atomic_reset			= drm_atomic_helper_bridge_reset,
+	.atomic_get_input_bus_fmts	= exynos_dsi_atomic_get_input_bus_fmts,
 	.atomic_check			= exynos_dsi_atomic_check,
 	.atomic_pre_enable		= exynos_dsi_atomic_pre_enable,
 	.atomic_enable			= exynos_dsi_atomic_enable,
-- 
2.25.1

[PATCH v13 12/18] drm: exynos: dsi: Consolidate component and bridge

[Jagan Teki]

DSI host registration, attach and detach operations are quite
different for the component and bridge-based DRM drivers. 

Supporting generic bridge driver to use both component and bridge
based DRM drivers can be tricky and would require additional host
related operation hooks.

Add host operation hooks for registering and unregistering Exynos
and generic drivers, where Exynos hooks are used in existing Exynos
component based DRM drivers and generic hooks are used in i.MX8M
bridge based DRM drivers. 

Add host attach and detach operation hooks for Exynos component
DRM drivers and those get invoked while DSI core host attach and
detach gets called.

Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- fix unneeded decleration
- collect RB from Marek
Changes for v11:
- none
Changes for v10:
- split from previous series patch
"drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge"

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 169 +++++++++++++++++++-----
 1 file changed, 134 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index aea56b6fbf17..de8604450fb9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -284,10 +284,10 @@ struct exynos_dsi_driver_data {
 
 struct exynos_dsi_plat_data {
 	enum exynos_dsi_type hw_type;
+	const struct exynos_dsim_host_ops *host_ops;
 };
 
 struct exynos_dsi {
-	struct drm_encoder encoder;
 	struct mipi_dsi_host dsi_host;
 	struct drm_bridge bridge;
 	struct drm_bridge *out_bridge;
@@ -317,6 +317,19 @@ struct exynos_dsi {
 
 	const struct exynos_dsi_driver_data *driver_data;
 	const struct exynos_dsi_plat_data *plat_data;
+
+	void *priv;
+};
+
+struct exynos_dsim_host_ops {
+	int (*register_host)(struct exynos_dsi *dsim);
+	void (*unregister_host)(struct exynos_dsi *dsim);
+	int (*attach)(struct exynos_dsi *dsim, struct mipi_dsi_device *device);
+	int (*detach)(struct exynos_dsi *dsim, struct mipi_dsi_device *device);
+};
+
+struct exynos_dsi_enc {
+	struct drm_encoder encoder;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1321,7 +1334,8 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
 static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
 {
 	struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
-	struct drm_encoder *encoder = &dsi->encoder;
+	struct exynos_dsi_enc *dsi_enc = dsi->priv;
+	struct drm_encoder *encoder = &dsi_enc->encoder;
 
 	if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
 		exynos_drm_crtc_te_handler(encoder->crtc);
@@ -1590,9 +1604,8 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
 				  struct mipi_dsi_device *device)
 {
 	struct exynos_dsi *dsi = host_to_dsi(host);
+	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
 	struct device *dev = dsi->dev;
-	struct drm_encoder *encoder = &dsi->encoder;
-	struct drm_device *drm = encoder->dev;
 	struct drm_bridge *bridge;
 	struct drm_panel *panel;
 	int ret;
@@ -1617,35 +1630,15 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
 
 	drm_bridge_add(&dsi->bridge);
 
-	drm_bridge_attach(encoder, &dsi->bridge,
-			  list_first_entry_or_null(&encoder->bridge_chain,
-						   struct drm_bridge,
-						   chain_node), 0);
-
-	/*
-	 * This is a temporary solution and should be made by more generic way.
-	 *
-	 * If attached panel device is for command mode one, dsi should register
-	 * TE interrupt handler.
-	 */
-	if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO)) {
-		ret = exynos_dsi_register_te_irq(dsi, &device->dev);
-		if (ret)
+	if (pdata->host_ops && pdata->host_ops->attach) {
+		ret = pdata->host_ops->attach(dsi, device);
+		if (ret < 0)
 			return ret;
 	}
 
-	mutex_lock(&drm->mode_config.mutex);
-
 	dsi->lanes = device->lanes;
 	dsi->format = device->format;
 	dsi->mode_flags = device->mode_flags;
-	exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
-			!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
-
-	mutex_unlock(&drm->mode_config.mutex);
-
-	if (drm->mode_config.poll_enabled)
-		drm_kms_helper_hotplug_event(drm);
 
 	return 0;
 }
@@ -1654,12 +1647,14 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
 				  struct mipi_dsi_device *device)
 {
 	struct exynos_dsi *dsi = host_to_dsi(host);
-	struct drm_device *drm = dsi->encoder.dev;
-
-	if (drm->mode_config.poll_enabled)
-		drm_kms_helper_hotplug_event(drm);
+	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
+	int ret;
 
-	exynos_dsi_unregister_te_irq(dsi);
+	if (pdata->host_ops && pdata->host_ops->detach) {
+		ret = pdata->host_ops->detach(dsi, device);
+		if (ret < 0)
+			return ret;
+	}
 
 	drm_bridge_remove(&dsi->bridge);
 
@@ -1733,11 +1728,67 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
 	return 0;
 }
 
+static int _exynos_dsi_host_attach(struct exynos_dsi *dsim,
+				   struct mipi_dsi_device *device)
+{
+	struct exynos_dsi_enc *dsi_enc = dsim->priv;
+	struct drm_encoder *encoder = &dsi_enc->encoder;
+	struct drm_device *drm = encoder->dev;
+	int ret;
+
+	drm_bridge_attach(encoder, &dsim->bridge,
+			  list_first_entry_or_null(&encoder->bridge_chain,
+						   struct drm_bridge,
+						   chain_node), 0);
+
+	/*
+	 * This is a temporary solution and should be made by more generic way.
+	 *
+	 * If attached panel device is for command mode one, dsi should register
+	 * TE interrupt handler.
+	 */
+	if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO)) {
+		ret = exynos_dsi_register_te_irq(dsim, &device->dev);
+		if (ret)
+			return ret;
+	}
+
+	mutex_lock(&drm->mode_config.mutex);
+
+	dsim->lanes = device->lanes;
+	dsim->format = device->format;
+	dsim->mode_flags = device->mode_flags;
+	exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
+			!(dsim->mode_flags & MIPI_DSI_MODE_VIDEO);
+
+	mutex_unlock(&drm->mode_config.mutex);
+
+	if (drm->mode_config.poll_enabled)
+		drm_kms_helper_hotplug_event(drm);
+
+	return 0;
+}
+
+static int _exynos_dsi_host_detach(struct exynos_dsi *dsim,
+				   struct mipi_dsi_device *device)
+{
+	struct exynos_dsi_enc *dsi_enc = dsim->priv;
+	struct drm_device *drm = dsi_enc->encoder.dev;
+
+	if (drm->mode_config.poll_enabled)
+		drm_kms_helper_hotplug_event(drm);
+
+	exynos_dsi_unregister_te_irq(dsim);
+
+	return 0;
+}
+
 static int exynos_dsi_bind(struct device *dev, struct device *master,
 				void *data)
 {
 	struct exynos_dsi *dsi = dev_get_drvdata(dev);
-	struct drm_encoder *encoder = &dsi->encoder;
+	struct exynos_dsi_enc *dsi_enc = dsi->priv;
+	struct drm_encoder *encoder = &dsi_enc->encoder;
 	struct drm_device *drm_dev = data;
 	int ret;
 
@@ -1755,7 +1806,7 @@ static void exynos_dsi_unbind(struct device *dev, struct device *master,
 {
 	struct exynos_dsi *dsi = dev_get_drvdata(dev);
 
-	exynos_dsi_atomic_disable(&dsi->bridge, NULL);
+	dsi->bridge.funcs->atomic_disable(&dsi->bridge, NULL);
 
 	mipi_dsi_host_unregister(&dsi->dsi_host);
 }
@@ -1765,6 +1816,40 @@ static const struct component_ops exynos_dsi_component_ops = {
 	.unbind	= exynos_dsi_unbind,
 };
 
+static int exynos_dsi_register_host(struct exynos_dsi *dsim)
+{
+	struct exynos_dsi_enc *dsi_enc;
+
+	dsi_enc = devm_kzalloc(dsim->dev, sizeof(*dsi_enc), GFP_KERNEL);
+	if (!dsi_enc)
+		return -ENOMEM;
+
+	dsim->priv = dsi_enc;
+	dsim->bridge.pre_enable_prev_first = true;
+
+	return component_add(dsim->dev, &exynos_dsi_component_ops);
+}
+
+static void exynos_dsi_unregister_host(struct exynos_dsi *dsim)
+{
+	component_del(dsim->dev, &exynos_dsi_component_ops);
+}
+
+static int generic_dsim_register_host(struct exynos_dsi *dsim)
+{
+	return mipi_dsi_host_register(&dsim->dsi_host);
+}
+
+static void generic_dsim_unregister_host(struct exynos_dsi *dsim)
+{
+	mipi_dsi_host_unregister(&dsim->dsi_host);
+}
+
+static const struct exynos_dsim_host_ops generic_dsim_host_ops = {
+	.register_host = generic_dsim_register_host,
+	.unregister_host = generic_dsim_unregister_host,
+};
+
 static const struct drm_bridge_timings dsim_bridge_timings_de_low = {
 	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
 };
@@ -1859,7 +1944,9 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 	if (dsi->plat_data->hw_type == DSIM_TYPE_IMX8MM)
 		dsi->bridge.timings = &dsim_bridge_timings_de_low;
 
-	ret = component_add(dev, &exynos_dsi_component_ops);
+	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
+		ret = dsi->plat_data->host_ops->register_host(dsi);
+
 	if (ret)
 		goto err_disable_runtime;
 
@@ -1950,24 +2037,36 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
 				pm_runtime_force_resume)
 };
 
+static const struct exynos_dsim_host_ops exynos_dsi_host_ops = {
+	.register_host = exynos_dsi_register_host,
+	.unregister_host = exynos_dsi_unregister_host,
+	.attach = _exynos_dsi_host_attach,
+	.detach = _exynos_dsi_host_detach,
+};
+
 static const struct exynos_dsi_plat_data exynos3250_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS3250,
+	.host_ops = &exynos_dsi_host_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos4210_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS4210,
+	.host_ops = &exynos_dsi_host_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5410_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5410,
+	.host_ops = &exynos_dsi_host_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5422_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5422,
+	.host_ops = &exynos_dsi_host_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5433_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5433,
+	.host_ops = &exynos_dsi_host_ops,
 };
 
 static const struct of_device_id exynos_dsi_of_match[] = {
-- 
2.25.1

[PATCH v13 13/18] drm: exynos: dsi: Add host helper for te_irq_handler

[Jagan Teki]

IRQ handler for te-gpio seems to be common across DSIM host.

However, Exynos is handling this via CRTC drivers but there is no clear
evidence on how the same has been handled in i.MX8MM. Keeping the handler
as-it-is can be a viable option but adding DSIM bridge core in upcoming
patches is not possible to call Exynos CRTC handler as DSIM bridge has
to be common across DRM bridge core instead of platform specific DRM
drivers like Exynos here.

So, this patch handles the handler via platform host helper, so-that
handling platform specific hook across Exynos and generic can be
reasonable till it makes it generic across all platforms.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- updated patch
- suggested by Marek V
Changes for v11:
- none
Changes for v10:
- split from previous series patch
"drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge"

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index de8604450fb9..938bbc701d3c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -326,6 +326,7 @@ struct exynos_dsim_host_ops {
 	void (*unregister_host)(struct exynos_dsi *dsim);
 	int (*attach)(struct exynos_dsi *dsim, struct mipi_dsi_device *device);
 	int (*detach)(struct exynos_dsi *dsim, struct mipi_dsi_device *device);
+	irqreturn_t (*te_irq_handler)(struct exynos_dsi *dsim);
 };
 
 struct exynos_dsi_enc {
@@ -1334,11 +1335,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
 static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
 {
 	struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
-	struct exynos_dsi_enc *dsi_enc = dsi->priv;
-	struct drm_encoder *encoder = &dsi_enc->encoder;
+	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
 
-	if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
-		exynos_drm_crtc_te_handler(encoder->crtc);
+	if (pdata->host_ops && pdata->host_ops->te_irq_handler)
+		return pdata->host_ops->te_irq_handler(dsi);
 
 	return IRQ_HANDLED;
 }
@@ -1728,6 +1728,17 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
 	return 0;
 }
 
+static irqreturn_t _exynos_dsi_te_irq_handler(struct exynos_dsi *dsim)
+{
+	struct exynos_dsi_enc *dsi_enc = dsim->priv;
+	struct drm_encoder *encoder = &dsi_enc->encoder;
+
+	if (dsim->state & DSIM_STATE_VIDOUT_AVAILABLE)
+		exynos_drm_crtc_te_handler(encoder->crtc);
+
+	return IRQ_HANDLED;
+}
+
 static int _exynos_dsi_host_attach(struct exynos_dsi *dsim,
 				   struct mipi_dsi_device *device)
 {
@@ -2042,6 +2053,7 @@ static const struct exynos_dsim_host_ops exynos_dsi_host_ops = {
 	.unregister_host = exynos_dsi_unregister_host,
 	.attach = _exynos_dsi_host_attach,
 	.detach = _exynos_dsi_host_detach,
+	.te_irq_handler = _exynos_dsi_te_irq_handler,
 };
 
 static const struct exynos_dsi_plat_data exynos3250_dsi_pdata = {
-- 
2.25.1

[PATCH v13 15/18] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support

[Jagan Teki]

Samsung MIPI DSIM bridge can also be found in i.MX8M Mini/Nano SoC.

Add dt-bingings for it.

Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- collect RB from Marek
Changes for v11, v10, v9:
- none
Changes for v8:
- add comment to include i.MX8M Nano.
Changes for v7, v6, v5, v4:
- none
Changes for v3:
- collect Rob Acked-by
Changes for v2:
- updated comments
Changes for v1:
- new patch

 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
index be377786e8cd..5133d4d39190 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
@@ -7,6 +7,7 @@ Required properties:
 		"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */
 		"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
 		"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
+		"fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
2.25.1

[PATCH v13 16/18] drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support

[Jagan Teki]

Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.

Add compatible and associated driver_data for it.

Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Acked-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- collect RB from Marek
Changes for v11:
- collect RB from Frieder
- collect ACK from Robert
Changes for v10, v9:
- none
Changed for v8:
- fix and update the comment
Changes for v7, v6:
- none
Changes for v3:
- enable DSIM_QUIRK_FIXUP_SYNC_POL quirk
Changes for v5:
- [mszyprow] rebased and adjusted to the new driver initialization
- drop quirk
Changes for v4:
- none
Changes for v3:
- enable DSIM_QUIRK_FIXUP_SYNC_POL quirk
Changes for v2:
- collect Laurent r-b
Changes for v1:
- none

 drivers/gpu/drm/bridge/samsung-dsim.c | 44 +++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index e0dac7aeab37..9c64a71d2ebd 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -376,6 +376,24 @@ static const unsigned int exynos5433_reg_values[] = {
 	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
 };
 
+static const unsigned int imx8mm_dsim_reg_values[] = {
+	[RESET_TYPE] = DSIM_SWRST,
+	[PLL_TIMER] = 500,
+	[STOP_STATE_CNT] = 0xf,
+	[PHYCTRL_ULPS_EXIT] = 0,
+	[PHYCTRL_VREG_LP] = 0,
+	[PHYCTRL_SLEW_UP] = 0,
+	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x06),
+	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0b),
+	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x07),
+	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x26),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x08),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
+};
+
 static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
 	.reg_ofs = exynos_reg_ofs,
 	.plltmr_reg = 0x50,
@@ -437,6 +455,22 @@ static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
 	.reg_values = exynos5422_reg_values,
 };
 
+static const struct samsung_dsim_driver_data imx8mm_dsi_driver_data = {
+	.reg_ofs = exynos5433_reg_ofs,
+	.plltmr_reg = 0xa0,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 2100,
+	.wait_for_reset = 0,
+	.num_bits_resol = 12,
+	/*
+	 * Unlike Exynos, PLL_P(PMS_P) offset 14 is used in i.MX8M Mini/Nano/Plus
+	 * downstream driver - drivers/gpu/drm/bridge/sec-dsim.c
+	 */
+	.pll_p_offset = 14,
+	.reg_values = imx8mm_dsim_reg_values,
+};
+
 static const struct samsung_dsim_driver_data *
 samsung_dsim_types[DSIM_TYPE_COUNT] = {
 	[DSIM_TYPE_EXYNOS3250] = &exynos3_dsi_driver_data,
@@ -444,6 +478,7 @@ samsung_dsim_types[DSIM_TYPE_COUNT] = {
 	[DSIM_TYPE_EXYNOS5410] = &exynos5_dsi_driver_data,
 	[DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
 	[DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
+	[DSIM_TYPE_IMX8MM] = &imx8mm_dsi_driver_data,
 };
 
 static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
@@ -1843,7 +1878,16 @@ const struct dev_pm_ops samsung_dsim_pm_ops = {
 };
 EXPORT_SYMBOL_GPL(samsung_dsim_pm_ops);
 
+static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
+	.hw_type = DSIM_TYPE_IMX8MM,
+	.host_ops = &generic_dsim_host_ops,
+};
+
 static const struct of_device_id samsung_dsim_of_match[] = {
+	{
+		.compatible = "fsl,imx8mm-mipi-dsim",
+		.data = &samsung_dsim_imx8mm_pdata,
+	},
 	{ /* sentinel. */ }
 };
 MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
-- 
2.25.1

[PATCH v13 17/18] dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support

[Jagan Teki]

Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC.

Add dt-bingings for it.

Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- collect RB from Marek
Changes for v11:
- collect ACK from Rob
Changes for v10, v9:
- none

 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
index 5133d4d39190..2a5f0889ec32 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
@@ -8,6 +8,7 @@ Required properties:
 		"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
 		"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
 		"fsl,imx8mm-mipi-dsim" /* for i.MX8M Mini/Nano SoCs */
+		"fsl,imx8mp-mipi-dsim" /* for i.MX8M Plus SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
2.25.1

[PATCH v13 18/18] drm: bridge: samsung-dsim: Add i.MX8M Plus support

[Jagan Teki]

From: Marek Vasut <marex@denx.de>

Add extras to support i.MX8M Plus. The main change is the removal of
HS/VS/DE signal inversion in the LCDIFv3-DSIM glue logic, otherwise
the implementation of this IP in i.MX8M Plus is very much compatible
with the i.MX8M Mini/Nano one.

Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Acked-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v13:
- none
Changes for v12:
- collect RB from Marek
Changes for v11:
- collect RB from Frieder
- collect ACK from Robert
Changes for v10:
- none
Changes for v9:
- added im8mp in DSIM_STATE_REINITIALIZED check
- drop previous = NULL check

 drivers/gpu/drm/bridge/samsung-dsim.c | 23 +++++++++++++++++++++++
 include/drm/bridge/samsung-dsim.h     |  1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
index 9c64a71d2ebd..f91f2feb1987 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -479,6 +479,7 @@ samsung_dsim_types[DSIM_TYPE_COUNT] = {
 	[DSIM_TYPE_EXYNOS5422] = &exynos5422_dsi_driver_data,
 	[DSIM_TYPE_EXYNOS5433] = &exynos5433_dsi_driver_data,
 	[DSIM_TYPE_IMX8MM] = &imx8mm_dsi_driver_data,
+	[DSIM_TYPE_IMX8MP] = &imx8mm_dsi_driver_data,
 };
 
 static inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
@@ -1452,10 +1453,17 @@ static int samsung_dsim_atomic_check(struct drm_bridge *bridge,
 	 * 13.6.2.7.2 RGB interface
 	 * both claim "Vsync, Hsync, and VDEN are active high signals.", the
 	 * LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW.
+	 *
+	 * The i.MX8M Plus glue logic between LCDIFv3 and DSIM does not
+	 * implement the same behavior, therefore LCDIFv3 must generate
+	 * HS/VS/DE signals active HIGH.
 	 */
 	if (dsi->plat_data->hw_type == DSIM_TYPE_IMX8MM) {
 		adjusted_mode->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
 		adjusted_mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+	} else if (dsi->plat_data->hw_type == DSIM_TYPE_IMX8MP) {
+		adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+		adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
 	}
 
 	return 0;
@@ -1689,6 +1697,10 @@ static const struct samsung_dsim_host_ops generic_dsim_host_ops = {
 	.unregister_host = generic_dsim_unregister_host,
 };
 
+static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_high = {
+	.input_bus_flags = DRM_BUS_FLAG_DE_HIGH,
+};
+
 static const struct drm_bridge_timings samsung_dsim_bridge_timings_de_low = {
 	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
 };
@@ -1778,6 +1790,8 @@ int samsung_dsim_probe(struct platform_device *pdev)
 	/* DE_LOW: i.MX8M Mini/Nano LCDIF-DSIM glue logic inverts HS/VS/DE */
 	if (dsi->plat_data->hw_type == DSIM_TYPE_IMX8MM)
 		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_low;
+	else
+		dsi->bridge.timings = &samsung_dsim_bridge_timings_de_high;
 
 	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->register_host)
 		ret = dsi->plat_data->host_ops->register_host(dsi);
@@ -1883,11 +1897,20 @@ static const struct samsung_dsim_plat_data samsung_dsim_imx8mm_pdata = {
 	.host_ops = &generic_dsim_host_ops,
 };
 
+static const struct samsung_dsim_plat_data samsung_dsim_imx8mp_pdata = {
+	.hw_type = DSIM_TYPE_IMX8MP,
+	.host_ops = &generic_dsim_host_ops,
+};
+
 static const struct of_device_id samsung_dsim_of_match[] = {
 	{
 		.compatible = "fsl,imx8mm-mipi-dsim",
 		.data = &samsung_dsim_imx8mm_pdata,
 	},
+	{
+		.compatible = "fsl,imx8mp-mipi-dsim",
+		.data = &samsung_dsim_imx8mp_pdata,
+	},
 	{ /* sentinel. */ }
 };
 MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
index 4ba387c958ae..fb923caf09e1 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -28,6 +28,7 @@ enum samsung_dsim_type {
 	DSIM_TYPE_EXYNOS5422,
 	DSIM_TYPE_EXYNOS5433,
 	DSIM_TYPE_IMX8MM,
+	DSIM_TYPE_IMX8MP,
 	DSIM_TYPE_COUNT,
 };
 
-- 
2.25.1

Re: [PATCH v13 02/18] drm: bridge: panel: Support nodrm case for drmm_panel_bridge_add

[Maxime Ripard]

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

On Mon, Feb 27, 2023 at 05:09:09PM +0530, Jagan Teki wrote:
> drmm_panel_bridge_add DRM-managed action helper is useful for the bridge
> which automatically removes the bridge when drm pointer is cleaned.
> 
> Supporting the same on non-component bridges like host DSI bridge requires
> a drm pointer which is indeed available only when a panel-bridge is found.
> 
> For these use cases, the caller would call the drmm_panel_bridge_add by
> passing NULL to drm pointer.
> 
> So, assign the bridge->dev to drm pointer for those cases.
> 
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v13:
> - new patch
> 
> Note: use case on 
> "[PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper"
> 
>  drivers/gpu/drm/bridge/panel.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index d4b112911a99..45a0c6671000 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -402,6 +402,13 @@ struct drm_bridge *drmm_panel_bridge_add(struct drm_device *drm,
>  	if (IS_ERR(bridge))
>  		return bridge;
>  
> +	/*
> +	 * For non-component bridges, like host DSI bridge the DRM pointer
> +	 * can be available only when a panel-bridge is found.
> +	 */
> +	if (!drm)
> +		drm = bridge->dev;
> +

Why can't the caller use bridge->dev?

Also, where did the devm_drm_of_dsi_get_bridge go? I thought you were
going to convert it to a drm-managed version?

Maxime

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

Re: [PATCH v13 02/18] drm: bridge: panel: Support nodrm case for drmm_panel_bridge_add

[Jagan Teki]

On Mon, Feb 27, 2023 at 5:41 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Mon, Feb 27, 2023 at 05:09:09PM +0530, Jagan Teki wrote:
> > drmm_panel_bridge_add DRM-managed action helper is useful for the bridge
> > which automatically removes the bridge when drm pointer is cleaned.
> >
> > Supporting the same on non-component bridges like host DSI bridge requires
> > a drm pointer which is indeed available only when a panel-bridge is found.
> >
> > For these use cases, the caller would call the drmm_panel_bridge_add by
> > passing NULL to drm pointer.
> >
> > So, assign the bridge->dev to drm pointer for those cases.
> >
> > Cc: Maxime Ripard <mripard@kernel.org>
> > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > Changes for v13:
> > - new patch
> >
> > Note: use case on
> > "[PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper"
> >
> >  drivers/gpu/drm/bridge/panel.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> > index d4b112911a99..45a0c6671000 100644
> > --- a/drivers/gpu/drm/bridge/panel.c
> > +++ b/drivers/gpu/drm/bridge/panel.c
> > @@ -402,6 +402,13 @@ struct drm_bridge *drmm_panel_bridge_add(struct drm_device *drm,
> >       if (IS_ERR(bridge))
> >               return bridge;
> >
> > +     /*
> > +      * For non-component bridges, like host DSI bridge the DRM pointer
> > +      * can be available only when a panel-bridge is found.
> > +      */
> > +     if (!drm)
> > +             drm = bridge->dev;
> > +
>
> Why can't the caller use bridge->dev?

The first step of drmm_panel_bridge_add is to find the panel-bridge,
so we can only get bridge->dev after this step. The caller doesn't
know anything about the panel bridge it just sends a panel pointer to
find the panel-bridge and then assigns bridge->dev to drm for DRM
action.

Please check this patch about the caller,
https://patchwork.kernel.org/project/dri-devel/patch/20230227113925.875425-5-jagan@amarulasolutions.com/

>
> Also, where did the devm_drm_of_dsi_get_bridge go? I thought you were
> going to convert it to a drm-managed version?

Look like your suggestion to can't use devm_drm_of_dsi_get_bridge and
call the DRM-action from the driver, that is the reason I have removed
this and done the same as your previous inputs.
https://lore.kernel.org/all/20230203110437.otzl2azscbujigv6@houat/

Jagan.

Re: [PATCH v13 02/18] drm: bridge: panel: Support nodrm case for drmm_panel_bridge_add

[Jagan Teki]

On Mon, Feb 27, 2023 at 5:41 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Mon, Feb 27, 2023 at 05:09:09PM +0530, Jagan Teki wrote:
> > drmm_panel_bridge_add DRM-managed action helper is useful for the bridge
> > which automatically removes the bridge when drm pointer is cleaned.
> >
> > Supporting the same on non-component bridges like host DSI bridge requires
> > a drm pointer which is indeed available only when a panel-bridge is found.
> >
> > For these use cases, the caller would call the drmm_panel_bridge_add by
> > passing NULL to drm pointer.
> >
> > So, assign the bridge->dev to drm pointer for those cases.
> >
> > Cc: Maxime Ripard <mripard@kernel.org>
> > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > Changes for v13:
> > - new patch
> >
> > Note: use case on
> > "[PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper"
> >
> >  drivers/gpu/drm/bridge/panel.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> > index d4b112911a99..45a0c6671000 100644
> > --- a/drivers/gpu/drm/bridge/panel.c
> > +++ b/drivers/gpu/drm/bridge/panel.c
> > @@ -402,6 +402,13 @@ struct drm_bridge *drmm_panel_bridge_add(struct drm_device *drm,
> >       if (IS_ERR(bridge))
> >               return bridge;
> >
> > +     /*
> > +      * For non-component bridges, like host DSI bridge the DRM pointer
> > +      * can be available only when a panel-bridge is found.
> > +      */
> > +     if (!drm)
> > +             drm = bridge->dev;
> > +
>
> Why can't the caller use bridge->dev?
>
> Also, where did the devm_drm_of_dsi_get_bridge go? I thought you were
> going to convert it to a drm-managed version?

I found another solution that supports DRM-managed action common
across dsi and normal bridges, can I send those patches alone by
excluding them from this series?

Please let me know.

Jagan.

Re: [PATCH v13 12/18] drm: exynos: dsi: Consolidate component and bridge

[Marek Vasut]

On 2/27/23 12:39, Jagan Teki wrote:

[...]

> @@ -1733,11 +1728,67 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>   	return 0;
>   }
>   
> +static int _exynos_dsi_host_attach(struct exynos_dsi *dsim,

I didn't notice it before, but please get rid of those leading 
underscores in function names, they shouldn't be necessary.

> +				   struct mipi_dsi_device *device)
> +{
> +	struct exynos_dsi_enc *dsi_enc = dsim->priv;

[...]

Re: [PATCH v13 13/18] drm: exynos: dsi: Add host helper for te_irq_handler

[Marek Vasut]

On 2/27/23 12:39, Jagan Teki wrote:
> IRQ handler for te-gpio seems to be common across DSIM host.
> 
> However, Exynos is handling this via CRTC drivers but there is no clear
> evidence on how the same has been handled in i.MX8MM. Keeping the handler
> as-it-is can be a viable option but adding DSIM bridge core in upcoming
> patches is not possible to call Exynos CRTC handler as DSIM bridge has
> to be common across DRM bridge core instead of platform specific DRM
> drivers like Exynos here.
> 
> So, this patch handles the handler via platform host helper, so-that
> handling platform specific hook across Exynos and generic can be
> reasonable till it makes it generic across all platforms.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Marek Vasut <marex@denx.de>

Re: [PATCH v13 11/18] drm: exynos: dsi: Add atomic_get_input_bus_fmts

[Marek Vasut]

On 2/27/23 12:39, Jagan Teki wrote:
> Finding the right input bus format throughout the pipeline is hard
> so add atomic_get_input_bus_fmts callback and initialize with the
> proper input format from list of supported output formats.
> 
> This format can be used in pipeline for negotiating bus format between
> the DSI-end of this bridge and the other component closer to pipeline
> components.
> 
> List of Pixel formats are taken from,
> AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> 3.7.4 Pixel formats
> Table 14. DSI pixel packing formats
> 
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Marek Vasut <marex@denx.de>

Re: [PATCH v13 02/18] drm: bridge: panel: Support nodrm case for drmm_panel_bridge_add

[Maxime Ripard]

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

On Mon, Feb 27, 2023 at 05:58:03PM +0530, Jagan Teki wrote:
> On Mon, Feb 27, 2023 at 5:41 PM Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > On Mon, Feb 27, 2023 at 05:09:09PM +0530, Jagan Teki wrote:
> > > drmm_panel_bridge_add DRM-managed action helper is useful for the bridge
> > > which automatically removes the bridge when drm pointer is cleaned.
> > >
> > > Supporting the same on non-component bridges like host DSI bridge requires
> > > a drm pointer which is indeed available only when a panel-bridge is found.
> > >
> > > For these use cases, the caller would call the drmm_panel_bridge_add by
> > > passing NULL to drm pointer.
> > >
> > > So, assign the bridge->dev to drm pointer for those cases.
> > >
> > > Cc: Maxime Ripard <mripard@kernel.org>
> > > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> > > Cc: Linus Walleij <linus.walleij@linaro.org>
> > > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > ---
> > > Changes for v13:
> > > - new patch
> > >
> > > Note: use case on
> > > "[PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper"
> > >
> > >  drivers/gpu/drm/bridge/panel.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> > > index d4b112911a99..45a0c6671000 100644
> > > --- a/drivers/gpu/drm/bridge/panel.c
> > > +++ b/drivers/gpu/drm/bridge/panel.c
> > > @@ -402,6 +402,13 @@ struct drm_bridge *drmm_panel_bridge_add(struct drm_device *drm,
> > >       if (IS_ERR(bridge))
> > >               return bridge;
> > >
> > > +     /*
> > > +      * For non-component bridges, like host DSI bridge the DRM pointer
> > > +      * can be available only when a panel-bridge is found.
> > > +      */
> > > +     if (!drm)
> > > +             drm = bridge->dev;
> > > +
> >
> > Why can't the caller use bridge->dev?
> 
> The first step of drmm_panel_bridge_add is to find the panel-bridge,
> so we can only get bridge->dev after this step. The caller doesn't
> know anything about the panel bridge it just sends a panel pointer to
> find the panel-bridge

Ah, yes, indeed. This is still a hack we don't need.

> then assigns bridge->dev to drm for DRM action
>
> Please check this patch about the caller,
> https://patchwork.kernel.org/project/dri-devel/patch/20230227113925.875425-5-jagan@amarulasolutions.com/

Because we've already been over this. You can't call that function from
DSI's attach. So you should change that to what I already pointed you
to, and then you'll have the drm device pointer available.

> > Also, where did the devm_drm_of_dsi_get_bridge go? I thought you were
> > going to convert it to a drm-managed version?
> 
> Look like your suggestion to can't use devm_drm_of_dsi_get_bridge and
> call the DRM-action from the driver, that is the reason I have removed
> this and done the same as your previous inputs.
> https://lore.kernel.org/all/20230203110437.otzl2azscbujigv6@houat/

You can't use devm. You can and should definitely use drmm.

Maxime

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

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Marek Vasut]

On 2/27/23 12:39, Jagan Teki wrote:
> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> downstream DSI bridge and panel and trying to add a panel bridge
> if the panel is found.
> 
> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> followed with drmm_panel_bridge_add.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v13, v12, v11:
> - none
> Changes for v10:
> - new patch
> 
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
>   1 file changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index df15501b1075..12a6dd987e8f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -25,6 +25,7 @@
>   #include <drm/drm_atomic_helper.h>
>   #include <drm/drm_bridge.h>
>   #include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_of.h>
>   #include <drm/drm_panel.h>
>   #include <drm/drm_print.h>
>   #include <drm/drm_probe_helper.h>
> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
>   	struct device *dev = dsi->dev;
>   	struct drm_encoder *encoder = &dsi->encoder;
>   	struct drm_device *drm = encoder->dev;
> +	struct drm_bridge *bridge;
>   	struct drm_panel *panel;
>   	int ret;
>   
> -	panel = of_drm_find_panel(device->dev.of_node);
> -	if (!IS_ERR(panel)) {
> -		dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> -	} else {
> -		dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> -		if (!dsi->out_bridge)
> -			dsi->out_bridge = ERR_PTR(-EINVAL);
> -	}

As far as I understand this from my conversation with Maxime (please put 
him on CC of V15), the change here should instead perform the panel look 
up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in 
the component_ops .bind callback . Here is an example of correct 
implementation:

https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805

In 14/18 patch, the same should be added to generic_dsim_register_host() 
, which is called from the driver .probe() callback, but that is OK.

With that implemented, you shouldn't need patches 1,2,3/18 anymore , so 
they can be dropped . And with this fixed, I think the driver should be 
good to be picked.

Please correct me if I'm wrong here.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
>
> On 2/27/23 12:39, Jagan Teki wrote:
> > drm_of_dsi_find_panel_or_bridge is capable of looking up the
> > downstream DSI bridge and panel and trying to add a panel bridge
> > if the panel is found.
> >
> > Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> > followed with drmm_panel_bridge_add.
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > Changes for v13, v12, v11:
> > - none
> > Changes for v10:
> > - new patch
> >
> >   drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> >   1 file changed, 13 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index df15501b1075..12a6dd987e8f 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -25,6 +25,7 @@
> >   #include <drm/drm_atomic_helper.h>
> >   #include <drm/drm_bridge.h>
> >   #include <drm/drm_mipi_dsi.h>
> > +#include <drm/drm_of.h>
> >   #include <drm/drm_panel.h>
> >   #include <drm/drm_print.h>
> >   #include <drm/drm_probe_helper.h>
> > @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> >       struct device *dev = dsi->dev;
> >       struct drm_encoder *encoder = &dsi->encoder;
> >       struct drm_device *drm = encoder->dev;
> > +     struct drm_bridge *bridge;
> >       struct drm_panel *panel;
> >       int ret;
> >
> > -     panel = of_drm_find_panel(device->dev.of_node);
> > -     if (!IS_ERR(panel)) {
> > -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> > -     } else {
> > -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> > -             if (!dsi->out_bridge)
> > -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> > -     }
>
> As far as I understand this from my conversation with Maxime (please put
> him on CC of V15), the change here should instead perform the panel look
> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> the component_ops .bind callback . Here is an example of correct
> implementation:
>
> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805

But, we don't have component_ops.bind for imx8m case, so where do we
want to place the panel hook?

Exynos drm drivers are component-based but, imx8mm is not.

Jagan.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Marek Vasut]

On 2/27/23 20:01, Jagan Teki wrote:
> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 2/27/23 12:39, Jagan Teki wrote:
>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
>>> downstream DSI bridge and panel and trying to add a panel bridge
>>> if the panel is found.
>>>
>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
>>> followed with drmm_panel_bridge_add.
>>>
>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>> ---
>>> Changes for v13, v12, v11:
>>> - none
>>> Changes for v10:
>>> - new patch
>>>
>>>    drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
>>>    1 file changed, 13 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index df15501b1075..12a6dd987e8f 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -25,6 +25,7 @@
>>>    #include <drm/drm_atomic_helper.h>
>>>    #include <drm/drm_bridge.h>
>>>    #include <drm/drm_mipi_dsi.h>
>>> +#include <drm/drm_of.h>
>>>    #include <drm/drm_panel.h>
>>>    #include <drm/drm_print.h>
>>>    #include <drm/drm_probe_helper.h>
>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
>>>        struct device *dev = dsi->dev;
>>>        struct drm_encoder *encoder = &dsi->encoder;
>>>        struct drm_device *drm = encoder->dev;
>>> +     struct drm_bridge *bridge;
>>>        struct drm_panel *panel;
>>>        int ret;
>>>
>>> -     panel = of_drm_find_panel(device->dev.of_node);
>>> -     if (!IS_ERR(panel)) {
>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
>>> -     } else {
>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
>>> -             if (!dsi->out_bridge)
>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
>>> -     }
>>
>> As far as I understand this from my conversation with Maxime (please put
>> him on CC of V15), the change here should instead perform the panel look
>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
>> the component_ops .bind callback . Here is an example of correct
>> implementation:
>>
>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> 
> But, we don't have component_ops.bind for imx8m case, so where do we
> want to place the panel hook?
> 
> Exynos drm drivers are component-based but, imx8mm is not.

In 14/18 patch, the same should be added to generic_dsim_register_host() 
, which is called from the driver .probe() callback, but that is OK.

That's ^ is the iMX part.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
>
> On 2/27/23 20:01, Jagan Teki wrote:
> > On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 2/27/23 12:39, Jagan Teki wrote:
> >>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> >>> downstream DSI bridge and panel and trying to add a panel bridge
> >>> if the panel is found.
> >>>
> >>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> >>> followed with drmm_panel_bridge_add.
> >>>
> >>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>> ---
> >>> Changes for v13, v12, v11:
> >>> - none
> >>> Changes for v10:
> >>> - new patch
> >>>
> >>>    drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> >>>    1 file changed, 13 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>> index df15501b1075..12a6dd987e8f 100644
> >>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>> @@ -25,6 +25,7 @@
> >>>    #include <drm/drm_atomic_helper.h>
> >>>    #include <drm/drm_bridge.h>
> >>>    #include <drm/drm_mipi_dsi.h>
> >>> +#include <drm/drm_of.h>
> >>>    #include <drm/drm_panel.h>
> >>>    #include <drm/drm_print.h>
> >>>    #include <drm/drm_probe_helper.h>
> >>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> >>>        struct device *dev = dsi->dev;
> >>>        struct drm_encoder *encoder = &dsi->encoder;
> >>>        struct drm_device *drm = encoder->dev;
> >>> +     struct drm_bridge *bridge;
> >>>        struct drm_panel *panel;
> >>>        int ret;
> >>>
> >>> -     panel = of_drm_find_panel(device->dev.of_node);
> >>> -     if (!IS_ERR(panel)) {
> >>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> >>> -     } else {
> >>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> >>> -             if (!dsi->out_bridge)
> >>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> >>> -     }
> >>
> >> As far as I understand this from my conversation with Maxime (please put
> >> him on CC of V15), the change here should instead perform the panel look
> >> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> >> the component_ops .bind callback . Here is an example of correct
> >> implementation:
> >>
> >> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> >
> > But, we don't have component_ops.bind for imx8m case, so where do we
> > want to place the panel hook?
> >
> > Exynos drm drivers are component-based but, imx8mm is not.
>
> In 14/18 patch, the same should be added to generic_dsim_register_host()
> , which is called from the driver .probe() callback, but that is OK.
>
> That's ^ is the iMX part.

Ohh. You mean, we need to find the panel hook separately in two places like
- bind for exynos
- probe for imx8mm

If so? how can I find the drm_device pointer in the probe?

Jagan.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Marek Vasut]

On 2/27/23 20:15, Jagan Teki wrote:
> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 2/27/23 20:01, Jagan Teki wrote:
>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 2/27/23 12:39, Jagan Teki wrote:
>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
>>>>> downstream DSI bridge and panel and trying to add a panel bridge
>>>>> if the panel is found.
>>>>>
>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
>>>>> followed with drmm_panel_bridge_add.
>>>>>
>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>> ---
>>>>> Changes for v13, v12, v11:
>>>>> - none
>>>>> Changes for v10:
>>>>> - new patch
>>>>>
>>>>>     drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
>>>>>     1 file changed, 13 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> index df15501b1075..12a6dd987e8f 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>> @@ -25,6 +25,7 @@
>>>>>     #include <drm/drm_atomic_helper.h>
>>>>>     #include <drm/drm_bridge.h>
>>>>>     #include <drm/drm_mipi_dsi.h>
>>>>> +#include <drm/drm_of.h>
>>>>>     #include <drm/drm_panel.h>
>>>>>     #include <drm/drm_print.h>
>>>>>     #include <drm/drm_probe_helper.h>
>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
>>>>>         struct device *dev = dsi->dev;
>>>>>         struct drm_encoder *encoder = &dsi->encoder;
>>>>>         struct drm_device *drm = encoder->dev;
>>>>> +     struct drm_bridge *bridge;
>>>>>         struct drm_panel *panel;
>>>>>         int ret;
>>>>>
>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
>>>>> -     if (!IS_ERR(panel)) {
>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
>>>>> -     } else {
>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
>>>>> -             if (!dsi->out_bridge)
>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
>>>>> -     }
>>>>
>>>> As far as I understand this from my conversation with Maxime (please put
>>>> him on CC of V15), the change here should instead perform the panel look
>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
>>>> the component_ops .bind callback . Here is an example of correct
>>>> implementation:
>>>>
>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
>>>
>>> But, we don't have component_ops.bind for imx8m case, so where do we
>>> want to place the panel hook?
>>>
>>> Exynos drm drivers are component-based but, imx8mm is not.
>>
>> In 14/18 patch, the same should be added to generic_dsim_register_host()
>> , which is called from the driver .probe() callback, but that is OK.
>>
>> That's ^ is the iMX part.
> 
> Ohh. You mean, we need to find the panel hook separately in two places like
> - bind for exynos
> - probe for imx8mm

Yes

> If so? how can I find the drm_device pointer in the probe?

What for ? The panel lookup uses OF graph . Where do you need the 
drm_device in it ?

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
>
> On 2/27/23 20:15, Jagan Teki wrote:
> > On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 2/27/23 20:01, Jagan Teki wrote:
> >>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
> >>>>
> >>>> On 2/27/23 12:39, Jagan Teki wrote:
> >>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> >>>>> downstream DSI bridge and panel and trying to add a panel bridge
> >>>>> if the panel is found.
> >>>>>
> >>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> >>>>> followed with drmm_panel_bridge_add.
> >>>>>
> >>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>> ---
> >>>>> Changes for v13, v12, v11:
> >>>>> - none
> >>>>> Changes for v10:
> >>>>> - new patch
> >>>>>
> >>>>>     drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> >>>>>     1 file changed, 13 insertions(+), 12 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>>>> index df15501b1075..12a6dd987e8f 100644
> >>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>>>> @@ -25,6 +25,7 @@
> >>>>>     #include <drm/drm_atomic_helper.h>
> >>>>>     #include <drm/drm_bridge.h>
> >>>>>     #include <drm/drm_mipi_dsi.h>
> >>>>> +#include <drm/drm_of.h>
> >>>>>     #include <drm/drm_panel.h>
> >>>>>     #include <drm/drm_print.h>
> >>>>>     #include <drm/drm_probe_helper.h>
> >>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> >>>>>         struct device *dev = dsi->dev;
> >>>>>         struct drm_encoder *encoder = &dsi->encoder;
> >>>>>         struct drm_device *drm = encoder->dev;
> >>>>> +     struct drm_bridge *bridge;
> >>>>>         struct drm_panel *panel;
> >>>>>         int ret;
> >>>>>
> >>>>> -     panel = of_drm_find_panel(device->dev.of_node);
> >>>>> -     if (!IS_ERR(panel)) {
> >>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> >>>>> -     } else {
> >>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> >>>>> -             if (!dsi->out_bridge)
> >>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> >>>>> -     }
> >>>>
> >>>> As far as I understand this from my conversation with Maxime (please put
> >>>> him on CC of V15), the change here should instead perform the panel look
> >>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> >>>> the component_ops .bind callback . Here is an example of correct
> >>>> implementation:
> >>>>
> >>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> >>>
> >>> But, we don't have component_ops.bind for imx8m case, so where do we
> >>> want to place the panel hook?
> >>>
> >>> Exynos drm drivers are component-based but, imx8mm is not.
> >>
> >> In 14/18 patch, the same should be added to generic_dsim_register_host()
> >> , which is called from the driver .probe() callback, but that is OK.
> >>
> >> That's ^ is the iMX part.
> >
> > Ohh. You mean, we need to find the panel hook separately in two places like
> > - bind for exynos
> > - probe for imx8mm
>
> Yes
>
> > If so? how can I find the drm_device pointer in the probe?
>
> What for ? The panel lookup uses OF graph . Where do you need the
> drm_device in it ?

May I can summarize the whole setback here so that everybody is on the
same page and find the proper solution?

The key blocker is accessing the DRM pointer in order to use the
DRM-managed action helper.

1. If we find the panel hook in Exynos component_ops.bind then we can
use the DRM pointer directly as VC4 does.
2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
imx8mm) then we can use the DRM pointer directly via bridge->dev.

If we make 2) has common across like finding the panel hook in
drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
panels.

The common solution for both exynos and imx8m is host.attach but if we
do so we cannot get find the DRM pointer.

If we go ahead with no need for DRM-managed helper at the moment, then
find the panel hook in host.attach and then drop 2/18.

Thanks,
Jagan.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Marek Vasut]

On 2/27/23 20:34, Jagan Teki wrote:
> On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 2/27/23 20:15, Jagan Teki wrote:
>>> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 2/27/23 20:01, Jagan Teki wrote:
>>>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>
>>>>>> On 2/27/23 12:39, Jagan Teki wrote:
>>>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
>>>>>>> downstream DSI bridge and panel and trying to add a panel bridge
>>>>>>> if the panel is found.
>>>>>>>
>>>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
>>>>>>> followed with drmm_panel_bridge_add.
>>>>>>>
>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>> ---
>>>>>>> Changes for v13, v12, v11:
>>>>>>> - none
>>>>>>> Changes for v10:
>>>>>>> - new patch
>>>>>>>
>>>>>>>      drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
>>>>>>>      1 file changed, 13 insertions(+), 12 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>>> index df15501b1075..12a6dd987e8f 100644
>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>>> @@ -25,6 +25,7 @@
>>>>>>>      #include <drm/drm_atomic_helper.h>
>>>>>>>      #include <drm/drm_bridge.h>
>>>>>>>      #include <drm/drm_mipi_dsi.h>
>>>>>>> +#include <drm/drm_of.h>
>>>>>>>      #include <drm/drm_panel.h>
>>>>>>>      #include <drm/drm_print.h>
>>>>>>>      #include <drm/drm_probe_helper.h>
>>>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
>>>>>>>          struct device *dev = dsi->dev;
>>>>>>>          struct drm_encoder *encoder = &dsi->encoder;
>>>>>>>          struct drm_device *drm = encoder->dev;
>>>>>>> +     struct drm_bridge *bridge;
>>>>>>>          struct drm_panel *panel;
>>>>>>>          int ret;
>>>>>>>
>>>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
>>>>>>> -     if (!IS_ERR(panel)) {
>>>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
>>>>>>> -     } else {
>>>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
>>>>>>> -             if (!dsi->out_bridge)
>>>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
>>>>>>> -     }
>>>>>>
>>>>>> As far as I understand this from my conversation with Maxime (please put
>>>>>> him on CC of V15), the change here should instead perform the panel look
>>>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
>>>>>> the component_ops .bind callback . Here is an example of correct
>>>>>> implementation:
>>>>>>
>>>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
>>>>>
>>>>> But, we don't have component_ops.bind for imx8m case, so where do we
>>>>> want to place the panel hook?
>>>>>
>>>>> Exynos drm drivers are component-based but, imx8mm is not.
>>>>
>>>> In 14/18 patch, the same should be added to generic_dsim_register_host()
>>>> , which is called from the driver .probe() callback, but that is OK.
>>>>
>>>> That's ^ is the iMX part.
>>>
>>> Ohh. You mean, we need to find the panel hook separately in two places like
>>> - bind for exynos
>>> - probe for imx8mm
>>
>> Yes
>>
>>> If so? how can I find the drm_device pointer in the probe?
>>
>> What for ? The panel lookup uses OF graph . Where do you need the
>> drm_device in it ?
> 
> May I can summarize the whole setback here so that everybody is on the
> same page and find the proper solution?
> 
> The key blocker is accessing the DRM pointer in order to use the
> DRM-managed action helper.
> 
> 1. If we find the panel hook in Exynos component_ops.bind then we can
> use the DRM pointer directly as VC4 does.
> 2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
> imx8mm) then we can use the DRM pointer directly via bridge->dev.
> 
> If we make 2) has common across like finding the panel hook in
> drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
> panels.
> 
> The common solution for both exynos and imx8m is host.attach but if we
> do so we cannot get find the DRM pointer.

There isn't going to be common solution, you would really have to do the 
look up in component_ops .bind callback for exynos , and 
generic_dsim_register_host() for i.MX .

> If we go ahead with no need for DRM-managed helper at the moment, then
> find the panel hook in host.attach and then drop 2/18.

The panel lookup must happen in .bind/.probe for exynos/imx respectively 
, that's really all that is required here. Then you can drop 1,2,3/18 
and get this series applied (I hope) .

Can you implement just this one change ?

There is no need to use drmm_* helper for now, that can be improved 
later if possible.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
>
> On 2/27/23 20:34, Jagan Teki wrote:
> > On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 2/27/23 20:15, Jagan Teki wrote:
> >>> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
> >>>>
> >>>> On 2/27/23 20:01, Jagan Teki wrote:
> >>>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
> >>>>>>
> >>>>>> On 2/27/23 12:39, Jagan Teki wrote:
> >>>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> >>>>>>> downstream DSI bridge and panel and trying to add a panel bridge
> >>>>>>> if the panel is found.
> >>>>>>>
> >>>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> >>>>>>> followed with drmm_panel_bridge_add.
> >>>>>>>
> >>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>> ---
> >>>>>>> Changes for v13, v12, v11:
> >>>>>>> - none
> >>>>>>> Changes for v10:
> >>>>>>> - new patch
> >>>>>>>
> >>>>>>>      drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> >>>>>>>      1 file changed, 13 insertions(+), 12 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>>>>>> index df15501b1075..12a6dd987e8f 100644
> >>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>>>>>> @@ -25,6 +25,7 @@
> >>>>>>>      #include <drm/drm_atomic_helper.h>
> >>>>>>>      #include <drm/drm_bridge.h>
> >>>>>>>      #include <drm/drm_mipi_dsi.h>
> >>>>>>> +#include <drm/drm_of.h>
> >>>>>>>      #include <drm/drm_panel.h>
> >>>>>>>      #include <drm/drm_print.h>
> >>>>>>>      #include <drm/drm_probe_helper.h>
> >>>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> >>>>>>>          struct device *dev = dsi->dev;
> >>>>>>>          struct drm_encoder *encoder = &dsi->encoder;
> >>>>>>>          struct drm_device *drm = encoder->dev;
> >>>>>>> +     struct drm_bridge *bridge;
> >>>>>>>          struct drm_panel *panel;
> >>>>>>>          int ret;
> >>>>>>>
> >>>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
> >>>>>>> -     if (!IS_ERR(panel)) {
> >>>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> >>>>>>> -     } else {
> >>>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> >>>>>>> -             if (!dsi->out_bridge)
> >>>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> >>>>>>> -     }
> >>>>>>
> >>>>>> As far as I understand this from my conversation with Maxime (please put
> >>>>>> him on CC of V15), the change here should instead perform the panel look
> >>>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> >>>>>> the component_ops .bind callback . Here is an example of correct
> >>>>>> implementation:
> >>>>>>
> >>>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> >>>>>
> >>>>> But, we don't have component_ops.bind for imx8m case, so where do we
> >>>>> want to place the panel hook?
> >>>>>
> >>>>> Exynos drm drivers are component-based but, imx8mm is not.
> >>>>
> >>>> In 14/18 patch, the same should be added to generic_dsim_register_host()
> >>>> , which is called from the driver .probe() callback, but that is OK.
> >>>>
> >>>> That's ^ is the iMX part.
> >>>
> >>> Ohh. You mean, we need to find the panel hook separately in two places like
> >>> - bind for exynos
> >>> - probe for imx8mm
> >>
> >> Yes
> >>
> >>> If so? how can I find the drm_device pointer in the probe?
> >>
> >> What for ? The panel lookup uses OF graph . Where do you need the
> >> drm_device in it ?
> >
> > May I can summarize the whole setback here so that everybody is on the
> > same page and find the proper solution?
> >
> > The key blocker is accessing the DRM pointer in order to use the
> > DRM-managed action helper.
> >
> > 1. If we find the panel hook in Exynos component_ops.bind then we can
> > use the DRM pointer directly as VC4 does.
> > 2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
> > imx8mm) then we can use the DRM pointer directly via bridge->dev.
> >
> > If we make 2) has common across like finding the panel hook in
> > drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
> > panels.
> >
> > The common solution for both exynos and imx8m is host.attach but if we
> > do so we cannot get find the DRM pointer.
>
> There isn't going to be common solution, you would really have to do the
> look up in component_ops .bind callback for exynos , and
> generic_dsim_register_host() for i.MX .
>
> > If we go ahead with no need for DRM-managed helper at the moment, then
> > find the panel hook in host.attach and then drop 2/18.
>
> The panel lookup must happen in .bind/.probe for exynos/imx respectively
> , that's really all that is required here. Then you can drop 1,2,3/18
> and get this series applied (I hope) .

I'm not quite sure, if the panel hook in .bind work for exynos or not?
the host. attach has KMS hotplug code after the panel hook and
bridge_attach as before. I believe that is a working scenario for
Exynos to be the panel hook in the host. attach.

>
> Can you implement just this one change ?
>
> There is no need to use drmm_* helper for now, that can be improved
> later if possible.

If this is the case then 1/18 will need otherwise we can drop 1,2,3/18
by doing the panel hook we did in v7
https://patchwork.kernel.org/project/dri-devel/patch/20221005151309.7278-3-jagan@amarulasolutions.com/

Jagan

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 1:19 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Tue, Feb 28, 2023 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
> >
> > On 2/27/23 20:34, Jagan Teki wrote:
> > > On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
> > >>
> > >> On 2/27/23 20:15, Jagan Teki wrote:
> > >>> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
> > >>>>
> > >>>> On 2/27/23 20:01, Jagan Teki wrote:
> > >>>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
> > >>>>>>
> > >>>>>> On 2/27/23 12:39, Jagan Teki wrote:
> > >>>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> > >>>>>>> downstream DSI bridge and panel and trying to add a panel bridge
> > >>>>>>> if the panel is found.
> > >>>>>>>
> > >>>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> > >>>>>>> followed with drmm_panel_bridge_add.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > >>>>>>> ---
> > >>>>>>> Changes for v13, v12, v11:
> > >>>>>>> - none
> > >>>>>>> Changes for v10:
> > >>>>>>> - new patch
> > >>>>>>>
> > >>>>>>>      drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> > >>>>>>>      1 file changed, 13 insertions(+), 12 deletions(-)
> > >>>>>>>
> > >>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > >>>>>>> index df15501b1075..12a6dd987e8f 100644
> > >>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > >>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > >>>>>>> @@ -25,6 +25,7 @@
> > >>>>>>>      #include <drm/drm_atomic_helper.h>
> > >>>>>>>      #include <drm/drm_bridge.h>
> > >>>>>>>      #include <drm/drm_mipi_dsi.h>
> > >>>>>>> +#include <drm/drm_of.h>
> > >>>>>>>      #include <drm/drm_panel.h>
> > >>>>>>>      #include <drm/drm_print.h>
> > >>>>>>>      #include <drm/drm_probe_helper.h>
> > >>>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> > >>>>>>>          struct device *dev = dsi->dev;
> > >>>>>>>          struct drm_encoder *encoder = &dsi->encoder;
> > >>>>>>>          struct drm_device *drm = encoder->dev;
> > >>>>>>> +     struct drm_bridge *bridge;
> > >>>>>>>          struct drm_panel *panel;
> > >>>>>>>          int ret;
> > >>>>>>>
> > >>>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
> > >>>>>>> -     if (!IS_ERR(panel)) {
> > >>>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> > >>>>>>> -     } else {
> > >>>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> > >>>>>>> -             if (!dsi->out_bridge)
> > >>>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> > >>>>>>> -     }
> > >>>>>>
> > >>>>>> As far as I understand this from my conversation with Maxime (please put
> > >>>>>> him on CC of V15), the change here should instead perform the panel look
> > >>>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> > >>>>>> the component_ops .bind callback . Here is an example of correct
> > >>>>>> implementation:
> > >>>>>>
> > >>>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> > >>>>>
> > >>>>> But, we don't have component_ops.bind for imx8m case, so where do we
> > >>>>> want to place the panel hook?
> > >>>>>
> > >>>>> Exynos drm drivers are component-based but, imx8mm is not.
> > >>>>
> > >>>> In 14/18 patch, the same should be added to generic_dsim_register_host()
> > >>>> , which is called from the driver .probe() callback, but that is OK.
> > >>>>
> > >>>> That's ^ is the iMX part.
> > >>>
> > >>> Ohh. You mean, we need to find the panel hook separately in two places like
> > >>> - bind for exynos
> > >>> - probe for imx8mm
> > >>
> > >> Yes
> > >>
> > >>> If so? how can I find the drm_device pointer in the probe?
> > >>
> > >> What for ? The panel lookup uses OF graph . Where do you need the
> > >> drm_device in it ?
> > >
> > > May I can summarize the whole setback here so that everybody is on the
> > > same page and find the proper solution?
> > >
> > > The key blocker is accessing the DRM pointer in order to use the
> > > DRM-managed action helper.
> > >
> > > 1. If we find the panel hook in Exynos component_ops.bind then we can
> > > use the DRM pointer directly as VC4 does.
> > > 2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
> > > imx8mm) then we can use the DRM pointer directly via bridge->dev.
> > >
> > > If we make 2) has common across like finding the panel hook in
> > > drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
> > > panels.
> > >
> > > The common solution for both exynos and imx8m is host.attach but if we
> > > do so we cannot get find the DRM pointer.
> >
> > There isn't going to be common solution, you would really have to do the
> > look up in component_ops .bind callback for exynos , and
> > generic_dsim_register_host() for i.MX .
> >
> > > If we go ahead with no need for DRM-managed helper at the moment, then
> > > find the panel hook in host.attach and then drop 2/18.
> >
> > The panel lookup must happen in .bind/.probe for exynos/imx respectively
> > , that's really all that is required here. Then you can drop 1,2,3/18
> > and get this series applied (I hope) .
>
> I'm not quite sure, if the panel hook in .bind work for exynos or not?
> the host. attach has KMS hotplug code after the panel hook and
> bridge_attach as before. I believe that is a working scenario for
> Exynos to be the panel hook in the host. attach.
>
> >
> > Can you implement just this one change ?
> >
> > There is no need to use drmm_* helper for now, that can be improved
> > later if possible.
>
> If this is the case then 1/18 will need otherwise we can drop 1,2,3/18
> by doing the panel hook we did in v7
> https://patchwork.kernel.org/project/dri-devel/patch/20221005151309.7278-3-jagan@amarulasolutions.com/

This makes panel hook common a cross bridge by handling in the host.attach

Jagan.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Marek Vasut]

On 2/27/23 20:49, Jagan Teki wrote:
> On Tue, Feb 28, 2023 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 2/27/23 20:34, Jagan Teki wrote:
>>> On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 2/27/23 20:15, Jagan Teki wrote:
>>>>> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>
>>>>>> On 2/27/23 20:01, Jagan Teki wrote:
>>>>>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
>>>>>>>>
>>>>>>>> On 2/27/23 12:39, Jagan Teki wrote:
>>>>>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
>>>>>>>>> downstream DSI bridge and panel and trying to add a panel bridge
>>>>>>>>> if the panel is found.
>>>>>>>>>
>>>>>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
>>>>>>>>> followed with drmm_panel_bridge_add.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>>>>>>>>> ---
>>>>>>>>> Changes for v13, v12, v11:
>>>>>>>>> - none
>>>>>>>>> Changes for v10:
>>>>>>>>> - new patch
>>>>>>>>>
>>>>>>>>>       drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
>>>>>>>>>       1 file changed, 13 insertions(+), 12 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>>>>> index df15501b1075..12a6dd987e8f 100644
>>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>>>>> @@ -25,6 +25,7 @@
>>>>>>>>>       #include <drm/drm_atomic_helper.h>
>>>>>>>>>       #include <drm/drm_bridge.h>
>>>>>>>>>       #include <drm/drm_mipi_dsi.h>
>>>>>>>>> +#include <drm/drm_of.h>
>>>>>>>>>       #include <drm/drm_panel.h>
>>>>>>>>>       #include <drm/drm_print.h>
>>>>>>>>>       #include <drm/drm_probe_helper.h>
>>>>>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
>>>>>>>>>           struct device *dev = dsi->dev;
>>>>>>>>>           struct drm_encoder *encoder = &dsi->encoder;
>>>>>>>>>           struct drm_device *drm = encoder->dev;
>>>>>>>>> +     struct drm_bridge *bridge;
>>>>>>>>>           struct drm_panel *panel;
>>>>>>>>>           int ret;
>>>>>>>>>
>>>>>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
>>>>>>>>> -     if (!IS_ERR(panel)) {
>>>>>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
>>>>>>>>> -     } else {
>>>>>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
>>>>>>>>> -             if (!dsi->out_bridge)
>>>>>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
>>>>>>>>> -     }
>>>>>>>>
>>>>>>>> As far as I understand this from my conversation with Maxime (please put
>>>>>>>> him on CC of V15), the change here should instead perform the panel look
>>>>>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
>>>>>>>> the component_ops .bind callback . Here is an example of correct
>>>>>>>> implementation:
>>>>>>>>
>>>>>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
>>>>>>>
>>>>>>> But, we don't have component_ops.bind for imx8m case, so where do we
>>>>>>> want to place the panel hook?
>>>>>>>
>>>>>>> Exynos drm drivers are component-based but, imx8mm is not.
>>>>>>
>>>>>> In 14/18 patch, the same should be added to generic_dsim_register_host()
>>>>>> , which is called from the driver .probe() callback, but that is OK.
>>>>>>
>>>>>> That's ^ is the iMX part.
>>>>>
>>>>> Ohh. You mean, we need to find the panel hook separately in two places like
>>>>> - bind for exynos
>>>>> - probe for imx8mm
>>>>
>>>> Yes
>>>>
>>>>> If so? how can I find the drm_device pointer in the probe?
>>>>
>>>> What for ? The panel lookup uses OF graph . Where do you need the
>>>> drm_device in it ?
>>>
>>> May I can summarize the whole setback here so that everybody is on the
>>> same page and find the proper solution?
>>>
>>> The key blocker is accessing the DRM pointer in order to use the
>>> DRM-managed action helper.
>>>
>>> 1. If we find the panel hook in Exynos component_ops.bind then we can
>>> use the DRM pointer directly as VC4 does.
>>> 2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
>>> imx8mm) then we can use the DRM pointer directly via bridge->dev.
>>>
>>> If we make 2) has common across like finding the panel hook in
>>> drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
>>> panels.
>>>
>>> The common solution for both exynos and imx8m is host.attach but if we
>>> do so we cannot get find the DRM pointer.
>>
>> There isn't going to be common solution, you would really have to do the
>> look up in component_ops .bind callback for exynos , and
>> generic_dsim_register_host() for i.MX .
>>
>>> If we go ahead with no need for DRM-managed helper at the moment, then
>>> find the panel hook in host.attach and then drop 2/18.
>>
>> The panel lookup must happen in .bind/.probe for exynos/imx respectively
>> , that's really all that is required here. Then you can drop 1,2,3/18
>> and get this series applied (I hope) .
> 
> I'm not quite sure, if the panel hook in .bind work for exynos or not?

Marek should be able to test exynos for you one more time I hope.

> the host. attach has KMS hotplug code after the panel hook and
> bridge_attach as before. I believe that is a working scenario for
> Exynos to be the panel hook in the host. attach.

As far as I understand it, the look up has to be in .bind callback (and 
generic_dsim_register_host() for imx). Can you try if/how that works ?

>> Can you implement just this one change ?
>>
>> There is no need to use drmm_* helper for now, that can be improved
>> later if possible.
> 
> If this is the case then 1/18 will need otherwise

Ah yes, 1/18 will be needed indeed. It should just be called from .bind 
callback or generic_dsim_register_host() (i.e. probe callback).

>  we can drop 1,2,3/18
> by doing the panel hook we did in v7
> https://patchwork.kernel.org/project/dri-devel/patch/20221005151309.7278-3-jagan@amarulasolutions.com/

[...]

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 1:40 AM Marek Vasut <marex@denx.de> wrote:
>
> On 2/27/23 20:49, Jagan Teki wrote:
> > On Tue, Feb 28, 2023 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 2/27/23 20:34, Jagan Teki wrote:
> >>> On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
> >>>>
> >>>> On 2/27/23 20:15, Jagan Teki wrote:
> >>>>> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
> >>>>>>
> >>>>>> On 2/27/23 20:01, Jagan Teki wrote:
> >>>>>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
> >>>>>>>>
> >>>>>>>> On 2/27/23 12:39, Jagan Teki wrote:
> >>>>>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> >>>>>>>>> downstream DSI bridge and panel and trying to add a panel bridge
> >>>>>>>>> if the panel is found.
> >>>>>>>>>
> >>>>>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> >>>>>>>>> followed with drmm_panel_bridge_add.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> >>>>>>>>> ---
> >>>>>>>>> Changes for v13, v12, v11:
> >>>>>>>>> - none
> >>>>>>>>> Changes for v10:
> >>>>>>>>> - new patch
> >>>>>>>>>
> >>>>>>>>>       drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> >>>>>>>>>       1 file changed, 13 insertions(+), 12 deletions(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>>>>>>>> index df15501b1075..12a6dd987e8f 100644
> >>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> >>>>>>>>> @@ -25,6 +25,7 @@
> >>>>>>>>>       #include <drm/drm_atomic_helper.h>
> >>>>>>>>>       #include <drm/drm_bridge.h>
> >>>>>>>>>       #include <drm/drm_mipi_dsi.h>
> >>>>>>>>> +#include <drm/drm_of.h>
> >>>>>>>>>       #include <drm/drm_panel.h>
> >>>>>>>>>       #include <drm/drm_print.h>
> >>>>>>>>>       #include <drm/drm_probe_helper.h>
> >>>>>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> >>>>>>>>>           struct device *dev = dsi->dev;
> >>>>>>>>>           struct drm_encoder *encoder = &dsi->encoder;
> >>>>>>>>>           struct drm_device *drm = encoder->dev;
> >>>>>>>>> +     struct drm_bridge *bridge;
> >>>>>>>>>           struct drm_panel *panel;
> >>>>>>>>>           int ret;
> >>>>>>>>>
> >>>>>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
> >>>>>>>>> -     if (!IS_ERR(panel)) {
> >>>>>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> >>>>>>>>> -     } else {
> >>>>>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> >>>>>>>>> -             if (!dsi->out_bridge)
> >>>>>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> >>>>>>>>> -     }
> >>>>>>>>
> >>>>>>>> As far as I understand this from my conversation with Maxime (please put
> >>>>>>>> him on CC of V15), the change here should instead perform the panel look
> >>>>>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> >>>>>>>> the component_ops .bind callback . Here is an example of correct
> >>>>>>>> implementation:
> >>>>>>>>
> >>>>>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> >>>>>>>
> >>>>>>> But, we don't have component_ops.bind for imx8m case, so where do we
> >>>>>>> want to place the panel hook?
> >>>>>>>
> >>>>>>> Exynos drm drivers are component-based but, imx8mm is not.
> >>>>>>
> >>>>>> In 14/18 patch, the same should be added to generic_dsim_register_host()
> >>>>>> , which is called from the driver .probe() callback, but that is OK.
> >>>>>>
> >>>>>> That's ^ is the iMX part.
> >>>>>
> >>>>> Ohh. You mean, we need to find the panel hook separately in two places like
> >>>>> - bind for exynos
> >>>>> - probe for imx8mm
> >>>>
> >>>> Yes
> >>>>
> >>>>> If so? how can I find the drm_device pointer in the probe?
> >>>>
> >>>> What for ? The panel lookup uses OF graph . Where do you need the
> >>>> drm_device in it ?
> >>>
> >>> May I can summarize the whole setback here so that everybody is on the
> >>> same page and find the proper solution?
> >>>
> >>> The key blocker is accessing the DRM pointer in order to use the
> >>> DRM-managed action helper.
> >>>
> >>> 1. If we find the panel hook in Exynos component_ops.bind then we can
> >>> use the DRM pointer directly as VC4 does.
> >>> 2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
> >>> imx8mm) then we can use the DRM pointer directly via bridge->dev.
> >>>
> >>> If we make 2) has common across like finding the panel hook in
> >>> drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
> >>> panels.
> >>>
> >>> The common solution for both exynos and imx8m is host.attach but if we
> >>> do so we cannot get find the DRM pointer.
> >>
> >> There isn't going to be common solution, you would really have to do the
> >> look up in component_ops .bind callback for exynos , and
> >> generic_dsim_register_host() for i.MX .
> >>
> >>> If we go ahead with no need for DRM-managed helper at the moment, then
> >>> find the panel hook in host.attach and then drop 2/18.
> >>
> >> The panel lookup must happen in .bind/.probe for exynos/imx respectively
> >> , that's really all that is required here. Then you can drop 1,2,3/18
> >> and get this series applied (I hope) .
> >
> > I'm not quite sure, if the panel hook in .bind work for exynos or not?
>
> Marek should be able to test exynos for you one more time I hope.
>
> > the host. attach has KMS hotplug code after the panel hook and
> > bridge_attach as before. I believe that is a working scenario for
> > Exynos to be the panel hook in the host. attach.
>
> As far as I understand it, the look up has to be in .bind callback (and
> generic_dsim_register_host() for imx). Can you try if/how that works ?
>
> >> Can you implement just this one change ?
> >>
> >> There is no need to use drmm_* helper for now, that can be improved
> >> later if possible.
> >
> > If this is the case then 1/18 will need otherwise
>
> Ah yes, 1/18 will be needed indeed. It should just be called from .bind
> callback or generic_dsim_register_host() (i.e. probe callback).

panel hook at the probe call would be wrong. the downstream bridge
will call mipi_dsi_attach for finding the connected upstream, so it
indeed calls host.attach. If we move the panel hook at the probe, then
probing will defer.

[   12.046862] platform 32e10000.dsi: deferred probe pending
[   12.052309] platform 32e00000.lcdif: deferred probe pending

What is the problem to have it in host.attach for both cases? some DSI
host bridges still do the same (mtk_dsi) and this is what is mentioned
in documentation point 2 and 3 here,
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges

"
The upstream driver doesn’t use the component framework, but is a
MIPI-DSI host. The bridge device uses the MIPI-DCS commands to be
controlled. In this case, the bridge device is a child of the display
device and when it will probe it’s assured that the display device
(and MIPI-DSI host) is present. The upstream driver will be assured
that the bridge driver is connected between the
mipi_dsi_host_ops.attach and mipi_dsi_host_ops.detach operations.
Therefore, it must run mipi_dsi_host_register() in its probe function,
and then run drm_bridge_attach() in its mipi_dsi_host_ops.attach hook.

The upstream driver uses the component framework and is a MIPI-DSI
host. The bridge device uses the MIPI-DCS commands to be controlled.
This is the same situation than above, and can run
mipi_dsi_host_register() in either its probe or bind hooks.
"

Point 2 for Exynos and 3 for imx8m flow, for both the cases
drm_bridge_attach in host_ops.attach hook so the panel hook must be in
same place.

Thanks,
Jagan.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Maxime Ripard]

On Tue, Feb 28, 2023 at 02:08:53AM +0530, Jagan Teki wrote:
> On Tue, Feb 28, 2023 at 1:40 AM Marek Vasut <marex@denx.de> wrote:
> >
> > On 2/27/23 20:49, Jagan Teki wrote:
> > > On Tue, Feb 28, 2023 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
> > >>
> > >> On 2/27/23 20:34, Jagan Teki wrote:
> > >>> On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
> > >>>>
> > >>>> On 2/27/23 20:15, Jagan Teki wrote:
> > >>>>> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
> > >>>>>>
> > >>>>>> On 2/27/23 20:01, Jagan Teki wrote:
> > >>>>>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
> > >>>>>>>>
> > >>>>>>>> On 2/27/23 12:39, Jagan Teki wrote:
> > >>>>>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> > >>>>>>>>> downstream DSI bridge and panel and trying to add a panel bridge
> > >>>>>>>>> if the panel is found.
> > >>>>>>>>>
> > >>>>>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> > >>>>>>>>> followed with drmm_panel_bridge_add.
> > >>>>>>>>>
> > >>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > >>>>>>>>> ---
> > >>>>>>>>> Changes for v13, v12, v11:
> > >>>>>>>>> - none
> > >>>>>>>>> Changes for v10:
> > >>>>>>>>> - new patch
> > >>>>>>>>>
> > >>>>>>>>>       drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> > >>>>>>>>>       1 file changed, 13 insertions(+), 12 deletions(-)
> > >>>>>>>>>
> > >>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > >>>>>>>>> index df15501b1075..12a6dd987e8f 100644
> > >>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > >>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > >>>>>>>>> @@ -25,6 +25,7 @@
> > >>>>>>>>>       #include <drm/drm_atomic_helper.h>
> > >>>>>>>>>       #include <drm/drm_bridge.h>
> > >>>>>>>>>       #include <drm/drm_mipi_dsi.h>
> > >>>>>>>>> +#include <drm/drm_of.h>
> > >>>>>>>>>       #include <drm/drm_panel.h>
> > >>>>>>>>>       #include <drm/drm_print.h>
> > >>>>>>>>>       #include <drm/drm_probe_helper.h>
> > >>>>>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> > >>>>>>>>>           struct device *dev = dsi->dev;
> > >>>>>>>>>           struct drm_encoder *encoder = &dsi->encoder;
> > >>>>>>>>>           struct drm_device *drm = encoder->dev;
> > >>>>>>>>> +     struct drm_bridge *bridge;
> > >>>>>>>>>           struct drm_panel *panel;
> > >>>>>>>>>           int ret;
> > >>>>>>>>>
> > >>>>>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
> > >>>>>>>>> -     if (!IS_ERR(panel)) {
> > >>>>>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> > >>>>>>>>> -     } else {
> > >>>>>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> > >>>>>>>>> -             if (!dsi->out_bridge)
> > >>>>>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> > >>>>>>>>> -     }
> > >>>>>>>>
> > >>>>>>>> As far as I understand this from my conversation with Maxime (please put
> > >>>>>>>> him on CC of V15), the change here should instead perform the panel look
> > >>>>>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> > >>>>>>>> the component_ops .bind callback . Here is an example of correct
> > >>>>>>>> implementation:
> > >>>>>>>>
> > >>>>>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> > >>>>>>>
> > >>>>>>> But, we don't have component_ops.bind for imx8m case, so where do we
> > >>>>>>> want to place the panel hook?
> > >>>>>>>
> > >>>>>>> Exynos drm drivers are component-based but, imx8mm is not.
> > >>>>>>
> > >>>>>> In 14/18 patch, the same should be added to generic_dsim_register_host()
> > >>>>>> , which is called from the driver .probe() callback, but that is OK.
> > >>>>>>
> > >>>>>> That's ^ is the iMX part.
> > >>>>>
> > >>>>> Ohh. You mean, we need to find the panel hook separately in two places like
> > >>>>> - bind for exynos
> > >>>>> - probe for imx8mm
> > >>>>
> > >>>> Yes
> > >>>>
> > >>>>> If so? how can I find the drm_device pointer in the probe?
> > >>>>
> > >>>> What for ? The panel lookup uses OF graph . Where do you need the
> > >>>> drm_device in it ?
> > >>>
> > >>> May I can summarize the whole setback here so that everybody is on the
> > >>> same page and find the proper solution?
> > >>>
> > >>> The key blocker is accessing the DRM pointer in order to use the
> > >>> DRM-managed action helper.
> > >>>
> > >>> 1. If we find the panel hook in Exynos component_ops.bind then we can
> > >>> use the DRM pointer directly as VC4 does.
> > >>> 2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
> > >>> imx8mm) then we can use the DRM pointer directly via bridge->dev.
> > >>>
> > >>> If we make 2) has common across like finding the panel hook in
> > >>> drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
> > >>> panels.
> > >>>
> > >>> The common solution for both exynos and imx8m is host.attach but if we
> > >>> do so we cannot get find the DRM pointer.
> > >>
> > >> There isn't going to be common solution, you would really have to do the
> > >> look up in component_ops .bind callback for exynos , and
> > >> generic_dsim_register_host() for i.MX .
> > >>
> > >>> If we go ahead with no need for DRM-managed helper at the moment, then
> > >>> find the panel hook in host.attach and then drop 2/18.
> > >>
> > >> The panel lookup must happen in .bind/.probe for exynos/imx respectively
> > >> , that's really all that is required here. Then you can drop 1,2,3/18
> > >> and get this series applied (I hope) .
> > >
> > > I'm not quite sure, if the panel hook in .bind work for exynos or not?
> >
> > Marek should be able to test exynos for you one more time I hope.
> >
> > > the host. attach has KMS hotplug code after the panel hook and
> > > bridge_attach as before. I believe that is a working scenario for
> > > Exynos to be the panel hook in the host. attach.
> >
> > As far as I understand it, the look up has to be in .bind callback (and
> > generic_dsim_register_host() for imx). Can you try if/how that works ?
> >
> > >> Can you implement just this one change ?
> > >>
> > >> There is no need to use drmm_* helper for now, that can be improved
> > >> later if possible.
> > >
> > > If this is the case then 1/18 will need otherwise
> >
> > Ah yes, 1/18 will be needed indeed. It should just be called from .bind
> > callback or generic_dsim_register_host() (i.e. probe callback).
> 
> panel hook at the probe call would be wrong.

Why?

> the downstream bridge will call mipi_dsi_attach for finding the
> connected upstream, so it indeed calls host.attach. If we move the
> panel hook at the probe, then probing will defer.
> 
> [   12.046862] platform 32e10000.dsi: deferred probe pending
> [   12.052309] platform 32e00000.lcdif: deferred probe pending

What is the dependency chain there, and why doesn't it probe?

> What is the problem to have it in host.attach for both cases?

You've put a link to the documentation that explains what the problem is
in your mail.

> some DSI host bridges still do the same (mtk_dsi)

Then some are broken. How is that an argument?

> and this is what is mentioned in documentation point 2 and 3 here,
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
> 
> "
> The upstream driver doesn’t use the component framework, but is a
> MIPI-DSI host.

Exynos uses the component framework. So that point doesn't apply to it.

> The bridge device uses the MIPI-DCS commands to be
> controlled. In this case, the bridge device is a child of the display
> device and when it will probe it’s assured that the display device
> (and MIPI-DSI host) is present. The upstream driver will be assured
> that the bridge driver is connected between the
> mipi_dsi_host_ops.attach and mipi_dsi_host_ops.detach operations.
> Therefore, it must run mipi_dsi_host_register() in its probe function,
> and then run drm_bridge_attach() in its mipi_dsi_host_ops.attach hook.
> 
> The upstream driver uses the component framework and is a MIPI-DSI
> host. The bridge device uses the MIPI-DCS commands to be controlled.
> This is the same situation than above, and can run
> mipi_dsi_host_register() in either its probe or bind hooks.
> "
> 
> Point 2 for Exynos and 3 for imx8m flow, for both the cases
> drm_bridge_attach in host_ops.attach hook so the panel hook must be in
> same place.

And you forgot the fourth point:

> The upstream driver uses the component framework and is a MIPI-DSI
> host. The bridge device uses a separate bus (such as I2C) to be
> controlled. In this case, there’s no correlation between the probe of
> the bridge and upstream drivers, so care must be taken to avoid an
> endless EPROBE_DEFER loop, with each driver waiting for the other to
> probe.

Which is what the whole discussion is about.

Maxime

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Maxime Ripard]

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

On Mon, Feb 27, 2023 at 08:41:22PM +0100, Marek Vasut wrote:
> > If we go ahead with no need for DRM-managed helper at the moment, then
> > find the panel hook in host.attach and then drop 2/18.
> 
> The panel lookup must happen in .bind/.probe for exynos/imx respectively ,
> that's really all that is required here. Then you can drop 1,2,3/18 and get
> this series applied (I hope) .
> 
> Can you implement just this one change ?
> 
> There is no need to use drmm_* helper for now, that can be improved later if
> possible.

Yeah... The drmm helper isn't needed per se, but not using it will
create a use-after-free pattern that is very easy to miss.

I'd really prefer not to add a new helper that favors an unsafe pattern,
but the driver seems to have a whole bunch of them anyway so it's not
really a big deal.

Which also raises another question: if it's code that is only really
relevant in the context of that driver, why are you creating a helper
for it in the first place?

It would be much easier to just have that code in your driver: there's
no need to consider all cases, document it properly, you can have as
many workarounds as possible, etc.

Maxime

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

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 5:40 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Mon, Feb 27, 2023 at 08:41:22PM +0100, Marek Vasut wrote:
> > > If we go ahead with no need for DRM-managed helper at the moment, then
> > > find the panel hook in host.attach and then drop 2/18.
> >
> > The panel lookup must happen in .bind/.probe for exynos/imx respectively ,
> > that's really all that is required here. Then you can drop 1,2,3/18 and get
> > this series applied (I hope) .
> >
> > Can you implement just this one change ?
> >
> > There is no need to use drmm_* helper for now, that can be improved later if
> > possible.
>
> Yeah... The drmm helper isn't needed per se, but not using it will
> create a use-after-free pattern that is very easy to miss.
>
> I'd really prefer not to add a new helper that favors an unsafe pattern,
> but the driver seems to have a whole bunch of them anyway so it's not
> really a big deal.
>
> Which also raises another question: if it's code that is only really
> relevant in the context of that driver, why are you creating a helper
> for it in the first place?

I can answer this question as I did add these helpers.

1. DSI-specific helper added since it is a good candidate for
common/helper code, based on the comments in V9 by Marek. V
https://patchwork.kernel.org/project/dri-devel/patch/20221209152343.180139-8-jagan@amarulasolutions.com/

So, I have added this to the common drm_of code in V10.
https://patchwork.kernel.org/project/dri-devel/patch/20221214125907.376148-2-jagan@amarulasolutions.com/

2. DRM-managed discussion was commented on in V11 by you, so from
where all discussion moved.
https://patchwork.kernel.org/project/dri-devel/patch/20230123151212.269082-3-jagan@amarulasolutions.com/

1) helper wouldn't be an unsafe helper as it can reuse many DSI
drivers but 2) helper might be an unsafe helper at the moment.

Jagan.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Maxime Ripard]

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

On Tue, Feb 28, 2023 at 06:04:39PM +0530, Jagan Teki wrote:
> On Tue, Feb 28, 2023 at 5:40 PM Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > On Mon, Feb 27, 2023 at 08:41:22PM +0100, Marek Vasut wrote:
> > > > If we go ahead with no need for DRM-managed helper at the moment, then
> > > > find the panel hook in host.attach and then drop 2/18.
> > >
> > > The panel lookup must happen in .bind/.probe for exynos/imx respectively ,
> > > that's really all that is required here. Then you can drop 1,2,3/18 and get
> > > this series applied (I hope) .
> > >
> > > Can you implement just this one change ?
> > >
> > > There is no need to use drmm_* helper for now, that can be improved later if
> > > possible.
> >
> > Yeah... The drmm helper isn't needed per se, but not using it will
> > create a use-after-free pattern that is very easy to miss.
> >
> > I'd really prefer not to add a new helper that favors an unsafe pattern,
> > but the driver seems to have a whole bunch of them anyway so it's not
> > really a big deal.
> >
> > Which also raises another question: if it's code that is only really
> > relevant in the context of that driver, why are you creating a helper
> > for it in the first place?
> 
> I can answer this question as I did add these helpers.
> 
> 1. DSI-specific helper added since it is a good candidate for
> common/helper code, based on the comments in V9 by Marek. V
> https://patchwork.kernel.org/project/dri-devel/patch/20221209152343.180139-8-jagan@amarulasolutions.com/
> 
> So, I have added this to the common drm_of code in V10.
> https://patchwork.kernel.org/project/dri-devel/patch/20221214125907.376148-2-jagan@amarulasolutions.com/
> 
> 2. DRM-managed discussion was commented on in V11 by you, so from
> where all discussion moved.
> https://patchwork.kernel.org/project/dri-devel/patch/20230123151212.269082-3-jagan@amarulasolutions.com/
> 
> 1) helper wouldn't be an unsafe helper as it can reuse many DSI
> drivers but 2) helper might be an unsafe helper at the moment.

You're wrong. The first one is unsafe, for the same reason than the devm
one you did is unsafe: the assumption everyone will get (and the one you
implemented in your driver) is that the bridge reference will be put
back at remove time.

The DRM/KMS structures however are free'd only when the last user closes
the file descriptor of the KMS device, so your driver functions will get
called after remove has been called.

If you are using the panel or bridge in any of your KMS hooks
implementations, this is now a use-after-free.

The drmm variant is safe though, because drmm actions run not when the
device is removed but when the DRM device is last closed.

Maxime

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

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 5:34 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Tue, Feb 28, 2023 at 02:08:53AM +0530, Jagan Teki wrote:
> > On Tue, Feb 28, 2023 at 1:40 AM Marek Vasut <marex@denx.de> wrote:
> > >
> > > On 2/27/23 20:49, Jagan Teki wrote:
> > > > On Tue, Feb 28, 2023 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
> > > >>
> > > >> On 2/27/23 20:34, Jagan Teki wrote:
> > > >>> On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
> > > >>>>
> > > >>>> On 2/27/23 20:15, Jagan Teki wrote:
> > > >>>>> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
> > > >>>>>>
> > > >>>>>> On 2/27/23 20:01, Jagan Teki wrote:
> > > >>>>>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
> > > >>>>>>>>
> > > >>>>>>>> On 2/27/23 12:39, Jagan Teki wrote:
> > > >>>>>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> > > >>>>>>>>> downstream DSI bridge and panel and trying to add a panel bridge
> > > >>>>>>>>> if the panel is found.
> > > >>>>>>>>>
> > > >>>>>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> > > >>>>>>>>> followed with drmm_panel_bridge_add.
> > > >>>>>>>>>
> > > >>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > >>>>>>>>> ---
> > > >>>>>>>>> Changes for v13, v12, v11:
> > > >>>>>>>>> - none
> > > >>>>>>>>> Changes for v10:
> > > >>>>>>>>> - new patch
> > > >>>>>>>>>
> > > >>>>>>>>>       drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> > > >>>>>>>>>       1 file changed, 13 insertions(+), 12 deletions(-)
> > > >>>>>>>>>
> > > >>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > > >>>>>>>>> index df15501b1075..12a6dd987e8f 100644
> > > >>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > > >>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > > >>>>>>>>> @@ -25,6 +25,7 @@
> > > >>>>>>>>>       #include <drm/drm_atomic_helper.h>
> > > >>>>>>>>>       #include <drm/drm_bridge.h>
> > > >>>>>>>>>       #include <drm/drm_mipi_dsi.h>
> > > >>>>>>>>> +#include <drm/drm_of.h>
> > > >>>>>>>>>       #include <drm/drm_panel.h>
> > > >>>>>>>>>       #include <drm/drm_print.h>
> > > >>>>>>>>>       #include <drm/drm_probe_helper.h>
> > > >>>>>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> > > >>>>>>>>>           struct device *dev = dsi->dev;
> > > >>>>>>>>>           struct drm_encoder *encoder = &dsi->encoder;
> > > >>>>>>>>>           struct drm_device *drm = encoder->dev;
> > > >>>>>>>>> +     struct drm_bridge *bridge;
> > > >>>>>>>>>           struct drm_panel *panel;
> > > >>>>>>>>>           int ret;
> > > >>>>>>>>>
> > > >>>>>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
> > > >>>>>>>>> -     if (!IS_ERR(panel)) {
> > > >>>>>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> > > >>>>>>>>> -     } else {
> > > >>>>>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> > > >>>>>>>>> -             if (!dsi->out_bridge)
> > > >>>>>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> > > >>>>>>>>> -     }
> > > >>>>>>>>
> > > >>>>>>>> As far as I understand this from my conversation with Maxime (please put
> > > >>>>>>>> him on CC of V15), the change here should instead perform the panel look
> > > >>>>>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> > > >>>>>>>> the component_ops .bind callback . Here is an example of correct
> > > >>>>>>>> implementation:
> > > >>>>>>>>
> > > >>>>>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> > > >>>>>>>
> > > >>>>>>> But, we don't have component_ops.bind for imx8m case, so where do we
> > > >>>>>>> want to place the panel hook?
> > > >>>>>>>
> > > >>>>>>> Exynos drm drivers are component-based but, imx8mm is not.
> > > >>>>>>
> > > >>>>>> In 14/18 patch, the same should be added to generic_dsim_register_host()
> > > >>>>>> , which is called from the driver .probe() callback, but that is OK.
> > > >>>>>>
> > > >>>>>> That's ^ is the iMX part.
> > > >>>>>
> > > >>>>> Ohh. You mean, we need to find the panel hook separately in two places like
> > > >>>>> - bind for exynos
> > > >>>>> - probe for imx8mm
> > > >>>>
> > > >>>> Yes
> > > >>>>
> > > >>>>> If so? how can I find the drm_device pointer in the probe?
> > > >>>>
> > > >>>> What for ? The panel lookup uses OF graph . Where do you need the
> > > >>>> drm_device in it ?
> > > >>>
> > > >>> May I can summarize the whole setback here so that everybody is on the
> > > >>> same page and find the proper solution?
> > > >>>
> > > >>> The key blocker is accessing the DRM pointer in order to use the
> > > >>> DRM-managed action helper.
> > > >>>
> > > >>> 1. If we find the panel hook in Exynos component_ops.bind then we can
> > > >>> use the DRM pointer directly as VC4 does.
> > > >>> 2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
> > > >>> imx8mm) then we can use the DRM pointer directly via bridge->dev.
> > > >>>
> > > >>> If we make 2) has common across like finding the panel hook in
> > > >>> drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
> > > >>> panels.
> > > >>>
> > > >>> The common solution for both exynos and imx8m is host.attach but if we
> > > >>> do so we cannot get find the DRM pointer.
> > > >>
> > > >> There isn't going to be common solution, you would really have to do the
> > > >> look up in component_ops .bind callback for exynos , and
> > > >> generic_dsim_register_host() for i.MX .
> > > >>
> > > >>> If we go ahead with no need for DRM-managed helper at the moment, then
> > > >>> find the panel hook in host.attach and then drop 2/18.
> > > >>
> > > >> The panel lookup must happen in .bind/.probe for exynos/imx respectively
> > > >> , that's really all that is required here. Then you can drop 1,2,3/18
> > > >> and get this series applied (I hope) .
> > > >
> > > > I'm not quite sure, if the panel hook in .bind work for exynos or not?
> > >
> > > Marek should be able to test exynos for you one more time I hope.
> > >
> > > > the host. attach has KMS hotplug code after the panel hook and
> > > > bridge_attach as before. I believe that is a working scenario for
> > > > Exynos to be the panel hook in the host. attach.
> > >
> > > As far as I understand it, the look up has to be in .bind callback (and
> > > generic_dsim_register_host() for imx). Can you try if/how that works ?
> > >
> > > >> Can you implement just this one change ?
> > > >>
> > > >> There is no need to use drmm_* helper for now, that can be improved
> > > >> later if possible.
> > > >
> > > > If this is the case then 1/18 will need otherwise
> > >
> > > Ah yes, 1/18 will be needed indeed. It should just be called from .bind
> > > callback or generic_dsim_register_host() (i.e. probe callback).
> >
> > panel hook at the probe call would be wrong.
>
> Why?
>
> > the downstream bridge will call mipi_dsi_attach for finding the
> > connected upstream, so it indeed calls host.attach. If we move the
> > panel hook at the probe, then probing will defer.
> >
> > [   12.046862] platform 32e10000.dsi: deferred probe pending
> > [   12.052309] platform 32e00000.lcdif: deferred probe pending
>
> What is the dependency chain there, and why doesn't it probe?

Let me answer here for the above 2 queries.

This is clearly a point 2 scenario from the documentation.

"
The upstream driver doesn’t use the component framework, but is a
MIPI-DSI host. The bridge device uses the MIPI-DCS commands to be
controlled. In this case, the bridge device is a child of the display
device and when it will probe it’s assured that the display device
(and MIPI-DSI host) is present. The upstream driver will be assured
that the bridge driver is connected between the
mipi_dsi_host_ops.attach and mipi_dsi_host_ops.detach operations.
Therefore, it must run mipi_dsi_host_register() in its probe function,
and then run drm_bridge_attach() in its mipi_dsi_host_ops.attach hook.
"

So, the samsung-dsim follows the same rule, mipi_dsi_host_register()
in the probe and drm_bridge_attach() in mipi_dsi_host_ops.attach hook.

Above also mentioned "The upstream driver will be assured that the
bridge driver is connected between the mipi_dsi_host_ops.attach and
mipi_dsi_host_ops.detach operations" that means we need to find the
panel or bridge in mipi_dsi_host_ops.attach am I correct? not in the
probe.

lcdif => samsung-dsim => ti-sn65dsi (I2C) => panel this is the bridge
chain. ti-sn65dsi is registered the MIPI Device and attaches the
upstream driver via mipi_dsi_attach that indeed calls upstream driver
mipi_dsi_host_ops.attach so if we move finding panel or bridge from
mipi_dsi_host_ops.attach to the probe then dev->of_node cannot be
valid so it will not find the bridge driver.

>
> > What is the problem to have it in host.attach for both cases?
>
> You've put a link to the documentation that explains what the problem is
> in your mail.
>
> > some DSI host bridges still do the same (mtk_dsi)
>
> Then some are broken. How is that an argument?

May be mtk_dsi has some different approach, not sure.

>
> > and this is what is mentioned in documentation point 2 and 3 here,
> > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
> >
> > "
> > The upstream driver doesn’t use the component framework, but is a
> > MIPI-DSI host.
>
> Exynos uses the component framework. So that point doesn't apply to it.
>
> > The bridge device uses the MIPI-DCS commands to be
> > controlled. In this case, the bridge device is a child of the display
> > device and when it will probe it’s assured that the display device
> > (and MIPI-DSI host) is present. The upstream driver will be assured
> > that the bridge driver is connected between the
> > mipi_dsi_host_ops.attach and mipi_dsi_host_ops.detach operations.
> > Therefore, it must run mipi_dsi_host_register() in its probe function,
> > and then run drm_bridge_attach() in its mipi_dsi_host_ops.attach hook.
> >
> > The upstream driver uses the component framework and is a MIPI-DSI
> > host. The bridge device uses the MIPI-DCS commands to be controlled.
> > This is the same situation than above, and can run
> > mipi_dsi_host_register() in either its probe or bind hooks.
> > "
> >
> > Point 2 for Exynos and 3 for imx8m flow, for both the cases
> > drm_bridge_attach in host_ops.attach hook so the panel hook must be in
> > same place.
>
> And you forgot the fourth point:
>
> > The upstream driver uses the component framework and is a MIPI-DSI
> > host. The bridge device uses a separate bus (such as I2C) to be
> > controlled. In this case, there’s no correlation between the probe of
> > the bridge and upstream drivers, so care must be taken to avoid an
> > endless EPROBE_DEFER loop, with each driver waiting for the other to
> > probe.
>
> Which is what the whole discussion is about.

I got it, Points 3, and 4 are followed by three points that are
related to Exynos DSI and the connected bridge is I2C-based. In this
case, the existing Exynos DSI has some faults. and It is working for
Exynos DSI since they didn't deal any I2C-based bridge driver, may be.

Jagan.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 8:05 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Tue, Feb 28, 2023 at 06:04:39PM +0530, Jagan Teki wrote:
> > On Tue, Feb 28, 2023 at 5:40 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > >
> > > On Mon, Feb 27, 2023 at 08:41:22PM +0100, Marek Vasut wrote:
> > > > > If we go ahead with no need for DRM-managed helper at the moment, then
> > > > > find the panel hook in host.attach and then drop 2/18.
> > > >
> > > > The panel lookup must happen in .bind/.probe for exynos/imx respectively ,
> > > > that's really all that is required here. Then you can drop 1,2,3/18 and get
> > > > this series applied (I hope) .
> > > >
> > > > Can you implement just this one change ?
> > > >
> > > > There is no need to use drmm_* helper for now, that can be improved later if
> > > > possible.
> > >
> > > Yeah... The drmm helper isn't needed per se, but not using it will
> > > create a use-after-free pattern that is very easy to miss.
> > >
> > > I'd really prefer not to add a new helper that favors an unsafe pattern,
> > > but the driver seems to have a whole bunch of them anyway so it's not
> > > really a big deal.
> > >
> > > Which also raises another question: if it's code that is only really
> > > relevant in the context of that driver, why are you creating a helper
> > > for it in the first place?
> >
> > I can answer this question as I did add these helpers.
> >
> > 1. DSI-specific helper added since it is a good candidate for
> > common/helper code, based on the comments in V9 by Marek. V
> > https://patchwork.kernel.org/project/dri-devel/patch/20221209152343.180139-8-jagan@amarulasolutions.com/
> >
> > So, I have added this to the common drm_of code in V10.
> > https://patchwork.kernel.org/project/dri-devel/patch/20221214125907.376148-2-jagan@amarulasolutions.com/
> >
> > 2. DRM-managed discussion was commented on in V11 by you, so from
> > where all discussion moved.
> > https://patchwork.kernel.org/project/dri-devel/patch/20230123151212.269082-3-jagan@amarulasolutions.com/
> >
> > 1) helper wouldn't be an unsafe helper as it can reuse many DSI
> > drivers but 2) helper might be an unsafe helper at the moment.
>
> You're wrong. The first one is unsafe, for the same reason than the devm
> one you did is unsafe: the assumption everyone will get (and the one you
> implemented in your driver) is that the bridge reference will be put
> back at remove time.
>
> The DRM/KMS structures however are free'd only when the last user closes
> the file descriptor of the KMS device, so your driver functions will get
> called after remove has been called.
>
> If you are using the panel or bridge in any of your KMS hooks
> implementations, this is now a use-after-free.
>
> The drmm variant is safe though, because drmm actions run not when the
> device is removed but when the DRM device is last closed.

Okay. So, even if we manually use drm_of_dsi_find_panel_or_bridge in
mipi_dsi_host_ops.attach and drm_panel_bridge_remove() in
mipi_dsi_host_ops.detach KMS doesn't aware of it and is still unsafe.
- am I correct?

Jagan.

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Maxime Ripard]

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

On Tue, Feb 28, 2023 at 08:09:26PM +0530, Jagan Teki wrote:
> On Tue, Feb 28, 2023 at 5:34 PM Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > On Tue, Feb 28, 2023 at 02:08:53AM +0530, Jagan Teki wrote:
> > > On Tue, Feb 28, 2023 at 1:40 AM Marek Vasut <marex@denx.de> wrote:
> > > >
> > > > On 2/27/23 20:49, Jagan Teki wrote:
> > > > > On Tue, Feb 28, 2023 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
> > > > >>
> > > > >> On 2/27/23 20:34, Jagan Teki wrote:
> > > > >>> On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
> > > > >>>>
> > > > >>>> On 2/27/23 20:15, Jagan Teki wrote:
> > > > >>>>> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
> > > > >>>>>>
> > > > >>>>>> On 2/27/23 20:01, Jagan Teki wrote:
> > > > >>>>>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>> On 2/27/23 12:39, Jagan Teki wrote:
> > > > >>>>>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> > > > >>>>>>>>> downstream DSI bridge and panel and trying to add a panel bridge
> > > > >>>>>>>>> if the panel is found.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> > > > >>>>>>>>> followed with drmm_panel_bridge_add.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > >>>>>>>>> ---
> > > > >>>>>>>>> Changes for v13, v12, v11:
> > > > >>>>>>>>> - none
> > > > >>>>>>>>> Changes for v10:
> > > > >>>>>>>>> - new patch
> > > > >>>>>>>>>
> > > > >>>>>>>>>       drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> > > > >>>>>>>>>       1 file changed, 13 insertions(+), 12 deletions(-)
> > > > >>>>>>>>>
> > > > >>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > > > >>>>>>>>> index df15501b1075..12a6dd987e8f 100644
> > > > >>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > > > >>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > > > >>>>>>>>> @@ -25,6 +25,7 @@
> > > > >>>>>>>>>       #include <drm/drm_atomic_helper.h>
> > > > >>>>>>>>>       #include <drm/drm_bridge.h>
> > > > >>>>>>>>>       #include <drm/drm_mipi_dsi.h>
> > > > >>>>>>>>> +#include <drm/drm_of.h>
> > > > >>>>>>>>>       #include <drm/drm_panel.h>
> > > > >>>>>>>>>       #include <drm/drm_print.h>
> > > > >>>>>>>>>       #include <drm/drm_probe_helper.h>
> > > > >>>>>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> > > > >>>>>>>>>           struct device *dev = dsi->dev;
> > > > >>>>>>>>>           struct drm_encoder *encoder = &dsi->encoder;
> > > > >>>>>>>>>           struct drm_device *drm = encoder->dev;
> > > > >>>>>>>>> +     struct drm_bridge *bridge;
> > > > >>>>>>>>>           struct drm_panel *panel;
> > > > >>>>>>>>>           int ret;
> > > > >>>>>>>>>
> > > > >>>>>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
> > > > >>>>>>>>> -     if (!IS_ERR(panel)) {
> > > > >>>>>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> > > > >>>>>>>>> -     } else {
> > > > >>>>>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> > > > >>>>>>>>> -             if (!dsi->out_bridge)
> > > > >>>>>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> > > > >>>>>>>>> -     }
> > > > >>>>>>>>
> > > > >>>>>>>> As far as I understand this from my conversation with Maxime (please put
> > > > >>>>>>>> him on CC of V15), the change here should instead perform the panel look
> > > > >>>>>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> > > > >>>>>>>> the component_ops .bind callback . Here is an example of correct
> > > > >>>>>>>> implementation:
> > > > >>>>>>>>
> > > > >>>>>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> > > > >>>>>>>
> > > > >>>>>>> But, we don't have component_ops.bind for imx8m case, so where do we
> > > > >>>>>>> want to place the panel hook?
> > > > >>>>>>>
> > > > >>>>>>> Exynos drm drivers are component-based but, imx8mm is not.
> > > > >>>>>>
> > > > >>>>>> In 14/18 patch, the same should be added to generic_dsim_register_host()
> > > > >>>>>> , which is called from the driver .probe() callback, but that is OK.
> > > > >>>>>>
> > > > >>>>>> That's ^ is the iMX part.
> > > > >>>>>
> > > > >>>>> Ohh. You mean, we need to find the panel hook separately in two places like
> > > > >>>>> - bind for exynos
> > > > >>>>> - probe for imx8mm
> > > > >>>>
> > > > >>>> Yes
> > > > >>>>
> > > > >>>>> If so? how can I find the drm_device pointer in the probe?
> > > > >>>>
> > > > >>>> What for ? The panel lookup uses OF graph . Where do you need the
> > > > >>>> drm_device in it ?
> > > > >>>
> > > > >>> May I can summarize the whole setback here so that everybody is on the
> > > > >>> same page and find the proper solution?
> > > > >>>
> > > > >>> The key blocker is accessing the DRM pointer in order to use the
> > > > >>> DRM-managed action helper.
> > > > >>>
> > > > >>> 1. If we find the panel hook in Exynos component_ops.bind then we can
> > > > >>> use the DRM pointer directly as VC4 does.
> > > > >>> 2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
> > > > >>> imx8mm) then we can use the DRM pointer directly via bridge->dev.
> > > > >>>
> > > > >>> If we make 2) has common across like finding the panel hook in
> > > > >>> drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
> > > > >>> panels.
> > > > >>>
> > > > >>> The common solution for both exynos and imx8m is host.attach but if we
> > > > >>> do so we cannot get find the DRM pointer.
> > > > >>
> > > > >> There isn't going to be common solution, you would really have to do the
> > > > >> look up in component_ops .bind callback for exynos , and
> > > > >> generic_dsim_register_host() for i.MX .
> > > > >>
> > > > >>> If we go ahead with no need for DRM-managed helper at the moment, then
> > > > >>> find the panel hook in host.attach and then drop 2/18.
> > > > >>
> > > > >> The panel lookup must happen in .bind/.probe for exynos/imx respectively
> > > > >> , that's really all that is required here. Then you can drop 1,2,3/18
> > > > >> and get this series applied (I hope) .
> > > > >
> > > > > I'm not quite sure, if the panel hook in .bind work for exynos or not?
> > > >
> > > > Marek should be able to test exynos for you one more time I hope.
> > > >
> > > > > the host. attach has KMS hotplug code after the panel hook and
> > > > > bridge_attach as before. I believe that is a working scenario for
> > > > > Exynos to be the panel hook in the host. attach.
> > > >
> > > > As far as I understand it, the look up has to be in .bind callback (and
> > > > generic_dsim_register_host() for imx). Can you try if/how that works ?
> > > >
> > > > >> Can you implement just this one change ?
> > > > >>
> > > > >> There is no need to use drmm_* helper for now, that can be improved
> > > > >> later if possible.
> > > > >
> > > > > If this is the case then 1/18 will need otherwise
> > > >
> > > > Ah yes, 1/18 will be needed indeed. It should just be called from .bind
> > > > callback or generic_dsim_register_host() (i.e. probe callback).
> > >
> > > panel hook at the probe call would be wrong.
> >
> > Why?
> >
> > > the downstream bridge will call mipi_dsi_attach for finding the
> > > connected upstream, so it indeed calls host.attach. If we move the
> > > panel hook at the probe, then probing will defer.
> > >
> > > [   12.046862] platform 32e10000.dsi: deferred probe pending
> > > [   12.052309] platform 32e00000.lcdif: deferred probe pending
> >
> > What is the dependency chain there, and why doesn't it probe?
> 
> Let me answer here for the above 2 queries.
> 
> This is clearly a point 2 scenario from the documentation.
> 
> "
> The upstream driver doesn’t use the component framework, but is a
> MIPI-DSI host. The bridge device uses the MIPI-DCS commands to be
> controlled. In this case, the bridge device is a child of the display
> device and when it will probe it’s assured that the display device
> (and MIPI-DSI host) is present. The upstream driver will be assured
> that the bridge driver is connected between the
> mipi_dsi_host_ops.attach and mipi_dsi_host_ops.detach operations.
> Therefore, it must run mipi_dsi_host_register() in its probe function,
> and then run drm_bridge_attach() in its mipi_dsi_host_ops.attach hook.
> "
> 
> So, the samsung-dsim follows the same rule, mipi_dsi_host_register()
> in the probe and drm_bridge_attach() in mipi_dsi_host_ops.attach hook.

But samsung-dsim is used together with the component framework, so this
doesn't work.

Seriously, I've been telling you that it doesn't work. We spent an hour
discussing this with Marek yesterday who also explained this to you.
Stop trying to make that happen, it just doesn't work.

Can we leave that solution behind and move forward?

> Above also mentioned "The upstream driver will be assured that the
> bridge driver is connected between the mipi_dsi_host_ops.attach and
> mipi_dsi_host_ops.detach operations" that means we need to find the
> panel or bridge in mipi_dsi_host_ops.attach am I correct? not in the
> probe.

No, you're not correct. Just like the documentation, Marek and I have
repeatedly told you.

> lcdif => samsung-ti => dsim-sn65dsi (I2C) => panel this is the bridge
> chain. ti-sn65dsi is registered the MIPI Device and attaches the
> upstream driver via mipi_dsi_attach that indeed calls upstream driver
> mipi_dsi_host_ops.attach so if we move finding panel or bridge from
> mipi_dsi_host_ops.attach to the probe then dev->of_node cannot be
> valid so it will not find the bridge driver.

Why not, dev->of_node is very much valid at probe time.

Maxime

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

Re: [PATCH v13 04/18] drm: exynos: dsi: Switch to DSI panel or bridge find helper

[Jagan Teki]

On Tue, Feb 28, 2023 at 8:26 PM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Tue, Feb 28, 2023 at 08:09:26PM +0530, Jagan Teki wrote:
> > On Tue, Feb 28, 2023 at 5:34 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > >
> > > On Tue, Feb 28, 2023 at 02:08:53AM +0530, Jagan Teki wrote:
> > > > On Tue, Feb 28, 2023 at 1:40 AM Marek Vasut <marex@denx.de> wrote:
> > > > >
> > > > > On 2/27/23 20:49, Jagan Teki wrote:
> > > > > > On Tue, Feb 28, 2023 at 1:11 AM Marek Vasut <marex@denx.de> wrote:
> > > > > >>
> > > > > >> On 2/27/23 20:34, Jagan Teki wrote:
> > > > > >>> On Tue, Feb 28, 2023 at 12:54 AM Marek Vasut <marex@denx.de> wrote:
> > > > > >>>>
> > > > > >>>> On 2/27/23 20:15, Jagan Teki wrote:
> > > > > >>>>> On Tue, Feb 28, 2023 at 12:38 AM Marek Vasut <marex@denx.de> wrote:
> > > > > >>>>>>
> > > > > >>>>>> On 2/27/23 20:01, Jagan Teki wrote:
> > > > > >>>>>>> On Tue, Feb 28, 2023 at 12:25 AM Marek Vasut <marex@denx.de> wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>> On 2/27/23 12:39, Jagan Teki wrote:
> > > > > >>>>>>>>> drm_of_dsi_find_panel_or_bridge is capable of looking up the
> > > > > >>>>>>>>> downstream DSI bridge and panel and trying to add a panel bridge
> > > > > >>>>>>>>> if the panel is found.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Replace explicit finding calls with drm_of_dsi_find_panel_or_bridge
> > > > > >>>>>>>>> followed with drmm_panel_bridge_add.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > >>>>>>>>> ---
> > > > > >>>>>>>>> Changes for v13, v12, v11:
> > > > > >>>>>>>>> - none
> > > > > >>>>>>>>> Changes for v10:
> > > > > >>>>>>>>> - new patch
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>       drivers/gpu/drm/exynos/exynos_drm_dsi.c | 25 +++++++++++++------------
> > > > > >>>>>>>>>       1 file changed, 13 insertions(+), 12 deletions(-)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > > > > >>>>>>>>> index df15501b1075..12a6dd987e8f 100644
> > > > > >>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > > > > >>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > > > > >>>>>>>>> @@ -25,6 +25,7 @@
> > > > > >>>>>>>>>       #include <drm/drm_atomic_helper.h>
> > > > > >>>>>>>>>       #include <drm/drm_bridge.h>
> > > > > >>>>>>>>>       #include <drm/drm_mipi_dsi.h>
> > > > > >>>>>>>>> +#include <drm/drm_of.h>
> > > > > >>>>>>>>>       #include <drm/drm_panel.h>
> > > > > >>>>>>>>>       #include <drm/drm_print.h>
> > > > > >>>>>>>>>       #include <drm/drm_probe_helper.h>
> > > > > >>>>>>>>> @@ -1470,24 +1471,26 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> > > > > >>>>>>>>>           struct device *dev = dsi->dev;
> > > > > >>>>>>>>>           struct drm_encoder *encoder = &dsi->encoder;
> > > > > >>>>>>>>>           struct drm_device *drm = encoder->dev;
> > > > > >>>>>>>>> +     struct drm_bridge *bridge;
> > > > > >>>>>>>>>           struct drm_panel *panel;
> > > > > >>>>>>>>>           int ret;
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> -     panel = of_drm_find_panel(device->dev.of_node);
> > > > > >>>>>>>>> -     if (!IS_ERR(panel)) {
> > > > > >>>>>>>>> -             dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel);
> > > > > >>>>>>>>> -     } else {
> > > > > >>>>>>>>> -             dsi->out_bridge = of_drm_find_bridge(device->dev.of_node);
> > > > > >>>>>>>>> -             if (!dsi->out_bridge)
> > > > > >>>>>>>>> -                     dsi->out_bridge = ERR_PTR(-EINVAL);
> > > > > >>>>>>>>> -     }
> > > > > >>>>>>>>
> > > > > >>>>>>>> As far as I understand this from my conversation with Maxime (please put
> > > > > >>>>>>>> him on CC of V15), the change here should instead perform the panel look
> > > > > >>>>>>>> up NOT in exynos_dsi_host_attach() , but in exynos_dsi_bind() , i.e. in
> > > > > >>>>>>>> the component_ops .bind callback . Here is an example of correct
> > > > > >>>>>>>> implementation:
> > > > > >>>>>>>>
> > > > > >>>>>>>> https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805
> > > > > >>>>>>>
> > > > > >>>>>>> But, we don't have component_ops.bind for imx8m case, so where do we
> > > > > >>>>>>> want to place the panel hook?
> > > > > >>>>>>>
> > > > > >>>>>>> Exynos drm drivers are component-based but, imx8mm is not.
> > > > > >>>>>>
> > > > > >>>>>> In 14/18 patch, the same should be added to generic_dsim_register_host()
> > > > > >>>>>> , which is called from the driver .probe() callback, but that is OK.
> > > > > >>>>>>
> > > > > >>>>>> That's ^ is the iMX part.
> > > > > >>>>>
> > > > > >>>>> Ohh. You mean, we need to find the panel hook separately in two places like
> > > > > >>>>> - bind for exynos
> > > > > >>>>> - probe for imx8mm
> > > > > >>>>
> > > > > >>>> Yes
> > > > > >>>>
> > > > > >>>>> If so? how can I find the drm_device pointer in the probe?
> > > > > >>>>
> > > > > >>>> What for ? The panel lookup uses OF graph . Where do you need the
> > > > > >>>> drm_device in it ?
> > > > > >>>
> > > > > >>> May I can summarize the whole setback here so that everybody is on the
> > > > > >>> same page and find the proper solution?
> > > > > >>>
> > > > > >>> The key blocker is accessing the DRM pointer in order to use the
> > > > > >>> DRM-managed action helper.
> > > > > >>>
> > > > > >>> 1. If we find the panel hook in Exynos component_ops.bind then we can
> > > > > >>> use the DRM pointer directly as VC4 does.
> > > > > >>> 2. if we find the panel hook in Samsung drm_bridge_funcs.attach (for
> > > > > >>> imx8mm) then we can use the DRM pointer directly via bridge->dev.
> > > > > >>>
> > > > > >>> If we make 2) has common across like finding the panel hook in
> > > > > >>> drm_bridge_funcs.attach the Exynos drm pipeline cannot find the
> > > > > >>> panels.
> > > > > >>>
> > > > > >>> The common solution for both exynos and imx8m is host.attach but if we
> > > > > >>> do so we cannot get find the DRM pointer.
> > > > > >>
> > > > > >> There isn't going to be common solution, you would really have to do the
> > > > > >> look up in component_ops .bind callback for exynos , and
> > > > > >> generic_dsim_register_host() for i.MX .
> > > > > >>
> > > > > >>> If we go ahead with no need for DRM-managed helper at the moment, then
> > > > > >>> find the panel hook in host.attach and then drop 2/18.
> > > > > >>
> > > > > >> The panel lookup must happen in .bind/.probe for exynos/imx respectively
> > > > > >> , that's really all that is required here. Then you can drop 1,2,3/18
> > > > > >> and get this series applied (I hope) .
> > > > > >
> > > > > > I'm not quite sure, if the panel hook in .bind work for exynos or not?
> > > > >
> > > > > Marek should be able to test exynos for you one more time I hope.
> > > > >
> > > > > > the host. attach has KMS hotplug code after the panel hook and
> > > > > > bridge_attach as before. I believe that is a working scenario for
> > > > > > Exynos to be the panel hook in the host. attach.
> > > > >
> > > > > As far as I understand it, the look up has to be in .bind callback (and
> > > > > generic_dsim_register_host() for imx). Can you try if/how that works ?
> > > > >
> > > > > >> Can you implement just this one change ?
> > > > > >>
> > > > > >> There is no need to use drmm_* helper for now, that can be improved
> > > > > >> later if possible.
> > > > > >
> > > > > > If this is the case then 1/18 will need otherwise
> > > > >
> > > > > Ah yes, 1/18 will be needed indeed. It should just be called from .bind
> > > > > callback or generic_dsim_register_host() (i.e. probe callback).
> > > >
> > > > panel hook at the probe call would be wrong.
> > >
> > > Why?
> > >
> > > > the downstream bridge will call mipi_dsi_attach for finding the
> > > > connected upstream, so it indeed calls host.attach. If we move the
> > > > panel hook at the probe, then probing will defer.
> > > >
> > > > [   12.046862] platform 32e10000.dsi: deferred probe pending
> > > > [   12.052309] platform 32e00000.lcdif: deferred probe pending
> > >
> > > What is the dependency chain there, and why doesn't it probe?
> >
> > Let me answer here for the above 2 queries.
> >
> > This is clearly a point 2 scenario from the documentation.
> >
> > "
> > The upstream driver doesn’t use the component framework, but is a
> > MIPI-DSI host. The bridge device uses the MIPI-DCS commands to be
> > controlled. In this case, the bridge device is a child of the display
> > device and when it will probe it’s assured that the display device
> > (and MIPI-DSI host) is present. The upstream driver will be assured
> > that the bridge driver is connected between the
> > mipi_dsi_host_ops.attach and mipi_dsi_host_ops.detach operations.
> > Therefore, it must run mipi_dsi_host_register() in its probe function,
> > and then run drm_bridge_attach() in its mipi_dsi_host_ops.attach hook.
> > "
> >
> > So, the samsung-dsim follows the same rule, mipi_dsi_host_register()
> > in the probe and drm_bridge_attach() in mipi_dsi_host_ops.attach hook.
>
> But samsung-dsim is used together with the component framework, so this
> doesn't work.
>
> Seriously, I've been telling you that it doesn't work. We spent an hour
> discussing this with Marek yesterday who also explained this to you.
> Stop trying to make that happen, it just doesn't work.
>
> Can we leave that solution behind and move forward?

I have given the logs of why it's not working. I did my best to
explain. Samsung-dsim is not component-based it is a non-component DSI
host bridge exclusively for imx8mm and Exynos DSI is component-based.
Samsung-dsim we have a platform calls to call Exynos which will
operate component binding. This means that imx8mm stuff cannot use the
component framework at all.

This is all I can explain. and adding panel or bridge finding code in
the probe simply not working on imx8mm as it is non-component based.

Thanks for your patience in answering queries.

Jagan.