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

[PATCH v10 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: adding devm_drm_of_dsi_get_bridge

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 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10

v9:
https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/

Any inputs?
Jagan.

Jagan Teki (16):
  drm: of: Lookup if child node has DSI panel or bridge
  drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
  drm: exynos: dsi: Drop explicit call to bridge detach
  drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
  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 Exynos based host irq hooks
  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                |   34 +
 drivers/gpu/drm/bridge/samsung-dsim.c         | 1883 +++++++++++++++++
 drivers/gpu/drm/drm_of.c                      |  113 +-
 drivers/gpu/drm/exynos/Kconfig                |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1793 +---------------
 include/drm/bridge/samsung-dsim.h             |  119 ++
 include/drm/drm_bridge.h                      |    2 +
 include/drm/drm_of.h                          |   12 +
 12 files changed, 2285 insertions(+), 1696 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
2.25.1

[PATCH v10 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: adding devm_drm_of_dsi_get_bridge

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 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10

v9:
https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/

Any inputs?
Jagan.

Jagan Teki (16):
  drm: of: Lookup if child node has DSI panel or bridge
  drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
  drm: exynos: dsi: Drop explicit call to bridge detach
  drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
  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 Exynos based host irq hooks
  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                |   34 +
 drivers/gpu/drm/bridge/samsung-dsim.c         | 1883 +++++++++++++++++
 drivers/gpu/drm/drm_of.c                      |  113 +-
 drivers/gpu/drm/exynos/Kconfig                |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1793 +---------------
 include/drm/bridge/samsung-dsim.h             |  119 ++
 include/drm/drm_bridge.h                      |    2 +
 include/drm/drm_of.h                          |   12 +
 12 files changed, 2285 insertions(+), 1696 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
2.25.1

[PATCH v10 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: adding devm_drm_of_dsi_get_bridge

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 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10

v9:
https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/

Any inputs?
Jagan.

Jagan Teki (16):
  drm: of: Lookup if child node has DSI panel or bridge
  drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
  drm: exynos: dsi: Drop explicit call to bridge detach
  drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
  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 Exynos based host irq hooks
  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                |   34 +
 drivers/gpu/drm/bridge/samsung-dsim.c         | 1883 +++++++++++++++++
 drivers/gpu/drm/drm_of.c                      |  113 +-
 drivers/gpu/drm/exynos/Kconfig                |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1793 +---------------
 include/drm/bridge/samsung-dsim.h             |  119 ++
 include/drm/drm_bridge.h                      |    2 +
 include/drm/drm_of.h                          |   12 +
 12 files changed, 2285 insertions(+), 1696 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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 v10:
- new patch

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

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 7bbcb999bb75..020457444dfe 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -216,6 +216,36 @@ 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
@@ -238,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)
@@ -259,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 10ab58c40746..7a97157c1fa0 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -47,6 +47,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);
@@ -99,6 +103,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 v10 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 v10:
- new patch

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

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 7bbcb999bb75..020457444dfe 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -216,6 +216,36 @@ 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
@@ -238,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)
@@ -259,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 10ab58c40746..7a97157c1fa0 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -47,6 +47,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);
@@ -99,6 +103,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 v10 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 v10:
- new patch

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

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 7bbcb999bb75..020457444dfe 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -216,6 +216,36 @@ 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
@@ -238,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)
@@ -259,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 10ab58c40746..7a97157c1fa0 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -47,6 +47,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);
@@ -99,6 +103,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper

[Jagan Teki]

Add devm OF helper to return the next DSI bridge in the chain.

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

Helper lookup a given 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.

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 v10:
- new patch

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

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 03c3274dc3d9..50ea5de45197 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -496,4 +496,38 @@ struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm,
 }
 EXPORT_SYMBOL(drmm_of_get_bridge);
 
+/**
+ * devm_drm_of_dsi_get_bridge - Return next DSI bridge in the chain
+ * @dev: device to tie the bridge lifetime to
+ * @np: device tree node containing encoder output ports
+ * @port: port in the device tree node
+ * @endpoint: endpoint in the device tree node
+ *
+ * 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 a pointer to the bridge if successful, or an error pointer
+ * otherwise.
+ */
+struct drm_bridge *devm_drm_of_dsi_get_bridge(struct device *dev,
+					      struct device_node *np,
+					      u32 port, u32 endpoint)
+{
+	struct drm_bridge *bridge;
+	struct drm_panel *panel;
+	int ret;
+
+	ret = drm_of_dsi_find_panel_or_bridge(np, port, endpoint,
+					      &panel, &bridge);
+	if (ret)
+		return ERR_PTR(ret);
+
+	if (panel)
+		bridge = devm_drm_panel_bridge_add(dev, panel);
+
+	return bridge;
+}
+EXPORT_SYMBOL(devm_drm_of_dsi_get_bridge);
+
 #endif
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 42f86327b40a..ccb14e361d3f 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -931,6 +931,8 @@ struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct device_node
 					  u32 port, u32 endpoint);
 struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm, struct device_node *node,
 					  u32 port, u32 endpoint);
+struct drm_bridge *devm_drm_of_dsi_get_bridge(struct device *dev, struct device_node *node,
+					      u32 port, u32 endpoint);
 #else
 static inline struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
 							struct device_node *node,
-- 
2.25.1

[PATCH v10 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper

[Jagan Teki]

Add devm OF helper to return the next DSI bridge in the chain.

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

Helper lookup a given 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.

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 v10:
- new patch

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

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 03c3274dc3d9..50ea5de45197 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -496,4 +496,38 @@ struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm,
 }
 EXPORT_SYMBOL(drmm_of_get_bridge);
 
+/**
+ * devm_drm_of_dsi_get_bridge - Return next DSI bridge in the chain
+ * @dev: device to tie the bridge lifetime to
+ * @np: device tree node containing encoder output ports
+ * @port: port in the device tree node
+ * @endpoint: endpoint in the device tree node
+ *
+ * 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 a pointer to the bridge if successful, or an error pointer
+ * otherwise.
+ */
+struct drm_bridge *devm_drm_of_dsi_get_bridge(struct device *dev,
+					      struct device_node *np,
+					      u32 port, u32 endpoint)
+{
+	struct drm_bridge *bridge;
+	struct drm_panel *panel;
+	int ret;
+
+	ret = drm_of_dsi_find_panel_or_bridge(np, port, endpoint,
+					      &panel, &bridge);
+	if (ret)
+		return ERR_PTR(ret);
+
+	if (panel)
+		bridge = devm_drm_panel_bridge_add(dev, panel);
+
+	return bridge;
+}
+EXPORT_SYMBOL(devm_drm_of_dsi_get_bridge);
+
 #endif
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 42f86327b40a..ccb14e361d3f 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -931,6 +931,8 @@ struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct device_node
 					  u32 port, u32 endpoint);
 struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm, struct device_node *node,
 					  u32 port, u32 endpoint);
+struct drm_bridge *devm_drm_of_dsi_get_bridge(struct device *dev, struct device_node *node,
+					      u32 port, u32 endpoint);
 #else
 static inline struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
 							struct device_node *node,
-- 
2.25.1

[PATCH v10 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper

[Jagan Teki]

Add devm OF helper to return the next DSI bridge in the chain.

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

Helper lookup a given 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.

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 v10:
- new patch

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

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 03c3274dc3d9..50ea5de45197 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -496,4 +496,38 @@ struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm,
 }
 EXPORT_SYMBOL(drmm_of_get_bridge);
 
+/**
+ * devm_drm_of_dsi_get_bridge - Return next DSI bridge in the chain
+ * @dev: device to tie the bridge lifetime to
+ * @np: device tree node containing encoder output ports
+ * @port: port in the device tree node
+ * @endpoint: endpoint in the device tree node
+ *
+ * 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 a pointer to the bridge if successful, or an error pointer
+ * otherwise.
+ */
+struct drm_bridge *devm_drm_of_dsi_get_bridge(struct device *dev,
+					      struct device_node *np,
+					      u32 port, u32 endpoint)
+{
+	struct drm_bridge *bridge;
+	struct drm_panel *panel;
+	int ret;
+
+	ret = drm_of_dsi_find_panel_or_bridge(np, port, endpoint,
+					      &panel, &bridge);
+	if (ret)
+		return ERR_PTR(ret);
+
+	if (panel)
+		bridge = devm_drm_panel_bridge_add(dev, panel);
+
+	return bridge;
+}
+EXPORT_SYMBOL(devm_drm_of_dsi_get_bridge);
+
 #endif
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 42f86327b40a..ccb14e361d3f 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -931,6 +931,8 @@ struct drm_bridge *devm_drm_of_get_bridge(struct device *dev, struct device_node
 					  u32 port, u32 endpoint);
 struct drm_bridge *drmm_of_get_bridge(struct drm_device *drm, struct device_node *node,
 					  u32 port, u32 endpoint);
+struct drm_bridge *devm_drm_of_dsi_get_bridge(struct device *dev, struct device_node *node,
+					      u32 port, u32 endpoint);
 #else
 static inline struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
 							struct device_node *node,
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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 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 v10 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 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 v10 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 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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 04/18] drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge

[Jagan Teki]

devm_drm_of_dsi_get_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 devm_drm_of_dsi_get_bridge.

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

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index df15501b1075..4a165764121d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1470,18 +1470,9 @@ 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_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);
-	}
-
+	dsi->out_bridge = devm_drm_of_dsi_get_bridge(dev, dev->of_node, 1, 0);
 	if (IS_ERR(dsi->out_bridge)) {
 		ret = PTR_ERR(dsi->out_bridge);
 		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
@@ -1531,8 +1522,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 v10 04/18] drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge

[Jagan Teki]

devm_drm_of_dsi_get_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 devm_drm_of_dsi_get_bridge.

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

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index df15501b1075..4a165764121d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1470,18 +1470,9 @@ 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_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);
-	}
-
+	dsi->out_bridge = devm_drm_of_dsi_get_bridge(dev, dev->of_node, 1, 0);
 	if (IS_ERR(dsi->out_bridge)) {
 		ret = PTR_ERR(dsi->out_bridge);
 		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
@@ -1531,8 +1522,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 v10 04/18] drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge

[Jagan Teki]

devm_drm_of_dsi_get_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 devm_drm_of_dsi_get_bridge.

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

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

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index df15501b1075..4a165764121d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1470,18 +1470,9 @@ 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_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);
-	}
-
+	dsi->out_bridge = devm_drm_of_dsi_get_bridge(dev, dev->of_node, 1, 0);
 	if (IS_ERR(dsi->out_bridge)) {
 		ret = PTR_ERR(dsi->out_bridge);
 		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
@@ -1531,8 +1522,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 4a165764121d..5918d31127aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1687,7 +1687,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 v10 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: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 4a165764121d..5918d31127aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1687,7 +1687,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 v10 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: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 4a165764121d..5918d31127aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1687,7 +1687,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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 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 5918d31127aa..7a845badb1b2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -194,7 +194,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)
 
@@ -263,6 +263,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;
 };
 
@@ -471,6 +472,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,
 };
 
@@ -483,6 +485,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,
 };
 
@@ -493,6 +496,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,
 };
 
@@ -504,6 +508,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,
 };
 
@@ -515,6 +520,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,
 };
 
@@ -628,7 +634,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 v10 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 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 5918d31127aa..7a845badb1b2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -194,7 +194,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)
 
@@ -263,6 +263,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;
 };
 
@@ -471,6 +472,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,
 };
 
@@ -483,6 +485,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,
 };
 
@@ -493,6 +496,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,
 };
 
@@ -504,6 +508,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,
 };
 
@@ -515,6 +520,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,
 };
 
@@ -628,7 +634,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 v10 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 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 5918d31127aa..7a845badb1b2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -194,7 +194,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)
 
@@ -263,6 +263,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;
 };
 
@@ -471,6 +472,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,
 };
 
@@ -483,6 +485,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,
 };
 
@@ -493,6 +496,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,
 };
 
@@ -504,6 +508,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,
 };
 
@@ -515,6 +520,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,
 };
 
@@ -628,7 +634,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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.

Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 84 ++++++++++++++++++++-----
 1 file changed, 69 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7a845badb1b2..fdaf514b39f2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,6 +254,16 @@ 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;
@@ -267,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;
@@ -297,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)
@@ -524,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)
@@ -1468,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)
 {
@@ -1659,7 +1667,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";
@@ -1817,6 +1826,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 v10 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.

Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 84 ++++++++++++++++++++-----
 1 file changed, 69 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7a845badb1b2..fdaf514b39f2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,6 +254,16 @@ 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;
@@ -267,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;
@@ -297,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)
@@ -524,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)
@@ -1468,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)
 {
@@ -1659,7 +1667,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";
@@ -1817,6 +1826,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 v10 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.

Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 84 ++++++++++++++++++++-----
 1 file changed, 69 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 7a845badb1b2..fdaf514b39f2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,6 +254,16 @@ 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;
@@ -267,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;
@@ -297,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)
@@ -524,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)
@@ -1468,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)
 {
@@ -1659,7 +1667,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";
@@ -1817,6 +1826,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
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 fdaf514b39f2..5792f9883cee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,6 +254,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,
@@ -1557,12 +1575,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 v10 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.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
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 fdaf514b39f2..5792f9883cee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,6 +254,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,
@@ -1557,12 +1575,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 v10 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.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
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 fdaf514b39f2..5792f9883cee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,6 +254,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,
@@ -1557,12 +1575,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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 a comment FIXME for this and updated the active low
sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.

Comments are suggested by Marek Vasut.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 5792f9883cee..12a40576f937 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -263,6 +263,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 v10 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 a comment FIXME for this and updated the active low
sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.

Comments are suggested by Marek Vasut.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 5792f9883cee..12a40576f937 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -263,6 +263,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 v10 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 a comment FIXME for this and updated the active low
sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.

Comments are suggested by Marek Vasut.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 5792f9883cee..12a40576f937 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -263,6 +263,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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.

Suggested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 12a40576f937..36820a7b5884 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1692,6 +1692,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;
@@ -1778,6 +1782,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 v10 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.

Suggested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 12a40576f937..36820a7b5884 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1692,6 +1692,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;
@@ -1778,6 +1782,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 v10 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.

Suggested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 12a40576f937..36820a7b5884 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1692,6 +1692,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;
@@ -1778,6 +1782,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 69 +++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 36820a7b5884..bb3d6a7fa84e 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,73 @@ 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,
+
+	MEDIA_BUS_FMT_FIXED,
+};
+
+static bool exynos_dsi_pixel_output_fmt_supported(u32 fmt)
+{
+	int i;
+
+	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;
+
+	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 = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	switch (output_fmt) {
+	case MEDIA_BUS_FMT_FIXED:
+		input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+		break;
+	default:
+		input_fmts[0] = output_fmt;
+		break;
+	}
+
+	*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 +1583,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 v10 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

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 69 +++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 36820a7b5884..bb3d6a7fa84e 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,73 @@ 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,
+
+	MEDIA_BUS_FMT_FIXED,
+};
+
+static bool exynos_dsi_pixel_output_fmt_supported(u32 fmt)
+{
+	int i;
+
+	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;
+
+	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 = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	switch (output_fmt) {
+	case MEDIA_BUS_FMT_FIXED:
+		input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+		break;
+	default:
+		input_fmts[0] = output_fmt;
+		break;
+	}
+
+	*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 +1583,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 v10 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

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 69 +++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 36820a7b5884..bb3d6a7fa84e 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,73 @@ 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,
+
+	MEDIA_BUS_FMT_FIXED,
+};
+
+static bool exynos_dsi_pixel_output_fmt_supported(u32 fmt)
+{
+	int i;
+
+	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;
+
+	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 = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	switch (output_fmt) {
+	case MEDIA_BUS_FMT_FIXED:
+		input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+		break;
+	default:
+		input_fmts[0] = output_fmt;
+		break;
+	}
+
+	*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 +1583,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 179 ++++++++++++++++++------
 1 file changed, 140 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index bb3d6a7fa84e..819131a36b96 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -250,6 +250,8 @@ struct exynos_dsi_transfer {
 	u16 rx_done;
 };
 
+struct exynos_dsi;
+
 #define DSIM_STATE_ENABLED		BIT(0)
 #define DSIM_STATE_INITIALIZED		BIT(1)
 #define DSIM_STATE_CMD_LPM		BIT(2)
@@ -282,12 +284,19 @@ struct exynos_dsi_driver_data {
 	const unsigned int *reg_values;
 };
 
+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_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 +326,12 @@ struct exynos_dsi {
 
 	const struct exynos_dsi_driver_data *driver_data;
 	const struct exynos_dsi_plat_data *plat_data;
+
+	void *priv;
+};
+
+struct exynos_dsi_enc {
+	struct drm_encoder encoder;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1320,10 +1335,11 @@ 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 *dsim = (struct exynos_dsi *)dev_id;
+	struct exynos_dsi_enc *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 
-	if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
+	if (dsim->state & DSIM_STATE_VIDOUT_AVAILABLE)
 		exynos_drm_crtc_te_handler(encoder->crtc);
 
 	return IRQ_HANDLED;
@@ -1597,9 +1613,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;
 	int ret;
 
 	dsi->out_bridge = devm_drm_of_dsi_get_bridge(dev, dev->of_node, 1, 0);
@@ -1613,35 +1628,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;
 }
@@ -1650,12 +1645,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);
 
@@ -1729,10 +1726,66 @@ 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 = dsim->priv;
+	struct drm_encoder *encoder = &dsi->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 = dsim->priv;
+	struct drm_device *drm = dsi->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 exynos_dsi *dsim = dev_get_drvdata(dev);
+	struct exynos_dsi_enc *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 	struct drm_device *drm_dev = data;
 	int ret;
@@ -1743,17 +1796,17 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
 	if (ret < 0)
 		return ret;
 
-	return mipi_dsi_host_register(&dsi->dsi_host);
+	return mipi_dsi_host_register(&dsim->dsi_host);
 }
 
 static void exynos_dsi_unbind(struct device *dev, struct device *master,
 				void *data)
 {
-	struct exynos_dsi *dsi = dev_get_drvdata(dev);
+	struct exynos_dsi *dsim = dev_get_drvdata(dev);
 
-	exynos_dsi_atomic_disable(&dsi->bridge, NULL);
+	dsim->bridge.funcs->atomic_disable(&dsim->bridge, NULL);
 
-	mipi_dsi_host_unregister(&dsi->dsi_host);
+	mipi_dsi_host_unregister(&dsim->dsi_host);
 }
 
 static const struct component_ops exynos_dsi_component_ops = {
@@ -1761,6 +1814,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;
+
+	dsi = devm_kzalloc(dsim->dev, sizeof(*dsi), GFP_KERNEL);
+	if (!dsi)
+		return -ENOMEM;
+
+	dsim->priv = dsi;
+	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,
 };
@@ -1855,7 +1942,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;
 
@@ -1946,24 +2035,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 v10 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.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 179 ++++++++++++++++++------
 1 file changed, 140 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index bb3d6a7fa84e..819131a36b96 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -250,6 +250,8 @@ struct exynos_dsi_transfer {
 	u16 rx_done;
 };
 
+struct exynos_dsi;
+
 #define DSIM_STATE_ENABLED		BIT(0)
 #define DSIM_STATE_INITIALIZED		BIT(1)
 #define DSIM_STATE_CMD_LPM		BIT(2)
@@ -282,12 +284,19 @@ struct exynos_dsi_driver_data {
 	const unsigned int *reg_values;
 };
 
+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_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 +326,12 @@ struct exynos_dsi {
 
 	const struct exynos_dsi_driver_data *driver_data;
 	const struct exynos_dsi_plat_data *plat_data;
+
+	void *priv;
+};
+
+struct exynos_dsi_enc {
+	struct drm_encoder encoder;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1320,10 +1335,11 @@ 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 *dsim = (struct exynos_dsi *)dev_id;
+	struct exynos_dsi_enc *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 
-	if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
+	if (dsim->state & DSIM_STATE_VIDOUT_AVAILABLE)
 		exynos_drm_crtc_te_handler(encoder->crtc);
 
 	return IRQ_HANDLED;
@@ -1597,9 +1613,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;
 	int ret;
 
 	dsi->out_bridge = devm_drm_of_dsi_get_bridge(dev, dev->of_node, 1, 0);
@@ -1613,35 +1628,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;
 }
@@ -1650,12 +1645,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);
 
@@ -1729,10 +1726,66 @@ 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 = dsim->priv;
+	struct drm_encoder *encoder = &dsi->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 = dsim->priv;
+	struct drm_device *drm = dsi->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 exynos_dsi *dsim = dev_get_drvdata(dev);
+	struct exynos_dsi_enc *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 	struct drm_device *drm_dev = data;
 	int ret;
@@ -1743,17 +1796,17 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
 	if (ret < 0)
 		return ret;
 
-	return mipi_dsi_host_register(&dsi->dsi_host);
+	return mipi_dsi_host_register(&dsim->dsi_host);
 }
 
 static void exynos_dsi_unbind(struct device *dev, struct device *master,
 				void *data)
 {
-	struct exynos_dsi *dsi = dev_get_drvdata(dev);
+	struct exynos_dsi *dsim = dev_get_drvdata(dev);
 
-	exynos_dsi_atomic_disable(&dsi->bridge, NULL);
+	dsim->bridge.funcs->atomic_disable(&dsim->bridge, NULL);
 
-	mipi_dsi_host_unregister(&dsi->dsi_host);
+	mipi_dsi_host_unregister(&dsim->dsi_host);
 }
 
 static const struct component_ops exynos_dsi_component_ops = {
@@ -1761,6 +1814,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;
+
+	dsi = devm_kzalloc(dsim->dev, sizeof(*dsi), GFP_KERNEL);
+	if (!dsi)
+		return -ENOMEM;
+
+	dsim->priv = dsi;
+	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,
 };
@@ -1855,7 +1942,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;
 
@@ -1946,24 +2035,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 v10 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.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 179 ++++++++++++++++++------
 1 file changed, 140 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index bb3d6a7fa84e..819131a36b96 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -250,6 +250,8 @@ struct exynos_dsi_transfer {
 	u16 rx_done;
 };
 
+struct exynos_dsi;
+
 #define DSIM_STATE_ENABLED		BIT(0)
 #define DSIM_STATE_INITIALIZED		BIT(1)
 #define DSIM_STATE_CMD_LPM		BIT(2)
@@ -282,12 +284,19 @@ struct exynos_dsi_driver_data {
 	const unsigned int *reg_values;
 };
 
+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_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 +326,12 @@ struct exynos_dsi {
 
 	const struct exynos_dsi_driver_data *driver_data;
 	const struct exynos_dsi_plat_data *plat_data;
+
+	void *priv;
+};
+
+struct exynos_dsi_enc {
+	struct drm_encoder encoder;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1320,10 +1335,11 @@ 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 *dsim = (struct exynos_dsi *)dev_id;
+	struct exynos_dsi_enc *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 
-	if (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE)
+	if (dsim->state & DSIM_STATE_VIDOUT_AVAILABLE)
 		exynos_drm_crtc_te_handler(encoder->crtc);
 
 	return IRQ_HANDLED;
@@ -1597,9 +1613,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;
 	int ret;
 
 	dsi->out_bridge = devm_drm_of_dsi_get_bridge(dev, dev->of_node, 1, 0);
@@ -1613,35 +1628,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;
 }
@@ -1650,12 +1645,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);
 
@@ -1729,10 +1726,66 @@ 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 = dsim->priv;
+	struct drm_encoder *encoder = &dsi->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 = dsim->priv;
+	struct drm_device *drm = dsi->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 exynos_dsi *dsim = dev_get_drvdata(dev);
+	struct exynos_dsi_enc *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 	struct drm_device *drm_dev = data;
 	int ret;
@@ -1743,17 +1796,17 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
 	if (ret < 0)
 		return ret;
 
-	return mipi_dsi_host_register(&dsi->dsi_host);
+	return mipi_dsi_host_register(&dsim->dsi_host);
 }
 
 static void exynos_dsi_unbind(struct device *dev, struct device *master,
 				void *data)
 {
-	struct exynos_dsi *dsi = dev_get_drvdata(dev);
+	struct exynos_dsi *dsim = dev_get_drvdata(dev);
 
-	exynos_dsi_atomic_disable(&dsi->bridge, NULL);
+	dsim->bridge.funcs->atomic_disable(&dsim->bridge, NULL);
 
-	mipi_dsi_host_unregister(&dsi->dsi_host);
+	mipi_dsi_host_unregister(&dsim->dsi_host);
 }
 
 static const struct component_ops exynos_dsi_component_ops = {
@@ -1761,6 +1814,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;
+
+	dsi = devm_kzalloc(dsim->dev, sizeof(*dsi), GFP_KERNEL);
+	if (!dsi)
+		return -ENOMEM;
+
+	dsim->priv = dsi;
+	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,
 };
@@ -1855,7 +1942,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;
 
@@ -1946,24 +2035,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 13/18] drm: exynos: dsi: Add Exynos based host irq hooks

[Jagan Teki]

Enable and disable of te_gpio's are Exynos platform specific
irq handling, so add the exynos based irq operations and hook
them for exynos plat_data.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 55 +++++++++++++++++++++----
 1 file changed, 47 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 819131a36b96..580e06595b37 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -291,9 +291,15 @@ struct exynos_dsim_host_ops {
 	int (*detach)(struct exynos_dsi *dsim, struct mipi_dsi_device *device);
 };
 
+struct exynos_dsim_irq_ops {
+	void (*enable)(struct exynos_dsi *dsim);
+	void (*disable)(struct exynos_dsi *dsim);
+};
+
 struct exynos_dsi_plat_data {
 	enum exynos_dsi_type hw_type;
 	const struct exynos_dsim_host_ops *host_ops;
+	const struct exynos_dsim_irq_ops *irq_ops;
 };
 
 struct exynos_dsi {
@@ -308,7 +314,6 @@ struct exynos_dsi {
 	struct clk **clks;
 	struct regulator_bulk_data supplies[2];
 	int irq;
-	struct gpio_desc *te_gpio;
 
 	u32 pll_clk_rate;
 	u32 burst_clk_rate;
@@ -332,6 +337,7 @@ struct exynos_dsi {
 
 struct exynos_dsi_enc {
 	struct drm_encoder encoder;
+	struct gpio_desc *te_gpio;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1345,18 +1351,38 @@ static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+static void _exynos_dsi_enable_irq(struct exynos_dsi *dsim)
 {
-	enable_irq(dsi->irq);
+	struct _exynos_dsi *dsi = dsim->priv;
 
 	if (dsi->te_gpio)
 		enable_irq(gpiod_to_irq(dsi->te_gpio));
 }
 
-static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
+static void _exynos_dsi_disable_irq(struct exynos_dsi *dsim)
 {
+	struct _exynos_dsi *dsi = dsim->priv;
+
 	if (dsi->te_gpio)
 		disable_irq(gpiod_to_irq(dsi->te_gpio));
+}
+
+static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+{
+	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
+
+	enable_irq(dsi->irq);
+
+	if (pdata->irq_ops && pdata->irq_ops->enable)
+		pdata->irq_ops->enable(dsi);
+}
+
+static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
+{
+	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
+
+	if (pdata->irq_ops && pdata->irq_ops->disable)
+		pdata->irq_ops->disable(dsi);
 
 	disable_irq(dsi->irq);
 }
@@ -1385,9 +1411,10 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
 	return 0;
 }
 
-static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
+static int exynos_dsi_register_te_irq(struct exynos_dsi *dsim,
 				      struct device *panel)
 {
+	struct _exynos_dsi *dsi = dsim->priv;
 	int ret;
 	int te_gpio_irq;
 
@@ -1395,7 +1422,7 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	if (!dsi->te_gpio) {
 		return 0;
 	} else if (IS_ERR(dsi->te_gpio)) {
-		dev_err(dsi->dev, "gpio request failed with %ld\n",
+		dev_err(dsim->dev, "gpio request failed with %ld\n",
 				PTR_ERR(dsi->te_gpio));
 		return PTR_ERR(dsi->te_gpio);
 	}
@@ -1405,7 +1432,7 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
 				   IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE", dsi);
 	if (ret) {
-		dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
+		dev_err(dsim->dev, "request interrupt failed with %d\n", ret);
 		gpiod_put(dsi->te_gpio);
 		return ret;
 	}
@@ -1413,8 +1440,10 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	return 0;
 }
 
-static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
+static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsim)
 {
+	struct _exynos_dsi *dsi = dsim->priv;
+
 	if (dsi->te_gpio) {
 		free_irq(gpiod_to_irq(dsi->te_gpio), dsi);
 		gpiod_put(dsi->te_gpio);
@@ -2035,6 +2064,11 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
 				pm_runtime_force_resume)
 };
 
+static const struct exynos_dsim_irq_ops exynos_dsi_irq_ops = {
+	.enable = _exynos_dsi_enable_irq,
+	.disable = _exynos_dsi_disable_irq,
+};
+
 static const struct exynos_dsim_host_ops exynos_dsi_host_ops = {
 	.register_host = exynos_dsi_register_host,
 	.unregister_host = exynos_dsi_unregister_host,
@@ -2045,26 +2079,31 @@ static const struct exynos_dsim_host_ops exynos_dsi_host_ops = {
 static const struct exynos_dsi_plat_data exynos3250_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS3250,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos4210_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS4210,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5410_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5410,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5422_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5422,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5433_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5433,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct of_device_id exynos_dsi_of_match[] = {
-- 
2.25.1

[PATCH v10 13/18] drm: exynos: dsi: Add Exynos based host irq hooks

[Jagan Teki]

Enable and disable of te_gpio's are Exynos platform specific
irq handling, so add the exynos based irq operations and hook
them for exynos plat_data.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 55 +++++++++++++++++++++----
 1 file changed, 47 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 819131a36b96..580e06595b37 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -291,9 +291,15 @@ struct exynos_dsim_host_ops {
 	int (*detach)(struct exynos_dsi *dsim, struct mipi_dsi_device *device);
 };
 
+struct exynos_dsim_irq_ops {
+	void (*enable)(struct exynos_dsi *dsim);
+	void (*disable)(struct exynos_dsi *dsim);
+};
+
 struct exynos_dsi_plat_data {
 	enum exynos_dsi_type hw_type;
 	const struct exynos_dsim_host_ops *host_ops;
+	const struct exynos_dsim_irq_ops *irq_ops;
 };
 
 struct exynos_dsi {
@@ -308,7 +314,6 @@ struct exynos_dsi {
 	struct clk **clks;
 	struct regulator_bulk_data supplies[2];
 	int irq;
-	struct gpio_desc *te_gpio;
 
 	u32 pll_clk_rate;
 	u32 burst_clk_rate;
@@ -332,6 +337,7 @@ struct exynos_dsi {
 
 struct exynos_dsi_enc {
 	struct drm_encoder encoder;
+	struct gpio_desc *te_gpio;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1345,18 +1351,38 @@ static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+static void _exynos_dsi_enable_irq(struct exynos_dsi *dsim)
 {
-	enable_irq(dsi->irq);
+	struct _exynos_dsi *dsi = dsim->priv;
 
 	if (dsi->te_gpio)
 		enable_irq(gpiod_to_irq(dsi->te_gpio));
 }
 
-static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
+static void _exynos_dsi_disable_irq(struct exynos_dsi *dsim)
 {
+	struct _exynos_dsi *dsi = dsim->priv;
+
 	if (dsi->te_gpio)
 		disable_irq(gpiod_to_irq(dsi->te_gpio));
+}
+
+static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+{
+	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
+
+	enable_irq(dsi->irq);
+
+	if (pdata->irq_ops && pdata->irq_ops->enable)
+		pdata->irq_ops->enable(dsi);
+}
+
+static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
+{
+	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
+
+	if (pdata->irq_ops && pdata->irq_ops->disable)
+		pdata->irq_ops->disable(dsi);
 
 	disable_irq(dsi->irq);
 }
@@ -1385,9 +1411,10 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
 	return 0;
 }
 
-static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
+static int exynos_dsi_register_te_irq(struct exynos_dsi *dsim,
 				      struct device *panel)
 {
+	struct _exynos_dsi *dsi = dsim->priv;
 	int ret;
 	int te_gpio_irq;
 
@@ -1395,7 +1422,7 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	if (!dsi->te_gpio) {
 		return 0;
 	} else if (IS_ERR(dsi->te_gpio)) {
-		dev_err(dsi->dev, "gpio request failed with %ld\n",
+		dev_err(dsim->dev, "gpio request failed with %ld\n",
 				PTR_ERR(dsi->te_gpio));
 		return PTR_ERR(dsi->te_gpio);
 	}
@@ -1405,7 +1432,7 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
 				   IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE", dsi);
 	if (ret) {
-		dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
+		dev_err(dsim->dev, "request interrupt failed with %d\n", ret);
 		gpiod_put(dsi->te_gpio);
 		return ret;
 	}
@@ -1413,8 +1440,10 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	return 0;
 }
 
-static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
+static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsim)
 {
+	struct _exynos_dsi *dsi = dsim->priv;
+
 	if (dsi->te_gpio) {
 		free_irq(gpiod_to_irq(dsi->te_gpio), dsi);
 		gpiod_put(dsi->te_gpio);
@@ -2035,6 +2064,11 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
 				pm_runtime_force_resume)
 };
 
+static const struct exynos_dsim_irq_ops exynos_dsi_irq_ops = {
+	.enable = _exynos_dsi_enable_irq,
+	.disable = _exynos_dsi_disable_irq,
+};
+
 static const struct exynos_dsim_host_ops exynos_dsi_host_ops = {
 	.register_host = exynos_dsi_register_host,
 	.unregister_host = exynos_dsi_unregister_host,
@@ -2045,26 +2079,31 @@ static const struct exynos_dsim_host_ops exynos_dsi_host_ops = {
 static const struct exynos_dsi_plat_data exynos3250_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS3250,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos4210_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS4210,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5410_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5410,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5422_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5422,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5433_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5433,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct of_device_id exynos_dsi_of_match[] = {
-- 
2.25.1

[PATCH v10 13/18] drm: exynos: dsi: Add Exynos based host irq hooks

[Jagan Teki]

Enable and disable of te_gpio's are Exynos platform specific
irq handling, so add the exynos based irq operations and hook
them for exynos plat_data.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 | 55 +++++++++++++++++++++----
 1 file changed, 47 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 819131a36b96..580e06595b37 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -291,9 +291,15 @@ struct exynos_dsim_host_ops {
 	int (*detach)(struct exynos_dsi *dsim, struct mipi_dsi_device *device);
 };
 
+struct exynos_dsim_irq_ops {
+	void (*enable)(struct exynos_dsi *dsim);
+	void (*disable)(struct exynos_dsi *dsim);
+};
+
 struct exynos_dsi_plat_data {
 	enum exynos_dsi_type hw_type;
 	const struct exynos_dsim_host_ops *host_ops;
+	const struct exynos_dsim_irq_ops *irq_ops;
 };
 
 struct exynos_dsi {
@@ -308,7 +314,6 @@ struct exynos_dsi {
 	struct clk **clks;
 	struct regulator_bulk_data supplies[2];
 	int irq;
-	struct gpio_desc *te_gpio;
 
 	u32 pll_clk_rate;
 	u32 burst_clk_rate;
@@ -332,6 +337,7 @@ struct exynos_dsi {
 
 struct exynos_dsi_enc {
 	struct drm_encoder encoder;
+	struct gpio_desc *te_gpio;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1345,18 +1351,38 @@ static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+static void _exynos_dsi_enable_irq(struct exynos_dsi *dsim)
 {
-	enable_irq(dsi->irq);
+	struct _exynos_dsi *dsi = dsim->priv;
 
 	if (dsi->te_gpio)
 		enable_irq(gpiod_to_irq(dsi->te_gpio));
 }
 
-static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
+static void _exynos_dsi_disable_irq(struct exynos_dsi *dsim)
 {
+	struct _exynos_dsi *dsi = dsim->priv;
+
 	if (dsi->te_gpio)
 		disable_irq(gpiod_to_irq(dsi->te_gpio));
+}
+
+static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
+{
+	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
+
+	enable_irq(dsi->irq);
+
+	if (pdata->irq_ops && pdata->irq_ops->enable)
+		pdata->irq_ops->enable(dsi);
+}
+
+static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
+{
+	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
+
+	if (pdata->irq_ops && pdata->irq_ops->disable)
+		pdata->irq_ops->disable(dsi);
 
 	disable_irq(dsi->irq);
 }
@@ -1385,9 +1411,10 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
 	return 0;
 }
 
-static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
+static int exynos_dsi_register_te_irq(struct exynos_dsi *dsim,
 				      struct device *panel)
 {
+	struct _exynos_dsi *dsi = dsim->priv;
 	int ret;
 	int te_gpio_irq;
 
@@ -1395,7 +1422,7 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	if (!dsi->te_gpio) {
 		return 0;
 	} else if (IS_ERR(dsi->te_gpio)) {
-		dev_err(dsi->dev, "gpio request failed with %ld\n",
+		dev_err(dsim->dev, "gpio request failed with %ld\n",
 				PTR_ERR(dsi->te_gpio));
 		return PTR_ERR(dsi->te_gpio);
 	}
@@ -1405,7 +1432,7 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
 				   IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE", dsi);
 	if (ret) {
-		dev_err(dsi->dev, "request interrupt failed with %d\n", ret);
+		dev_err(dsim->dev, "request interrupt failed with %d\n", ret);
 		gpiod_put(dsi->te_gpio);
 		return ret;
 	}
@@ -1413,8 +1440,10 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
 	return 0;
 }
 
-static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
+static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsim)
 {
+	struct _exynos_dsi *dsi = dsim->priv;
+
 	if (dsi->te_gpio) {
 		free_irq(gpiod_to_irq(dsi->te_gpio), dsi);
 		gpiod_put(dsi->te_gpio);
@@ -2035,6 +2064,11 @@ static const struct dev_pm_ops exynos_dsi_pm_ops = {
 				pm_runtime_force_resume)
 };
 
+static const struct exynos_dsim_irq_ops exynos_dsi_irq_ops = {
+	.enable = _exynos_dsi_enable_irq,
+	.disable = _exynos_dsi_disable_irq,
+};
+
 static const struct exynos_dsim_host_ops exynos_dsi_host_ops = {
 	.register_host = exynos_dsi_register_host,
 	.unregister_host = exynos_dsi_unregister_host,
@@ -2045,26 +2079,31 @@ static const struct exynos_dsim_host_ops exynos_dsi_host_ops = {
 static const struct exynos_dsi_plat_data exynos3250_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS3250,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos4210_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS4210,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5410_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5410,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5422_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5422,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct exynos_dsi_plat_data exynos5433_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5433,
 	.host_ops = &exynos_dsi_host_ops,
+	.irq_ops = &exynos_dsi_irq_ops,
 };
 
 static const struct of_device_id exynos_dsi_of_match[] = {
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 14/18] drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge

[Jagan Teki]

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

In order to access this DSI controller between various platform SoCs,
the ideal way to incorporate this in the drm stack is via the drm bridge
driver.

We already have a consolidated code for supporting component and bridge
based DRM drivers, so keep the exynos component based code in existing
exynos_drm_dsi.c and move generic bridge code as part of samsung-dsim.c

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v10:
- don't add new code
- move the files and update samsung_dsim names
- update commit message
Changes for v9:
- drop the bridge attach fix for Exynos
Changes for v8:
- update the commit message head
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 pointer for exynos dsi
Changes for v5:
- [mszyprow] reworked driver initialization using the same approach as in
  drivers/gpu/drm/{exynos/exynos_dp.c, bridge/analogix/analogix_dp_core.c},
  removed weak functions, moved exynos_dsi_driver back to exynos_drm_dsi.c
  and restored integration with exynos_drm custom initialization.
- updated the commit message [Jagan]
Changes for v4:
- include Inki Dae in MAINTAINERS
- remove dsi_driver probe in exynos_drm_drv to support multi-arch build
Changes for v3:
- restore gpio related fixes
- restore proper bridge chain
- rework initialization issue
- fix header includes in proper way
Changes for v2:
- fixed exynos dsi driver conversion (Marek Szyprowski)
- updated commit message
- updated MAINTAINERS file
Changes for v1:
- don't maintain component_ops in bridge driver
- don't maintain platform glue code in bridge driver
- add platform-specific glue code and make a common bridge

 MAINTAINERS                             |    9 +
 drivers/gpu/drm/bridge/Kconfig          |   12 +
 drivers/gpu/drm/bridge/Makefile         |    1 +
 drivers/gpu/drm/bridge/samsung-dsim.c   | 1816 ++++++++++++++++++++
 drivers/gpu/drm/exynos/Kconfig          |    1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2007 +----------------------
 include/drm/bridge/samsung-dsim.h       |  118 ++
 7 files changed, 2027 insertions(+), 1937 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
 create mode 100644 include/drm/bridge/samsung-dsim.h

diff --git a/MAINTAINERS b/MAINTAINERS
index f3edff6b1cad..9a37cce05062 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6675,6 +6675,15 @@ T:	git git://anongit.freedesktop.org/drm/drm-misc
 F:	Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml
 F:	drivers/gpu/drm/panel/panel-samsung-db7430.c
 
+DRM DRIVER FOR SAMSUNG MIPI DSIM BRIDGE
+M:	Jagan Teki <jagan@amarulasolutions.com>
+M:	Marek Szyprowski <m.szyprowski@samsung.com>
+M:	Inki Dae <inki.dae@samsung.com
+S:	Maintained
+T:	git git://anongit.freedesktop.org/drm/drm-misc
+F:	drivers/gpu/drm/bridge/samsung-dsim.c
+F:	include/drm/bridge/samsung-dsim.h
+
 DRM DRIVER FOR SAMSUNG S6D27A1 PANELS
 M:	Markuss Broks <markuss.broks@gmail.com>
 S:	Maintained
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 57946d80b02d..8e85dac9f53e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -231,6 +231,18 @@ config DRM_PARADE_PS8640
 	  The PS8640 is a high-performance and low-power
 	  MIPI DSI to eDP converter
 
+config DRM_SAMSUNG_DSIM
+	tristate "Samsung MIPI DSIM bridge driver"
+	depends on COMMON_CLK
+	depends on OF && HAS_IOMEM
+	select DRM_KMS_HELPER
+	select DRM_MIPI_DSI
+	select DRM_PANEL_BRIDGE
+	help
+	  The Samsung MIPI DSIM bridge controller driver.
+	  This MIPI DSIM bridge can be found it on Exynos SoCs and
+	  NXP's i.MX8M Mini/Nano.
+
 config DRM_SIL_SII8620
 	tristate "Silicon Image SII8620 HDMI/MHL bridge"
 	depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 1884803c6860..dae843723991 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
+obj-$(CONFIG_DRM_SAMSUNG_DSIM) += samsung-dsim.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_SII9234) += sii9234.o
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
new file mode 100644
index 000000000000..dd27935081a3
--- /dev/null
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -0,0 +1,1816 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Samsung MIPI DSIM bridge driver.
+ *
+ * Copyright (C) 2021 Amarula Solutions(India)
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Author: Jagan Teki <jagan@amarulasolutions.com>
+ *
+ * Based on exynos_drm_dsi from
+ * Tomasz Figa <t.figa@samsung.com>
+ */
+
+#include <asm/unaligned.h>
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/irq.h>
+#include <linux/media-bus-format.h>
+#include <linux/of_device.h>
+#include <linux/phy/phy.h>
+
+#include <video/mipi_display.h>
+
+#include <drm/bridge/samsung-dsim.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_print.h>
+
+/* returns true iff both arguments logically differs */
+#define NEQV(a, b) (!(a) ^ !(b))
+
+/* DSIM_STATUS */
+#define DSIM_STOP_STATE_DAT(x)		(((x) & 0xf) << 0)
+#define DSIM_STOP_STATE_CLK		(1 << 8)
+#define DSIM_TX_READY_HS_CLK		(1 << 10)
+#define DSIM_PLL_STABLE			(1 << 31)
+
+/* DSIM_SWRST */
+#define DSIM_FUNCRST			(1 << 16)
+#define DSIM_SWRST			(1 << 0)
+
+/* DSIM_TIMEOUT */
+#define DSIM_LPDR_TIMEOUT(x)		((x) << 0)
+#define DSIM_BTA_TIMEOUT(x)		((x) << 16)
+
+/* DSIM_CLKCTRL */
+#define DSIM_ESC_PRESCALER(x)		(((x) & 0xffff) << 0)
+#define DSIM_ESC_PRESCALER_MASK		(0xffff << 0)
+#define DSIM_LANE_ESC_CLK_EN_CLK	(1 << 19)
+#define DSIM_LANE_ESC_CLK_EN_DATA(x)	(((x) & 0xf) << 20)
+#define DSIM_LANE_ESC_CLK_EN_DATA_MASK	(0xf << 20)
+#define DSIM_BYTE_CLKEN			(1 << 24)
+#define DSIM_BYTE_CLK_SRC(x)		(((x) & 0x3) << 25)
+#define DSIM_BYTE_CLK_SRC_MASK		(0x3 << 25)
+#define DSIM_PLL_BYPASS			(1 << 27)
+#define DSIM_ESC_CLKEN			(1 << 28)
+#define DSIM_TX_REQUEST_HSCLK		(1 << 31)
+
+/* DSIM_CONFIG */
+#define DSIM_LANE_EN_CLK		(1 << 0)
+#define DSIM_LANE_EN(x)			(((x) & 0xf) << 1)
+#define DSIM_NUM_OF_DATA_LANE(x)	(((x) & 0x3) << 5)
+#define DSIM_SUB_PIX_FORMAT(x)		(((x) & 0x7) << 8)
+#define DSIM_MAIN_PIX_FORMAT_MASK	(0x7 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB888	(0x7 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB666	(0x6 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB666_P	(0x5 << 12)
+#define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
+#define DSIM_SUB_VC			(((x) & 0x3) << 16)
+#define DSIM_MAIN_VC			(((x) & 0x3) << 18)
+#define DSIM_HSA_DISABLE_MODE		(1 << 20)
+#define DSIM_HBP_DISABLE_MODE		(1 << 21)
+#define DSIM_HFP_DISABLE_MODE		(1 << 22)
+/*
+ * The i.MX 8M Mini Applications Processor Reference Manual,
+ * Rev. 3, 11/2020 Page 4091
+ * The i.MX 8M Nano Applications Processor Reference Manual,
+ * Rev. 2, 07/2022 Page 3058
+ * The i.MX 8M Plus Applications Processor Reference Manual,
+ * Rev. 1, 06/2021 Page 5436
+ * all claims this bit is 'HseDisableMode' with the definition
+ * 0 = Disables transfer
+ * 1 = Enables transfer
+ *
+ * This clearly states that HSE is not a disabled bit.
+ *
+ * The naming convention follows as per the manual and the
+ * driver logic is based on the MIPI_DSI_MODE_VIDEO_HSE flag.
+ */
+#define DSIM_HSE_DISABLE_MODE		(1 << 23)
+#define DSIM_AUTO_MODE			(1 << 24)
+#define DSIM_VIDEO_MODE			(1 << 25)
+#define DSIM_BURST_MODE			(1 << 26)
+#define DSIM_SYNC_INFORM		(1 << 27)
+#define DSIM_EOT_DISABLE		(1 << 28)
+#define DSIM_MFLUSH_VS			(1 << 29)
+/* This flag is valid only for exynos3250/3472/5260/5430 */
+#define DSIM_CLKLANE_STOP		(1 << 30)
+
+/* DSIM_ESCMODE */
+#define DSIM_TX_TRIGGER_RST		(1 << 4)
+#define DSIM_TX_LPDT_LP			(1 << 6)
+#define DSIM_CMD_LPDT_LP		(1 << 7)
+#define DSIM_FORCE_BTA			(1 << 16)
+#define DSIM_FORCE_STOP_STATE		(1 << 20)
+#define DSIM_STOP_STATE_CNT(x)		(((x) & 0x7ff) << 21)
+#define DSIM_STOP_STATE_CNT_MASK	(0x7ff << 21)
+
+/* DSIM_MDRESOL */
+#define DSIM_MAIN_STAND_BY		(1 << 31)
+#define DSIM_MAIN_VRESOL(x, num_bits)	(((x) & ((1 << (num_bits)) - 1)) << 16)
+#define DSIM_MAIN_HRESOL(x, num_bits)	(((x) & ((1 << (num_bits)) - 1)) << 0)
+
+/* DSIM_MVPORCH */
+#define DSIM_CMD_ALLOW(x)		((x) << 28)
+#define DSIM_STABLE_VFP(x)		((x) << 16)
+#define DSIM_MAIN_VBP(x)		((x) << 0)
+#define DSIM_CMD_ALLOW_MASK		(0xf << 28)
+#define DSIM_STABLE_VFP_MASK		(0x7ff << 16)
+#define DSIM_MAIN_VBP_MASK		(0x7ff << 0)
+
+/* DSIM_MHPORCH */
+#define DSIM_MAIN_HFP(x)		((x) << 16)
+#define DSIM_MAIN_HBP(x)		((x) << 0)
+#define DSIM_MAIN_HFP_MASK		((0xffff) << 16)
+#define DSIM_MAIN_HBP_MASK		((0xffff) << 0)
+
+/* DSIM_MSYNC */
+#define DSIM_MAIN_VSA(x)		((x) << 22)
+#define DSIM_MAIN_HSA(x)		((x) << 0)
+#define DSIM_MAIN_VSA_MASK		((0x3ff) << 22)
+#define DSIM_MAIN_HSA_MASK		((0xffff) << 0)
+
+/* DSIM_SDRESOL */
+#define DSIM_SUB_STANDY(x)		((x) << 31)
+#define DSIM_SUB_VRESOL(x)		((x) << 16)
+#define DSIM_SUB_HRESOL(x)		((x) << 0)
+#define DSIM_SUB_STANDY_MASK		((0x1) << 31)
+#define DSIM_SUB_VRESOL_MASK		((0x7ff) << 16)
+#define DSIM_SUB_HRESOL_MASK		((0x7ff) << 0)
+
+/* DSIM_INTSRC */
+#define DSIM_INT_PLL_STABLE		(1 << 31)
+#define DSIM_INT_SW_RST_RELEASE		(1 << 30)
+#define DSIM_INT_SFR_FIFO_EMPTY		(1 << 29)
+#define DSIM_INT_SFR_HDR_FIFO_EMPTY	(1 << 28)
+#define DSIM_INT_BTA			(1 << 25)
+#define DSIM_INT_FRAME_DONE		(1 << 24)
+#define DSIM_INT_RX_TIMEOUT		(1 << 21)
+#define DSIM_INT_BTA_TIMEOUT		(1 << 20)
+#define DSIM_INT_RX_DONE		(1 << 18)
+#define DSIM_INT_RX_TE			(1 << 17)
+#define DSIM_INT_RX_ACK			(1 << 16)
+#define DSIM_INT_RX_ECC_ERR		(1 << 15)
+#define DSIM_INT_RX_CRC_ERR		(1 << 14)
+
+/* DSIM_FIFOCTRL */
+#define DSIM_RX_DATA_FULL		(1 << 25)
+#define DSIM_RX_DATA_EMPTY		(1 << 24)
+#define DSIM_SFR_HEADER_FULL		(1 << 23)
+#define DSIM_SFR_HEADER_EMPTY		(1 << 22)
+#define DSIM_SFR_PAYLOAD_FULL		(1 << 21)
+#define DSIM_SFR_PAYLOAD_EMPTY		(1 << 20)
+#define DSIM_I80_HEADER_FULL		(1 << 19)
+#define DSIM_I80_HEADER_EMPTY		(1 << 18)
+#define DSIM_I80_PAYLOAD_FULL		(1 << 17)
+#define DSIM_I80_PAYLOAD_EMPTY		(1 << 16)
+#define DSIM_SD_HEADER_FULL		(1 << 15)
+#define DSIM_SD_HEADER_EMPTY		(1 << 14)
+#define DSIM_SD_PAYLOAD_FULL		(1 << 13)
+#define DSIM_SD_PAYLOAD_EMPTY		(1 << 12)
+#define DSIM_MD_HEADER_FULL		(1 << 11)
+#define DSIM_MD_HEADER_EMPTY		(1 << 10)
+#define DSIM_MD_PAYLOAD_FULL		(1 << 9)
+#define DSIM_MD_PAYLOAD_EMPTY		(1 << 8)
+#define DSIM_RX_FIFO			(1 << 4)
+#define DSIM_SFR_FIFO			(1 << 3)
+#define DSIM_I80_FIFO			(1 << 2)
+#define DSIM_SD_FIFO			(1 << 1)
+#define DSIM_MD_FIFO			(1 << 0)
+
+/* DSIM_PHYACCHR */
+#define DSIM_AFC_EN			(1 << 14)
+#define DSIM_AFC_CTL(x)			(((x) & 0x7) << 5)
+
+/* DSIM_PLLCTRL */
+#define DSIM_FREQ_BAND(x)		((x) << 24)
+#define DSIM_PLL_EN			(1 << 23)
+#define DSIM_PLL_P(x, offset)		((x) << (offset))
+#define DSIM_PLL_M(x)			((x) << 4)
+#define DSIM_PLL_S(x)			((x) << 1)
+
+/* DSIM_PHYCTRL */
+#define DSIM_PHYCTRL_ULPS_EXIT(x)	(((x) & 0x1ff) << 0)
+#define DSIM_PHYCTRL_B_DPHYCTL_VREG_LP	(1 << 30)
+#define DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP	(1 << 14)
+
+/* DSIM_PHYTIMING */
+#define DSIM_PHYTIMING_LPX(x)		((x) << 8)
+#define DSIM_PHYTIMING_HS_EXIT(x)	((x) << 0)
+
+/* DSIM_PHYTIMING1 */
+#define DSIM_PHYTIMING1_CLK_PREPARE(x)	((x) << 24)
+#define DSIM_PHYTIMING1_CLK_ZERO(x)	((x) << 16)
+#define DSIM_PHYTIMING1_CLK_POST(x)	((x) << 8)
+#define DSIM_PHYTIMING1_CLK_TRAIL(x)	((x) << 0)
+
+/* DSIM_PHYTIMING2 */
+#define DSIM_PHYTIMING2_HS_PREPARE(x)	((x) << 16)
+#define DSIM_PHYTIMING2_HS_ZERO(x)	((x) << 8)
+#define DSIM_PHYTIMING2_HS_TRAIL(x)	((x) << 0)
+
+#define DSI_MAX_BUS_WIDTH		4
+#define DSI_NUM_VIRTUAL_CHANNELS	4
+#define DSI_TX_FIFO_SIZE		2048
+#define DSI_RX_FIFO_SIZE		256
+#define DSI_XFER_TIMEOUT_MS		100
+#define DSI_RX_FIFO_EMPTY		0x30800002
+
+#define OLD_SCLK_MIPI_CLK_NAME		"pll_clk"
+
+static const char *const clk_names[5] = {
+	"bus_clk",
+	"sclk_mipi",
+	"phyclk_mipidphy0_bitclkdiv8",
+	"phyclk_mipidphy0_rxclkesc0",
+	"sclk_rgb_vclk_to_dsim0"
+};
+
+enum samsung_dsim_transfer_type {
+	EXYNOS_DSI_TX,
+	EXYNOS_DSI_RX,
+};
+
+enum reg_idx {
+	DSIM_STATUS_REG,	/* Status register */
+	DSIM_SWRST_REG,		/* Software reset register */
+	DSIM_CLKCTRL_REG,	/* Clock control register */
+	DSIM_TIMEOUT_REG,	/* Time out register */
+	DSIM_CONFIG_REG,	/* Configuration register */
+	DSIM_ESCMODE_REG,	/* Escape mode register */
+	DSIM_MDRESOL_REG,
+	DSIM_MVPORCH_REG,	/* Main display Vporch register */
+	DSIM_MHPORCH_REG,	/* Main display Hporch register */
+	DSIM_MSYNC_REG,		/* Main display sync area register */
+	DSIM_INTSRC_REG,	/* Interrupt source register */
+	DSIM_INTMSK_REG,	/* Interrupt mask register */
+	DSIM_PKTHDR_REG,	/* Packet Header FIFO register */
+	DSIM_PAYLOAD_REG,	/* Payload FIFO register */
+	DSIM_RXFIFO_REG,	/* Read FIFO register */
+	DSIM_FIFOCTRL_REG,	/* FIFO status and control register */
+	DSIM_PLLCTRL_REG,	/* PLL control register */
+	DSIM_PHYCTRL_REG,
+	DSIM_PHYTIMING_REG,
+	DSIM_PHYTIMING1_REG,
+	DSIM_PHYTIMING2_REG,
+	NUM_REGS
+};
+
+static const unsigned int exynos_reg_ofs[] = {
+	[DSIM_STATUS_REG] =  0x00,
+	[DSIM_SWRST_REG] =  0x04,
+	[DSIM_CLKCTRL_REG] =  0x08,
+	[DSIM_TIMEOUT_REG] =  0x0c,
+	[DSIM_CONFIG_REG] =  0x10,
+	[DSIM_ESCMODE_REG] =  0x14,
+	[DSIM_MDRESOL_REG] =  0x18,
+	[DSIM_MVPORCH_REG] =  0x1c,
+	[DSIM_MHPORCH_REG] =  0x20,
+	[DSIM_MSYNC_REG] =  0x24,
+	[DSIM_INTSRC_REG] =  0x2c,
+	[DSIM_INTMSK_REG] =  0x30,
+	[DSIM_PKTHDR_REG] =  0x34,
+	[DSIM_PAYLOAD_REG] =  0x38,
+	[DSIM_RXFIFO_REG] =  0x3c,
+	[DSIM_FIFOCTRL_REG] =  0x44,
+	[DSIM_PLLCTRL_REG] =  0x4c,
+	[DSIM_PHYCTRL_REG] =  0x5c,
+	[DSIM_PHYTIMING_REG] =  0x64,
+	[DSIM_PHYTIMING1_REG] =  0x68,
+	[DSIM_PHYTIMING2_REG] =  0x6c,
+};
+
+static const unsigned int exynos5433_reg_ofs[] = {
+	[DSIM_STATUS_REG] = 0x04,
+	[DSIM_SWRST_REG] = 0x0C,
+	[DSIM_CLKCTRL_REG] = 0x10,
+	[DSIM_TIMEOUT_REG] = 0x14,
+	[DSIM_CONFIG_REG] = 0x18,
+	[DSIM_ESCMODE_REG] = 0x1C,
+	[DSIM_MDRESOL_REG] = 0x20,
+	[DSIM_MVPORCH_REG] = 0x24,
+	[DSIM_MHPORCH_REG] = 0x28,
+	[DSIM_MSYNC_REG] = 0x2C,
+	[DSIM_INTSRC_REG] = 0x34,
+	[DSIM_INTMSK_REG] = 0x38,
+	[DSIM_PKTHDR_REG] = 0x3C,
+	[DSIM_PAYLOAD_REG] = 0x40,
+	[DSIM_RXFIFO_REG] = 0x44,
+	[DSIM_FIFOCTRL_REG] = 0x4C,
+	[DSIM_PLLCTRL_REG] = 0x94,
+	[DSIM_PHYCTRL_REG] = 0xA4,
+	[DSIM_PHYTIMING_REG] = 0xB4,
+	[DSIM_PHYTIMING1_REG] = 0xB8,
+	[DSIM_PHYTIMING2_REG] = 0xBC,
+};
+
+enum reg_value_idx {
+	RESET_TYPE,
+	PLL_TIMER,
+	STOP_STATE_CNT,
+	PHYCTRL_ULPS_EXIT,
+	PHYCTRL_VREG_LP,
+	PHYCTRL_SLEW_UP,
+	PHYTIMING_LPX,
+	PHYTIMING_HS_EXIT,
+	PHYTIMING_CLK_PREPARE,
+	PHYTIMING_CLK_ZERO,
+	PHYTIMING_CLK_POST,
+	PHYTIMING_CLK_TRAIL,
+	PHYTIMING_HS_PREPARE,
+	PHYTIMING_HS_ZERO,
+	PHYTIMING_HS_TRAIL
+};
+
+static const unsigned int reg_values[] = {
+	[RESET_TYPE] = DSIM_SWRST,
+	[PLL_TIMER] = 500,
+	[STOP_STATE_CNT] = 0xf,
+	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x0af),
+	[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(0x27),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x09),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
+};
+
+static const unsigned int exynos5422_reg_values[] = {
+	[RESET_TYPE] = DSIM_SWRST,
+	[PLL_TIMER] = 500,
+	[STOP_STATE_CNT] = 0xf,
+	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0xaf),
+	[PHYCTRL_VREG_LP] = 0,
+	[PHYCTRL_SLEW_UP] = 0,
+	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x08),
+	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0d),
+	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
+	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x30),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x0a),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0c),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x11),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0d),
+};
+
+static const unsigned int exynos5433_reg_values[] = {
+	[RESET_TYPE] = DSIM_FUNCRST,
+	[PLL_TIMER] = 22200,
+	[STOP_STATE_CNT] = 0xa,
+	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x190),
+	[PHYCTRL_VREG_LP] = DSIM_PHYCTRL_B_DPHYCTL_VREG_LP,
+	[PHYCTRL_SLEW_UP] = DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP,
+	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x07),
+	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0c),
+	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
+	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x2d),
+	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
+	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x09),
+	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0b),
+	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x10),
+	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
+};
+
+static const struct samsung_dsim_driver_data exynos3_dsi_driver_data = {
+	.reg_ofs = exynos_reg_ofs,
+	.plltmr_reg = 0x50,
+	.has_freqband = 1,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 1000,
+	.wait_for_reset = 1,
+	.num_bits_resol = 11,
+	.pll_p_offset = 13,
+	.reg_values = reg_values,
+};
+
+static const struct samsung_dsim_driver_data exynos4_dsi_driver_data = {
+	.reg_ofs = exynos_reg_ofs,
+	.plltmr_reg = 0x50,
+	.has_freqband = 1,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 1000,
+	.wait_for_reset = 1,
+	.num_bits_resol = 11,
+	.pll_p_offset = 13,
+	.reg_values = reg_values,
+};
+
+static const struct samsung_dsim_driver_data exynos5_dsi_driver_data = {
+	.reg_ofs = exynos_reg_ofs,
+	.plltmr_reg = 0x58,
+	.num_clks = 2,
+	.max_freq = 1000,
+	.wait_for_reset = 1,
+	.num_bits_resol = 11,
+	.pll_p_offset = 13,
+	.reg_values = reg_values,
+};
+
+static const struct samsung_dsim_driver_data exynos5433_dsi_driver_data = {
+	.reg_ofs = exynos5433_reg_ofs,
+	.plltmr_reg = 0xa0,
+	.has_clklane_stop = 1,
+	.num_clks = 5,
+	.max_freq = 1500,
+	.wait_for_reset = 0,
+	.num_bits_resol = 12,
+	.pll_p_offset = 13,
+	.reg_values = exynos5433_reg_values,
+};
+
+static const struct samsung_dsim_driver_data exynos5422_dsi_driver_data = {
+	.reg_ofs = exynos5433_reg_ofs,
+	.plltmr_reg = 0xa0,
+	.has_clklane_stop = 1,
+	.num_clks = 2,
+	.max_freq = 1500,
+	.wait_for_reset = 1,
+	.num_bits_resol = 12,
+	.pll_p_offset = 13,
+	.reg_values = exynos5422_reg_values,
+};
+
+static const struct samsung_dsim_driver_data *
+samsung_dsim_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 inline struct samsung_dsim *host_to_dsi(struct mipi_dsi_host *h)
+{
+	return container_of(h, struct samsung_dsim, dsi_host);
+}
+
+static inline struct samsung_dsim *bridge_to_dsi(struct drm_bridge *b)
+{
+	return container_of(b, struct samsung_dsim, bridge);
+}
+
+static inline void samsung_dsim_write(struct samsung_dsim *dsi,
+				      enum reg_idx idx, u32 val)
+{
+	writel(val, dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
+}
+
+static inline u32 samsung_dsim_read(struct samsung_dsim *dsi, enum reg_idx idx)
+{
+	return readl(dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
+}
+
+static void samsung_dsim_wait_for_reset(struct samsung_dsim *dsi)
+{
+	if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
+		return;
+
+	dev_err(dsi->dev, "timeout waiting for reset\n");
+}
+
+static void samsung_dsim_reset(struct samsung_dsim *dsi)
+{
+	u32 reset_val = dsi->driver_data->reg_values[RESET_TYPE];
+
+	reinit_completion(&dsi->completed);
+	samsung_dsim_write(dsi, DSIM_SWRST_REG, reset_val);
+}
+
+#ifndef MHZ
+#define MHZ	(1000*1000)
+#endif
+
+static unsigned long samsung_dsim_pll_find_pms(struct samsung_dsim *dsi,
+					       unsigned long fin,
+					       unsigned long fout,
+					       u8 *p, u16 *m, u8 *s)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	unsigned long best_freq = 0;
+	u32 min_delta = 0xffffffff;
+	u8 p_min, p_max;
+	u8 _p, best_p;
+	u16 _m, best_m;
+	u8 _s, best_s;
+
+	p_min = DIV_ROUND_UP(fin, (12 * MHZ));
+	p_max = fin / (6 * MHZ);
+
+	for (_p = p_min; _p <= p_max; ++_p) {
+		for (_s = 0; _s <= 5; ++_s) {
+			u64 tmp;
+			u32 delta;
+
+			tmp = (u64)fout * (_p << _s);
+			do_div(tmp, fin);
+			_m = tmp;
+			if (_m < 41 || _m > 125)
+				continue;
+
+			tmp = (u64)_m * fin;
+			do_div(tmp, _p);
+			if (tmp < 500 * MHZ ||
+					tmp > driver_data->max_freq * MHZ)
+				continue;
+
+			tmp = (u64)_m * fin;
+			do_div(tmp, _p << _s);
+
+			delta = abs(fout - tmp);
+			if (delta < min_delta) {
+				best_p = _p;
+				best_m = _m;
+				best_s = _s;
+				min_delta = delta;
+				best_freq = tmp;
+			}
+		}
+	}
+
+	if (best_freq) {
+		*p = best_p;
+		*m = best_m;
+		*s = best_s;
+	}
+
+	return best_freq;
+}
+
+static unsigned long samsung_dsim_set_pll(struct samsung_dsim *dsi,
+					  unsigned long freq)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	unsigned long fin, fout;
+	int timeout;
+	u8 p, s;
+	u16 m;
+	u32 reg;
+
+	fin = dsi->pll_clk_rate;
+	fout = samsung_dsim_pll_find_pms(dsi, fin, freq, &p, &m, &s);
+	if (!fout) {
+		dev_err(dsi->dev,
+			"failed to find PLL PMS for requested frequency\n");
+		return 0;
+	}
+	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
+
+	writel(driver_data->reg_values[PLL_TIMER],
+			dsi->reg_base + driver_data->plltmr_reg);
+
+	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[] = {
+			100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
+			270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
+			510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
+			770 * MHZ, 870 * MHZ, 950 * MHZ,
+		};
+		int band;
+
+		for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
+			if (fout < freq_bands[band])
+				break;
+
+		dev_dbg(dsi->dev, "band %d\n", band);
+
+		reg |= DSIM_FREQ_BAND(band);
+	}
+
+	samsung_dsim_write(dsi, DSIM_PLLCTRL_REG, reg);
+
+	timeout = 1000;
+	do {
+		if (timeout-- == 0) {
+			dev_err(dsi->dev, "PLL failed to stabilize\n");
+			return 0;
+		}
+		reg = samsung_dsim_read(dsi, DSIM_STATUS_REG);
+	} while ((reg & DSIM_PLL_STABLE) == 0);
+
+	return fout;
+}
+
+static int samsung_dsim_enable_clock(struct samsung_dsim *dsi)
+{
+	unsigned long hs_clk, byte_clk, esc_clk;
+	unsigned long esc_div;
+	u32 reg;
+
+	hs_clk = samsung_dsim_set_pll(dsi, dsi->burst_clk_rate);
+	if (!hs_clk) {
+		dev_err(dsi->dev, "failed to configure DSI PLL\n");
+		return -EFAULT;
+	}
+
+	byte_clk = hs_clk / 8;
+	esc_div = DIV_ROUND_UP(byte_clk, dsi->esc_clk_rate);
+	esc_clk = byte_clk / esc_div;
+
+	if (esc_clk > 20 * MHZ) {
+		++esc_div;
+		esc_clk = byte_clk / esc_div;
+	}
+
+	dev_dbg(dsi->dev, "hs_clk = %lu, byte_clk = %lu, esc_clk = %lu\n",
+		hs_clk, byte_clk, esc_clk);
+
+	reg = samsung_dsim_read(dsi, DSIM_CLKCTRL_REG);
+	reg &= ~(DSIM_ESC_PRESCALER_MASK | DSIM_LANE_ESC_CLK_EN_CLK
+			| DSIM_LANE_ESC_CLK_EN_DATA_MASK | DSIM_PLL_BYPASS
+			| DSIM_BYTE_CLK_SRC_MASK);
+	reg |= DSIM_ESC_CLKEN | DSIM_BYTE_CLKEN
+			| DSIM_ESC_PRESCALER(esc_div)
+			| DSIM_LANE_ESC_CLK_EN_CLK
+			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
+			| DSIM_BYTE_CLK_SRC(0)
+			| DSIM_TX_REQUEST_HSCLK;
+	samsung_dsim_write(dsi, DSIM_CLKCTRL_REG, reg);
+
+	return 0;
+}
+
+static void samsung_dsim_set_phy_ctrl(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	const unsigned int *reg_values = driver_data->reg_values;
+	u32 reg;
+
+	if (driver_data->has_freqband)
+		return;
+
+	/* B D-PHY: D-PHY Master & Slave Analog Block control */
+	reg = reg_values[PHYCTRL_ULPS_EXIT] | reg_values[PHYCTRL_VREG_LP] |
+		reg_values[PHYCTRL_SLEW_UP];
+	samsung_dsim_write(dsi, DSIM_PHYCTRL_REG, reg);
+
+	/*
+	 * T LPX: Transmitted length of any Low-Power state period
+	 * T HS-EXIT: Time that the transmitter drives LP-11 following a HS
+	 *	burst
+	 */
+	reg = reg_values[PHYTIMING_LPX] | reg_values[PHYTIMING_HS_EXIT];
+	samsung_dsim_write(dsi, DSIM_PHYTIMING_REG, reg);
+
+	/*
+	 * T CLK-PREPARE: Time that the transmitter drives the Clock Lane LP-00
+	 *	Line state immediately before the HS-0 Line state starting the
+	 *	HS transmission
+	 * T CLK-ZERO: Time that the transmitter drives the HS-0 state prior to
+	 *	transmitting the Clock.
+	 * T CLK_POST: Time that the transmitter continues to send HS clock
+	 *	after the last associated Data Lane has transitioned to LP Mode
+	 *	Interval is defined as the period from the end of T HS-TRAIL to
+	 *	the beginning of T CLK-TRAIL
+	 * T CLK-TRAIL: Time that the transmitter drives the HS-0 state after
+	 *	the last payload clock bit of a HS transmission burst
+	 */
+	reg = reg_values[PHYTIMING_CLK_PREPARE] |
+		reg_values[PHYTIMING_CLK_ZERO] |
+		reg_values[PHYTIMING_CLK_POST] |
+		reg_values[PHYTIMING_CLK_TRAIL];
+
+	samsung_dsim_write(dsi, DSIM_PHYTIMING1_REG, reg);
+
+	/*
+	 * T HS-PREPARE: Time that the transmitter drives the Data Lane LP-00
+	 *	Line state immediately before the HS-0 Line state starting the
+	 *	HS transmission
+	 * T HS-ZERO: Time that the transmitter drives the HS-0 state prior to
+	 *	transmitting the Sync sequence.
+	 * T HS-TRAIL: Time that the transmitter drives the flipped differential
+	 *	state after last payload data bit of a HS transmission burst
+	 */
+	reg = reg_values[PHYTIMING_HS_PREPARE] | reg_values[PHYTIMING_HS_ZERO] |
+		reg_values[PHYTIMING_HS_TRAIL];
+	samsung_dsim_write(dsi, DSIM_PHYTIMING2_REG, reg);
+}
+
+static void samsung_dsim_disable_clock(struct samsung_dsim *dsi)
+{
+	u32 reg;
+
+	reg = samsung_dsim_read(dsi, DSIM_CLKCTRL_REG);
+	reg &= ~(DSIM_LANE_ESC_CLK_EN_CLK | DSIM_LANE_ESC_CLK_EN_DATA_MASK
+			| DSIM_ESC_CLKEN | DSIM_BYTE_CLKEN);
+	samsung_dsim_write(dsi, DSIM_CLKCTRL_REG, reg);
+
+	reg = samsung_dsim_read(dsi, DSIM_PLLCTRL_REG);
+	reg &= ~DSIM_PLL_EN;
+	samsung_dsim_write(dsi, DSIM_PLLCTRL_REG, reg);
+}
+
+static void samsung_dsim_enable_lane(struct samsung_dsim *dsi, u32 lane)
+{
+	u32 reg = samsung_dsim_read(dsi, DSIM_CONFIG_REG);
+
+	reg |= (DSIM_NUM_OF_DATA_LANE(dsi->lanes - 1) | DSIM_LANE_EN_CLK |
+			DSIM_LANE_EN(lane));
+	samsung_dsim_write(dsi, DSIM_CONFIG_REG, reg);
+}
+
+static int samsung_dsim_init_link(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	int timeout;
+	u32 reg;
+	u32 lanes_mask;
+
+	/* Initialize FIFO pointers */
+	reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
+	reg &= ~0x1f;
+	samsung_dsim_write(dsi, DSIM_FIFOCTRL_REG, reg);
+
+	usleep_range(9000, 11000);
+
+	reg |= 0x1f;
+	samsung_dsim_write(dsi, DSIM_FIFOCTRL_REG, reg);
+	usleep_range(9000, 11000);
+
+	/* DSI configuration */
+	reg = 0;
+
+	/*
+	 * The first bit of mode_flags specifies display configuration.
+	 * If this bit is set[= MIPI_DSI_MODE_VIDEO], dsi will support video
+	 * mode, otherwise it will support command mode.
+	 */
+	if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
+		reg |= DSIM_VIDEO_MODE;
+
+		/*
+		 * The user manual describes that following bits are ignored in
+		 * command mode.
+		 */
+		if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
+			reg |= DSIM_MFLUSH_VS;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
+			reg |= DSIM_SYNC_INFORM;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
+			reg |= DSIM_BURST_MODE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
+			reg |= DSIM_AUTO_MODE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
+			reg |= DSIM_HSE_DISABLE_MODE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
+			reg |= DSIM_HFP_DISABLE_MODE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
+			reg |= DSIM_HBP_DISABLE_MODE;
+		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
+			reg |= DSIM_HSA_DISABLE_MODE;
+	}
+
+	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
+		reg |= DSIM_EOT_DISABLE;
+
+	switch (dsi->format) {
+	case MIPI_DSI_FMT_RGB888:
+		reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
+		break;
+	case MIPI_DSI_FMT_RGB666:
+		reg |= DSIM_MAIN_PIX_FORMAT_RGB666;
+		break;
+	case MIPI_DSI_FMT_RGB666_PACKED:
+		reg |= DSIM_MAIN_PIX_FORMAT_RGB666_P;
+		break;
+	case MIPI_DSI_FMT_RGB565:
+		reg |= DSIM_MAIN_PIX_FORMAT_RGB565;
+		break;
+	default:
+		dev_err(dsi->dev, "invalid pixel format\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * Use non-continuous clock mode if the periparal wants and
+	 * host controller supports
+	 *
+	 * In non-continous clock mode, host controller will turn off
+	 * the HS clock between high-speed transmissions to reduce
+	 * power consumption.
+	 */
+	if (driver_data->has_clklane_stop &&
+			dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
+		reg |= DSIM_CLKLANE_STOP;
+	}
+	samsung_dsim_write(dsi, DSIM_CONFIG_REG, reg);
+
+	lanes_mask = BIT(dsi->lanes) - 1;
+	samsung_dsim_enable_lane(dsi, lanes_mask);
+
+	/* Check clock and data lane state are stop state */
+	timeout = 100;
+	do {
+		if (timeout-- == 0) {
+			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
+			return -EFAULT;
+		}
+
+		reg = samsung_dsim_read(dsi, DSIM_STATUS_REG);
+		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
+		    != DSIM_STOP_STATE_DAT(lanes_mask))
+			continue;
+	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
+
+	reg = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
+	reg &= ~DSIM_STOP_STATE_CNT_MASK;
+	reg |= DSIM_STOP_STATE_CNT(driver_data->reg_values[STOP_STATE_CNT]);
+	samsung_dsim_write(dsi, DSIM_ESCMODE_REG, reg);
+
+	reg = DSIM_BTA_TIMEOUT(0xff) | DSIM_LPDR_TIMEOUT(0xffff);
+	samsung_dsim_write(dsi, DSIM_TIMEOUT_REG, reg);
+
+	return 0;
+}
+
+static void samsung_dsim_set_display_mode(struct samsung_dsim *dsi)
+{
+	struct drm_display_mode *m = &dsi->mode;
+	unsigned int num_bits_resol = dsi->driver_data->num_bits_resol;
+	u32 reg;
+
+	if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
+		reg = DSIM_CMD_ALLOW(0xf)
+			| DSIM_STABLE_VFP(m->vsync_start - m->vdisplay)
+			| DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
+		samsung_dsim_write(dsi, DSIM_MVPORCH_REG, reg);
+
+		reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
+			| DSIM_MAIN_HBP(m->htotal - m->hsync_end);
+		samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
+
+		reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
+			| DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
+		samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
+	}
+	reg =  DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
+		DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol);
+
+	samsung_dsim_write(dsi, DSIM_MDRESOL_REG, reg);
+
+	dev_dbg(dsi->dev, "LCD size = %dx%d\n", m->hdisplay, m->vdisplay);
+}
+
+static void samsung_dsim_set_display_enable(struct samsung_dsim *dsi, bool enable)
+{
+	u32 reg;
+
+	reg = samsung_dsim_read(dsi, DSIM_MDRESOL_REG);
+	if (enable)
+		reg |= DSIM_MAIN_STAND_BY;
+	else
+		reg &= ~DSIM_MAIN_STAND_BY;
+	samsung_dsim_write(dsi, DSIM_MDRESOL_REG, reg);
+}
+
+static int samsung_dsim_wait_for_hdr_fifo(struct samsung_dsim *dsi)
+{
+	int timeout = 2000;
+
+	do {
+		u32 reg = samsung_dsim_read(dsi, DSIM_FIFOCTRL_REG);
+
+		if (!(reg & DSIM_SFR_HEADER_FULL))
+			return 0;
+
+		if (!cond_resched())
+			usleep_range(950, 1050);
+	} while (--timeout);
+
+	return -ETIMEDOUT;
+}
+
+static void samsung_dsim_set_cmd_lpm(struct samsung_dsim *dsi, bool lpm)
+{
+	u32 v = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
+
+	if (lpm)
+		v |= DSIM_CMD_LPDT_LP;
+	else
+		v &= ~DSIM_CMD_LPDT_LP;
+
+	samsung_dsim_write(dsi, DSIM_ESCMODE_REG, v);
+}
+
+static void samsung_dsim_force_bta(struct samsung_dsim *dsi)
+{
+	u32 v = samsung_dsim_read(dsi, DSIM_ESCMODE_REG);
+
+	v |= DSIM_FORCE_BTA;
+	samsung_dsim_write(dsi, DSIM_ESCMODE_REG, v);
+}
+
+static void samsung_dsim_send_to_fifo(struct samsung_dsim *dsi,
+				      struct samsung_dsim_transfer *xfer)
+{
+	struct device *dev = dsi->dev;
+	struct mipi_dsi_packet *pkt = &xfer->packet;
+	const u8 *payload = pkt->payload + xfer->tx_done;
+	u16 length = pkt->payload_length - xfer->tx_done;
+	bool first = !xfer->tx_done;
+	u32 reg;
+
+	dev_dbg(dev, "< xfer %pK: tx len %u, done %u, rx len %u, done %u\n",
+		xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
+
+	if (length > DSI_TX_FIFO_SIZE)
+		length = DSI_TX_FIFO_SIZE;
+
+	xfer->tx_done += length;
+
+	/* Send payload */
+	while (length >= 4) {
+		reg = get_unaligned_le32(payload);
+		samsung_dsim_write(dsi, DSIM_PAYLOAD_REG, reg);
+		payload += 4;
+		length -= 4;
+	}
+
+	reg = 0;
+	switch (length) {
+	case 3:
+		reg |= payload[2] << 16;
+		fallthrough;
+	case 2:
+		reg |= payload[1] << 8;
+		fallthrough;
+	case 1:
+		reg |= payload[0];
+		samsung_dsim_write(dsi, DSIM_PAYLOAD_REG, reg);
+		break;
+	}
+
+	/* Send packet header */
+	if (!first)
+		return;
+
+	reg = get_unaligned_le32(pkt->header);
+	if (samsung_dsim_wait_for_hdr_fifo(dsi)) {
+		dev_err(dev, "waiting for header FIFO timed out\n");
+		return;
+	}
+
+	if (NEQV(xfer->flags & MIPI_DSI_MSG_USE_LPM,
+		 dsi->state & DSIM_STATE_CMD_LPM)) {
+		samsung_dsim_set_cmd_lpm(dsi, xfer->flags & MIPI_DSI_MSG_USE_LPM);
+		dsi->state ^= DSIM_STATE_CMD_LPM;
+	}
+
+	samsung_dsim_write(dsi, DSIM_PKTHDR_REG, reg);
+
+	if (xfer->flags & MIPI_DSI_MSG_REQ_ACK)
+		samsung_dsim_force_bta(dsi);
+}
+
+static void samsung_dsim_read_from_fifo(struct samsung_dsim *dsi,
+					struct samsung_dsim_transfer *xfer)
+{
+	u8 *payload = xfer->rx_payload + xfer->rx_done;
+	bool first = !xfer->rx_done;
+	struct device *dev = dsi->dev;
+	u16 length;
+	u32 reg;
+
+	if (first) {
+		reg = samsung_dsim_read(dsi, DSIM_RXFIFO_REG);
+
+		switch (reg & 0x3f) {
+		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
+		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
+			if (xfer->rx_len >= 2) {
+				payload[1] = reg >> 16;
+				++xfer->rx_done;
+			}
+			fallthrough;
+		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
+		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
+			payload[0] = reg >> 8;
+			++xfer->rx_done;
+			xfer->rx_len = xfer->rx_done;
+			xfer->result = 0;
+			goto clear_fifo;
+		case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
+			dev_err(dev, "DSI Error Report: 0x%04x\n", (reg >> 8) & 0xffff);
+			xfer->result = 0;
+			goto clear_fifo;
+		}
+
+		length = (reg >> 8) & 0xffff;
+		if (length > xfer->rx_len) {
+			dev_err(dev,
+				"response too long (%u > %u bytes), stripping\n",
+				xfer->rx_len, length);
+			length = xfer->rx_len;
+		} else if (length < xfer->rx_len)
+			xfer->rx_len = length;
+	}
+
+	length = xfer->rx_len - xfer->rx_done;
+	xfer->rx_done += length;
+
+	/* Receive payload */
+	while (length >= 4) {
+		reg = samsung_dsim_read(dsi, DSIM_RXFIFO_REG);
+		payload[0] = (reg >>  0) & 0xff;
+		payload[1] = (reg >>  8) & 0xff;
+		payload[2] = (reg >> 16) & 0xff;
+		payload[3] = (reg >> 24) & 0xff;
+		payload += 4;
+		length -= 4;
+	}
+
+	if (length) {
+		reg = samsung_dsim_read(dsi, DSIM_RXFIFO_REG);
+		switch (length) {
+		case 3:
+			payload[2] = (reg >> 16) & 0xff;
+			fallthrough;
+		case 2:
+			payload[1] = (reg >> 8) & 0xff;
+			fallthrough;
+		case 1:
+			payload[0] = reg & 0xff;
+		}
+	}
+
+	if (xfer->rx_done == xfer->rx_len)
+		xfer->result = 0;
+
+clear_fifo:
+	length = DSI_RX_FIFO_SIZE / 4;
+	do {
+		reg = samsung_dsim_read(dsi, DSIM_RXFIFO_REG);
+		if (reg == DSI_RX_FIFO_EMPTY)
+			break;
+	} while (--length);
+}
+
+static void samsung_dsim_transfer_start(struct samsung_dsim *dsi)
+{
+	unsigned long flags;
+	struct samsung_dsim_transfer *xfer;
+	bool start = false;
+
+again:
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	if (list_empty(&dsi->transfer_list)) {
+		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+		return;
+	}
+
+	xfer = list_first_entry(&dsi->transfer_list,
+				struct samsung_dsim_transfer, list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	if (xfer->packet.payload_length &&
+	    xfer->tx_done == xfer->packet.payload_length)
+		/* waiting for RX */
+		return;
+
+	samsung_dsim_send_to_fifo(dsi, xfer);
+
+	if (xfer->packet.payload_length || xfer->rx_len)
+		return;
+
+	xfer->result = 0;
+	complete(&xfer->completed);
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	list_del_init(&xfer->list);
+	start = !list_empty(&dsi->transfer_list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	if (start)
+		goto again;
+}
+
+static bool samsung_dsim_transfer_finish(struct samsung_dsim *dsi)
+{
+	struct samsung_dsim_transfer *xfer;
+	unsigned long flags;
+	bool start = true;
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	if (list_empty(&dsi->transfer_list)) {
+		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+		return false;
+	}
+
+	xfer = list_first_entry(&dsi->transfer_list,
+				struct samsung_dsim_transfer, list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	dev_dbg(dsi->dev,
+		"> xfer %pK, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
+		xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
+		xfer->rx_done);
+
+	if (xfer->tx_done != xfer->packet.payload_length)
+		return true;
+
+	if (xfer->rx_done != xfer->rx_len)
+		samsung_dsim_read_from_fifo(dsi, xfer);
+
+	if (xfer->rx_done != xfer->rx_len)
+		return true;
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	list_del_init(&xfer->list);
+	start = !list_empty(&dsi->transfer_list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	if (!xfer->rx_len)
+		xfer->result = 0;
+	complete(&xfer->completed);
+
+	return start;
+}
+
+static void samsung_dsim_remove_transfer(struct samsung_dsim *dsi,
+					 struct samsung_dsim_transfer *xfer)
+{
+	unsigned long flags;
+	bool start;
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	if (!list_empty(&dsi->transfer_list) &&
+	    xfer == list_first_entry(&dsi->transfer_list,
+				     struct samsung_dsim_transfer, list)) {
+		list_del_init(&xfer->list);
+		start = !list_empty(&dsi->transfer_list);
+		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+		if (start)
+			samsung_dsim_transfer_start(dsi);
+		return;
+	}
+
+	list_del_init(&xfer->list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+}
+
+static int samsung_dsim_transfer(struct samsung_dsim *dsi,
+				 struct samsung_dsim_transfer *xfer)
+{
+	unsigned long flags;
+	bool stopped;
+
+	xfer->tx_done = 0;
+	xfer->rx_done = 0;
+	xfer->result = -ETIMEDOUT;
+	init_completion(&xfer->completed);
+
+	spin_lock_irqsave(&dsi->transfer_lock, flags);
+
+	stopped = list_empty(&dsi->transfer_list);
+	list_add_tail(&xfer->list, &dsi->transfer_list);
+
+	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
+
+	if (stopped)
+		samsung_dsim_transfer_start(dsi);
+
+	wait_for_completion_timeout(&xfer->completed,
+				    msecs_to_jiffies(DSI_XFER_TIMEOUT_MS));
+	if (xfer->result == -ETIMEDOUT) {
+		struct mipi_dsi_packet *pkt = &xfer->packet;
+
+		samsung_dsim_remove_transfer(dsi, xfer);
+		dev_err(dsi->dev, "xfer timed out: %*ph %*ph\n", 4, pkt->header,
+			(int)pkt->payload_length, pkt->payload);
+		return -ETIMEDOUT;
+	}
+
+	/* Also covers hardware timeout condition */
+	return xfer->result;
+}
+
+static irqreturn_t samsung_dsim_irq(int irq, void *dev_id)
+{
+	struct samsung_dsim *dsi = dev_id;
+	u32 status;
+
+	status = samsung_dsim_read(dsi, DSIM_INTSRC_REG);
+	if (!status) {
+		static unsigned long j;
+
+		if (printk_timed_ratelimit(&j, 500))
+			dev_warn(dsi->dev, "spurious interrupt\n");
+		return IRQ_HANDLED;
+	}
+	samsung_dsim_write(dsi, DSIM_INTSRC_REG, status);
+
+	if (status & DSIM_INT_SW_RST_RELEASE) {
+		u32 mask = ~(DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
+			DSIM_INT_SFR_HDR_FIFO_EMPTY | DSIM_INT_RX_ECC_ERR |
+			DSIM_INT_SW_RST_RELEASE);
+		samsung_dsim_write(dsi, DSIM_INTMSK_REG, mask);
+		complete(&dsi->completed);
+		return IRQ_HANDLED;
+	}
+
+	if (!(status & (DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
+			DSIM_INT_PLL_STABLE)))
+		return IRQ_HANDLED;
+
+	if (samsung_dsim_transfer_finish(dsi))
+		samsung_dsim_transfer_start(dsi);
+
+	return IRQ_HANDLED;
+}
+
+static void samsung_dsim_enable_irq(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
+
+	enable_irq(dsi->irq);
+
+	if (pdata->irq_ops && pdata->irq_ops->enable)
+		pdata->irq_ops->enable(dsi);
+}
+
+static void samsung_dsim_disable_irq(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
+
+	if (pdata->irq_ops && pdata->irq_ops->disable)
+		pdata->irq_ops->disable(dsi);
+
+	disable_irq(dsi->irq);
+}
+
+static int samsung_dsim_init(struct samsung_dsim *dsi)
+{
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+
+	if (dsi->state & DSIM_STATE_INITIALIZED)
+		return 0;
+
+	samsung_dsim_reset(dsi);
+	samsung_dsim_enable_irq(dsi);
+
+	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
+		samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
+
+	samsung_dsim_enable_clock(dsi);
+	if (driver_data->wait_for_reset)
+		samsung_dsim_wait_for_reset(dsi);
+	samsung_dsim_set_phy_ctrl(dsi);
+	samsung_dsim_init_link(dsi);
+
+	dsi->state |= DSIM_STATE_INITIALIZED;
+
+	return 0;
+}
+
+static void samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
+					   struct drm_bridge_state *old_bridge_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+	int ret;
+
+	if (dsi->state & DSIM_STATE_ENABLED)
+		return;
+
+	ret = pm_runtime_resume_and_get(dsi->dev);
+	if (ret < 0) {
+		dev_err(dsi->dev, "failed to enable DSI device.\n");
+		return;
+	}
+
+	dsi->state |= DSIM_STATE_ENABLED;
+
+	/*
+	 * For Exynos-DSIM the downstream bridge, or panel are expecting
+	 * the host initialization during DSI transfer.
+	 */
+	if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type)) {
+		ret = samsung_dsim_init(dsi);
+		if (ret)
+			return;
+	}
+}
+
+static void samsung_dsim_atomic_enable(struct drm_bridge *bridge,
+				       struct drm_bridge_state *old_bridge_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+
+	samsung_dsim_set_display_mode(dsi);
+	samsung_dsim_set_display_enable(dsi, true);
+
+	dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
+}
+
+static void samsung_dsim_atomic_disable(struct drm_bridge *bridge,
+					struct drm_bridge_state *old_bridge_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+
+	if (!(dsi->state & DSIM_STATE_ENABLED))
+		return;
+
+	dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
+}
+
+static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
+					     struct drm_bridge_state *old_bridge_state)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+
+	samsung_dsim_set_display_enable(dsi, false);
+
+	dsi->state &= ~DSIM_STATE_ENABLED;
+	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 samsung_dsim_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,
+
+	MEDIA_BUS_FMT_FIXED,
+};
+
+static bool samsung_dsim_pixel_output_fmt_supported(u32 fmt)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(samsung_dsim_pixel_output_fmts); i++) {
+		if (samsung_dsim_pixel_output_fmts[i] == fmt)
+			return true;
+	}
+
+	return false;
+}
+
+static u32 *
+samsung_dsim_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;
+
+	if (!samsung_dsim_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 = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	switch (output_fmt) {
+	case MEDIA_BUS_FMT_FIXED:
+		input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+		break;
+	default:
+		input_fmts[0] = output_fmt;
+		break;
+	}
+
+	*num_input_fmts = 1;
+
+	return input_fmts;
+}
+
+static int samsung_dsim_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 samsung_dsim *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 samsung_dsim_mode_set(struct drm_bridge *bridge,
+				  const struct drm_display_mode *mode,
+				  const struct drm_display_mode *adjusted_mode)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+
+	drm_mode_copy(&dsi->mode, adjusted_mode);
+}
+
+static int samsung_dsim_attach(struct drm_bridge *bridge,
+			       enum drm_bridge_attach_flags flags)
+{
+	struct samsung_dsim *dsi = bridge_to_dsi(bridge);
+
+	return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge,
+				 flags);
+}
+
+static const struct drm_bridge_funcs samsung_dsim_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	= samsung_dsim_atomic_get_input_bus_fmts,
+	.atomic_check			= samsung_dsim_atomic_check,
+	.atomic_pre_enable		= samsung_dsim_atomic_pre_enable,
+	.atomic_enable			= samsung_dsim_atomic_enable,
+	.atomic_disable			= samsung_dsim_atomic_disable,
+	.atomic_post_disable		= samsung_dsim_atomic_post_disable,
+	.mode_set			= samsung_dsim_mode_set,
+	.attach				= samsung_dsim_attach,
+};
+
+static int samsung_dsim_host_attach(struct mipi_dsi_host *host,
+				    struct mipi_dsi_device *device)
+{
+	struct samsung_dsim *dsi = host_to_dsi(host);
+	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
+	struct device *dev = dsi->dev;
+	int ret;
+
+	dsi->out_bridge = devm_drm_of_dsi_get_bridge(dev, dev->of_node, 1, 0);
+	if (IS_ERR(dsi->out_bridge)) {
+		ret = PTR_ERR(dsi->out_bridge);
+		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
+		return ret;
+	}
+
+	DRM_DEV_INFO(dev, "Attached %s device\n", device->name);
+
+	drm_bridge_add(&dsi->bridge);
+
+	if (pdata->host_ops && pdata->host_ops->attach) {
+		ret = pdata->host_ops->attach(dsi, device);
+		if (ret < 0)
+			return ret;
+	}
+
+	dsi->lanes = device->lanes;
+	dsi->format = device->format;
+	dsi->mode_flags = device->mode_flags;
+
+	return 0;
+}
+
+static int samsung_dsim_host_detach(struct mipi_dsi_host *host,
+				    struct mipi_dsi_device *device)
+{
+	struct samsung_dsim *dsi = host_to_dsi(host);
+	const struct samsung_dsim_plat_data *pdata = dsi->plat_data;
+	int ret;
+
+	if (dsi->out_bridge->funcs->detach)
+		dsi->out_bridge->funcs->detach(dsi->out_bridge);
+
+	dsi->out_bridge = NULL;
+
+	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);
+
+	return 0;
+}
+
+static ssize_t samsung_dsim_host_transfer(struct mipi_dsi_host *host,
+					  const struct mipi_dsi_msg *msg)
+{
+	struct samsung_dsim *dsi = host_to_dsi(host);
+	struct samsung_dsim_transfer xfer;
+	int ret;
+
+	if (!(dsi->state & DSIM_STATE_ENABLED))
+		return -EINVAL;
+
+	ret = samsung_dsim_init(dsi);
+	if (ret)
+		return ret;
+
+	ret = mipi_dsi_create_packet(&xfer.packet, msg);
+	if (ret < 0)
+		return ret;
+
+	xfer.rx_len = msg->rx_len;
+	xfer.rx_payload = msg->rx_buf;
+	xfer.flags = msg->flags;
+
+	ret = samsung_dsim_transfer(dsi, &xfer);
+	return (ret < 0) ? ret : xfer.rx_done;
+}
+
+static const struct mipi_dsi_host_ops samsung_dsim_ops = {
+	.attach = samsung_dsim_host_attach,
+	.detach = samsung_dsim_host_detach,
+	.transfer = samsung_dsim_host_transfer,
+};
+
+static int samsung_dsim_of_read_u32(const struct device_node *np,
+				    const char *propname, u32 *out_value)
+{
+	int ret = of_property_read_u32(np, propname, out_value);
+
+	if (ret < 0)
+		pr_err("%pOF: failed to get '%s' property\n", np, propname);
+
+	return ret;
+}
+
+static int samsung_dsim_parse_dt(struct samsung_dsim *dsi)
+{
+	struct device *dev = dsi->dev;
+	struct device_node *node = dev->of_node;
+	int ret;
+
+	ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
+				       &dsi->pll_clk_rate);
+	if (ret < 0)
+		return ret;
+
+	ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
+				       &dsi->burst_clk_rate);
+	if (ret < 0)
+		return ret;
+
+	ret = samsung_dsim_of_read_u32(node, "samsung,esc-clock-frequency",
+				       &dsi->esc_clk_rate);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+static int generic_dsim_register_host(struct samsung_dsim *dsi)
+{
+	return mipi_dsi_host_register(&dsi->dsi_host);
+}
+
+static void generic_dsim_unregister_host(struct samsung_dsim *dsi)
+{
+	mipi_dsi_host_unregister(&dsi->dsi_host);
+}
+
+static const struct samsung_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 samsung_dsim_bridge_timings_de_low = {
+	.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
+};
+
+int samsung_dsim_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct samsung_dsim *dsi;
+	int ret, i;
+
+	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
+	if (!dsi)
+		return -ENOMEM;
+
+	init_completion(&dsi->completed);
+	spin_lock_init(&dsi->transfer_lock);
+	INIT_LIST_HEAD(&dsi->transfer_list);
+
+	dsi->dsi_host.ops = &samsung_dsim_ops;
+	dsi->dsi_host.dev = dev;
+
+	dsi->dev = dev;
+	dsi->plat_data = of_device_get_match_data(dev);
+	dsi->driver_data = samsung_dsim_types[dsi->plat_data->hw_type];
+
+	dsi->supplies[0].supply = "vddcore";
+	dsi->supplies[1].supply = "vddio";
+	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
+				      dsi->supplies);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to get regulators\n");
+
+	dsi->clks = devm_kcalloc(dev, dsi->driver_data->num_clks,
+				 sizeof(*dsi->clks), GFP_KERNEL);
+	if (!dsi->clks)
+		return -ENOMEM;
+
+	for (i = 0; i < dsi->driver_data->num_clks; i++) {
+		dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
+		if (IS_ERR(dsi->clks[i])) {
+			if (strcmp(clk_names[i], "sclk_mipi") == 0) {
+				dsi->clks[i] = devm_clk_get(dev, OLD_SCLK_MIPI_CLK_NAME);
+				if (!IS_ERR(dsi->clks[i]))
+					continue;
+			}
+
+			dev_info(dev, "failed to get the clock: %s\n", clk_names[i]);
+			return PTR_ERR(dsi->clks[i]);
+		}
+	}
+
+	dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(dsi->reg_base))
+		return PTR_ERR(dsi->reg_base);
+
+	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);
+	}
+
+	dsi->irq = platform_get_irq(pdev, 0);
+	if (dsi->irq < 0)
+		return dsi->irq;
+
+	ret = devm_request_threaded_irq(dev, dsi->irq, NULL,
+					samsung_dsim_irq,
+					IRQF_ONESHOT | IRQF_NO_AUTOEN,
+					dev_name(dev), dsi);
+	if (ret) {
+		dev_err(dev, "failed to request dsi irq\n");
+		return ret;
+	}
+
+	ret = samsung_dsim_parse_dt(dsi);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, dsi);
+
+	pm_runtime_enable(dev);
+
+	dsi->bridge.funcs = &samsung_dsim_bridge_funcs;
+	dsi->bridge.of_node = dev->of_node;
+	dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
+
+	/* 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;
+
+	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;
+
+	return 0;
+
+err_disable_runtime:
+	pm_runtime_disable(dev);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(samsung_dsim_probe);
+
+int samsung_dsim_remove(struct platform_device *pdev)
+{
+	struct samsung_dsim *dsi = platform_get_drvdata(pdev);
+
+	pm_runtime_disable(&pdev->dev);
+
+	if (dsi->plat_data->host_ops && dsi->plat_data->host_ops->unregister_host)
+		dsi->plat_data->host_ops->unregister_host(dsi);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(samsung_dsim_remove);
+
+static int __maybe_unused samsung_dsim_suspend(struct device *dev)
+{
+	struct samsung_dsim *dsi = dev_get_drvdata(dev);
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	int ret, i;
+
+	usleep_range(10000, 20000);
+
+	if (dsi->state & DSIM_STATE_INITIALIZED) {
+		dsi->state &= ~DSIM_STATE_INITIALIZED;
+
+		samsung_dsim_disable_clock(dsi);
+
+		samsung_dsim_disable_irq(dsi);
+	}
+
+	dsi->state &= ~DSIM_STATE_CMD_LPM;
+
+	phy_power_off(dsi->phy);
+
+	for (i = driver_data->num_clks - 1; i > -1; i--)
+		clk_disable_unprepare(dsi->clks[i]);
+
+	ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
+	if (ret < 0)
+		dev_err(dsi->dev, "cannot disable regulators %d\n", ret);
+
+	return 0;
+}
+
+static int __maybe_unused samsung_dsim_resume(struct device *dev)
+{
+	struct samsung_dsim *dsi = dev_get_drvdata(dev);
+	const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
+	int ret, i;
+
+	ret = regulator_bulk_enable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
+	if (ret < 0) {
+		dev_err(dsi->dev, "cannot enable regulators %d\n", ret);
+		return ret;
+	}
+
+	for (i = 0; i < driver_data->num_clks; i++) {
+		ret = clk_prepare_enable(dsi->clks[i]);
+		if (ret < 0)
+			goto err_clk;
+	}
+
+	ret = phy_power_on(dsi->phy);
+	if (ret < 0) {
+		dev_err(dsi->dev, "cannot enable phy %d\n", ret);
+		goto err_clk;
+	}
+
+	return 0;
+
+err_clk:
+	while (--i > -1)
+		clk_disable_unprepare(dsi->clks[i]);
+	regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
+
+	return ret;
+}
+
+const struct dev_pm_ops samsung_dsim_pm_ops = {
+	SET_RUNTIME_PM_OPS(samsung_dsim_suspend, samsung_dsim_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+};
+EXPORT_SYMBOL_GPL(samsung_dsim_pm_ops);
+
+static const struct of_device_id samsung_dsim_of_match[] = {
+	{ /* sentinel. */ }
+};
+MODULE_DEVICE_TABLE(of, samsung_dsim_of_match);
+
+static struct platform_driver samsung_dsim_driver = {
+	.probe = samsung_dsim_probe,
+	.remove = samsung_dsim_remove,
+	.driver = {
+		   .name = "samsung-dsim",
+		   .owner = THIS_MODULE,
+		   .pm = &samsung_dsim_pm_ops,
+		   .of_match_table = samsung_dsim_of_match,
+	},
+};
+
+module_platform_driver(samsung_dsim_driver);
+
+MODULE_AUTHOR("Jagan Teki <jagan@amarulasolutions.com>");
+MODULE_DESCRIPTION("Samsung MIPI DSIM controller bridge");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 3d2f025d4fd4..a65acfed15b9 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -59,6 +59,7 @@ config DRM_EXYNOS_DSI
 	depends on DRM_EXYNOS_FIMD || DRM_EXYNOS5433_DECON || DRM_EXYNOS7_DECON
 	select DRM_MIPI_DSI
 	select DRM_PANEL
+	select DRM_SAMSUNG_DSIM
 	default n
 	help
 	  This enables support for Exynos MIPI-DSI device.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 580e06595b37..47a1592ba46b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1,1436 +1,76 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * Samsung SoC MIPI DSI Master driver.
+ * Samsung MIPI DSIM glue for Exynos SoCs.
  *
  * Copyright (c) 2014 Samsung Electronics Co., Ltd
  *
  * Contacts: Tomasz Figa <t.figa@samsung.com>
-*/
+ */
 
-#include <linux/clk.h>
-#include <linux/delay.h>
 #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>
-#include <linux/regulator/consumer.h>
-
-#include <asm/unaligned.h>
-
-#include <video/mipi_display.h>
-#include <video/videomode.h>
-
-#include <drm/drm_atomic_helper.h>
-#include <drm/drm_bridge.h>
-#include <drm/drm_mipi_dsi.h>
-#include <drm/drm_panel.h>
-#include <drm/drm_print.h>
-#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
-
-#include "exynos_drm_crtc.h"
-#include "exynos_drm_drv.h"
-
-/* returns true iff both arguments logically differs */
-#define NEQV(a, b) (!(a) ^ !(b))
-
-/* DSIM_STATUS */
-#define DSIM_STOP_STATE_DAT(x)		(((x) & 0xf) << 0)
-#define DSIM_STOP_STATE_CLK		(1 << 8)
-#define DSIM_TX_READY_HS_CLK		(1 << 10)
-#define DSIM_PLL_STABLE			(1 << 31)
-
-/* DSIM_SWRST */
-#define DSIM_FUNCRST			(1 << 16)
-#define DSIM_SWRST			(1 << 0)
-
-/* DSIM_TIMEOUT */
-#define DSIM_LPDR_TIMEOUT(x)		((x) << 0)
-#define DSIM_BTA_TIMEOUT(x)		((x) << 16)
-
-/* DSIM_CLKCTRL */
-#define DSIM_ESC_PRESCALER(x)		(((x) & 0xffff) << 0)
-#define DSIM_ESC_PRESCALER_MASK		(0xffff << 0)
-#define DSIM_LANE_ESC_CLK_EN_CLK	(1 << 19)
-#define DSIM_LANE_ESC_CLK_EN_DATA(x)	(((x) & 0xf) << 20)
-#define DSIM_LANE_ESC_CLK_EN_DATA_MASK	(0xf << 20)
-#define DSIM_BYTE_CLKEN			(1 << 24)
-#define DSIM_BYTE_CLK_SRC(x)		(((x) & 0x3) << 25)
-#define DSIM_BYTE_CLK_SRC_MASK		(0x3 << 25)
-#define DSIM_PLL_BYPASS			(1 << 27)
-#define DSIM_ESC_CLKEN			(1 << 28)
-#define DSIM_TX_REQUEST_HSCLK		(1 << 31)
-
-/* DSIM_CONFIG */
-#define DSIM_LANE_EN_CLK		(1 << 0)
-#define DSIM_LANE_EN(x)			(((x) & 0xf) << 1)
-#define DSIM_NUM_OF_DATA_LANE(x)	(((x) & 0x3) << 5)
-#define DSIM_SUB_PIX_FORMAT(x)		(((x) & 0x7) << 8)
-#define DSIM_MAIN_PIX_FORMAT_MASK	(0x7 << 12)
-#define DSIM_MAIN_PIX_FORMAT_RGB888	(0x7 << 12)
-#define DSIM_MAIN_PIX_FORMAT_RGB666	(0x6 << 12)
-#define DSIM_MAIN_PIX_FORMAT_RGB666_P	(0x5 << 12)
-#define DSIM_MAIN_PIX_FORMAT_RGB565	(0x4 << 12)
-#define DSIM_SUB_VC			(((x) & 0x3) << 16)
-#define DSIM_MAIN_VC			(((x) & 0x3) << 18)
-#define DSIM_HSA_DISABLE_MODE		(1 << 20)
-#define DSIM_HBP_DISABLE_MODE		(1 << 21)
-#define DSIM_HFP_DISABLE_MODE		(1 << 22)
-/*
- * The i.MX 8M Mini Applications Processor Reference Manual,
- * Rev. 3, 11/2020 Page 4091
- * The i.MX 8M Nano Applications Processor Reference Manual,
- * Rev. 2, 07/2022 Page 3058
- * The i.MX 8M Plus Applications Processor Reference Manual,
- * Rev. 1, 06/2021 Page 5436
- * named this bit as 'HseDisableMode' but the bit definition
- * is quite opposite like
- * 0 = Disables transfer
- * 1 = Enables transfer
- * which clearly states that HSE is not a disable bit.
- *
- * This bit is named as per the manual even though it is not
- * a disable bit however the driver logic for handling HSE
- * is based on the MIPI_DSI_MODE_VIDEO_HSE flag itself.
- */
-#define DSIM_HSE_DISABLE_MODE		(1 << 23)
-#define DSIM_AUTO_MODE			(1 << 24)
-#define DSIM_VIDEO_MODE			(1 << 25)
-#define DSIM_BURST_MODE			(1 << 26)
-#define DSIM_SYNC_INFORM		(1 << 27)
-#define DSIM_EOT_DISABLE		(1 << 28)
-#define DSIM_MFLUSH_VS			(1 << 29)
-/* This flag is valid only for exynos3250/3472/5260/5430 */
-#define DSIM_CLKLANE_STOP		(1 << 30)
-
-/* DSIM_ESCMODE */
-#define DSIM_TX_TRIGGER_RST		(1 << 4)
-#define DSIM_TX_LPDT_LP			(1 << 6)
-#define DSIM_CMD_LPDT_LP		(1 << 7)
-#define DSIM_FORCE_BTA			(1 << 16)
-#define DSIM_FORCE_STOP_STATE		(1 << 20)
-#define DSIM_STOP_STATE_CNT(x)		(((x) & 0x7ff) << 21)
-#define DSIM_STOP_STATE_CNT_MASK	(0x7ff << 21)
-
-/* DSIM_MDRESOL */
-#define DSIM_MAIN_STAND_BY		(1 << 31)
-#define DSIM_MAIN_VRESOL(x, num_bits)	(((x) & ((1 << (num_bits)) - 1)) << 16)
-#define DSIM_MAIN_HRESOL(x, num_bits)	(((x) & ((1 << (num_bits)) - 1)) << 0)
-
-/* DSIM_MVPORCH */
-#define DSIM_CMD_ALLOW(x)		((x) << 28)
-#define DSIM_STABLE_VFP(x)		((x) << 16)
-#define DSIM_MAIN_VBP(x)		((x) << 0)
-#define DSIM_CMD_ALLOW_MASK		(0xf << 28)
-#define DSIM_STABLE_VFP_MASK		(0x7ff << 16)
-#define DSIM_MAIN_VBP_MASK		(0x7ff << 0)
-
-/* DSIM_MHPORCH */
-#define DSIM_MAIN_HFP(x)		((x) << 16)
-#define DSIM_MAIN_HBP(x)		((x) << 0)
-#define DSIM_MAIN_HFP_MASK		((0xffff) << 16)
-#define DSIM_MAIN_HBP_MASK		((0xffff) << 0)
-
-/* DSIM_MSYNC */
-#define DSIM_MAIN_VSA(x)		((x) << 22)
-#define DSIM_MAIN_HSA(x)		((x) << 0)
-#define DSIM_MAIN_VSA_MASK		((0x3ff) << 22)
-#define DSIM_MAIN_HSA_MASK		((0xffff) << 0)
-
-/* DSIM_SDRESOL */
-#define DSIM_SUB_STANDY(x)		((x) << 31)
-#define DSIM_SUB_VRESOL(x)		((x) << 16)
-#define DSIM_SUB_HRESOL(x)		((x) << 0)
-#define DSIM_SUB_STANDY_MASK		((0x1) << 31)
-#define DSIM_SUB_VRESOL_MASK		((0x7ff) << 16)
-#define DSIM_SUB_HRESOL_MASK		((0x7ff) << 0)
-
-/* DSIM_INTSRC */
-#define DSIM_INT_PLL_STABLE		(1 << 31)
-#define DSIM_INT_SW_RST_RELEASE		(1 << 30)
-#define DSIM_INT_SFR_FIFO_EMPTY		(1 << 29)
-#define DSIM_INT_SFR_HDR_FIFO_EMPTY	(1 << 28)
-#define DSIM_INT_BTA			(1 << 25)
-#define DSIM_INT_FRAME_DONE		(1 << 24)
-#define DSIM_INT_RX_TIMEOUT		(1 << 21)
-#define DSIM_INT_BTA_TIMEOUT		(1 << 20)
-#define DSIM_INT_RX_DONE		(1 << 18)
-#define DSIM_INT_RX_TE			(1 << 17)
-#define DSIM_INT_RX_ACK			(1 << 16)
-#define DSIM_INT_RX_ECC_ERR		(1 << 15)
-#define DSIM_INT_RX_CRC_ERR		(1 << 14)
-
-/* DSIM_FIFOCTRL */
-#define DSIM_RX_DATA_FULL		(1 << 25)
-#define DSIM_RX_DATA_EMPTY		(1 << 24)
-#define DSIM_SFR_HEADER_FULL		(1 << 23)
-#define DSIM_SFR_HEADER_EMPTY		(1 << 22)
-#define DSIM_SFR_PAYLOAD_FULL		(1 << 21)
-#define DSIM_SFR_PAYLOAD_EMPTY		(1 << 20)
-#define DSIM_I80_HEADER_FULL		(1 << 19)
-#define DSIM_I80_HEADER_EMPTY		(1 << 18)
-#define DSIM_I80_PAYLOAD_FULL		(1 << 17)
-#define DSIM_I80_PAYLOAD_EMPTY		(1 << 16)
-#define DSIM_SD_HEADER_FULL		(1 << 15)
-#define DSIM_SD_HEADER_EMPTY		(1 << 14)
-#define DSIM_SD_PAYLOAD_FULL		(1 << 13)
-#define DSIM_SD_PAYLOAD_EMPTY		(1 << 12)
-#define DSIM_MD_HEADER_FULL		(1 << 11)
-#define DSIM_MD_HEADER_EMPTY		(1 << 10)
-#define DSIM_MD_PAYLOAD_FULL		(1 << 9)
-#define DSIM_MD_PAYLOAD_EMPTY		(1 << 8)
-#define DSIM_RX_FIFO			(1 << 4)
-#define DSIM_SFR_FIFO			(1 << 3)
-#define DSIM_I80_FIFO			(1 << 2)
-#define DSIM_SD_FIFO			(1 << 1)
-#define DSIM_MD_FIFO			(1 << 0)
-
-/* DSIM_PHYACCHR */
-#define DSIM_AFC_EN			(1 << 14)
-#define DSIM_AFC_CTL(x)			(((x) & 0x7) << 5)
-
-/* DSIM_PLLCTRL */
-#define DSIM_FREQ_BAND(x)		((x) << 24)
-#define DSIM_PLL_EN			(1 << 23)
-#define DSIM_PLL_P(x, offset)		((x) << (offset))
-#define DSIM_PLL_M(x)			((x) << 4)
-#define DSIM_PLL_S(x)			((x) << 1)
-
-/* DSIM_PHYCTRL */
-#define DSIM_PHYCTRL_ULPS_EXIT(x)	(((x) & 0x1ff) << 0)
-#define DSIM_PHYCTRL_B_DPHYCTL_VREG_LP	(1 << 30)
-#define DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP	(1 << 14)
-
-/* DSIM_PHYTIMING */
-#define DSIM_PHYTIMING_LPX(x)		((x) << 8)
-#define DSIM_PHYTIMING_HS_EXIT(x)	((x) << 0)
-
-/* DSIM_PHYTIMING1 */
-#define DSIM_PHYTIMING1_CLK_PREPARE(x)	((x) << 24)
-#define DSIM_PHYTIMING1_CLK_ZERO(x)	((x) << 16)
-#define DSIM_PHYTIMING1_CLK_POST(x)	((x) << 8)
-#define DSIM_PHYTIMING1_CLK_TRAIL(x)	((x) << 0)
-
-/* DSIM_PHYTIMING2 */
-#define DSIM_PHYTIMING2_HS_PREPARE(x)	((x) << 16)
-#define DSIM_PHYTIMING2_HS_ZERO(x)	((x) << 8)
-#define DSIM_PHYTIMING2_HS_TRAIL(x)	((x) << 0)
-
-#define DSI_MAX_BUS_WIDTH		4
-#define DSI_NUM_VIRTUAL_CHANNELS	4
-#define DSI_TX_FIFO_SIZE		2048
-#define DSI_RX_FIFO_SIZE		256
-#define DSI_XFER_TIMEOUT_MS		100
-#define DSI_RX_FIFO_EMPTY		0x30800002
-
-#define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
-
-static const char *const clk_names[5] = { "bus_clk", "sclk_mipi",
-	"phyclk_mipidphy0_bitclkdiv8", "phyclk_mipidphy0_rxclkesc0",
-	"sclk_rgb_vclk_to_dsim0" };
-
-enum exynos_dsi_transfer_type {
-	EXYNOS_DSI_TX,
-	EXYNOS_DSI_RX,
-};
-
-struct exynos_dsi_transfer {
-	struct list_head list;
-	struct completion completed;
-	int result;
-	struct mipi_dsi_packet packet;
-	u16 flags;
-	u16 tx_done;
-
-	u8 *rx_payload;
-	u16 rx_len;
-	u16 rx_done;
-};
-
-struct exynos_dsi;
-
-#define DSIM_STATE_ENABLED		BIT(0)
-#define DSIM_STATE_INITIALIZED		BIT(1)
-#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,
-	DSIM_TYPE_EXYNOS5410,
-	DSIM_TYPE_EXYNOS5422,
-	DSIM_TYPE_EXYNOS5433,
-	DSIM_TYPE_IMX8MM,
-
-	DSIM_TYPE_COUNT,
-};
-
-struct exynos_dsi_driver_data {
-	const unsigned int *reg_ofs;
-	unsigned int plltmr_reg;
-	unsigned int has_freqband:1;
-	unsigned int has_clklane_stop:1;
-	unsigned int num_clks;
-	unsigned int max_freq;
-	unsigned int wait_for_reset;
-	unsigned int num_bits_resol;
-	unsigned int pll_p_offset;
-	const unsigned int *reg_values;
-};
-
-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_dsim_irq_ops {
-	void (*enable)(struct exynos_dsi *dsim);
-	void (*disable)(struct exynos_dsi *dsim);
-};
-
-struct exynos_dsi_plat_data {
-	enum exynos_dsi_type hw_type;
-	const struct exynos_dsim_host_ops *host_ops;
-	const struct exynos_dsim_irq_ops *irq_ops;
-};
-
-struct exynos_dsi {
-	struct mipi_dsi_host dsi_host;
-	struct drm_bridge bridge;
-	struct drm_bridge *out_bridge;
-	struct device *dev;
-	struct drm_display_mode mode;
-
-	void __iomem *reg_base;
-	struct phy *phy;
-	struct clk **clks;
-	struct regulator_bulk_data supplies[2];
-	int irq;
-
-	u32 pll_clk_rate;
-	u32 burst_clk_rate;
-	u32 esc_clk_rate;
-	u32 lanes;
-	u32 mode_flags;
-	u32 format;
-
-	int state;
-	struct drm_property *brightness;
-	struct completion completed;
-
-	spinlock_t transfer_lock; /* protects transfer_list */
-	struct list_head transfer_list;
-
-	const struct exynos_dsi_driver_data *driver_data;
-	const struct exynos_dsi_plat_data *plat_data;
-
-	void *priv;
-};
-
-struct exynos_dsi_enc {
-	struct drm_encoder encoder;
-	struct gpio_desc *te_gpio;
-};
-
-#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
-
-static inline struct exynos_dsi *bridge_to_dsi(struct drm_bridge *b)
-{
-	return container_of(b, struct exynos_dsi, bridge);
-}
-
-enum reg_idx {
-	DSIM_STATUS_REG,	/* Status register */
-	DSIM_SWRST_REG,		/* Software reset register */
-	DSIM_CLKCTRL_REG,	/* Clock control register */
-	DSIM_TIMEOUT_REG,	/* Time out register */
-	DSIM_CONFIG_REG,	/* Configuration register */
-	DSIM_ESCMODE_REG,	/* Escape mode register */
-	DSIM_MDRESOL_REG,
-	DSIM_MVPORCH_REG,	/* Main display Vporch register */
-	DSIM_MHPORCH_REG,	/* Main display Hporch register */
-	DSIM_MSYNC_REG,		/* Main display sync area register */
-	DSIM_INTSRC_REG,	/* Interrupt source register */
-	DSIM_INTMSK_REG,	/* Interrupt mask register */
-	DSIM_PKTHDR_REG,	/* Packet Header FIFO register */
-	DSIM_PAYLOAD_REG,	/* Payload FIFO register */
-	DSIM_RXFIFO_REG,	/* Read FIFO register */
-	DSIM_FIFOCTRL_REG,	/* FIFO status and control register */
-	DSIM_PLLCTRL_REG,	/* PLL control register */
-	DSIM_PHYCTRL_REG,
-	DSIM_PHYTIMING_REG,
-	DSIM_PHYTIMING1_REG,
-	DSIM_PHYTIMING2_REG,
-	NUM_REGS
-};
-
-static inline void exynos_dsi_write(struct exynos_dsi *dsi, enum reg_idx idx,
-				    u32 val)
-{
-
-	writel(val, dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
-}
-
-static inline u32 exynos_dsi_read(struct exynos_dsi *dsi, enum reg_idx idx)
-{
-	return readl(dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
-}
-
-static const unsigned int exynos_reg_ofs[] = {
-	[DSIM_STATUS_REG] =  0x00,
-	[DSIM_SWRST_REG] =  0x04,
-	[DSIM_CLKCTRL_REG] =  0x08,
-	[DSIM_TIMEOUT_REG] =  0x0c,
-	[DSIM_CONFIG_REG] =  0x10,
-	[DSIM_ESCMODE_REG] =  0x14,
-	[DSIM_MDRESOL_REG] =  0x18,
-	[DSIM_MVPORCH_REG] =  0x1c,
-	[DSIM_MHPORCH_REG] =  0x20,
-	[DSIM_MSYNC_REG] =  0x24,
-	[DSIM_INTSRC_REG] =  0x2c,
-	[DSIM_INTMSK_REG] =  0x30,
-	[DSIM_PKTHDR_REG] =  0x34,
-	[DSIM_PAYLOAD_REG] =  0x38,
-	[DSIM_RXFIFO_REG] =  0x3c,
-	[DSIM_FIFOCTRL_REG] =  0x44,
-	[DSIM_PLLCTRL_REG] =  0x4c,
-	[DSIM_PHYCTRL_REG] =  0x5c,
-	[DSIM_PHYTIMING_REG] =  0x64,
-	[DSIM_PHYTIMING1_REG] =  0x68,
-	[DSIM_PHYTIMING2_REG] =  0x6c,
-};
-
-static const unsigned int exynos5433_reg_ofs[] = {
-	[DSIM_STATUS_REG] = 0x04,
-	[DSIM_SWRST_REG] = 0x0C,
-	[DSIM_CLKCTRL_REG] = 0x10,
-	[DSIM_TIMEOUT_REG] = 0x14,
-	[DSIM_CONFIG_REG] = 0x18,
-	[DSIM_ESCMODE_REG] = 0x1C,
-	[DSIM_MDRESOL_REG] = 0x20,
-	[DSIM_MVPORCH_REG] = 0x24,
-	[DSIM_MHPORCH_REG] = 0x28,
-	[DSIM_MSYNC_REG] = 0x2C,
-	[DSIM_INTSRC_REG] = 0x34,
-	[DSIM_INTMSK_REG] = 0x38,
-	[DSIM_PKTHDR_REG] = 0x3C,
-	[DSIM_PAYLOAD_REG] = 0x40,
-	[DSIM_RXFIFO_REG] = 0x44,
-	[DSIM_FIFOCTRL_REG] = 0x4C,
-	[DSIM_PLLCTRL_REG] = 0x94,
-	[DSIM_PHYCTRL_REG] = 0xA4,
-	[DSIM_PHYTIMING_REG] = 0xB4,
-	[DSIM_PHYTIMING1_REG] = 0xB8,
-	[DSIM_PHYTIMING2_REG] = 0xBC,
-};
-
-enum reg_value_idx {
-	RESET_TYPE,
-	PLL_TIMER,
-	STOP_STATE_CNT,
-	PHYCTRL_ULPS_EXIT,
-	PHYCTRL_VREG_LP,
-	PHYCTRL_SLEW_UP,
-	PHYTIMING_LPX,
-	PHYTIMING_HS_EXIT,
-	PHYTIMING_CLK_PREPARE,
-	PHYTIMING_CLK_ZERO,
-	PHYTIMING_CLK_POST,
-	PHYTIMING_CLK_TRAIL,
-	PHYTIMING_HS_PREPARE,
-	PHYTIMING_HS_ZERO,
-	PHYTIMING_HS_TRAIL
-};
-
-static const unsigned int reg_values[] = {
-	[RESET_TYPE] = DSIM_SWRST,
-	[PLL_TIMER] = 500,
-	[STOP_STATE_CNT] = 0xf,
-	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x0af),
-	[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(0x27),
-	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0d),
-	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x08),
-	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x09),
-	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x0d),
-	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0b),
-};
-
-static const unsigned int exynos5422_reg_values[] = {
-	[RESET_TYPE] = DSIM_SWRST,
-	[PLL_TIMER] = 500,
-	[STOP_STATE_CNT] = 0xf,
-	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0xaf),
-	[PHYCTRL_VREG_LP] = 0,
-	[PHYCTRL_SLEW_UP] = 0,
-	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x08),
-	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0d),
-	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
-	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x30),
-	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
-	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x0a),
-	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0c),
-	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x11),
-	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0d),
-};
-
-static const unsigned int exynos5433_reg_values[] = {
-	[RESET_TYPE] = DSIM_FUNCRST,
-	[PLL_TIMER] = 22200,
-	[STOP_STATE_CNT] = 0xa,
-	[PHYCTRL_ULPS_EXIT] = DSIM_PHYCTRL_ULPS_EXIT(0x190),
-	[PHYCTRL_VREG_LP] = DSIM_PHYCTRL_B_DPHYCTL_VREG_LP,
-	[PHYCTRL_SLEW_UP] = DSIM_PHYCTRL_B_DPHYCTL_SLEW_UP,
-	[PHYTIMING_LPX] = DSIM_PHYTIMING_LPX(0x07),
-	[PHYTIMING_HS_EXIT] = DSIM_PHYTIMING_HS_EXIT(0x0c),
-	[PHYTIMING_CLK_PREPARE] = DSIM_PHYTIMING1_CLK_PREPARE(0x09),
-	[PHYTIMING_CLK_ZERO] = DSIM_PHYTIMING1_CLK_ZERO(0x2d),
-	[PHYTIMING_CLK_POST] = DSIM_PHYTIMING1_CLK_POST(0x0e),
-	[PHYTIMING_CLK_TRAIL] = DSIM_PHYTIMING1_CLK_TRAIL(0x09),
-	[PHYTIMING_HS_PREPARE] = DSIM_PHYTIMING2_HS_PREPARE(0x0b),
-	[PHYTIMING_HS_ZERO] = DSIM_PHYTIMING2_HS_ZERO(0x10),
-	[PHYTIMING_HS_TRAIL] = DSIM_PHYTIMING2_HS_TRAIL(0x0c),
-};
-
-static const struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
-	.reg_ofs = exynos_reg_ofs,
-	.plltmr_reg = 0x50,
-	.has_freqband = 1,
-	.has_clklane_stop = 1,
-	.num_clks = 2,
-	.max_freq = 1000,
-	.wait_for_reset = 1,
-	.num_bits_resol = 11,
-	.pll_p_offset = 13,
-	.reg_values = reg_values,
-};
-
-static const struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
-	.reg_ofs = exynos_reg_ofs,
-	.plltmr_reg = 0x50,
-	.has_freqband = 1,
-	.has_clklane_stop = 1,
-	.num_clks = 2,
-	.max_freq = 1000,
-	.wait_for_reset = 1,
-	.num_bits_resol = 11,
-	.pll_p_offset = 13,
-	.reg_values = reg_values,
-};
-
-static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
-	.reg_ofs = exynos_reg_ofs,
-	.plltmr_reg = 0x58,
-	.num_clks = 2,
-	.max_freq = 1000,
-	.wait_for_reset = 1,
-	.num_bits_resol = 11,
-	.pll_p_offset = 13,
-	.reg_values = reg_values,
-};
-
-static const struct exynos_dsi_driver_data exynos5433_dsi_driver_data = {
-	.reg_ofs = exynos5433_reg_ofs,
-	.plltmr_reg = 0xa0,
-	.has_clklane_stop = 1,
-	.num_clks = 5,
-	.max_freq = 1500,
-	.wait_for_reset = 0,
-	.num_bits_resol = 12,
-	.pll_p_offset = 13,
-	.reg_values = exynos5433_reg_values,
-};
-
-static const struct exynos_dsi_driver_data exynos5422_dsi_driver_data = {
-	.reg_ofs = exynos5433_reg_ofs,
-	.plltmr_reg = 0xa0,
-	.has_clklane_stop = 1,
-	.num_clks = 2,
-	.max_freq = 1500,
-	.wait_for_reset = 1,
-	.num_bits_resol = 12,
-	.pll_p_offset = 13,
-	.reg_values = exynos5422_reg_values,
-};
-
-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)
-{
-	if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
-		return;
-
-	dev_err(dsi->dev, "timeout waiting for reset\n");
-}
-
-static void exynos_dsi_reset(struct exynos_dsi *dsi)
-{
-	u32 reset_val = dsi->driver_data->reg_values[RESET_TYPE];
-
-	reinit_completion(&dsi->completed);
-	exynos_dsi_write(dsi, DSIM_SWRST_REG, reset_val);
-}
-
-#ifndef MHZ
-#define MHZ	(1000*1000)
-#endif
-
-static unsigned long exynos_dsi_pll_find_pms(struct exynos_dsi *dsi,
-		unsigned long fin, unsigned long fout, u8 *p, u16 *m, u8 *s)
-{
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	unsigned long best_freq = 0;
-	u32 min_delta = 0xffffffff;
-	u8 p_min, p_max;
-	u8 _p, best_p;
-	u16 _m, best_m;
-	u8 _s, best_s;
-
-	p_min = DIV_ROUND_UP(fin, (12 * MHZ));
-	p_max = fin / (6 * MHZ);
-
-	for (_p = p_min; _p <= p_max; ++_p) {
-		for (_s = 0; _s <= 5; ++_s) {
-			u64 tmp;
-			u32 delta;
-
-			tmp = (u64)fout * (_p << _s);
-			do_div(tmp, fin);
-			_m = tmp;
-			if (_m < 41 || _m > 125)
-				continue;
-
-			tmp = (u64)_m * fin;
-			do_div(tmp, _p);
-			if (tmp < 500 * MHZ ||
-					tmp > driver_data->max_freq * MHZ)
-				continue;
-
-			tmp = (u64)_m * fin;
-			do_div(tmp, _p << _s);
-
-			delta = abs(fout - tmp);
-			if (delta < min_delta) {
-				best_p = _p;
-				best_m = _m;
-				best_s = _s;
-				min_delta = delta;
-				best_freq = tmp;
-			}
-		}
-	}
-
-	if (best_freq) {
-		*p = best_p;
-		*m = best_m;
-		*s = best_s;
-	}
-
-	return best_freq;
-}
-
-static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
-					unsigned long freq)
-{
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	unsigned long fin, fout;
-	int timeout;
-	u8 p, s;
-	u16 m;
-	u32 reg;
-
-	fin = dsi->pll_clk_rate;
-	fout = exynos_dsi_pll_find_pms(dsi, fin, freq, &p, &m, &s);
-	if (!fout) {
-		dev_err(dsi->dev,
-			"failed to find PLL PMS for requested frequency\n");
-		return 0;
-	}
-	dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
-
-	writel(driver_data->reg_values[PLL_TIMER],
-			dsi->reg_base + driver_data->plltmr_reg);
-
-	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[] = {
-			100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
-			270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
-			510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
-			770 * MHZ, 870 * MHZ, 950 * MHZ,
-		};
-		int band;
-
-		for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
-			if (fout < freq_bands[band])
-				break;
-
-		dev_dbg(dsi->dev, "band %d\n", band);
-
-		reg |= DSIM_FREQ_BAND(band);
-	}
-
-	exynos_dsi_write(dsi, DSIM_PLLCTRL_REG, reg);
-
-	timeout = 1000;
-	do {
-		if (timeout-- == 0) {
-			dev_err(dsi->dev, "PLL failed to stabilize\n");
-			return 0;
-		}
-		reg = exynos_dsi_read(dsi, DSIM_STATUS_REG);
-	} while ((reg & DSIM_PLL_STABLE) == 0);
-
-	return fout;
-}
-
-static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
-{
-	unsigned long hs_clk, byte_clk, esc_clk;
-	unsigned long esc_div;
-	u32 reg;
-
-	hs_clk = exynos_dsi_set_pll(dsi, dsi->burst_clk_rate);
-	if (!hs_clk) {
-		dev_err(dsi->dev, "failed to configure DSI PLL\n");
-		return -EFAULT;
-	}
-
-	byte_clk = hs_clk / 8;
-	esc_div = DIV_ROUND_UP(byte_clk, dsi->esc_clk_rate);
-	esc_clk = byte_clk / esc_div;
-
-	if (esc_clk > 20 * MHZ) {
-		++esc_div;
-		esc_clk = byte_clk / esc_div;
-	}
-
-	dev_dbg(dsi->dev, "hs_clk = %lu, byte_clk = %lu, esc_clk = %lu\n",
-		hs_clk, byte_clk, esc_clk);
-
-	reg = exynos_dsi_read(dsi, DSIM_CLKCTRL_REG);
-	reg &= ~(DSIM_ESC_PRESCALER_MASK | DSIM_LANE_ESC_CLK_EN_CLK
-			| DSIM_LANE_ESC_CLK_EN_DATA_MASK | DSIM_PLL_BYPASS
-			| DSIM_BYTE_CLK_SRC_MASK);
-	reg |= DSIM_ESC_CLKEN | DSIM_BYTE_CLKEN
-			| DSIM_ESC_PRESCALER(esc_div)
-			| DSIM_LANE_ESC_CLK_EN_CLK
-			| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
-			| DSIM_BYTE_CLK_SRC(0)
-			| DSIM_TX_REQUEST_HSCLK;
-	exynos_dsi_write(dsi, DSIM_CLKCTRL_REG, reg);
-
-	return 0;
-}
-
-static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
-{
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	const unsigned int *reg_values = driver_data->reg_values;
-	u32 reg;
-
-	if (driver_data->has_freqband)
-		return;
-
-	/* B D-PHY: D-PHY Master & Slave Analog Block control */
-	reg = reg_values[PHYCTRL_ULPS_EXIT] | reg_values[PHYCTRL_VREG_LP] |
-		reg_values[PHYCTRL_SLEW_UP];
-	exynos_dsi_write(dsi, DSIM_PHYCTRL_REG, reg);
-
-	/*
-	 * T LPX: Transmitted length of any Low-Power state period
-	 * T HS-EXIT: Time that the transmitter drives LP-11 following a HS
-	 *	burst
-	 */
-	reg = reg_values[PHYTIMING_LPX] | reg_values[PHYTIMING_HS_EXIT];
-	exynos_dsi_write(dsi, DSIM_PHYTIMING_REG, reg);
-
-	/*
-	 * T CLK-PREPARE: Time that the transmitter drives the Clock Lane LP-00
-	 *	Line state immediately before the HS-0 Line state starting the
-	 *	HS transmission
-	 * T CLK-ZERO: Time that the transmitter drives the HS-0 state prior to
-	 *	transmitting the Clock.
-	 * T CLK_POST: Time that the transmitter continues to send HS clock
-	 *	after the last associated Data Lane has transitioned to LP Mode
-	 *	Interval is defined as the period from the end of T HS-TRAIL to
-	 *	the beginning of T CLK-TRAIL
-	 * T CLK-TRAIL: Time that the transmitter drives the HS-0 state after
-	 *	the last payload clock bit of a HS transmission burst
-	 */
-	reg = reg_values[PHYTIMING_CLK_PREPARE] |
-		reg_values[PHYTIMING_CLK_ZERO] |
-		reg_values[PHYTIMING_CLK_POST] |
-		reg_values[PHYTIMING_CLK_TRAIL];
-
-	exynos_dsi_write(dsi, DSIM_PHYTIMING1_REG, reg);
-
-	/*
-	 * T HS-PREPARE: Time that the transmitter drives the Data Lane LP-00
-	 *	Line state immediately before the HS-0 Line state starting the
-	 *	HS transmission
-	 * T HS-ZERO: Time that the transmitter drives the HS-0 state prior to
-	 *	transmitting the Sync sequence.
-	 * T HS-TRAIL: Time that the transmitter drives the flipped differential
-	 *	state after last payload data bit of a HS transmission burst
-	 */
-	reg = reg_values[PHYTIMING_HS_PREPARE] | reg_values[PHYTIMING_HS_ZERO] |
-		reg_values[PHYTIMING_HS_TRAIL];
-	exynos_dsi_write(dsi, DSIM_PHYTIMING2_REG, reg);
-}
-
-static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
-{
-	u32 reg;
-
-	reg = exynos_dsi_read(dsi, DSIM_CLKCTRL_REG);
-	reg &= ~(DSIM_LANE_ESC_CLK_EN_CLK | DSIM_LANE_ESC_CLK_EN_DATA_MASK
-			| DSIM_ESC_CLKEN | DSIM_BYTE_CLKEN);
-	exynos_dsi_write(dsi, DSIM_CLKCTRL_REG, reg);
-
-	reg = exynos_dsi_read(dsi, DSIM_PLLCTRL_REG);
-	reg &= ~DSIM_PLL_EN;
-	exynos_dsi_write(dsi, DSIM_PLLCTRL_REG, reg);
-}
-
-static void exynos_dsi_enable_lane(struct exynos_dsi *dsi, u32 lane)
-{
-	u32 reg = exynos_dsi_read(dsi, DSIM_CONFIG_REG);
-	reg |= (DSIM_NUM_OF_DATA_LANE(dsi->lanes - 1) | DSIM_LANE_EN_CLK |
-			DSIM_LANE_EN(lane));
-	exynos_dsi_write(dsi, DSIM_CONFIG_REG, reg);
-}
-
-static int exynos_dsi_init_link(struct exynos_dsi *dsi)
-{
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	int timeout;
-	u32 reg;
-	u32 lanes_mask;
-
-	/* Initialize FIFO pointers */
-	reg = exynos_dsi_read(dsi, DSIM_FIFOCTRL_REG);
-	reg &= ~0x1f;
-	exynos_dsi_write(dsi, DSIM_FIFOCTRL_REG, reg);
-
-	usleep_range(9000, 11000);
-
-	reg |= 0x1f;
-	exynos_dsi_write(dsi, DSIM_FIFOCTRL_REG, reg);
-	usleep_range(9000, 11000);
-
-	/* DSI configuration */
-	reg = 0;
-
-	/*
-	 * The first bit of mode_flags specifies display configuration.
-	 * If this bit is set[= MIPI_DSI_MODE_VIDEO], dsi will support video
-	 * mode, otherwise it will support command mode.
-	 */
-	if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
-		reg |= DSIM_VIDEO_MODE;
-
-		/*
-		 * The user manual describes that following bits are ignored in
-		 * command mode.
-		 */
-		if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
-			reg |= DSIM_MFLUSH_VS;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
-			reg |= DSIM_SYNC_INFORM;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
-			reg |= DSIM_BURST_MODE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_AUTO_VERT)
-			reg |= DSIM_AUTO_MODE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_HSE)
-			reg |= DSIM_HSE_DISABLE_MODE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HFP)
-			reg |= DSIM_HFP_DISABLE_MODE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HBP)
-			reg |= DSIM_HBP_DISABLE_MODE;
-		if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_NO_HSA)
-			reg |= DSIM_HSA_DISABLE_MODE;
-	}
-
-	if (dsi->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET)
-		reg |= DSIM_EOT_DISABLE;
-
-	switch (dsi->format) {
-	case MIPI_DSI_FMT_RGB888:
-		reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
-		break;
-	case MIPI_DSI_FMT_RGB666:
-		reg |= DSIM_MAIN_PIX_FORMAT_RGB666;
-		break;
-	case MIPI_DSI_FMT_RGB666_PACKED:
-		reg |= DSIM_MAIN_PIX_FORMAT_RGB666_P;
-		break;
-	case MIPI_DSI_FMT_RGB565:
-		reg |= DSIM_MAIN_PIX_FORMAT_RGB565;
-		break;
-	default:
-		dev_err(dsi->dev, "invalid pixel format\n");
-		return -EINVAL;
-	}
-
-	/*
-	 * Use non-continuous clock mode if the periparal wants and
-	 * host controller supports
-	 *
-	 * In non-continous clock mode, host controller will turn off
-	 * the HS clock between high-speed transmissions to reduce
-	 * power consumption.
-	 */
-	if (driver_data->has_clklane_stop &&
-			dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
-		reg |= DSIM_CLKLANE_STOP;
-	}
-	exynos_dsi_write(dsi, DSIM_CONFIG_REG, reg);
-
-	lanes_mask = BIT(dsi->lanes) - 1;
-	exynos_dsi_enable_lane(dsi, lanes_mask);
-
-	/* Check clock and data lane state are stop state */
-	timeout = 100;
-	do {
-		if (timeout-- == 0) {
-			dev_err(dsi->dev, "waiting for bus lanes timed out\n");
-			return -EFAULT;
-		}
-
-		reg = exynos_dsi_read(dsi, DSIM_STATUS_REG);
-		if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
-		    != DSIM_STOP_STATE_DAT(lanes_mask))
-			continue;
-	} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
-
-	reg = exynos_dsi_read(dsi, DSIM_ESCMODE_REG);
-	reg &= ~DSIM_STOP_STATE_CNT_MASK;
-	reg |= DSIM_STOP_STATE_CNT(driver_data->reg_values[STOP_STATE_CNT]);
-	exynos_dsi_write(dsi, DSIM_ESCMODE_REG, reg);
-
-	reg = DSIM_BTA_TIMEOUT(0xff) | DSIM_LPDR_TIMEOUT(0xffff);
-	exynos_dsi_write(dsi, DSIM_TIMEOUT_REG, reg);
-
-	return 0;
-}
-
-static void exynos_dsi_set_display_mode(struct exynos_dsi *dsi)
-{
-	struct drm_display_mode *m = &dsi->mode;
-	unsigned int num_bits_resol = dsi->driver_data->num_bits_resol;
-	u32 reg;
-
-	if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
-		reg = DSIM_CMD_ALLOW(0xf)
-			| DSIM_STABLE_VFP(m->vsync_start - m->vdisplay)
-			| DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
-		exynos_dsi_write(dsi, DSIM_MVPORCH_REG, reg);
-
-		reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
-			| DSIM_MAIN_HBP(m->htotal - m->hsync_end);
-		exynos_dsi_write(dsi, DSIM_MHPORCH_REG, reg);
-
-		reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
-			| DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
-		exynos_dsi_write(dsi, DSIM_MSYNC_REG, reg);
-	}
-	reg =  DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
-		DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol);
-
-	exynos_dsi_write(dsi, DSIM_MDRESOL_REG, reg);
-
-	dev_dbg(dsi->dev, "LCD size = %dx%d\n", m->hdisplay, m->vdisplay);
-}
-
-static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
-{
-	u32 reg;
-
-	reg = exynos_dsi_read(dsi, DSIM_MDRESOL_REG);
-	if (enable)
-		reg |= DSIM_MAIN_STAND_BY;
-	else
-		reg &= ~DSIM_MAIN_STAND_BY;
-	exynos_dsi_write(dsi, DSIM_MDRESOL_REG, reg);
-}
-
-static int exynos_dsi_wait_for_hdr_fifo(struct exynos_dsi *dsi)
-{
-	int timeout = 2000;
-
-	do {
-		u32 reg = exynos_dsi_read(dsi, DSIM_FIFOCTRL_REG);
-
-		if (!(reg & DSIM_SFR_HEADER_FULL))
-			return 0;
-
-		if (!cond_resched())
-			usleep_range(950, 1050);
-	} while (--timeout);
-
-	return -ETIMEDOUT;
-}
-
-static void exynos_dsi_set_cmd_lpm(struct exynos_dsi *dsi, bool lpm)
-{
-	u32 v = exynos_dsi_read(dsi, DSIM_ESCMODE_REG);
-
-	if (lpm)
-		v |= DSIM_CMD_LPDT_LP;
-	else
-		v &= ~DSIM_CMD_LPDT_LP;
-
-	exynos_dsi_write(dsi, DSIM_ESCMODE_REG, v);
-}
-
-static void exynos_dsi_force_bta(struct exynos_dsi *dsi)
-{
-	u32 v = exynos_dsi_read(dsi, DSIM_ESCMODE_REG);
-	v |= DSIM_FORCE_BTA;
-	exynos_dsi_write(dsi, DSIM_ESCMODE_REG, v);
-}
-
-static void exynos_dsi_send_to_fifo(struct exynos_dsi *dsi,
-					struct exynos_dsi_transfer *xfer)
-{
-	struct device *dev = dsi->dev;
-	struct mipi_dsi_packet *pkt = &xfer->packet;
-	const u8 *payload = pkt->payload + xfer->tx_done;
-	u16 length = pkt->payload_length - xfer->tx_done;
-	bool first = !xfer->tx_done;
-	u32 reg;
-
-	dev_dbg(dev, "< xfer %pK: tx len %u, done %u, rx len %u, done %u\n",
-		xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
-
-	if (length > DSI_TX_FIFO_SIZE)
-		length = DSI_TX_FIFO_SIZE;
-
-	xfer->tx_done += length;
-
-	/* Send payload */
-	while (length >= 4) {
-		reg = get_unaligned_le32(payload);
-		exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
-		payload += 4;
-		length -= 4;
-	}
-
-	reg = 0;
-	switch (length) {
-	case 3:
-		reg |= payload[2] << 16;
-		fallthrough;
-	case 2:
-		reg |= payload[1] << 8;
-		fallthrough;
-	case 1:
-		reg |= payload[0];
-		exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
-		break;
-	}
-
-	/* Send packet header */
-	if (!first)
-		return;
-
-	reg = get_unaligned_le32(pkt->header);
-	if (exynos_dsi_wait_for_hdr_fifo(dsi)) {
-		dev_err(dev, "waiting for header FIFO timed out\n");
-		return;
-	}
-
-	if (NEQV(xfer->flags & MIPI_DSI_MSG_USE_LPM,
-		 dsi->state & DSIM_STATE_CMD_LPM)) {
-		exynos_dsi_set_cmd_lpm(dsi, xfer->flags & MIPI_DSI_MSG_USE_LPM);
-		dsi->state ^= DSIM_STATE_CMD_LPM;
-	}
-
-	exynos_dsi_write(dsi, DSIM_PKTHDR_REG, reg);
-
-	if (xfer->flags & MIPI_DSI_MSG_REQ_ACK)
-		exynos_dsi_force_bta(dsi);
-}
-
-static void exynos_dsi_read_from_fifo(struct exynos_dsi *dsi,
-					struct exynos_dsi_transfer *xfer)
-{
-	u8 *payload = xfer->rx_payload + xfer->rx_done;
-	bool first = !xfer->rx_done;
-	struct device *dev = dsi->dev;
-	u16 length;
-	u32 reg;
-
-	if (first) {
-		reg = exynos_dsi_read(dsi, DSIM_RXFIFO_REG);
-
-		switch (reg & 0x3f) {
-		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
-		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
-			if (xfer->rx_len >= 2) {
-				payload[1] = reg >> 16;
-				++xfer->rx_done;
-			}
-			fallthrough;
-		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
-		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
-			payload[0] = reg >> 8;
-			++xfer->rx_done;
-			xfer->rx_len = xfer->rx_done;
-			xfer->result = 0;
-			goto clear_fifo;
-		case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
-			dev_err(dev, "DSI Error Report: 0x%04x\n",
-				(reg >> 8) & 0xffff);
-			xfer->result = 0;
-			goto clear_fifo;
-		}
-
-		length = (reg >> 8) & 0xffff;
-		if (length > xfer->rx_len) {
-			dev_err(dev,
-				"response too long (%u > %u bytes), stripping\n",
-				xfer->rx_len, length);
-			length = xfer->rx_len;
-		} else if (length < xfer->rx_len)
-			xfer->rx_len = length;
-	}
-
-	length = xfer->rx_len - xfer->rx_done;
-	xfer->rx_done += length;
-
-	/* Receive payload */
-	while (length >= 4) {
-		reg = exynos_dsi_read(dsi, DSIM_RXFIFO_REG);
-		payload[0] = (reg >>  0) & 0xff;
-		payload[1] = (reg >>  8) & 0xff;
-		payload[2] = (reg >> 16) & 0xff;
-		payload[3] = (reg >> 24) & 0xff;
-		payload += 4;
-		length -= 4;
-	}
-
-	if (length) {
-		reg = exynos_dsi_read(dsi, DSIM_RXFIFO_REG);
-		switch (length) {
-		case 3:
-			payload[2] = (reg >> 16) & 0xff;
-			fallthrough;
-		case 2:
-			payload[1] = (reg >> 8) & 0xff;
-			fallthrough;
-		case 1:
-			payload[0] = reg & 0xff;
-		}
-	}
-
-	if (xfer->rx_done == xfer->rx_len)
-		xfer->result = 0;
-
-clear_fifo:
-	length = DSI_RX_FIFO_SIZE / 4;
-	do {
-		reg = exynos_dsi_read(dsi, DSIM_RXFIFO_REG);
-		if (reg == DSI_RX_FIFO_EMPTY)
-			break;
-	} while (--length);
-}
-
-static void exynos_dsi_transfer_start(struct exynos_dsi *dsi)
-{
-	unsigned long flags;
-	struct exynos_dsi_transfer *xfer;
-	bool start = false;
-
-again:
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	if (list_empty(&dsi->transfer_list)) {
-		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-		return;
-	}
-
-	xfer = list_first_entry(&dsi->transfer_list,
-					struct exynos_dsi_transfer, list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	if (xfer->packet.payload_length &&
-	    xfer->tx_done == xfer->packet.payload_length)
-		/* waiting for RX */
-		return;
-
-	exynos_dsi_send_to_fifo(dsi, xfer);
-
-	if (xfer->packet.payload_length || xfer->rx_len)
-		return;
-
-	xfer->result = 0;
-	complete(&xfer->completed);
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	list_del_init(&xfer->list);
-	start = !list_empty(&dsi->transfer_list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	if (start)
-		goto again;
-}
-
-static bool exynos_dsi_transfer_finish(struct exynos_dsi *dsi)
-{
-	struct exynos_dsi_transfer *xfer;
-	unsigned long flags;
-	bool start = true;
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	if (list_empty(&dsi->transfer_list)) {
-		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-		return false;
-	}
-
-	xfer = list_first_entry(&dsi->transfer_list,
-					struct exynos_dsi_transfer, list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	dev_dbg(dsi->dev,
-		"> xfer %pK, tx_len %zu, tx_done %u, rx_len %u, rx_done %u\n",
-		xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
-		xfer->rx_done);
-
-	if (xfer->tx_done != xfer->packet.payload_length)
-		return true;
-
-	if (xfer->rx_done != xfer->rx_len)
-		exynos_dsi_read_from_fifo(dsi, xfer);
-
-	if (xfer->rx_done != xfer->rx_len)
-		return true;
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	list_del_init(&xfer->list);
-	start = !list_empty(&dsi->transfer_list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	if (!xfer->rx_len)
-		xfer->result = 0;
-	complete(&xfer->completed);
-
-	return start;
-}
-
-static void exynos_dsi_remove_transfer(struct exynos_dsi *dsi,
-					struct exynos_dsi_transfer *xfer)
-{
-	unsigned long flags;
-	bool start;
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	if (!list_empty(&dsi->transfer_list) &&
-	    xfer == list_first_entry(&dsi->transfer_list,
-				     struct exynos_dsi_transfer, list)) {
-		list_del_init(&xfer->list);
-		start = !list_empty(&dsi->transfer_list);
-		spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-		if (start)
-			exynos_dsi_transfer_start(dsi);
-		return;
-	}
-
-	list_del_init(&xfer->list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-}
-
-static int exynos_dsi_transfer(struct exynos_dsi *dsi,
-					struct exynos_dsi_transfer *xfer)
-{
-	unsigned long flags;
-	bool stopped;
-
-	xfer->tx_done = 0;
-	xfer->rx_done = 0;
-	xfer->result = -ETIMEDOUT;
-	init_completion(&xfer->completed);
-
-	spin_lock_irqsave(&dsi->transfer_lock, flags);
-
-	stopped = list_empty(&dsi->transfer_list);
-	list_add_tail(&xfer->list, &dsi->transfer_list);
-
-	spin_unlock_irqrestore(&dsi->transfer_lock, flags);
-
-	if (stopped)
-		exynos_dsi_transfer_start(dsi);
-
-	wait_for_completion_timeout(&xfer->completed,
-				    msecs_to_jiffies(DSI_XFER_TIMEOUT_MS));
-	if (xfer->result == -ETIMEDOUT) {
-		struct mipi_dsi_packet *pkt = &xfer->packet;
-		exynos_dsi_remove_transfer(dsi, xfer);
-		dev_err(dsi->dev, "xfer timed out: %*ph %*ph\n", 4, pkt->header,
-			(int)pkt->payload_length, pkt->payload);
-		return -ETIMEDOUT;
-	}
-
-	/* Also covers hardware timeout condition */
-	return xfer->result;
-}
-
-static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
-{
-	struct exynos_dsi *dsi = dev_id;
-	u32 status;
-
-	status = exynos_dsi_read(dsi, DSIM_INTSRC_REG);
-	if (!status) {
-		static unsigned long int j;
-		if (printk_timed_ratelimit(&j, 500))
-			dev_warn(dsi->dev, "spurious interrupt\n");
-		return IRQ_HANDLED;
-	}
-	exynos_dsi_write(dsi, DSIM_INTSRC_REG, status);
-
-	if (status & DSIM_INT_SW_RST_RELEASE) {
-		u32 mask = ~(DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
-			DSIM_INT_SFR_HDR_FIFO_EMPTY | DSIM_INT_RX_ECC_ERR |
-			DSIM_INT_SW_RST_RELEASE);
-		exynos_dsi_write(dsi, DSIM_INTMSK_REG, mask);
-		complete(&dsi->completed);
-		return IRQ_HANDLED;
-	}
-
-	if (!(status & (DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
-			DSIM_INT_PLL_STABLE)))
-		return IRQ_HANDLED;
-
-	if (exynos_dsi_transfer_finish(dsi))
-		exynos_dsi_transfer_start(dsi);
-
-	return IRQ_HANDLED;
-}
-
-static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
-{
-	struct exynos_dsi *dsim = (struct exynos_dsi *)dev_id;
-	struct exynos_dsi_enc *dsi = dsim->priv;
-	struct drm_encoder *encoder = &dsi->encoder;
+#include <linux/of_device.h>
 
-	if (dsim->state & DSIM_STATE_VIDOUT_AVAILABLE)
-		exynos_drm_crtc_te_handler(encoder->crtc);
+#include <drm/bridge/samsung-dsim.h>
+#include <drm/drm_probe_helper.h>
+#include <drm/drm_simple_kms_helper.h>
 
-	return IRQ_HANDLED;
-}
+#include "exynos_drm_crtc.h"
+#include "exynos_drm_drv.h"
+
+struct exynos_dsi {
+	struct drm_encoder encoder;
+	struct gpio_desc *te_gpio;
+};
 
-static void _exynos_dsi_enable_irq(struct exynos_dsi *dsim)
+static void exynos_dsi_enable_irq(struct samsung_dsim *dsim)
 {
-	struct _exynos_dsi *dsi = dsim->priv;
+	struct exynos_dsi *dsi = dsim->priv;
 
 	if (dsi->te_gpio)
 		enable_irq(gpiod_to_irq(dsi->te_gpio));
 }
 
-static void _exynos_dsi_disable_irq(struct exynos_dsi *dsim)
+static void exynos_dsi_disable_irq(struct samsung_dsim *dsim)
 {
-	struct _exynos_dsi *dsi = dsim->priv;
+	struct exynos_dsi *dsi = dsim->priv;
 
 	if (dsi->te_gpio)
 		disable_irq(gpiod_to_irq(dsi->te_gpio));
 }
 
-static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
-{
-	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
-
-	enable_irq(dsi->irq);
-
-	if (pdata->irq_ops && pdata->irq_ops->enable)
-		pdata->irq_ops->enable(dsi);
-}
-
-static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
-{
-	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
-
-	if (pdata->irq_ops && pdata->irq_ops->disable)
-		pdata->irq_ops->disable(dsi);
-
-	disable_irq(dsi->irq);
-}
-
-static int exynos_dsi_init(struct exynos_dsi *dsi)
+static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
 {
-	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);
-
-	if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
-		exynos_dsi_enable_lane(dsi, BIT(dsi->lanes) - 1);
-
-	exynos_dsi_enable_clock(dsi);
-	if (driver_data->wait_for_reset)
-		exynos_dsi_wait_for_reset(dsi);
-	exynos_dsi_set_phy_ctrl(dsi);
-	exynos_dsi_init_link(dsi);
+	struct samsung_dsim *dsim = (struct samsung_dsim *)dev_id;
+	struct exynos_dsi *dsi = dsim->priv;
+	struct drm_encoder *encoder = &dsi->encoder;
 
-	dsi->state |= DSIM_STATE_INITIALIZED;
+	if (dsim->state & DSIM_STATE_VIDOUT_AVAILABLE)
+		exynos_drm_crtc_te_handler(encoder->crtc);
 
-	return 0;
+	return IRQ_HANDLED;
 }
 
-static int exynos_dsi_register_te_irq(struct exynos_dsi *dsim,
-				      struct device *panel)
+static int exynos_dsi_register_te_irq(struct samsung_dsim *dsim, struct device *panel)
 {
-	struct _exynos_dsi *dsi = dsim->priv;
-	int ret;
+	struct exynos_dsi *dsi = dsim->priv;
 	int te_gpio_irq;
+	int ret;
 
-	dsi->te_gpio = gpiod_get_optional(panel, "te", GPIOD_IN);
+	dsi->te_gpio = devm_gpiod_get_optional(panel, "te", GPIOD_IN);
 	if (!dsi->te_gpio) {
 		return 0;
 	} else if (IS_ERR(dsi->te_gpio)) {
 		dev_err(dsim->dev, "gpio request failed with %ld\n",
-				PTR_ERR(dsi->te_gpio));
+			PTR_ERR(dsi->te_gpio));
 		return PTR_ERR(dsi->te_gpio);
 	}
 
 	te_gpio_irq = gpiod_to_irq(dsi->te_gpio);
 
 	ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
-				   IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE", dsi);
+				   IRQF_TRIGGER_RISING | IRQF_NO_AUTOEN, "TE",
+				   dsim);
 	if (ret) {
 		dev_err(dsim->dev, "request interrupt failed with %d\n", ret);
 		gpiod_put(dsi->te_gpio);
@@ -1440,9 +80,9 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi *dsim,
 	return 0;
 }
 
-static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsim)
+static void exynos_dsi_unregister_te_irq(struct samsung_dsim *dsim)
 {
-	struct _exynos_dsi *dsi = dsim->priv;
+	struct exynos_dsi *dsi = dsim->priv;
 
 	if (dsi->te_gpio) {
 		free_irq(gpiod_to_irq(dsi->te_gpio), dsi);
@@ -1450,315 +90,10 @@ static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsim)
 	}
 }
 
-static void exynos_dsi_atomic_pre_enable(struct drm_bridge *bridge,
-					 struct drm_bridge_state *old_bridge_state)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-	int ret;
-
-	if (dsi->state & DSIM_STATE_ENABLED)
-		return;
-
-	ret = pm_runtime_resume_and_get(dsi->dev);
-	if (ret < 0) {
-		dev_err(dsi->dev, "failed to enable DSI device.\n");
-		return;
-	}
-
-	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,
-				     struct drm_bridge_state *old_bridge_state)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	exynos_dsi_set_display_mode(dsi);
-	exynos_dsi_set_display_enable(dsi, true);
-
-	dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
-
-	return;
-}
-
-static void exynos_dsi_atomic_disable(struct drm_bridge *bridge,
-				      struct drm_bridge_state *old_bridge_state)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	if (!(dsi->state & DSIM_STATE_ENABLED))
-		return;
-
-	dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
-}
-
-static void exynos_dsi_atomic_post_disable(struct drm_bridge *bridge,
-					   struct drm_bridge_state *old_bridge_state)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	exynos_dsi_set_display_enable(dsi, false);
-
-	dsi->state &= ~DSIM_STATE_ENABLED;
-	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,
-
-	MEDIA_BUS_FMT_FIXED,
-};
-
-static bool exynos_dsi_pixel_output_fmt_supported(u32 fmt)
-{
-	int i;
-
-	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;
-
-	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 = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
-	if (!input_fmts)
-		return NULL;
-
-	switch (output_fmt) {
-	case MEDIA_BUS_FMT_FIXED:
-		input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
-		break;
-	default:
-		input_fmts[0] = output_fmt;
-		break;
-	}
-
-	*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,
-				   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)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	drm_mode_copy(&dsi->mode, adjusted_mode);
-}
-
-static int exynos_dsi_attach(struct drm_bridge *bridge,
-			     enum drm_bridge_attach_flags flags)
-{
-	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
-
-	return drm_bridge_attach(bridge->encoder, dsi->out_bridge, bridge,
-				 flags);
-}
-
-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,
-	.atomic_disable			= exynos_dsi_atomic_disable,
-	.atomic_post_disable		= exynos_dsi_atomic_post_disable,
-	.mode_set			= exynos_dsi_mode_set,
-	.attach				= exynos_dsi_attach,
-};
-
-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;
-	int ret;
-
-	dsi->out_bridge = devm_drm_of_dsi_get_bridge(dev, dev->of_node, 1, 0);
-	if (IS_ERR(dsi->out_bridge)) {
-		ret = PTR_ERR(dsi->out_bridge);
-		DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret);
-		return ret;
-	}
-
-	DRM_DEV_INFO(dev, "Attached %s device\n", device->name);
-
-	drm_bridge_add(&dsi->bridge);
-
-	if (pdata->host_ops && pdata->host_ops->attach) {
-		ret = pdata->host_ops->attach(dsi, device);
-		if (ret < 0)
-			return ret;
-	}
-
-	dsi->lanes = device->lanes;
-	dsi->format = device->format;
-	dsi->mode_flags = device->mode_flags;
-
-	return 0;
-}
-
-static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
+static int exynos_dsi_host_attach(struct samsung_dsim *dsim,
 				  struct mipi_dsi_device *device)
 {
-	struct exynos_dsi *dsi = host_to_dsi(host);
-	const struct exynos_dsi_plat_data *pdata = dsi->plat_data;
-	int ret;
-
-	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);
-
-	return 0;
-}
-
-static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
-					 const struct mipi_dsi_msg *msg)
-{
-	struct exynos_dsi *dsi = host_to_dsi(host);
-	struct exynos_dsi_transfer xfer;
-	int ret;
-
-	if (!(dsi->state & DSIM_STATE_ENABLED))
-		return -EINVAL;
-
-	ret = exynos_dsi_init(dsi);
-	if (ret)
-		return ret;
-
-	ret = mipi_dsi_create_packet(&xfer.packet, msg);
-	if (ret < 0)
-		return ret;
-
-	xfer.rx_len = msg->rx_len;
-	xfer.rx_payload = msg->rx_buf;
-	xfer.flags = msg->flags;
-
-	ret = exynos_dsi_transfer(dsi, &xfer);
-	return (ret < 0) ? ret : xfer.rx_done;
-}
-
-static const struct mipi_dsi_host_ops exynos_dsi_ops = {
-	.attach = exynos_dsi_host_attach,
-	.detach = exynos_dsi_host_detach,
-	.transfer = exynos_dsi_host_transfer,
-};
-
-static int exynos_dsi_of_read_u32(const struct device_node *np,
-				  const char *propname, u32 *out_value)
-{
-	int ret = of_property_read_u32(np, propname, out_value);
-
-	if (ret < 0)
-		pr_err("%pOF: failed to get '%s' property\n", np, propname);
-
-	return ret;
-}
-
-static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
-{
-	struct device *dev = dsi->dev;
-	struct device_node *node = dev->of_node;
-	int ret;
-
-	ret = exynos_dsi_of_read_u32(node, "samsung,pll-clock-frequency",
-				     &dsi->pll_clk_rate);
-	if (ret < 0)
-		return ret;
-
-	ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
-				     &dsi->burst_clk_rate);
-	if (ret < 0)
-		return ret;
-
-	ret = exynos_dsi_of_read_u32(node, "samsung,esc-clock-frequency",
-				     &dsi->esc_clk_rate);
-	if (ret < 0)
-		return ret;
-
-	return 0;
-}
-
-static int _exynos_dsi_host_attach(struct exynos_dsi *dsim,
-				   struct mipi_dsi_device *device)
-{
-	struct exynos_dsi_enc *dsi = dsim->priv;
+	struct exynos_dsi *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 	struct drm_device *drm = encoder->dev;
 	int ret;
@@ -1796,10 +131,10 @@ static int _exynos_dsi_host_attach(struct exynos_dsi *dsim,
 	return 0;
 }
 
-static int _exynos_dsi_host_detach(struct exynos_dsi *dsim,
-				   struct mipi_dsi_device *device)
+static int exynos_dsi_host_detach(struct samsung_dsim *dsim,
+				  struct mipi_dsi_device *device)
 {
-	struct exynos_dsi_enc *dsi = dsim->priv;
+	struct exynos_dsi *dsi = dsim->priv;
 	struct drm_device *drm = dsi->encoder.dev;
 
 	if (drm->mode_config.poll_enabled)
@@ -1810,11 +145,10 @@ static int _exynos_dsi_host_detach(struct exynos_dsi *dsim,
 	return 0;
 }
 
-static int exynos_dsi_bind(struct device *dev, struct device *master,
-				void *data)
+static int exynos_dsi_bind(struct device *dev, struct device *master, void *data)
 {
-	struct exynos_dsi *dsim = dev_get_drvdata(dev);
-	struct exynos_dsi_enc *dsi = dsim->priv;
+	struct samsung_dsim *dsim = dev_get_drvdata(dev);
+	struct exynos_dsi *dsi = dsim->priv;
 	struct drm_encoder *encoder = &dsi->encoder;
 	struct drm_device *drm_dev = data;
 	int ret;
@@ -1828,10 +162,11 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
 	return mipi_dsi_host_register(&dsim->dsi_host);
 }
 
-static void exynos_dsi_unbind(struct device *dev, struct device *master,
-				void *data)
+static void exynos_dsi_unbind(struct device *dev, struct device *master, void *data)
 {
-	struct exynos_dsi *dsim = dev_get_drvdata(dev);
+	struct samsung_dsim *dsim = dev_get_drvdata(dev);
+
+	dsim->bridge.funcs->atomic_disable(&dsim->bridge, NULL);
 
 	dsim->bridge.funcs->atomic_disable(&dsim->bridge, NULL);
 
@@ -1843,266 +178,64 @@ static const struct component_ops exynos_dsi_component_ops = {
 	.unbind	= exynos_dsi_unbind,
 };
 
-static int exynos_dsi_register_host(struct exynos_dsi *dsim)
+static int exynos_dsi_register_host(struct samsung_dsim *dsim)
 {
-	struct exynos_dsi_enc *dsi;
+	struct exynos_dsi *exynos_dsi;
 
-	dsi = devm_kzalloc(dsim->dev, sizeof(*dsi), GFP_KERNEL);
-	if (!dsi)
+	exynos_dsi = devm_kzalloc(dsim->dev, sizeof(*exynos_dsi), GFP_KERNEL);
+	if (!exynos_dsi)
 		return -ENOMEM;
 
-	dsim->priv = dsi;
+	dsim->priv = exynos_dsi;
 	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)
+static void exynos_dsi_unregister_host(struct samsung_dsim *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,
-};
-
-static int exynos_dsi_probe(struct platform_device *pdev)
-{
-	struct device *dev = &pdev->dev;
-	struct exynos_dsi *dsi;
-	int ret, i;
-
-	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
-	if (!dsi)
-		return -ENOMEM;
-
-	init_completion(&dsi->completed);
-	spin_lock_init(&dsi->transfer_lock);
-	INIT_LIST_HEAD(&dsi->transfer_list);
-
-	dsi->dsi_host.ops = &exynos_dsi_ops;
-	dsi->dsi_host.dev = dev;
-
-	dsi->dev = 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";
-	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
-				      dsi->supplies);
-	if (ret)
-		return dev_err_probe(dev, ret, "failed to get regulators\n");
-
-	dsi->clks = devm_kcalloc(dev,
-			dsi->driver_data->num_clks, sizeof(*dsi->clks),
-			GFP_KERNEL);
-	if (!dsi->clks)
-		return -ENOMEM;
-
-	for (i = 0; i < dsi->driver_data->num_clks; i++) {
-		dsi->clks[i] = devm_clk_get(dev, clk_names[i]);
-		if (IS_ERR(dsi->clks[i])) {
-			if (strcmp(clk_names[i], "sclk_mipi") == 0) {
-				dsi->clks[i] = devm_clk_get(dev,
-							OLD_SCLK_MIPI_CLK_NAME);
-				if (!IS_ERR(dsi->clks[i]))
-					continue;
-			}
-
-			dev_info(dev, "failed to get the clock: %s\n",
-					clk_names[i]);
-			return PTR_ERR(dsi->clks[i]);
-		}
-	}
-
-	dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
-	if (IS_ERR(dsi->reg_base))
-		return PTR_ERR(dsi->reg_base);
-
-	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);
-	}
-
-	dsi->irq = platform_get_irq(pdev, 0);
-	if (dsi->irq < 0)
-		return dsi->irq;
-
-	ret = devm_request_threaded_irq(dev, dsi->irq, NULL,
-					exynos_dsi_irq,
-					IRQF_ONESHOT | IRQF_NO_AUTOEN,
-					dev_name(dev), dsi);
-	if (ret) {
-		dev_err(dev, "failed to request dsi irq\n");
-		return ret;
-	}
-
-	ret = exynos_dsi_parse_dt(dsi);
-	if (ret)
-		return ret;
-
-	platform_set_drvdata(pdev, dsi);
-
-	pm_runtime_enable(dev);
-
-	dsi->bridge.funcs = &exynos_dsi_bridge_funcs;
-	dsi->bridge.of_node = dev->of_node;
-	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;
-
-	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;
-
-	return 0;
-
-err_disable_runtime:
-	pm_runtime_disable(dev);
-
-	return ret;
-}
-
-static int exynos_dsi_remove(struct platform_device *pdev)
-{
-	pm_runtime_disable(&pdev->dev);
-
-	component_del(&pdev->dev, &exynos_dsi_component_ops);
-
-	return 0;
-}
-
-static int __maybe_unused exynos_dsi_suspend(struct device *dev)
-{
-	struct exynos_dsi *dsi = dev_get_drvdata(dev);
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	int ret, i;
-
-	usleep_range(10000, 20000);
-
-	if (dsi->state & DSIM_STATE_INITIALIZED) {
-		dsi->state &= ~DSIM_STATE_INITIALIZED;
-
-		exynos_dsi_disable_clock(dsi);
-
-		exynos_dsi_disable_irq(dsi);
-	}
-
-	dsi->state &= ~DSIM_STATE_CMD_LPM;
-
-	phy_power_off(dsi->phy);
-
-	for (i = driver_data->num_clks - 1; i > -1; i--)
-		clk_disable_unprepare(dsi->clks[i]);
-
-	ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
-	if (ret < 0)
-		dev_err(dsi->dev, "cannot disable regulators %d\n", ret);
-
-	return 0;
-}
-
-static int __maybe_unused exynos_dsi_resume(struct device *dev)
-{
-	struct exynos_dsi *dsi = dev_get_drvdata(dev);
-	const struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
-	int ret, i;
-
-	ret = regulator_bulk_enable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
-	if (ret < 0) {
-		dev_err(dsi->dev, "cannot enable regulators %d\n", ret);
-		return ret;
-	}
-
-	for (i = 0; i < driver_data->num_clks; i++) {
-		ret = clk_prepare_enable(dsi->clks[i]);
-		if (ret < 0)
-			goto err_clk;
-	}
-
-	ret = phy_power_on(dsi->phy);
-	if (ret < 0) {
-		dev_err(dsi->dev, "cannot enable phy %d\n", ret);
-		goto err_clk;
-	}
-
-	return 0;
-
-err_clk:
-	while (--i > -1)
-		clk_disable_unprepare(dsi->clks[i]);
-	regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
-
-	return ret;
-}
-
-static const struct dev_pm_ops exynos_dsi_pm_ops = {
-	SET_RUNTIME_PM_OPS(exynos_dsi_suspend, exynos_dsi_resume, NULL)
-	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
-				pm_runtime_force_resume)
+static const struct samsung_dsim_irq_ops exynos_dsi_irq_ops = {
+	.enable = exynos_dsi_enable_irq,
+	.disable = exynos_dsi_disable_irq,
 };
 
-static const struct exynos_dsim_irq_ops exynos_dsi_irq_ops = {
-	.enable = _exynos_dsi_enable_irq,
-	.disable = _exynos_dsi_disable_irq,
-};
-
-static const struct exynos_dsim_host_ops exynos_dsi_host_ops = {
+static const struct samsung_dsim_host_ops exynos_dsi_exynos_host_ops = {
 	.register_host = exynos_dsi_register_host,
 	.unregister_host = exynos_dsi_unregister_host,
-	.attach = _exynos_dsi_host_attach,
-	.detach = _exynos_dsi_host_detach,
+	.attach = exynos_dsi_host_attach,
+	.detach = exynos_dsi_host_detach,
 };
 
-static const struct exynos_dsi_plat_data exynos3250_dsi_pdata = {
+static const struct samsung_dsim_plat_data exynos3250_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS3250,
-	.host_ops = &exynos_dsi_host_ops,
+	.host_ops = &exynos_dsi_exynos_host_ops,
 	.irq_ops = &exynos_dsi_irq_ops,
 };
 
-static const struct exynos_dsi_plat_data exynos4210_dsi_pdata = {
+static const struct samsung_dsim_plat_data exynos4210_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS4210,
-	.host_ops = &exynos_dsi_host_ops,
+	.host_ops = &exynos_dsi_exynos_host_ops,
 	.irq_ops = &exynos_dsi_irq_ops,
 };
 
-static const struct exynos_dsi_plat_data exynos5410_dsi_pdata = {
+static const struct samsung_dsim_plat_data exynos5410_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5410,
-	.host_ops = &exynos_dsi_host_ops,
+	.host_ops = &exynos_dsi_exynos_host_ops,
 	.irq_ops = &exynos_dsi_irq_ops,
 };
 
-static const struct exynos_dsi_plat_data exynos5422_dsi_pdata = {
+static const struct samsung_dsim_plat_data exynos5422_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5422,
-	.host_ops = &exynos_dsi_host_ops,
+	.host_ops = &exynos_dsi_exynos_host_ops,
 	.irq_ops = &exynos_dsi_irq_ops,
 };
 
-static const struct exynos_dsi_plat_data exynos5433_dsi_pdata = {
+static const struct samsung_dsim_plat_data exynos5433_dsi_pdata = {
 	.hw_type = DSIM_TYPE_EXYNOS5433,
-	.host_ops = &exynos_dsi_host_ops,
+	.host_ops = &exynos_dsi_exynos_host_ops,
 	.irq_ops = &exynos_dsi_irq_ops,
 };
 
@@ -2132,12 +265,12 @@ static const struct of_device_id exynos_dsi_of_match[] = {
 MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
 
 struct platform_driver dsi_driver = {
-	.probe = exynos_dsi_probe,
-	.remove = exynos_dsi_remove,
+	.probe = samsung_dsim_probe,
+	.remove = samsung_dsim_remove,
 	.driver = {
 		   .name = "exynos-dsi",
 		   .owner = THIS_MODULE,
-		   .pm = &exynos_dsi_pm_ops,
+		   .pm = &samsung_dsim_pm_ops,
 		   .of_match_table = exynos_dsi_of_match,
 	},
 };
diff --git a/include/drm/bridge/samsung-dsim.h b/include/drm/bridge/samsung-dsim.h
new file mode 100644
index 000000000000..e54e62f5f632
--- /dev/null
+++ b/include/drm/bridge/samsung-dsim.h
@@ -0,0 +1,118 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2022 Amarula Solutions(India)
+ * Author: Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+#ifndef __SAMSUNG_DSIM__
+#define __SAMSUNG_DSIM__
+
+#include <linux/regulator/consumer.h>
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_of.h>
+#include <drm/drm_mipi_dsi.h>
+
+struct samsung_dsim;
+
+#define DSIM_STATE_ENABLED		BIT(0)
+#define DSIM_STATE_INITIALIZED		BIT(1)
+#define DSIM_STATE_CMD_LPM		BIT(2)
+#define DSIM_STATE_VIDOUT_AVAILABLE	BIT(3)
+
+enum samsung_dsim_type {
+	DSIM_TYPE_EXYNOS3250,
+	DSIM_TYPE_EXYNOS4210,
+	DSIM_TYPE_EXYNOS5410,
+	DSIM_TYPE_EXYNOS5422,
+	DSIM_TYPE_EXYNOS5433,
+	DSIM_TYPE_IMX8MM,
+
+	DSIM_TYPE_COUNT,
+};
+
+#define samsung_dsim_hw_is_exynos(hw) \
+	((hw) >= DSIM_TYPE_EXYNOS3250 && (hw) <= DSIM_TYPE_EXYNOS5433)
+
+struct samsung_dsim_transfer {
+	struct list_head list;
+	struct completion completed;
+	int result;
+	struct mipi_dsi_packet packet;
+	u16 flags;
+	u16 tx_done;
+
+	u8 *rx_payload;
+	u16 rx_len;
+	u16 rx_done;
+};
+
+struct samsung_dsim_driver_data {
+	const unsigned int *reg_ofs;
+	unsigned int plltmr_reg;
+	unsigned int has_freqband:1;
+	unsigned int has_clklane_stop:1;
+	unsigned int num_clks;
+	unsigned int max_freq;
+	unsigned int wait_for_reset;
+	unsigned int num_bits_resol;
+	unsigned int pll_p_offset;
+	const unsigned int *reg_values;
+};
+
+struct samsung_dsim_host_ops {
+	int (*register_host)(struct samsung_dsim *priv);
+	void (*unregister_host)(struct samsung_dsim *priv);
+	int (*attach)(struct samsung_dsim *priv, struct mipi_dsi_device *device);
+	int (*detach)(struct samsung_dsim *priv, struct mipi_dsi_device *device);
+};
+
+struct samsung_dsim_irq_ops {
+	void (*enable)(struct samsung_dsim *priv);
+	void (*disable)(struct samsung_dsim *priv);
+};
+
+struct samsung_dsim_plat_data {
+	enum samsung_dsim_type hw_type;
+	const struct samsung_dsim_host_ops *host_ops;
+	const struct samsung_dsim_irq_ops *irq_ops;
+};
+
+struct samsung_dsim {
+	struct mipi_dsi_host dsi_host;
+	struct drm_bridge bridge;
+	struct drm_bridge *out_bridge;
+	struct device *dev;
+	struct drm_display_mode mode;
+
+	void __iomem *reg_base;
+	struct phy *phy;
+	struct clk **clks;
+	struct regulator_bulk_data supplies[2];
+	int irq;
+
+	u32 pll_clk_rate;
+	u32 burst_clk_rate;
+	u32 esc_clk_rate;
+	u32 lanes;
+	u32 mode_flags;
+	u32 format;
+
+	int state;
+	struct drm_property *brightness;
+	struct completion completed;
+
+	spinlock_t transfer_lock; /* protects transfer_list */
+	struct list_head transfer_list;
+
+	const struct samsung_dsim_driver_data *driver_data;
+	const struct samsung_dsim_plat_data *plat_data;
+
+	void *priv;
+};
+
+extern int samsung_dsim_probe(struct platform_device *pdev);
+extern int samsung_dsim_remove(struct platform_device *pdev);
+extern const struct dev_pm_ops samsung_dsim_pm_ops;
+
+#endif /* __SAMSUNG_DSIM__ */
-- 
2.25.1

[PATCH v10 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.

Cc: devicetree@vger.kernel.org
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for 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 v10 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.

Cc: devicetree@vger.kernel.org
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for 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 v10 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.

Cc: devicetree@vger.kernel.org
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for 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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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: 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 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 dd27935081a3..b14efb6fca91 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)
@@ -1793,7 +1828,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 v10 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: 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 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 dd27935081a3..b14efb6fca91 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)
@@ -1793,7 +1828,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 v10 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: 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 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 dd27935081a3..b14efb6fca91 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)
@@ -1793,7 +1828,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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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.

Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 v10 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.

Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 v10 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.

Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v10 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.

Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 b14efb6fca91..13ce21af3b4c 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)
@@ -1461,10 +1462,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;
@@ -1639,6 +1647,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,
 };
@@ -1728,6 +1740,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);
@@ -1833,11 +1847,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 e54e62f5f632..5b3dfcaf9fac 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -27,6 +27,7 @@ enum samsung_dsim_type {
 	DSIM_TYPE_EXYNOS5422,
 	DSIM_TYPE_EXYNOS5433,
 	DSIM_TYPE_IMX8MM,
+	DSIM_TYPE_IMX8MP,
 
 	DSIM_TYPE_COUNT,
 };
-- 
2.25.1

[PATCH v10 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.

Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 b14efb6fca91..13ce21af3b4c 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)
@@ -1461,10 +1462,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;
@@ -1639,6 +1647,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,
 };
@@ -1728,6 +1740,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);
@@ -1833,11 +1847,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 e54e62f5f632..5b3dfcaf9fac 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -27,6 +27,7 @@ enum samsung_dsim_type {
 	DSIM_TYPE_EXYNOS5422,
 	DSIM_TYPE_EXYNOS5433,
 	DSIM_TYPE_IMX8MM,
+	DSIM_TYPE_IMX8MP,
 
 	DSIM_TYPE_COUNT,
 };
-- 
2.25.1

[PATCH v10 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.

Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
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 b14efb6fca91..13ce21af3b4c 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)
@@ -1461,10 +1462,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;
@@ -1639,6 +1647,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,
 };
@@ -1728,6 +1740,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);
@@ -1833,11 +1847,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 e54e62f5f632..5b3dfcaf9fac 100644
--- a/include/drm/bridge/samsung-dsim.h
+++ b/include/drm/bridge/samsung-dsim.h
@@ -27,6 +27,7 @@ enum samsung_dsim_type {
 	DSIM_TYPE_EXYNOS5422,
 	DSIM_TYPE_EXYNOS5433,
 	DSIM_TYPE_IMX8MM,
+	DSIM_TYPE_IMX8MP,
 
 	DSIM_TYPE_COUNT,
 };
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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: Marek Vasut <marex@denx.de>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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: Marek Vasut <marex@denx.de>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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: Marek Vasut <marex@denx.de>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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.
> 
> Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> 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 | 84 ++++++++++++++++++++-----
>  1 file changed, 69 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 7a845badb1b2..fdaf514b39f2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -254,6 +254,16 @@ 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,
> +

The empty line looks a bit awkward to me. Otherwise:

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

> +	DSIM_TYPE_COUNT,
> +};
> +
[...]

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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.
> 
> Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> 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 | 84 ++++++++++++++++++++-----
>  1 file changed, 69 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 7a845badb1b2..fdaf514b39f2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -254,6 +254,16 @@ 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,
> +

The empty line looks a bit awkward to me. Otherwise:

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

> +	DSIM_TYPE_COUNT,
> +};
> +
[...]

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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.
> 
> Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> 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 | 84 ++++++++++++++++++++-----
>  1 file changed, 69 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 7a845badb1b2..fdaf514b39f2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -254,6 +254,16 @@ 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,
> +

The empty line looks a bit awkward to me. Otherwise:

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

> +	DSIM_TYPE_COUNT,
> +};
> +
[...]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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 a comment FIXME for this and updated the active low
> sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.
> 
> Comments are suggested by Marek Vasut.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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 a comment FIXME for this and updated the active low
> sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.
> 
> Comments are suggested by Marek Vasut.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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 a comment FIXME for this and updated the active low
> sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.
> 
> Comments are suggested by Marek Vasut.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frieder Schrempf]

On 15.12.22 09:39, Frieder Schrempf wrote:
> On 14.12.22 13:58, Jagan Teki wrote:
>> 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 a comment FIXME for this and updated the active low
>> sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.

By the way, the commit message mentions a FIXME comment above. But it's
not in the patch. The commit message probably needs an update.

>>
>> Comments are suggested by Marek Vasut.
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> 
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 15.12.22 09:39, Frieder Schrempf wrote:
> On 14.12.22 13:58, Jagan Teki wrote:
>> 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 a comment FIXME for this and updated the active low
>> sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.

By the way, the commit message mentions a FIXME comment above. But it's
not in the patch. The commit message probably needs an update.

>>
>> Comments are suggested by Marek Vasut.
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> 
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 15.12.22 09:39, Frieder Schrempf wrote:
> On 14.12.22 13:58, Jagan Teki wrote:
>> 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 a comment FIXME for this and updated the active low
>> sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type.

By the way, the commit message mentions a FIXME comment above. But it's
not in the patch. The commit message probably needs an update.

>>
>> Comments are suggested by Marek Vasut.
>>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> 
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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.
> 
> Suggested-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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.
> 
> Suggested-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:58, Jagan Teki wrote:
> 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.
> 
> Suggested-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frieder Schrempf]

On 14.12.22 13:59, 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
> 
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:59, 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
> 
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:59, 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
> 
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frieder Schrempf]

On 14.12.22 13:59, Jagan Teki wrote:
> Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.
> 
> Add compatible and associated driver_data for it.
> 
> 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>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:59, Jagan Teki wrote:
> Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.
> 
> Add compatible and associated driver_data for it.
> 
> 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>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:59, Jagan Teki wrote:
> Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.
> 
> Add compatible and associated driver_data for it.
> 
> 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>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frieder Schrempf]

On 14.12.22 13:59, Jagan Teki wrote:
> 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.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:59, Jagan Teki wrote:
> 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.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

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

[Frieder Schrempf]

On 14.12.22 13:59, Jagan Teki wrote:
> 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.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Robert Foss]

On Thu, 15 Dec 2022 at 10:22, Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 14.12.22 13:59, Jagan Teki wrote:
> > Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.
> >
> > Add compatible and associated driver_data for it.
> >
> > 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>
>
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

Acked-by: Robert Foss <robert.foss@linaro.org>

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

[Robert Foss]

On Thu, 15 Dec 2022 at 10:22, Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 14.12.22 13:59, Jagan Teki wrote:
> > Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.
> >
> > Add compatible and associated driver_data for it.
> >
> > 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>
>
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

Acked-by: Robert Foss <robert.foss@linaro.org>

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

[Robert Foss]

On Thu, 15 Dec 2022 at 10:22, Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 14.12.22 13:59, Jagan Teki wrote:
> > Samsung MIPI DSIM master can also be found in i.MX8M Mini/Nano SoC.
> >
> > Add compatible and associated driver_data for it.
> >
> > 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>
>
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

Acked-by: Robert Foss <robert.foss@linaro.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Robert Foss]

On Thu, 15 Dec 2022 at 10:23, Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 14.12.22 13:59, Jagan Teki wrote:
> > 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.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

Acked-by: Robert Foss <robert.foss@linaro.org>

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

[Robert Foss]

On Thu, 15 Dec 2022 at 10:23, Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 14.12.22 13:59, Jagan Teki wrote:
> > 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.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

Acked-by: Robert Foss <robert.foss@linaro.org>

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

[Robert Foss]

On Thu, 15 Dec 2022 at 10:23, Frieder Schrempf
<frieder.schrempf@kontron.de> wrote:
>
> On 14.12.22 13:59, Jagan Teki wrote:
> > 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.
> >
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>

Acked-by: Robert Foss <robert.foss@linaro.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Rob Herring]

On Wed, 14 Dec 2022 18:29:06 +0530, Jagan Teki wrote:
> Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC.
> 
> Add dt-bingings for it.
> 
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v10, v9:
> - none
> 
>  Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

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

[Rob Herring]

On Wed, 14 Dec 2022 18:29:06 +0530, Jagan Teki wrote:
> Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC.
> 
> Add dt-bingings for it.
> 
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v10, v9:
> - none
> 
>  Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

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

[Rob Herring]

On Wed, 14 Dec 2022 18:29:06 +0530, Jagan Teki wrote:
> Samsung MIPI DSIM bridge can also be found in i.MX8M Plus SoC.
> 
> Add dt-bingings for it.
> 
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v10, v9:
> - none
> 
>  Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Jagan Teki]

On Wed, Dec 14, 2022 at 6:29 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> 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: adding devm_drm_of_dsi_get_bridge
>
> 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 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
>
> v9:
> https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/
>
> Any inputs?
> Jagan.
>
> Jagan Teki (16):
>   drm: of: Lookup if child node has DSI panel or bridge
>   drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
>   drm: exynos: dsi: Drop explicit call to bridge detach
>   drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
>   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 Exynos based host irq hooks
>   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

Does anyone have any other comments on this? I would like to send v11
with a few nits on v10. Please let me know.

Thanks,
Jagan.

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

[Jagan Teki]

On Wed, Dec 14, 2022 at 6:29 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> 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: adding devm_drm_of_dsi_get_bridge
>
> 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 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
>
> v9:
> https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/
>
> Any inputs?
> Jagan.
>
> Jagan Teki (16):
>   drm: of: Lookup if child node has DSI panel or bridge
>   drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
>   drm: exynos: dsi: Drop explicit call to bridge detach
>   drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
>   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 Exynos based host irq hooks
>   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

Does anyone have any other comments on this? I would like to send v11
with a few nits on v10. Please let me know.

Thanks,
Jagan.

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

[Jagan Teki]

On Wed, Dec 14, 2022 at 6:29 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> 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: adding devm_drm_of_dsi_get_bridge
>
> 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 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
>
> v9:
> https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/
>
> Any inputs?
> Jagan.
>
> Jagan Teki (16):
>   drm: of: Lookup if child node has DSI panel or bridge
>   drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
>   drm: exynos: dsi: Drop explicit call to bridge detach
>   drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
>   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 Exynos based host irq hooks
>   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

Does anyone have any other comments on this? I would like to send v11
with a few nits on v10. Please let me know.

Thanks,
Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Adam Ford]

On Thu, Jan 5, 2023 at 4:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Wed, Dec 14, 2022 at 6:29 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > 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: adding devm_drm_of_dsi_get_bridge
> >
> > 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 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
> >
> > v9:
> > https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/
> >
> > Any inputs?
> > Jagan.
> >
> > Jagan Teki (16):
> >   drm: of: Lookup if child node has DSI panel or bridge
> >   drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
> >   drm: exynos: dsi: Drop explicit call to bridge detach
> >   drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
> >   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 Exynos based host irq hooks
> >   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
>
> Does anyone have any other comments on this? I would like to send v11
> with a few nits on v10. Please let me know.

I got it working on an LVDS display that I have, but I didn't get it
working on the HDMI bridge.  Since we have a few tested-by people,
it'd be nice to see this integrated so we can work on ading more
functionality

adam
>
> Thanks,
> Jagan.

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

[Adam Ford]

On Thu, Jan 5, 2023 at 4:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Wed, Dec 14, 2022 at 6:29 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > 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: adding devm_drm_of_dsi_get_bridge
> >
> > 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 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
> >
> > v9:
> > https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/
> >
> > Any inputs?
> > Jagan.
> >
> > Jagan Teki (16):
> >   drm: of: Lookup if child node has DSI panel or bridge
> >   drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
> >   drm: exynos: dsi: Drop explicit call to bridge detach
> >   drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
> >   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 Exynos based host irq hooks
> >   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
>
> Does anyone have any other comments on this? I would like to send v11
> with a few nits on v10. Please let me know.

I got it working on an LVDS display that I have, but I didn't get it
working on the HDMI bridge.  Since we have a few tested-by people,
it'd be nice to see this integrated so we can work on ading more
functionality

adam
>
> Thanks,
> Jagan.

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

[Adam Ford]

On Thu, Jan 5, 2023 at 4:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Wed, Dec 14, 2022 at 6:29 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > 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: adding devm_drm_of_dsi_get_bridge
> >
> > 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 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
> >
> > v9:
> > https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/
> >
> > Any inputs?
> > Jagan.
> >
> > Jagan Teki (16):
> >   drm: of: Lookup if child node has DSI panel or bridge
> >   drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
> >   drm: exynos: dsi: Drop explicit call to bridge detach
> >   drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
> >   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 Exynos based host irq hooks
> >   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
>
> Does anyone have any other comments on this? I would like to send v11
> with a few nits on v10. Please let me know.

I got it working on an LVDS display that I have, but I didn't get it
working on the HDMI bridge.  Since we have a few tested-by people,
it'd be nice to see this integrated so we can work on ading more
functionality

adam
>
> Thanks,
> Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Fabio Estevam]

On Fri, Jan 6, 2023 at 11:34 AM Adam Ford <aford173@gmail.com> wrote:

> I got it working on an LVDS display that I have, but I didn't get it
> working on the HDMI bridge.  Since we have a few tested-by people,
> it'd be nice to see this integrated so we can work on ading more
> functionality

Agreed. Hopefully, this series can be applied soon so we don't miss
another cycle.

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

[Fabio Estevam]

On Fri, Jan 6, 2023 at 11:34 AM Adam Ford <aford173@gmail.com> wrote:

> I got it working on an LVDS display that I have, but I didn't get it
> working on the HDMI bridge.  Since we have a few tested-by people,
> it'd be nice to see this integrated so we can work on ading more
> functionality

Agreed. Hopefully, this series can be applied soon so we don't miss
another cycle.

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

[Fabio Estevam]

On Fri, Jan 6, 2023 at 11:34 AM Adam Ford <aford173@gmail.com> wrote:

> I got it working on an LVDS display that I have, but I didn't get it
> working on the HDMI bridge.  Since we have a few tested-by people,
> it'd be nice to see this integrated so we can work on ading more
> functionality

Agreed. Hopefully, this series can be applied soon so we don't miss
another cycle.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Fabio Estevam]

Hi Jagan,

On Thu, Jan 5, 2023 at 7:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote:

> Does anyone have any other comments on this? I would like to send v11
> with a few nits on v10. Please let me know.

What is blocking this series to be applied?

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

[Fabio Estevam]

Hi Jagan,

On Thu, Jan 5, 2023 at 7:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote:

> Does anyone have any other comments on this? I would like to send v11
> with a few nits on v10. Please let me know.

What is blocking this series to be applied?

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

[Fabio Estevam]

Hi Jagan,

On Thu, Jan 5, 2023 at 7:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote:

> Does anyone have any other comments on this? I would like to send v11
> with a few nits on v10. Please let me know.

What is blocking this series to be applied?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Jagan Teki]

Hi Fabio,

On Thu, Jan 19, 2023 at 10:57 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Jagan,
>
> On Thu, Jan 5, 2023 at 7:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> > Does anyone have any other comments on this? I would like to send v11
> > with a few nits on v10. Please let me know.
>
> What is blocking this series to be applied?

There are two patch series prior to this need to apply.

https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

Regarding this series, the patch 09/18 commit message has "FIXME" this
need to remove.
https://patchwork.kernel.org/project/dri-devel/patch/20221214125907.376148-10-jagan@amarulasolutions.com/

I think it is possible to remove it while applying otherwise I will
resend this patch alone or in series again.

Jagan.

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

[Jagan Teki]

Hi Fabio,

On Thu, Jan 19, 2023 at 10:57 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Jagan,
>
> On Thu, Jan 5, 2023 at 7:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> > Does anyone have any other comments on this? I would like to send v11
> > with a few nits on v10. Please let me know.
>
> What is blocking this series to be applied?

There are two patch series prior to this need to apply.

https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

Regarding this series, the patch 09/18 commit message has "FIXME" this
need to remove.
https://patchwork.kernel.org/project/dri-devel/patch/20221214125907.376148-10-jagan@amarulasolutions.com/

I think it is possible to remove it while applying otherwise I will
resend this patch alone or in series again.

Jagan.

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

[Jagan Teki]

Hi Fabio,

On Thu, Jan 19, 2023 at 10:57 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Jagan,
>
> On Thu, Jan 5, 2023 at 7:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> > Does anyone have any other comments on this? I would like to send v11
> > with a few nits on v10. Please let me know.
>
> What is blocking this series to be applied?

There are two patch series prior to this need to apply.

https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

Regarding this series, the patch 09/18 commit message has "FIXME" this
need to remove.
https://patchwork.kernel.org/project/dri-devel/patch/20221214125907.376148-10-jagan@amarulasolutions.com/

I think it is possible to remove it while applying otherwise I will
resend this patch alone or in series again.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Fabio Estevam]

Hi Jagan,

On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:

> There are two patch series prior to this need to apply.
>
> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

Would it make sense to re-submit these two patches as part of your series?

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

[Fabio Estevam]

Hi Jagan,

On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:

> There are two patch series prior to this need to apply.
>
> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

Would it make sense to re-submit these two patches as part of your series?

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

[Fabio Estevam]

Hi Jagan,

On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:

> There are two patch series prior to this need to apply.
>
> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

Would it make sense to re-submit these two patches as part of your series?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Jagan Teki]

Hi Fabio,

On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Jagan,
>
> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> > There are two patch series prior to this need to apply.
> >
> > https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> > https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
>
> Would it make sense to re-submit these two patches as part of your series?

The previous version's comment was to separate them from the DSIM series.

Jagan.

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

[Jagan Teki]

Hi Fabio,

On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Jagan,
>
> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> > There are two patch series prior to this need to apply.
> >
> > https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> > https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
>
> Would it make sense to re-submit these two patches as part of your series?

The previous version's comment was to separate them from the DSIM series.

Jagan.

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

[Jagan Teki]

Hi Fabio,

On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Jagan,
>
> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> > There are two patch series prior to this need to apply.
> >
> > https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> > https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
>
> Would it make sense to re-submit these two patches as part of your series?

The previous version's comment was to separate them from the DSIM series.

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marek Vasut]

On 1/20/23 15:41, Jagan Teki wrote:
> Hi Fabio,

Hello all,

> On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
>>
>> Hi Jagan,
>>
>> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>>
>>> There are two patch series prior to this need to apply.
>>>
>>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
>>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
>>
>> Would it make sense to re-submit these two patches as part of your series?
> 
> The previous version's comment was to separate them from the DSIM series.

Hmmmmm, seems like those first two patches got stuck. I fixed up the 
malformed Fixes: line (it was split across two lines and had angular 
brackets around it) and picked the first series via drm-misc-next .

Can you send a subsequent patch to convert the DSIM_* macros to BIT() 
macro , since checkpatch --strict complains about it ?

For the second series, you likely want a RB from Maxime Ripard and Dave 
Stevenson first about the probe order handling.

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

[Marek Vasut]

On 1/20/23 15:41, Jagan Teki wrote:
> Hi Fabio,

Hello all,

> On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
>>
>> Hi Jagan,
>>
>> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>>
>>> There are two patch series prior to this need to apply.
>>>
>>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
>>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
>>
>> Would it make sense to re-submit these two patches as part of your series?
> 
> The previous version's comment was to separate them from the DSIM series.

Hmmmmm, seems like those first two patches got stuck. I fixed up the 
malformed Fixes: line (it was split across two lines and had angular 
brackets around it) and picked the first series via drm-misc-next .

Can you send a subsequent patch to convert the DSIM_* macros to BIT() 
macro , since checkpatch --strict complains about it ?

For the second series, you likely want a RB from Maxime Ripard and Dave 
Stevenson first about the probe order handling.

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

[Marek Vasut]

On 1/20/23 15:41, Jagan Teki wrote:
> Hi Fabio,

Hello all,

> On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
>>
>> Hi Jagan,
>>
>> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>>
>>> There are two patch series prior to this need to apply.
>>>
>>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
>>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
>>
>> Would it make sense to re-submit these two patches as part of your series?
> 
> The previous version's comment was to separate them from the DSIM series.

Hmmmmm, seems like those first two patches got stuck. I fixed up the 
malformed Fixes: line (it was split across two lines and had angular 
brackets around it) and picked the first series via drm-misc-next .

Can you send a subsequent patch to convert the DSIM_* macros to BIT() 
macro , since checkpatch --strict complains about it ?

For the second series, you likely want a RB from Maxime Ripard and Dave 
Stevenson first about the probe order handling.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Jagan Teki]

On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >>
> >>> There are two patch series prior to this need to apply.
> >>>
> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> >>
> >> Would it make sense to re-submit these two patches as part of your series?
> >
> > The previous version's comment was to separate them from the DSIM series.
>
> Hmmmmm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .

Thanks.

We have another series for Exynos, prior to DSIM
https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

>
> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> macro , since checkpatch --strict complains about it ?

Okay.

>
> For the second series, you likely want a RB from Maxime Ripard and Dave
> Stevenson first about the probe order handling.

Do you mean for 01/18 and 02/18 patches?

Jagan.

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

[Jagan Teki]

On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >>
> >>> There are two patch series prior to this need to apply.
> >>>
> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> >>
> >> Would it make sense to re-submit these two patches as part of your series?
> >
> > The previous version's comment was to separate them from the DSIM series.
>
> Hmmmmm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .

Thanks.

We have another series for Exynos, prior to DSIM
https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

>
> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> macro , since checkpatch --strict complains about it ?

Okay.

>
> For the second series, you likely want a RB from Maxime Ripard and Dave
> Stevenson first about the probe order handling.

Do you mean for 01/18 and 02/18 patches?

Jagan.

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

[Jagan Teki]

On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >>
> >>> There are two patch series prior to this need to apply.
> >>>
> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> >>
> >> Would it make sense to re-submit these two patches as part of your series?
> >
> > The previous version's comment was to separate them from the DSIM series.
>
> Hmmmmm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .

Thanks.

We have another series for Exynos, prior to DSIM
https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

>
> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> macro , since checkpatch --strict complains about it ?

Okay.

>
> For the second series, you likely want a RB from Maxime Ripard and Dave
> Stevenson first about the probe order handling.

Do you mean for 01/18 and 02/18 patches?

Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Dave Stevenson]

Hi Marek & Jagan

On Fri, 20 Jan 2023 at 15:06, Marek Vasut <marex@denx.de> wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >>
> >>> There are two patch series prior to this need to apply.
> >>>
> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> >>
> >> Would it make sense to re-submit these two patches as part of your series?
> >
> > The previous version's comment was to separate them from the DSIM series.
>
> Hmmmmm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .
>
> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> macro , since checkpatch --strict complains about it ?
>
> For the second series, you likely want a RB from Maxime Ripard and Dave
> Stevenson first about the probe order handling.

Not sure what I can add for "Enable prepare_prev_first flag for
samsung-s6e panels" and "tc358764: Enable pre_enable_prev_first flag"
as I have no datasheet for those devices.
On the basis that they are wanting the DSI host to be in LP-11 before
prepare/pre_enable, then setting the flag is the right thing. More
than happy to say
Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
to those two (I can't find them quickly in my mail to respond directly).

I have just sent a separate response on the third patch.

  Dave

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

[Dave Stevenson]

Hi Marek & Jagan

On Fri, 20 Jan 2023 at 15:06, Marek Vasut <marex@denx.de> wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >>
> >>> There are two patch series prior to this need to apply.
> >>>
> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> >>
> >> Would it make sense to re-submit these two patches as part of your series?
> >
> > The previous version's comment was to separate them from the DSIM series.
>
> Hmmmmm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .
>
> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> macro , since checkpatch --strict complains about it ?
>
> For the second series, you likely want a RB from Maxime Ripard and Dave
> Stevenson first about the probe order handling.

Not sure what I can add for "Enable prepare_prev_first flag for
samsung-s6e panels" and "tc358764: Enable pre_enable_prev_first flag"
as I have no datasheet for those devices.
On the basis that they are wanting the DSI host to be in LP-11 before
prepare/pre_enable, then setting the flag is the right thing. More
than happy to say
Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
to those two (I can't find them quickly in my mail to respond directly).

I have just sent a separate response on the third patch.

  Dave

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

[Dave Stevenson]

Hi Marek & Jagan

On Fri, 20 Jan 2023 at 15:06, Marek Vasut <marex@denx.de> wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >>
> >>> There are two patch series prior to this need to apply.
> >>>
> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> >>
> >> Would it make sense to re-submit these two patches as part of your series?
> >
> > The previous version's comment was to separate them from the DSIM series.
>
> Hmmmmm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .
>
> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> macro , since checkpatch --strict complains about it ?
>
> For the second series, you likely want a RB from Maxime Ripard and Dave
> Stevenson first about the probe order handling.

Not sure what I can add for "Enable prepare_prev_first flag for
samsung-s6e panels" and "tc358764: Enable pre_enable_prev_first flag"
as I have no datasheet for those devices.
On the basis that they are wanting the DSI host to be in LP-11 before
prepare/pre_enable, then setting the flag is the right thing. More
than happy to say
Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
to those two (I can't find them quickly in my mail to respond directly).

I have just sent a separate response on the third patch.

  Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marek Vasut]

On 1/20/23 19:54, Jagan Teki wrote:
> On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 1/20/23 15:41, Jagan Teki wrote:
>>> Hi Fabio,
>>
>> Hello all,
>>
>>> On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
>>>>
>>>> Hi Jagan,
>>>>
>>>> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>>>>
>>>>> There are two patch series prior to this need to apply.
>>>>>
>>>>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
>>>>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
>>>>
>>>> Would it make sense to re-submit these two patches as part of your series?
>>>
>>> The previous version's comment was to separate them from the DSIM series.
>>
>> Hmmmmm, seems like those first two patches got stuck. I fixed up the
>> malformed Fixes: line (it was split across two lines and had angular
>> brackets around it) and picked the first series via drm-misc-next .
> 
> Thanks.
> 
> We have another series for Exynos, prior to DSIM
> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> 
>>
>> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
>> macro , since checkpatch --strict complains about it ?
> 
> Okay.
> 
>>
>> For the second series, you likely want a RB from Maxime Ripard and Dave
>> Stevenson first about the probe order handling.
> 
> Do you mean for 01/18 and 02/18 patches?

I mean

https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

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

[Marek Vasut]

On 1/20/23 19:54, Jagan Teki wrote:
> On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 1/20/23 15:41, Jagan Teki wrote:
>>> Hi Fabio,
>>
>> Hello all,
>>
>>> On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
>>>>
>>>> Hi Jagan,
>>>>
>>>> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>>>>
>>>>> There are two patch series prior to this need to apply.
>>>>>
>>>>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
>>>>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
>>>>
>>>> Would it make sense to re-submit these two patches as part of your series?
>>>
>>> The previous version's comment was to separate them from the DSIM series.
>>
>> Hmmmmm, seems like those first two patches got stuck. I fixed up the
>> malformed Fixes: line (it was split across two lines and had angular
>> brackets around it) and picked the first series via drm-misc-next .
> 
> Thanks.
> 
> We have another series for Exynos, prior to DSIM
> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> 
>>
>> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
>> macro , since checkpatch --strict complains about it ?
> 
> Okay.
> 
>>
>> For the second series, you likely want a RB from Maxime Ripard and Dave
>> Stevenson first about the probe order handling.
> 
> Do you mean for 01/18 and 02/18 patches?

I mean

https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

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

[Marek Vasut]

On 1/20/23 19:54, Jagan Teki wrote:
> On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 1/20/23 15:41, Jagan Teki wrote:
>>> Hi Fabio,
>>
>> Hello all,
>>
>>> On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
>>>>
>>>> Hi Jagan,
>>>>
>>>> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>>>>
>>>>> There are two patch series prior to this need to apply.
>>>>>
>>>>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
>>>>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
>>>>
>>>> Would it make sense to re-submit these two patches as part of your series?
>>>
>>> The previous version's comment was to separate them from the DSIM series.
>>
>> Hmmmmm, seems like those first two patches got stuck. I fixed up the
>> malformed Fixes: line (it was split across two lines and had angular
>> brackets around it) and picked the first series via drm-misc-next .
> 
> Thanks.
> 
> We have another series for Exynos, prior to DSIM
> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> 
>>
>> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
>> macro , since checkpatch --strict complains about it ?
> 
> Okay.
> 
>>
>> For the second series, you likely want a RB from Maxime Ripard and Dave
>> Stevenson first about the probe order handling.
> 
> Do you mean for 01/18 and 02/18 patches?

I mean

https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Jagan Teki]

On Sat, Jan 21, 2023 at 12:29 AM Dave Stevenson
<dave.stevenson@raspberrypi.com> wrote:
>
> Hi Marek & Jagan
>
> On Fri, 20 Jan 2023 at 15:06, Marek Vasut <marex@denx.de> wrote:
> >
> > On 1/20/23 15:41, Jagan Teki wrote:
> > > Hi Fabio,
> >
> > Hello all,
> >
> > > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> > >>
> > >> Hi Jagan,
> > >>
> > >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >>
> > >>> There are two patch series prior to this need to apply.
> > >>>
> > >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> > >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> > >>
> > >> Would it make sense to re-submit these two patches as part of your series?
> > >
> > > The previous version's comment was to separate them from the DSIM series.
> >
> > Hmmmmm, seems like those first two patches got stuck. I fixed up the
> > malformed Fixes: line (it was split across two lines and had angular
> > brackets around it) and picked the first series via drm-misc-next .
> >
> > Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> > macro , since checkpatch --strict complains about it ?
> >
> > For the second series, you likely want a RB from Maxime Ripard and Dave
> > Stevenson first about the probe order handling.
>
> Not sure what I can add for "Enable prepare_prev_first flag for
> samsung-s6e panels" and "tc358764: Enable pre_enable_prev_first flag"
> as I have no datasheet for those devices.
> On the basis that they are wanting the DSI host to be in LP-11 before
> prepare/pre_enable, then setting the flag is the right thing. More
> than happy to say
> Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> to those two (I can't find them quickly in my mail to respond directly).
>
> I have just sent a separate response on the third patch.

Fyi: please check my answers on that thread.

Thanks,
Jagan.

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

[Jagan Teki]

On Sat, Jan 21, 2023 at 12:29 AM Dave Stevenson
<dave.stevenson@raspberrypi.com> wrote:
>
> Hi Marek & Jagan
>
> On Fri, 20 Jan 2023 at 15:06, Marek Vasut <marex@denx.de> wrote:
> >
> > On 1/20/23 15:41, Jagan Teki wrote:
> > > Hi Fabio,
> >
> > Hello all,
> >
> > > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> > >>
> > >> Hi Jagan,
> > >>
> > >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >>
> > >>> There are two patch series prior to this need to apply.
> > >>>
> > >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> > >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> > >>
> > >> Would it make sense to re-submit these two patches as part of your series?
> > >
> > > The previous version's comment was to separate them from the DSIM series.
> >
> > Hmmmmm, seems like those first two patches got stuck. I fixed up the
> > malformed Fixes: line (it was split across two lines and had angular
> > brackets around it) and picked the first series via drm-misc-next .
> >
> > Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> > macro , since checkpatch --strict complains about it ?
> >
> > For the second series, you likely want a RB from Maxime Ripard and Dave
> > Stevenson first about the probe order handling.
>
> Not sure what I can add for "Enable prepare_prev_first flag for
> samsung-s6e panels" and "tc358764: Enable pre_enable_prev_first flag"
> as I have no datasheet for those devices.
> On the basis that they are wanting the DSI host to be in LP-11 before
> prepare/pre_enable, then setting the flag is the right thing. More
> than happy to say
> Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> to those two (I can't find them quickly in my mail to respond directly).
>
> I have just sent a separate response on the third patch.

Fyi: please check my answers on that thread.

Thanks,
Jagan.

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

[Jagan Teki]

On Sat, Jan 21, 2023 at 12:29 AM Dave Stevenson
<dave.stevenson@raspberrypi.com> wrote:
>
> Hi Marek & Jagan
>
> On Fri, 20 Jan 2023 at 15:06, Marek Vasut <marex@denx.de> wrote:
> >
> > On 1/20/23 15:41, Jagan Teki wrote:
> > > Hi Fabio,
> >
> > Hello all,
> >
> > > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> > >>
> > >> Hi Jagan,
> > >>
> > >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > >>
> > >>> There are two patch series prior to this need to apply.
> > >>>
> > >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> > >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> > >>
> > >> Would it make sense to re-submit these two patches as part of your series?
> > >
> > > The previous version's comment was to separate them from the DSIM series.
> >
> > Hmmmmm, seems like those first two patches got stuck. I fixed up the
> > malformed Fixes: line (it was split across two lines and had angular
> > brackets around it) and picked the first series via drm-misc-next .
> >
> > Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> > macro , since checkpatch --strict complains about it ?
> >
> > For the second series, you likely want a RB from Maxime Ripard and Dave
> > Stevenson first about the probe order handling.
>
> Not sure what I can add for "Enable prepare_prev_first flag for
> samsung-s6e panels" and "tc358764: Enable pre_enable_prev_first flag"
> as I have no datasheet for those devices.
> On the basis that they are wanting the DSI host to be in LP-11 before
> prepare/pre_enable, then setting the flag is the right thing. More
> than happy to say
> Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> to those two (I can't find them quickly in my mail to respond directly).
>
> I have just sent a separate response on the third patch.

Fyi: please check my answers on that thread.

Thanks,
Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Jagan Teki]

Hi Marek,

On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >>
> >>> There are two patch series prior to this need to apply.
> >>>
> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> >>
> >> Would it make sense to re-submit these two patches as part of your series?
> >
> > The previous version's comment was to separate them from the DSIM series.
>
> Hmmmmm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .
>
> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> macro , since checkpatch --strict complains about it ?

Fyi: I sent the v11 series for this with RESEND prefix.

Let me know if you have any further comments on this.

Thanks,
Jagan.

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

[Jagan Teki]

Hi Marek,

On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >>
> >>> There are two patch series prior to this need to apply.
> >>>
> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> >>
> >> Would it make sense to re-submit these two patches as part of your series?
> >
> > The previous version's comment was to separate them from the DSIM series.
>
> Hmmmmm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .
>
> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> macro , since checkpatch --strict complains about it ?

Fyi: I sent the v11 series for this with RESEND prefix.

Let me know if you have any further comments on this.

Thanks,
Jagan.

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

[Jagan Teki]

Hi Marek,

On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >>
> >>> There are two patch series prior to this need to apply.
> >>>
> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/
> >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
> >>
> >> Would it make sense to re-submit these two patches as part of your series?
> >
> > The previous version's comment was to separate them from the DSIM series.
>
> Hmmmmm, seems like those first two patches got stuck. I fixed up the
> malformed Fixes: line (it was split across two lines and had angular
> brackets around it) and picked the first series via drm-misc-next .
>
> Can you send a subsequent patch to convert the DSIM_* macros to BIT()
> macro , since checkpatch --strict complains about it ?

Fyi: I sent the v11 series for this with RESEND prefix.

Let me know if you have any further comments on this.

Thanks,
Jagan.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Maxime Ripard]

On Wed, Jan 04, 2023 at 04:08:47PM +0100, Marek Vasut wrote:
> On 1/3/23 11:59, Alexander Stein wrote:
> > Hi,
> > 
> > Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
> > > On 12/18/22 23:24, Adam Ford wrote:
> > > > On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
> > > > > On 12/18/22 05:23, Adam Ford wrote:
> > > > > > On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
> > > > > > > On 12/16/22 14:25, Alexander Stein wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > > > Oh, nice, thanks for the pointer. When setting
> > > > > > > > 
> > > > > > > > > samsung,burst-clock-frequency = <668250000>;
> > > > > > > > 
> > > > > > > > in imx8mm.dtsi
> > > > > > > > I get a non-flickering display using 4 lanes. Although admittedly this
> > > > > > > > is just random guessing. I'm not sure which clock exactly has to be
> > > > > > > > in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes
> > > > > > > > SN65DSI84 is configured for>>>>>
> > > > > > > > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> > > > > > > > > samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> > > > > > > > > samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
> > > > > > > > > esc_clk
> > > > > > > > 
> > > > > > > > = 16706250
> > > > > > > 
> > > > > > > If I recall it right, minimum PLL frequency is:
> > > > > > > 
> > > > > > > fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> > > > > > > 
> > > > > > > the link frequency is then
> > > > > > > 
> > > > > > > fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> > > > > > > 
> > > > > > > So DSI83 should be in the range of 80..85 MHz input clock if I
> > > > > > > calculate
> > > > > > > this right. Can you check what is the value of mode->clock, the
> > > > > > > mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> > > > > > > sm65dsi83_get_dsi_range() ?
> > > > > > > 
> > > > > > > > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just
> > > > > > > > from DT
> > > > > > > > properties, while SN65DSI84 is using display mode and number of lanes.
> > > > > > > > 
> > > > > > > > Is it expected that the DSIM PLL frequencies are set in DT for a
> > > > > > > > specific
> > > > > > > > bridge/display setup?
> > > > > > > 
> > > > > > > No, there should be negotiation between the host and bridge/panel, I
> > > > > > > tried to propose two variants, but they were all rejected.
> > > > > > 
> > > > > > For one of Jagan's previous revisions, I added some code to let the
> > > > > > PHY auto adjust the frequencies instead of being fixed.  NXP had this
> > > > > > in their downstream kernel, but with this patch and another, I was
> > > > > > able to set a variety of pixel clocks from my HDMI monitor and my
> > > > > > DSI83. I haven't had time to re-base my work on Jagan's latest work,
> > > > > > but you can link to the patch I did for the older stuff here:
> > > > > > 
> > > > > > https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8
> > > > > > 8ab4b67e4 and
> > > > > > https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134
> > > > > > 75241936f
> > > > > > 
> > > > > > I've been traveling a lot lately, so I haven't had time to evaluate
> > > > > > his series, but I hope to get something like those re-based once the
> > > > > > DSI stuff has been accepted.
> > > > > 
> > > > > I have these two attempts, both rejected:
> > > > > 
> > > > > https://patchwork.freedesktop.org/patch/475207/
> > > > > https://patchwork.freedesktop.org/patch/496049/
> > > > 
> > > > I have some patches re-based to Jagan's latest branch.  It doesn't
> > > > impact any drivers other than the new samsung-dsim driver, and it
> > > > doesn't touch any of the drm helper functions either.  It adjusts hs
> > > > clock based on the connected device.  I am not sure what the impact
> > > > will have on the attached Exynos devices, so I am expecting some
> > > > iterations.  Right now it's working with my DSI83 chip, but I need to
> > > > get it working with my adv7535 part as well.  On the older branch, I
> > > > was able to sync the ad7535 with a variety of resolutions using
> > > > different pixel clock rates.
> > > > 
> > > > Once I get it working again with my adv7535 and cleaned up, I'll
> > > > submit the patches to the drm group, and I'll CC you, Jagan and Marek
> > > > Szyprowski with a reference to Jagan's series so people wanting to try
> > > > it can apply it to his branch.
> > > 
> > > The negotiation has to happen between the host and the bridge/panel,
> > > otherwise you won't be able to support bridge/panel devices which
> > > require specific clock rate on the DSI. Only the bridge/panel driver
> > > knows about such requirement.
> > 
> > AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable
> > callback. So at this point the negotiation has to be finished already.
> > Wouldn't it be possible to setup 'dsi->format' within a atomic_check for
> > samsung_dsim? But I don't know how you would get the expected clock frequency
> > from the downward bridge.

I have zero context there, so I'm not sure what proposals have been made
already, but why isn't it possible to do it the other way around and
make the bridge ask the upstream driver if it can provide the clock
frequency the bridge require?

It's pretty much how the common clock framework works too: you set the
rate on the leaf clock, and it propagates upwards in your tree,
adjusting for any constraint we have along the way.

It does need to happen at atomic_check time though, otherwise it would
be terrible for anyone attempting to use that driver.

Maxime

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

[Maxime Ripard]

On Wed, Jan 04, 2023 at 04:08:47PM +0100, Marek Vasut wrote:
> On 1/3/23 11:59, Alexander Stein wrote:
> > Hi,
> > 
> > Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
> > > On 12/18/22 23:24, Adam Ford wrote:
> > > > On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
> > > > > On 12/18/22 05:23, Adam Ford wrote:
> > > > > > On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
> > > > > > > On 12/16/22 14:25, Alexander Stein wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > > > Oh, nice, thanks for the pointer. When setting
> > > > > > > > 
> > > > > > > > > samsung,burst-clock-frequency = <668250000>;
> > > > > > > > 
> > > > > > > > in imx8mm.dtsi
> > > > > > > > I get a non-flickering display using 4 lanes. Although admittedly this
> > > > > > > > is just random guessing. I'm not sure which clock exactly has to be
> > > > > > > > in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes
> > > > > > > > SN65DSI84 is configured for>>>>>
> > > > > > > > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> > > > > > > > > samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> > > > > > > > > samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
> > > > > > > > > esc_clk
> > > > > > > > 
> > > > > > > > = 16706250
> > > > > > > 
> > > > > > > If I recall it right, minimum PLL frequency is:
> > > > > > > 
> > > > > > > fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> > > > > > > 
> > > > > > > the link frequency is then
> > > > > > > 
> > > > > > > fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> > > > > > > 
> > > > > > > So DSI83 should be in the range of 80..85 MHz input clock if I
> > > > > > > calculate
> > > > > > > this right. Can you check what is the value of mode->clock, the
> > > > > > > mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> > > > > > > sm65dsi83_get_dsi_range() ?
> > > > > > > 
> > > > > > > > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just
> > > > > > > > from DT
> > > > > > > > properties, while SN65DSI84 is using display mode and number of lanes.
> > > > > > > > 
> > > > > > > > Is it expected that the DSIM PLL frequencies are set in DT for a
> > > > > > > > specific
> > > > > > > > bridge/display setup?
> > > > > > > 
> > > > > > > No, there should be negotiation between the host and bridge/panel, I
> > > > > > > tried to propose two variants, but they were all rejected.
> > > > > > 
> > > > > > For one of Jagan's previous revisions, I added some code to let the
> > > > > > PHY auto adjust the frequencies instead of being fixed.  NXP had this
> > > > > > in their downstream kernel, but with this patch and another, I was
> > > > > > able to set a variety of pixel clocks from my HDMI monitor and my
> > > > > > DSI83. I haven't had time to re-base my work on Jagan's latest work,
> > > > > > but you can link to the patch I did for the older stuff here:
> > > > > > 
> > > > > > https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8
> > > > > > 8ab4b67e4 and
> > > > > > https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134
> > > > > > 75241936f
> > > > > > 
> > > > > > I've been traveling a lot lately, so I haven't had time to evaluate
> > > > > > his series, but I hope to get something like those re-based once the
> > > > > > DSI stuff has been accepted.
> > > > > 
> > > > > I have these two attempts, both rejected:
> > > > > 
> > > > > https://patchwork.freedesktop.org/patch/475207/
> > > > > https://patchwork.freedesktop.org/patch/496049/
> > > > 
> > > > I have some patches re-based to Jagan's latest branch.  It doesn't
> > > > impact any drivers other than the new samsung-dsim driver, and it
> > > > doesn't touch any of the drm helper functions either.  It adjusts hs
> > > > clock based on the connected device.  I am not sure what the impact
> > > > will have on the attached Exynos devices, so I am expecting some
> > > > iterations.  Right now it's working with my DSI83 chip, but I need to
> > > > get it working with my adv7535 part as well.  On the older branch, I
> > > > was able to sync the ad7535 with a variety of resolutions using
> > > > different pixel clock rates.
> > > > 
> > > > Once I get it working again with my adv7535 and cleaned up, I'll
> > > > submit the patches to the drm group, and I'll CC you, Jagan and Marek
> > > > Szyprowski with a reference to Jagan's series so people wanting to try
> > > > it can apply it to his branch.
> > > 
> > > The negotiation has to happen between the host and the bridge/panel,
> > > otherwise you won't be able to support bridge/panel devices which
> > > require specific clock rate on the DSI. Only the bridge/panel driver
> > > knows about such requirement.
> > 
> > AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable
> > callback. So at this point the negotiation has to be finished already.
> > Wouldn't it be possible to setup 'dsi->format' within a atomic_check for
> > samsung_dsim? But I don't know how you would get the expected clock frequency
> > from the downward bridge.

I have zero context there, so I'm not sure what proposals have been made
already, but why isn't it possible to do it the other way around and
make the bridge ask the upstream driver if it can provide the clock
frequency the bridge require?

It's pretty much how the common clock framework works too: you set the
rate on the leaf clock, and it propagates upwards in your tree,
adjusting for any constraint we have along the way.

It does need to happen at atomic_check time though, otherwise it would
be terrible for anyone attempting to use that driver.

Maxime

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Maxime Ripard]

On Wed, Jan 04, 2023 at 04:08:47PM +0100, Marek Vasut wrote:
> On 1/3/23 11:59, Alexander Stein wrote:
> > Hi,
> > 
> > Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
> > > On 12/18/22 23:24, Adam Ford wrote:
> > > > On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
> > > > > On 12/18/22 05:23, Adam Ford wrote:
> > > > > > On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
> > > > > > > On 12/16/22 14:25, Alexander Stein wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > > > Oh, nice, thanks for the pointer. When setting
> > > > > > > > 
> > > > > > > > > samsung,burst-clock-frequency = <668250000>;
> > > > > > > > 
> > > > > > > > in imx8mm.dtsi
> > > > > > > > I get a non-flickering display using 4 lanes. Although admittedly this
> > > > > > > > is just random guessing. I'm not sure which clock exactly has to be
> > > > > > > > in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes
> > > > > > > > SN65DSI84 is configured for>>>>>
> > > > > > > > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> > > > > > > > > samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> > > > > > > > > samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
> > > > > > > > > esc_clk
> > > > > > > > 
> > > > > > > > = 16706250
> > > > > > > 
> > > > > > > If I recall it right, minimum PLL frequency is:
> > > > > > > 
> > > > > > > fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> > > > > > > 
> > > > > > > the link frequency is then
> > > > > > > 
> > > > > > > fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> > > > > > > 
> > > > > > > So DSI83 should be in the range of 80..85 MHz input clock if I
> > > > > > > calculate
> > > > > > > this right. Can you check what is the value of mode->clock, the
> > > > > > > mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> > > > > > > sm65dsi83_get_dsi_range() ?
> > > > > > > 
> > > > > > > > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just
> > > > > > > > from DT
> > > > > > > > properties, while SN65DSI84 is using display mode and number of lanes.
> > > > > > > > 
> > > > > > > > Is it expected that the DSIM PLL frequencies are set in DT for a
> > > > > > > > specific
> > > > > > > > bridge/display setup?
> > > > > > > 
> > > > > > > No, there should be negotiation between the host and bridge/panel, I
> > > > > > > tried to propose two variants, but they were all rejected.
> > > > > > 
> > > > > > For one of Jagan's previous revisions, I added some code to let the
> > > > > > PHY auto adjust the frequencies instead of being fixed.  NXP had this
> > > > > > in their downstream kernel, but with this patch and another, I was
> > > > > > able to set a variety of pixel clocks from my HDMI monitor and my
> > > > > > DSI83. I haven't had time to re-base my work on Jagan's latest work,
> > > > > > but you can link to the patch I did for the older stuff here:
> > > > > > 
> > > > > > https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8
> > > > > > 8ab4b67e4 and
> > > > > > https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134
> > > > > > 75241936f
> > > > > > 
> > > > > > I've been traveling a lot lately, so I haven't had time to evaluate
> > > > > > his series, but I hope to get something like those re-based once the
> > > > > > DSI stuff has been accepted.
> > > > > 
> > > > > I have these two attempts, both rejected:
> > > > > 
> > > > > https://patchwork.freedesktop.org/patch/475207/
> > > > > https://patchwork.freedesktop.org/patch/496049/
> > > > 
> > > > I have some patches re-based to Jagan's latest branch.  It doesn't
> > > > impact any drivers other than the new samsung-dsim driver, and it
> > > > doesn't touch any of the drm helper functions either.  It adjusts hs
> > > > clock based on the connected device.  I am not sure what the impact
> > > > will have on the attached Exynos devices, so I am expecting some
> > > > iterations.  Right now it's working with my DSI83 chip, but I need to
> > > > get it working with my adv7535 part as well.  On the older branch, I
> > > > was able to sync the ad7535 with a variety of resolutions using
> > > > different pixel clock rates.
> > > > 
> > > > Once I get it working again with my adv7535 and cleaned up, I'll
> > > > submit the patches to the drm group, and I'll CC you, Jagan and Marek
> > > > Szyprowski with a reference to Jagan's series so people wanting to try
> > > > it can apply it to his branch.
> > > 
> > > The negotiation has to happen between the host and the bridge/panel,
> > > otherwise you won't be able to support bridge/panel devices which
> > > require specific clock rate on the DSI. Only the bridge/panel driver
> > > knows about such requirement.
> > 
> > AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable
> > callback. So at this point the negotiation has to be finished already.
> > Wouldn't it be possible to setup 'dsi->format' within a atomic_check for
> > samsung_dsim? But I don't know how you would get the expected clock frequency
> > from the downward bridge.

I have zero context there, so I'm not sure what proposals have been made
already, but why isn't it possible to do it the other way around and
make the bridge ask the upstream driver if it can provide the clock
frequency the bridge require?

It's pretty much how the common clock framework works too: you set the
rate on the leaf clock, and it propagates upwards in your tree,
adjusting for any constraint we have along the way.

It does need to happen at atomic_check time though, otherwise it would
be terrible for anyone attempting to use that driver.

Maxime

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

[Marek Vasut]

On 1/3/23 11:59, Alexander Stein wrote:
> Hi,
> 
> Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
>> On 12/18/22 23:24, Adam Ford wrote:
>>> On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
>>>> On 12/18/22 05:23, Adam Ford wrote:
>>>>> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>>>>>> On 12/16/22 14:25, Alexander Stein wrote:
>>>>>> Hi,
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> Oh, nice, thanks for the pointer. When setting
>>>>>>>
>>>>>>>> samsung,burst-clock-frequency = <668250000>;
>>>>>>>
>>>>>>> in imx8mm.dtsi
>>>>>>> I get a non-flickering display using 4 lanes. Although admittedly this
>>>>>>> is just random guessing. I'm not sure which clock exactly has to be
>>>>>>> in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes
>>>>>>> SN65DSI84 is configured for>>>>>
>>>>>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>>>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>>>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
>>>>>>>> esc_clk
>>>>>>>
>>>>>>> = 16706250
>>>>>>
>>>>>> If I recall it right, minimum PLL frequency is:
>>>>>>
>>>>>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>>>>>
>>>>>> the link frequency is then
>>>>>>
>>>>>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>>>>>>
>>>>>> So DSI83 should be in the range of 80..85 MHz input clock if I
>>>>>> calculate
>>>>>> this right. Can you check what is the value of mode->clock, the
>>>>>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>>>>>> sm65dsi83_get_dsi_range() ?
>>>>>>
>>>>>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just
>>>>>>> from DT
>>>>>>> properties, while SN65DSI84 is using display mode and number of lanes.
>>>>>>>
>>>>>>> Is it expected that the DSIM PLL frequencies are set in DT for a
>>>>>>> specific
>>>>>>> bridge/display setup?
>>>>>>
>>>>>> No, there should be negotiation between the host and bridge/panel, I
>>>>>> tried to propose two variants, but they were all rejected.
>>>>>
>>>>> For one of Jagan's previous revisions, I added some code to let the
>>>>> PHY auto adjust the frequencies instead of being fixed.  NXP had this
>>>>> in their downstream kernel, but with this patch and another, I was
>>>>> able to set a variety of pixel clocks from my HDMI monitor and my
>>>>> DSI83. I haven't had time to re-base my work on Jagan's latest work,
>>>>> but you can link to the patch I did for the older stuff here:
>>>>>
>>>>> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8
>>>>> 8ab4b67e4 and
>>>>> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134
>>>>> 75241936f
>>>>>
>>>>> I've been traveling a lot lately, so I haven't had time to evaluate
>>>>> his series, but I hope to get something like those re-based once the
>>>>> DSI stuff has been accepted.
>>>>
>>>> I have these two attempts, both rejected:
>>>>
>>>> https://patchwork.freedesktop.org/patch/475207/
>>>> https://patchwork.freedesktop.org/patch/496049/
>>>
>>> I have some patches re-based to Jagan's latest branch.  It doesn't
>>> impact any drivers other than the new samsung-dsim driver, and it
>>> doesn't touch any of the drm helper functions either.  It adjusts hs
>>> clock based on the connected device.  I am not sure what the impact
>>> will have on the attached Exynos devices, so I am expecting some
>>> iterations.  Right now it's working with my DSI83 chip, but I need to
>>> get it working with my adv7535 part as well.  On the older branch, I
>>> was able to sync the ad7535 with a variety of resolutions using
>>> different pixel clock rates.
>>>
>>> Once I get it working again with my adv7535 and cleaned up, I'll
>>> submit the patches to the drm group, and I'll CC you, Jagan and Marek
>>> Szyprowski with a reference to Jagan's series so people wanting to try
>>> it can apply it to his branch.
>>
>> The negotiation has to happen between the host and the bridge/panel,
>> otherwise you won't be able to support bridge/panel devices which
>> require specific clock rate on the DSI. Only the bridge/panel driver
>> knows about such requirement.
> 
> AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable
> callback. So at this point the negotiation has to be finished already.
> Wouldn't it be possible to setup 'dsi->format' within a atomic_check for
> samsung_dsim? But I don't know how you would get the expected clock frequency
> from the downward bridge.

Maybe Maxime can comment on this ?

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

[Marek Vasut]

On 1/3/23 11:59, Alexander Stein wrote:
> Hi,
> 
> Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
>> On 12/18/22 23:24, Adam Ford wrote:
>>> On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
>>>> On 12/18/22 05:23, Adam Ford wrote:
>>>>> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>>>>>> On 12/16/22 14:25, Alexander Stein wrote:
>>>>>> Hi,
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> Oh, nice, thanks for the pointer. When setting
>>>>>>>
>>>>>>>> samsung,burst-clock-frequency = <668250000>;
>>>>>>>
>>>>>>> in imx8mm.dtsi
>>>>>>> I get a non-flickering display using 4 lanes. Although admittedly this
>>>>>>> is just random guessing. I'm not sure which clock exactly has to be
>>>>>>> in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes
>>>>>>> SN65DSI84 is configured for>>>>>
>>>>>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>>>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>>>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
>>>>>>>> esc_clk
>>>>>>>
>>>>>>> = 16706250
>>>>>>
>>>>>> If I recall it right, minimum PLL frequency is:
>>>>>>
>>>>>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>>>>>
>>>>>> the link frequency is then
>>>>>>
>>>>>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>>>>>>
>>>>>> So DSI83 should be in the range of 80..85 MHz input clock if I
>>>>>> calculate
>>>>>> this right. Can you check what is the value of mode->clock, the
>>>>>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>>>>>> sm65dsi83_get_dsi_range() ?
>>>>>>
>>>>>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just
>>>>>>> from DT
>>>>>>> properties, while SN65DSI84 is using display mode and number of lanes.
>>>>>>>
>>>>>>> Is it expected that the DSIM PLL frequencies are set in DT for a
>>>>>>> specific
>>>>>>> bridge/display setup?
>>>>>>
>>>>>> No, there should be negotiation between the host and bridge/panel, I
>>>>>> tried to propose two variants, but they were all rejected.
>>>>>
>>>>> For one of Jagan's previous revisions, I added some code to let the
>>>>> PHY auto adjust the frequencies instead of being fixed.  NXP had this
>>>>> in their downstream kernel, but with this patch and another, I was
>>>>> able to set a variety of pixel clocks from my HDMI monitor and my
>>>>> DSI83. I haven't had time to re-base my work on Jagan's latest work,
>>>>> but you can link to the patch I did for the older stuff here:
>>>>>
>>>>> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8
>>>>> 8ab4b67e4 and
>>>>> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134
>>>>> 75241936f
>>>>>
>>>>> I've been traveling a lot lately, so I haven't had time to evaluate
>>>>> his series, but I hope to get something like those re-based once the
>>>>> DSI stuff has been accepted.
>>>>
>>>> I have these two attempts, both rejected:
>>>>
>>>> https://patchwork.freedesktop.org/patch/475207/
>>>> https://patchwork.freedesktop.org/patch/496049/
>>>
>>> I have some patches re-based to Jagan's latest branch.  It doesn't
>>> impact any drivers other than the new samsung-dsim driver, and it
>>> doesn't touch any of the drm helper functions either.  It adjusts hs
>>> clock based on the connected device.  I am not sure what the impact
>>> will have on the attached Exynos devices, so I am expecting some
>>> iterations.  Right now it's working with my DSI83 chip, but I need to
>>> get it working with my adv7535 part as well.  On the older branch, I
>>> was able to sync the ad7535 with a variety of resolutions using
>>> different pixel clock rates.
>>>
>>> Once I get it working again with my adv7535 and cleaned up, I'll
>>> submit the patches to the drm group, and I'll CC you, Jagan and Marek
>>> Szyprowski with a reference to Jagan's series so people wanting to try
>>> it can apply it to his branch.
>>
>> The negotiation has to happen between the host and the bridge/panel,
>> otherwise you won't be able to support bridge/panel devices which
>> require specific clock rate on the DSI. Only the bridge/panel driver
>> knows about such requirement.
> 
> AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable
> callback. So at this point the negotiation has to be finished already.
> Wouldn't it be possible to setup 'dsi->format' within a atomic_check for
> samsung_dsim? But I don't know how you would get the expected clock frequency
> from the downward bridge.

Maybe Maxime can comment on this ?

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

[Marek Vasut]

On 1/3/23 11:59, Alexander Stein wrote:
> Hi,
> 
> Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
>> On 12/18/22 23:24, Adam Ford wrote:
>>> On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
>>>> On 12/18/22 05:23, Adam Ford wrote:
>>>>> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>>>>>> On 12/16/22 14:25, Alexander Stein wrote:
>>>>>> Hi,
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> Oh, nice, thanks for the pointer. When setting
>>>>>>>
>>>>>>>> samsung,burst-clock-frequency = <668250000>;
>>>>>>>
>>>>>>> in imx8mm.dtsi
>>>>>>> I get a non-flickering display using 4 lanes. Although admittedly this
>>>>>>> is just random guessing. I'm not sure which clock exactly has to be
>>>>>>> in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes
>>>>>>> SN65DSI84 is configured for>>>>>
>>>>>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>>>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>>>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
>>>>>>>> esc_clk
>>>>>>>
>>>>>>> = 16706250
>>>>>>
>>>>>> If I recall it right, minimum PLL frequency is:
>>>>>>
>>>>>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>>>>>
>>>>>> the link frequency is then
>>>>>>
>>>>>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>>>>>>
>>>>>> So DSI83 should be in the range of 80..85 MHz input clock if I
>>>>>> calculate
>>>>>> this right. Can you check what is the value of mode->clock, the
>>>>>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>>>>>> sm65dsi83_get_dsi_range() ?
>>>>>>
>>>>>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just
>>>>>>> from DT
>>>>>>> properties, while SN65DSI84 is using display mode and number of lanes.
>>>>>>>
>>>>>>> Is it expected that the DSIM PLL frequencies are set in DT for a
>>>>>>> specific
>>>>>>> bridge/display setup?
>>>>>>
>>>>>> No, there should be negotiation between the host and bridge/panel, I
>>>>>> tried to propose two variants, but they were all rejected.
>>>>>
>>>>> For one of Jagan's previous revisions, I added some code to let the
>>>>> PHY auto adjust the frequencies instead of being fixed.  NXP had this
>>>>> in their downstream kernel, but with this patch and another, I was
>>>>> able to set a variety of pixel clocks from my HDMI monitor and my
>>>>> DSI83. I haven't had time to re-base my work on Jagan's latest work,
>>>>> but you can link to the patch I did for the older stuff here:
>>>>>
>>>>> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8
>>>>> 8ab4b67e4 and
>>>>> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134
>>>>> 75241936f
>>>>>
>>>>> I've been traveling a lot lately, so I haven't had time to evaluate
>>>>> his series, but I hope to get something like those re-based once the
>>>>> DSI stuff has been accepted.
>>>>
>>>> I have these two attempts, both rejected:
>>>>
>>>> https://patchwork.freedesktop.org/patch/475207/
>>>> https://patchwork.freedesktop.org/patch/496049/
>>>
>>> I have some patches re-based to Jagan's latest branch.  It doesn't
>>> impact any drivers other than the new samsung-dsim driver, and it
>>> doesn't touch any of the drm helper functions either.  It adjusts hs
>>> clock based on the connected device.  I am not sure what the impact
>>> will have on the attached Exynos devices, so I am expecting some
>>> iterations.  Right now it's working with my DSI83 chip, but I need to
>>> get it working with my adv7535 part as well.  On the older branch, I
>>> was able to sync the ad7535 with a variety of resolutions using
>>> different pixel clock rates.
>>>
>>> Once I get it working again with my adv7535 and cleaned up, I'll
>>> submit the patches to the drm group, and I'll CC you, Jagan and Marek
>>> Szyprowski with a reference to Jagan's series so people wanting to try
>>> it can apply it to his branch.
>>
>> The negotiation has to happen between the host and the bridge/panel,
>> otherwise you won't be able to support bridge/panel devices which
>> require specific clock rate on the DSI. Only the bridge/panel driver
>> knows about such requirement.
> 
> AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable
> callback. So at this point the negotiation has to be finished already.
> Wouldn't it be possible to setup 'dsi->format' within a atomic_check for
> samsung_dsim? But I don't know how you would get the expected clock frequency
> from the downward bridge.

Maybe Maxime can comment on this ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marek Vasut]

On 1/3/23 10:51, Alexander Stein wrote:
> Hi Marek,
> 
> Am Sonntag, 18. Dezember 2022, 00:55:57 CET schrieb Marek Vasut:
>> On 12/16/22 14:25, Alexander Stein wrote:
>> Hi,
>>
>> [...]
>>
>>> Oh, nice, thanks for the pointer. When setting
>>>
>>>> samsung,burst-clock-frequency = <668250000>;
>>>
>>> in imx8mm.dtsi
>>> I get a non-flickering display using 4 lanes. Although admittedly this is
>>> just random guessing. I'm not sure which clock exactly has to be in the
>>> range CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is
>>> configured for>
>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
>>>> esc_clk
>>>
>>> = 16706250
>>
>> If I recall it right, minimum PLL frequency is:
>>
>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>
>> the link frequency is then
>>
>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> 
> Mh, there is something bogus about this. Right now the PLL freq is set
> depending on 'samsung,burst-clock-frequency' property. But this actually is
> somehow depending on the number of lanes I configure. From the debug output
> hs_clk and PLL freq are identical. AFAICS there is also no divider from PLL to
> hs_clk in the register map.

Could it be that samsung,burst-clock-frequency is fPMS / 2 ?

>> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
>> this right. Can you check what is the value of mode->clock, the
>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>> sm65dsi83_get_dsi_range() ?
> 
> A working setup on a tianma,tm070jvhg33 display (1280x800) is:
>> samsung-dsim 32e10000.dsi: PLL freq 891000000, (p 3, m 99, s 0)
>> samsung-dsim 32e10000.dsi: hs_clk = 891000000, byte_clk = 111375000, esc_clk
> = 18562500
>> sn65dsi83 2-002d: mode->clock: 68200
>> sn65dsi83 2-002d: mode bpp: 24
>> sn65dsi83 2-002d: ctx->dsi->lanes: 3
>> sn65dsi83 2-002d: samsung_dsim_set_pll: 0x37
> 
> Calculating backwards, sn64dsi83 is expecting a clock in the range of 275-280
> MHz. But I fail to see a corresponding clock in the DSIM PLL configuration.

294.9 MHz, no ? 1280x800x24x60x1.2 / 3 / 2 = 294.9 .

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

[Marek Vasut]

On 1/3/23 10:51, Alexander Stein wrote:
> Hi Marek,
> 
> Am Sonntag, 18. Dezember 2022, 00:55:57 CET schrieb Marek Vasut:
>> On 12/16/22 14:25, Alexander Stein wrote:
>> Hi,
>>
>> [...]
>>
>>> Oh, nice, thanks for the pointer. When setting
>>>
>>>> samsung,burst-clock-frequency = <668250000>;
>>>
>>> in imx8mm.dtsi
>>> I get a non-flickering display using 4 lanes. Although admittedly this is
>>> just random guessing. I'm not sure which clock exactly has to be in the
>>> range CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is
>>> configured for>
>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
>>>> esc_clk
>>>
>>> = 16706250
>>
>> If I recall it right, minimum PLL frequency is:
>>
>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>
>> the link frequency is then
>>
>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> 
> Mh, there is something bogus about this. Right now the PLL freq is set
> depending on 'samsung,burst-clock-frequency' property. But this actually is
> somehow depending on the number of lanes I configure. From the debug output
> hs_clk and PLL freq are identical. AFAICS there is also no divider from PLL to
> hs_clk in the register map.

Could it be that samsung,burst-clock-frequency is fPMS / 2 ?

>> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
>> this right. Can you check what is the value of mode->clock, the
>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>> sm65dsi83_get_dsi_range() ?
> 
> A working setup on a tianma,tm070jvhg33 display (1280x800) is:
>> samsung-dsim 32e10000.dsi: PLL freq 891000000, (p 3, m 99, s 0)
>> samsung-dsim 32e10000.dsi: hs_clk = 891000000, byte_clk = 111375000, esc_clk
> = 18562500
>> sn65dsi83 2-002d: mode->clock: 68200
>> sn65dsi83 2-002d: mode bpp: 24
>> sn65dsi83 2-002d: ctx->dsi->lanes: 3
>> sn65dsi83 2-002d: samsung_dsim_set_pll: 0x37
> 
> Calculating backwards, sn64dsi83 is expecting a clock in the range of 275-280
> MHz. But I fail to see a corresponding clock in the DSIM PLL configuration.

294.9 MHz, no ? 1280x800x24x60x1.2 / 3 / 2 = 294.9 .

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

[Marek Vasut]

On 1/3/23 10:51, Alexander Stein wrote:
> Hi Marek,
> 
> Am Sonntag, 18. Dezember 2022, 00:55:57 CET schrieb Marek Vasut:
>> On 12/16/22 14:25, Alexander Stein wrote:
>> Hi,
>>
>> [...]
>>
>>> Oh, nice, thanks for the pointer. When setting
>>>
>>>> samsung,burst-clock-frequency = <668250000>;
>>>
>>> in imx8mm.dtsi
>>> I get a non-flickering display using 4 lanes. Although admittedly this is
>>> just random guessing. I'm not sure which clock exactly has to be in the
>>> range CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is
>>> configured for>
>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
>>>> esc_clk
>>>
>>> = 16706250
>>
>> If I recall it right, minimum PLL frequency is:
>>
>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>
>> the link frequency is then
>>
>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> 
> Mh, there is something bogus about this. Right now the PLL freq is set
> depending on 'samsung,burst-clock-frequency' property. But this actually is
> somehow depending on the number of lanes I configure. From the debug output
> hs_clk and PLL freq are identical. AFAICS there is also no divider from PLL to
> hs_clk in the register map.

Could it be that samsung,burst-clock-frequency is fPMS / 2 ?

>> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
>> this right. Can you check what is the value of mode->clock, the
>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>> sm65dsi83_get_dsi_range() ?
> 
> A working setup on a tianma,tm070jvhg33 display (1280x800) is:
>> samsung-dsim 32e10000.dsi: PLL freq 891000000, (p 3, m 99, s 0)
>> samsung-dsim 32e10000.dsi: hs_clk = 891000000, byte_clk = 111375000, esc_clk
> = 18562500
>> sn65dsi83 2-002d: mode->clock: 68200
>> sn65dsi83 2-002d: mode bpp: 24
>> sn65dsi83 2-002d: ctx->dsi->lanes: 3
>> sn65dsi83 2-002d: samsung_dsim_set_pll: 0x37
> 
> Calculating backwards, sn64dsi83 is expecting a clock in the range of 275-280
> MHz. But I fail to see a corresponding clock in the DSIM PLL configuration.

294.9 MHz, no ? 1280x800x24x60x1.2 / 3 / 2 = 294.9 .

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Alexander Stein]

Hi,

Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
> On 12/18/22 23:24, Adam Ford wrote:
> > On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
> >> On 12/18/22 05:23, Adam Ford wrote:
> >>> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
> >>>> On 12/16/22 14:25, Alexander Stein wrote:
> >>>> Hi,
> >>>> 
> >>>> [...]
> >>>> 
> >>>>> Oh, nice, thanks for the pointer. When setting
> >>>>> 
> >>>>>> samsung,burst-clock-frequency = <668250000>;
> >>>>> 
> >>>>> in imx8mm.dtsi
> >>>>> I get a non-flickering display using 4 lanes. Although admittedly this
> >>>>> is just random guessing. I'm not sure which clock exactly has to be
> >>>>> in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes
> >>>>> SN65DSI84 is configured for>>>>> 
> >>>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >>>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >>>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
> >>>>>> esc_clk
> >>>>> 
> >>>>> = 16706250
> >>>> 
> >>>> If I recall it right, minimum PLL frequency is:
> >>>> 
> >>>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> >>>> 
> >>>> the link frequency is then
> >>>> 
> >>>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> >>>> 
> >>>> So DSI83 should be in the range of 80..85 MHz input clock if I
> >>>> calculate
> >>>> this right. Can you check what is the value of mode->clock, the
> >>>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> >>>> sm65dsi83_get_dsi_range() ?
> >>>> 
> >>>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just
> >>>>> from DT
> >>>>> properties, while SN65DSI84 is using display mode and number of lanes.
> >>>>> 
> >>>>> Is it expected that the DSIM PLL frequencies are set in DT for a
> >>>>> specific
> >>>>> bridge/display setup?
> >>>> 
> >>>> No, there should be negotiation between the host and bridge/panel, I
> >>>> tried to propose two variants, but they were all rejected.
> >>> 
> >>> For one of Jagan's previous revisions, I added some code to let the
> >>> PHY auto adjust the frequencies instead of being fixed.  NXP had this
> >>> in their downstream kernel, but with this patch and another, I was
> >>> able to set a variety of pixel clocks from my HDMI monitor and my
> >>> DSI83. I haven't had time to re-base my work on Jagan's latest work,
> >>> but you can link to the patch I did for the older stuff here:
> >>> 
> >>> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8
> >>> 8ab4b67e4 and
> >>> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134
> >>> 75241936f
> >>> 
> >>> I've been traveling a lot lately, so I haven't had time to evaluate
> >>> his series, but I hope to get something like those re-based once the
> >>> DSI stuff has been accepted.
> >> 
> >> I have these two attempts, both rejected:
> >> 
> >> https://patchwork.freedesktop.org/patch/475207/
> >> https://patchwork.freedesktop.org/patch/496049/
> > 
> > I have some patches re-based to Jagan's latest branch.  It doesn't
> > impact any drivers other than the new samsung-dsim driver, and it
> > doesn't touch any of the drm helper functions either.  It adjusts hs
> > clock based on the connected device.  I am not sure what the impact
> > will have on the attached Exynos devices, so I am expecting some
> > iterations.  Right now it's working with my DSI83 chip, but I need to
> > get it working with my adv7535 part as well.  On the older branch, I
> > was able to sync the ad7535 with a variety of resolutions using
> > different pixel clock rates.
> > 
> > Once I get it working again with my adv7535 and cleaned up, I'll
> > submit the patches to the drm group, and I'll CC you, Jagan and Marek
> > Szyprowski with a reference to Jagan's series so people wanting to try
> > it can apply it to his branch.
> 
> The negotiation has to happen between the host and the bridge/panel,
> otherwise you won't be able to support bridge/panel devices which
> require specific clock rate on the DSI. Only the bridge/panel driver
> knows about such requirement.

AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable 
callback. So at this point the negotiation has to be finished already.
Wouldn't it be possible to setup 'dsi->format' within a atomic_check for 
samsung_dsim? But I don't know how you would get the expected clock frequency 
from the downward bridge.

Best regards,
Alexander

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

[Alexander Stein]

Hi,

Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
> On 12/18/22 23:24, Adam Ford wrote:
> > On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
> >> On 12/18/22 05:23, Adam Ford wrote:
> >>> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
> >>>> On 12/16/22 14:25, Alexander Stein wrote:
> >>>> Hi,
> >>>> 
> >>>> [...]
> >>>> 
> >>>>> Oh, nice, thanks for the pointer. When setting
> >>>>> 
> >>>>>> samsung,burst-clock-frequency = <668250000>;
> >>>>> 
> >>>>> in imx8mm.dtsi
> >>>>> I get a non-flickering display using 4 lanes. Although admittedly this
> >>>>> is just random guessing. I'm not sure which clock exactly has to be
> >>>>> in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes
> >>>>> SN65DSI84 is configured for>>>>> 
> >>>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >>>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >>>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
> >>>>>> esc_clk
> >>>>> 
> >>>>> = 16706250
> >>>> 
> >>>> If I recall it right, minimum PLL frequency is:
> >>>> 
> >>>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> >>>> 
> >>>> the link frequency is then
> >>>> 
> >>>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> >>>> 
> >>>> So DSI83 should be in the range of 80..85 MHz input clock if I
> >>>> calculate
> >>>> this right. Can you check what is the value of mode->clock, the
> >>>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> >>>> sm65dsi83_get_dsi_range() ?
> >>>> 
> >>>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just
> >>>>> from DT
> >>>>> properties, while SN65DSI84 is using display mode and number of lanes.
> >>>>> 
> >>>>> Is it expected that the DSIM PLL frequencies are set in DT for a
> >>>>> specific
> >>>>> bridge/display setup?
> >>>> 
> >>>> No, there should be negotiation between the host and bridge/panel, I
> >>>> tried to propose two variants, but they were all rejected.
> >>> 
> >>> For one of Jagan's previous revisions, I added some code to let the
> >>> PHY auto adjust the frequencies instead of being fixed.  NXP had this
> >>> in their downstream kernel, but with this patch and another, I was
> >>> able to set a variety of pixel clocks from my HDMI monitor and my
> >>> DSI83. I haven't had time to re-base my work on Jagan's latest work,
> >>> but you can link to the patch I did for the older stuff here:
> >>> 
> >>> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8
> >>> 8ab4b67e4 and
> >>> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134
> >>> 75241936f
> >>> 
> >>> I've been traveling a lot lately, so I haven't had time to evaluate
> >>> his series, but I hope to get something like those re-based once the
> >>> DSI stuff has been accepted.
> >> 
> >> I have these two attempts, both rejected:
> >> 
> >> https://patchwork.freedesktop.org/patch/475207/
> >> https://patchwork.freedesktop.org/patch/496049/
> > 
> > I have some patches re-based to Jagan's latest branch.  It doesn't
> > impact any drivers other than the new samsung-dsim driver, and it
> > doesn't touch any of the drm helper functions either.  It adjusts hs
> > clock based on the connected device.  I am not sure what the impact
> > will have on the attached Exynos devices, so I am expecting some
> > iterations.  Right now it's working with my DSI83 chip, but I need to
> > get it working with my adv7535 part as well.  On the older branch, I
> > was able to sync the ad7535 with a variety of resolutions using
> > different pixel clock rates.
> > 
> > Once I get it working again with my adv7535 and cleaned up, I'll
> > submit the patches to the drm group, and I'll CC you, Jagan and Marek
> > Szyprowski with a reference to Jagan's series so people wanting to try
> > it can apply it to his branch.
> 
> The negotiation has to happen between the host and the bridge/panel,
> otherwise you won't be able to support bridge/panel devices which
> require specific clock rate on the DSI. Only the bridge/panel driver
> knows about such requirement.

AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable 
callback. So at this point the negotiation has to be finished already.
Wouldn't it be possible to setup 'dsi->format' within a atomic_check for 
samsung_dsim? But I don't know how you would get the expected clock frequency 
from the downward bridge.

Best regards,
Alexander

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

[Alexander Stein]

Hi,

Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
> On 12/18/22 23:24, Adam Ford wrote:
> > On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
> >> On 12/18/22 05:23, Adam Ford wrote:
> >>> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
> >>>> On 12/16/22 14:25, Alexander Stein wrote:
> >>>> Hi,
> >>>> 
> >>>> [...]
> >>>> 
> >>>>> Oh, nice, thanks for the pointer. When setting
> >>>>> 
> >>>>>> samsung,burst-clock-frequency = <668250000>;
> >>>>> 
> >>>>> in imx8mm.dtsi
> >>>>> I get a non-flickering display using 4 lanes. Although admittedly this
> >>>>> is just random guessing. I'm not sure which clock exactly has to be
> >>>>> in the range CHA_DSI_CLK_RANGE is configured to. With 4 lanes
> >>>>> SN65DSI84 is configured for>>>>> 
> >>>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >>>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >>>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
> >>>>>> esc_clk
> >>>>> 
> >>>>> = 16706250
> >>>> 
> >>>> If I recall it right, minimum PLL frequency is:
> >>>> 
> >>>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> >>>> 
> >>>> the link frequency is then
> >>>> 
> >>>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> >>>> 
> >>>> So DSI83 should be in the range of 80..85 MHz input clock if I
> >>>> calculate
> >>>> this right. Can you check what is the value of mode->clock, the
> >>>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> >>>> sm65dsi83_get_dsi_range() ?
> >>>> 
> >>>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just
> >>>>> from DT
> >>>>> properties, while SN65DSI84 is using display mode and number of lanes.
> >>>>> 
> >>>>> Is it expected that the DSIM PLL frequencies are set in DT for a
> >>>>> specific
> >>>>> bridge/display setup?
> >>>> 
> >>>> No, there should be negotiation between the host and bridge/panel, I
> >>>> tried to propose two variants, but they were all rejected.
> >>> 
> >>> For one of Jagan's previous revisions, I added some code to let the
> >>> PHY auto adjust the frequencies instead of being fixed.  NXP had this
> >>> in their downstream kernel, but with this patch and another, I was
> >>> able to set a variety of pixel clocks from my HDMI monitor and my
> >>> DSI83. I haven't had time to re-base my work on Jagan's latest work,
> >>> but you can link to the patch I did for the older stuff here:
> >>> 
> >>> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb8
> >>> 8ab4b67e4 and
> >>> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef6398134
> >>> 75241936f
> >>> 
> >>> I've been traveling a lot lately, so I haven't had time to evaluate
> >>> his series, but I hope to get something like those re-based once the
> >>> DSI stuff has been accepted.
> >> 
> >> I have these two attempts, both rejected:
> >> 
> >> https://patchwork.freedesktop.org/patch/475207/
> >> https://patchwork.freedesktop.org/patch/496049/
> > 
> > I have some patches re-based to Jagan's latest branch.  It doesn't
> > impact any drivers other than the new samsung-dsim driver, and it
> > doesn't touch any of the drm helper functions either.  It adjusts hs
> > clock based on the connected device.  I am not sure what the impact
> > will have on the attached Exynos devices, so I am expecting some
> > iterations.  Right now it's working with my DSI83 chip, but I need to
> > get it working with my adv7535 part as well.  On the older branch, I
> > was able to sync the ad7535 with a variety of resolutions using
> > different pixel clock rates.
> > 
> > Once I get it working again with my adv7535 and cleaned up, I'll
> > submit the patches to the drm group, and I'll CC you, Jagan and Marek
> > Szyprowski with a reference to Jagan's series so people wanting to try
> > it can apply it to his branch.
> 
> The negotiation has to happen between the host and the bridge/panel,
> otherwise you won't be able to support bridge/panel devices which
> require specific clock rate on the DSI. Only the bridge/panel driver
> knows about such requirement.

AFAICS using Adam's patch the dynamic DPHY config is done in atomic_pre_enable 
callback. So at this point the negotiation has to be finished already.
Wouldn't it be possible to setup 'dsi->format' within a atomic_check for 
samsung_dsim? But I don't know how you would get the expected clock frequency 
from the downward bridge.

Best regards,
Alexander



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Alexander Stein]

Hi Marek,

Am Sonntag, 18. Dezember 2022, 00:55:57 CET schrieb Marek Vasut:
> On 12/16/22 14:25, Alexander Stein wrote:
> Hi,
> 
> [...]
> 
> > Oh, nice, thanks for the pointer. When setting
> > 
> >> samsung,burst-clock-frequency = <668250000>;
> > 
> > in imx8mm.dtsi
> > I get a non-flickering display using 4 lanes. Although admittedly this is
> > just random guessing. I'm not sure which clock exactly has to be in the
> > range CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is
> > configured for> 
> > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
> >> esc_clk
> > 
> > = 16706250
> 
> If I recall it right, minimum PLL frequency is:
> 
> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> 
> the link frequency is then
> 
> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)

Mh, there is something bogus about this. Right now the PLL freq is set 
depending on 'samsung,burst-clock-frequency' property. But this actually is 
somehow depending on the number of lanes I configure. From the debug output 
hs_clk and PLL freq are identical. AFAICS there is also no divider from PLL to 
hs_clk in the register map.

> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
> this right. Can you check what is the value of mode->clock, the
> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> sm65dsi83_get_dsi_range() ?

A working setup on a tianma,tm070jvhg33 display (1280x800) is:
> samsung-dsim 32e10000.dsi: PLL freq 891000000, (p 3, m 99, s 0)
> samsung-dsim 32e10000.dsi: hs_clk = 891000000, byte_clk = 111375000, esc_clk 
= 18562500
> sn65dsi83 2-002d: mode->clock: 68200
> sn65dsi83 2-002d: mode bpp: 24
> sn65dsi83 2-002d: ctx->dsi->lanes: 3
> sn65dsi83 2-002d: samsung_dsim_set_pll: 0x37

Calculating backwards, sn64dsi83 is expecting a clock in the range of 275-280 
MHz. But I fail to see a corresponding clock in the DSIM PLL configuration.

Best regards,
Alexander

> > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from
> > DT
> > properties, while SN65DSI84 is using display mode and number of lanes.
> > 
> > Is it expected that the DSIM PLL frequencies are set in DT for a specific
> > bridge/display setup?
> 
> No, there should be negotiation between the host and bridge/panel, I
> tried to propose two variants, but they were all rejected.

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

[Alexander Stein]

Hi Marek,

Am Sonntag, 18. Dezember 2022, 00:55:57 CET schrieb Marek Vasut:
> On 12/16/22 14:25, Alexander Stein wrote:
> Hi,
> 
> [...]
> 
> > Oh, nice, thanks for the pointer. When setting
> > 
> >> samsung,burst-clock-frequency = <668250000>;
> > 
> > in imx8mm.dtsi
> > I get a non-flickering display using 4 lanes. Although admittedly this is
> > just random guessing. I'm not sure which clock exactly has to be in the
> > range CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is
> > configured for> 
> > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
> >> esc_clk
> > 
> > = 16706250
> 
> If I recall it right, minimum PLL frequency is:
> 
> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> 
> the link frequency is then
> 
> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)

Mh, there is something bogus about this. Right now the PLL freq is set 
depending on 'samsung,burst-clock-frequency' property. But this actually is 
somehow depending on the number of lanes I configure. From the debug output 
hs_clk and PLL freq are identical. AFAICS there is also no divider from PLL to 
hs_clk in the register map.

> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
> this right. Can you check what is the value of mode->clock, the
> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> sm65dsi83_get_dsi_range() ?

A working setup on a tianma,tm070jvhg33 display (1280x800) is:
> samsung-dsim 32e10000.dsi: PLL freq 891000000, (p 3, m 99, s 0)
> samsung-dsim 32e10000.dsi: hs_clk = 891000000, byte_clk = 111375000, esc_clk 
= 18562500
> sn65dsi83 2-002d: mode->clock: 68200
> sn65dsi83 2-002d: mode bpp: 24
> sn65dsi83 2-002d: ctx->dsi->lanes: 3
> sn65dsi83 2-002d: samsung_dsim_set_pll: 0x37

Calculating backwards, sn64dsi83 is expecting a clock in the range of 275-280 
MHz. But I fail to see a corresponding clock in the DSIM PLL configuration.

Best regards,
Alexander

> > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from
> > DT
> > properties, while SN65DSI84 is using display mode and number of lanes.
> > 
> > Is it expected that the DSIM PLL frequencies are set in DT for a specific
> > bridge/display setup?
> 
> No, there should be negotiation between the host and bridge/panel, I
> tried to propose two variants, but they were all rejected.

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

[Alexander Stein]

Hi Marek,

Am Sonntag, 18. Dezember 2022, 00:55:57 CET schrieb Marek Vasut:
> On 12/16/22 14:25, Alexander Stein wrote:
> Hi,
> 
> [...]
> 
> > Oh, nice, thanks for the pointer. When setting
> > 
> >> samsung,burst-clock-frequency = <668250000>;
> > 
> > in imx8mm.dtsi
> > I get a non-flickering display using 4 lanes. Although admittedly this is
> > just random guessing. I'm not sure which clock exactly has to be in the
> > range CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is
> > configured for> 
> > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250,
> >> esc_clk
> > 
> > = 16706250
> 
> If I recall it right, minimum PLL frequency is:
> 
> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> 
> the link frequency is then
> 
> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)

Mh, there is something bogus about this. Right now the PLL freq is set 
depending on 'samsung,burst-clock-frequency' property. But this actually is 
somehow depending on the number of lanes I configure. From the debug output 
hs_clk and PLL freq are identical. AFAICS there is also no divider from PLL to 
hs_clk in the register map.

> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
> this right. Can you check what is the value of mode->clock, the
> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> sm65dsi83_get_dsi_range() ?

A working setup on a tianma,tm070jvhg33 display (1280x800) is:
> samsung-dsim 32e10000.dsi: PLL freq 891000000, (p 3, m 99, s 0)
> samsung-dsim 32e10000.dsi: hs_clk = 891000000, byte_clk = 111375000, esc_clk 
= 18562500
> sn65dsi83 2-002d: mode->clock: 68200
> sn65dsi83 2-002d: mode bpp: 24
> sn65dsi83 2-002d: ctx->dsi->lanes: 3
> sn65dsi83 2-002d: samsung_dsim_set_pll: 0x37

Calculating backwards, sn64dsi83 is expecting a clock in the range of 275-280 
MHz. But I fail to see a corresponding clock in the DSIM PLL configuration.

Best regards,
Alexander

> > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from
> > DT
> > properties, while SN65DSI84 is using display mode and number of lanes.
> > 
> > Is it expected that the DSIM PLL frequencies are set in DT for a specific
> > bridge/display setup?
> 
> No, there should be negotiation between the host and bridge/panel, I
> tried to propose two variants, but they were all rejected.





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marek Vasut]

On 12/18/22 23:24, Adam Ford wrote:
> On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 12/18/22 05:23, Adam Ford wrote:
>>> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 12/16/22 14:25, Alexander Stein wrote:
>>>> Hi,
>>>>
>>>> [...]
>>>>
>>>>> Oh, nice, thanks for the pointer. When setting
>>>>>> samsung,burst-clock-frequency = <668250000>;
>>>>> in imx8mm.dtsi
>>>>> I get a non-flickering display using 4 lanes. Although admittedly this is just
>>>>> random guessing. I'm not sure which clock exactly has to be in the range
>>>>> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
>>>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
>>>>> = 16706250
>>>>
>>>> If I recall it right, minimum PLL frequency is:
>>>>
>>>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>>>
>>>> the link frequency is then
>>>>
>>>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>>>>
>>>> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
>>>> this right. Can you check what is the value of mode->clock, the
>>>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>>>> sm65dsi83_get_dsi_range() ?
>>>>
>>>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
>>>>> properties, while SN65DSI84 is using display mode and number of lanes.
>>>>>
>>>>> Is it expected that the DSIM PLL frequencies are set in DT for a specific
>>>>> bridge/display setup?
>>>>
>>>> No, there should be negotiation between the host and bridge/panel, I
>>>> tried to propose two variants, but they were all rejected.
>>>
>>> For one of Jagan's previous revisions, I added some code to let the
>>> PHY auto adjust the frequencies instead of being fixed.  NXP had this
>>> in their downstream kernel, but with this patch and another, I was
>>> able to set a variety of pixel clocks from my HDMI monitor and my
>>> DSI83. I haven't had time to re-base my work on Jagan's latest work,
>>> but you can link to the patch I did for the older stuff here:
>>>
>>> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
>>> and
>>> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f
>>>
>>> I've been traveling a lot lately, so I haven't had time to evaluate
>>> his series, but I hope to get something like those re-based once the
>>> DSI stuff has been accepted.
>>
>> I have these two attempts, both rejected:
>>
>> https://patchwork.freedesktop.org/patch/475207/
>> https://patchwork.freedesktop.org/patch/496049/
> 
> I have some patches re-based to Jagan's latest branch.  It doesn't
> impact any drivers other than the new samsung-dsim driver, and it
> doesn't touch any of the drm helper functions either.  It adjusts hs
> clock based on the connected device.  I am not sure what the impact
> will have on the attached Exynos devices, so I am expecting some
> iterations.  Right now it's working with my DSI83 chip, but I need to
> get it working with my adv7535 part as well.  On the older branch, I
> was able to sync the ad7535 with a variety of resolutions using
> different pixel clock rates.
> 
> Once I get it working again with my adv7535 and cleaned up, I'll
> submit the patches to the drm group, and I'll CC you, Jagan and Marek
> Szyprowski with a reference to Jagan's series so people wanting to try
> it can apply it to his branch.

The negotiation has to happen between the host and the bridge/panel, 
otherwise you won't be able to support bridge/panel devices which 
require specific clock rate on the DSI. Only the bridge/panel driver 
knows about such requirement.

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

[Marek Vasut]

On 12/18/22 23:24, Adam Ford wrote:
> On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 12/18/22 05:23, Adam Ford wrote:
>>> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 12/16/22 14:25, Alexander Stein wrote:
>>>> Hi,
>>>>
>>>> [...]
>>>>
>>>>> Oh, nice, thanks for the pointer. When setting
>>>>>> samsung,burst-clock-frequency = <668250000>;
>>>>> in imx8mm.dtsi
>>>>> I get a non-flickering display using 4 lanes. Although admittedly this is just
>>>>> random guessing. I'm not sure which clock exactly has to be in the range
>>>>> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
>>>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
>>>>> = 16706250
>>>>
>>>> If I recall it right, minimum PLL frequency is:
>>>>
>>>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>>>
>>>> the link frequency is then
>>>>
>>>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>>>>
>>>> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
>>>> this right. Can you check what is the value of mode->clock, the
>>>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>>>> sm65dsi83_get_dsi_range() ?
>>>>
>>>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
>>>>> properties, while SN65DSI84 is using display mode and number of lanes.
>>>>>
>>>>> Is it expected that the DSIM PLL frequencies are set in DT for a specific
>>>>> bridge/display setup?
>>>>
>>>> No, there should be negotiation between the host and bridge/panel, I
>>>> tried to propose two variants, but they were all rejected.
>>>
>>> For one of Jagan's previous revisions, I added some code to let the
>>> PHY auto adjust the frequencies instead of being fixed.  NXP had this
>>> in their downstream kernel, but with this patch and another, I was
>>> able to set a variety of pixel clocks from my HDMI monitor and my
>>> DSI83. I haven't had time to re-base my work on Jagan's latest work,
>>> but you can link to the patch I did for the older stuff here:
>>>
>>> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
>>> and
>>> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f
>>>
>>> I've been traveling a lot lately, so I haven't had time to evaluate
>>> his series, but I hope to get something like those re-based once the
>>> DSI stuff has been accepted.
>>
>> I have these two attempts, both rejected:
>>
>> https://patchwork.freedesktop.org/patch/475207/
>> https://patchwork.freedesktop.org/patch/496049/
> 
> I have some patches re-based to Jagan's latest branch.  It doesn't
> impact any drivers other than the new samsung-dsim driver, and it
> doesn't touch any of the drm helper functions either.  It adjusts hs
> clock based on the connected device.  I am not sure what the impact
> will have on the attached Exynos devices, so I am expecting some
> iterations.  Right now it's working with my DSI83 chip, but I need to
> get it working with my adv7535 part as well.  On the older branch, I
> was able to sync the ad7535 with a variety of resolutions using
> different pixel clock rates.
> 
> Once I get it working again with my adv7535 and cleaned up, I'll
> submit the patches to the drm group, and I'll CC you, Jagan and Marek
> Szyprowski with a reference to Jagan's series so people wanting to try
> it can apply it to his branch.

The negotiation has to happen between the host and the bridge/panel, 
otherwise you won't be able to support bridge/panel devices which 
require specific clock rate on the DSI. Only the bridge/panel driver 
knows about such requirement.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marek Vasut]

On 12/18/22 23:24, Adam Ford wrote:
> On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 12/18/22 05:23, Adam Ford wrote:
>>> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> On 12/16/22 14:25, Alexander Stein wrote:
>>>> Hi,
>>>>
>>>> [...]
>>>>
>>>>> Oh, nice, thanks for the pointer. When setting
>>>>>> samsung,burst-clock-frequency = <668250000>;
>>>>> in imx8mm.dtsi
>>>>> I get a non-flickering display using 4 lanes. Although admittedly this is just
>>>>> random guessing. I'm not sure which clock exactly has to be in the range
>>>>> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
>>>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
>>>>> = 16706250
>>>>
>>>> If I recall it right, minimum PLL frequency is:
>>>>
>>>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>>>
>>>> the link frequency is then
>>>>
>>>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>>>>
>>>> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
>>>> this right. Can you check what is the value of mode->clock, the
>>>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>>>> sm65dsi83_get_dsi_range() ?
>>>>
>>>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
>>>>> properties, while SN65DSI84 is using display mode and number of lanes.
>>>>>
>>>>> Is it expected that the DSIM PLL frequencies are set in DT for a specific
>>>>> bridge/display setup?
>>>>
>>>> No, there should be negotiation between the host and bridge/panel, I
>>>> tried to propose two variants, but they were all rejected.
>>>
>>> For one of Jagan's previous revisions, I added some code to let the
>>> PHY auto adjust the frequencies instead of being fixed.  NXP had this
>>> in their downstream kernel, but with this patch and another, I was
>>> able to set a variety of pixel clocks from my HDMI monitor and my
>>> DSI83. I haven't had time to re-base my work on Jagan's latest work,
>>> but you can link to the patch I did for the older stuff here:
>>>
>>> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
>>> and
>>> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f
>>>
>>> I've been traveling a lot lately, so I haven't had time to evaluate
>>> his series, but I hope to get something like those re-based once the
>>> DSI stuff has been accepted.
>>
>> I have these two attempts, both rejected:
>>
>> https://patchwork.freedesktop.org/patch/475207/
>> https://patchwork.freedesktop.org/patch/496049/
> 
> I have some patches re-based to Jagan's latest branch.  It doesn't
> impact any drivers other than the new samsung-dsim driver, and it
> doesn't touch any of the drm helper functions either.  It adjusts hs
> clock based on the connected device.  I am not sure what the impact
> will have on the attached Exynos devices, so I am expecting some
> iterations.  Right now it's working with my DSI83 chip, but I need to
> get it working with my adv7535 part as well.  On the older branch, I
> was able to sync the ad7535 with a variety of resolutions using
> different pixel clock rates.
> 
> Once I get it working again with my adv7535 and cleaned up, I'll
> submit the patches to the drm group, and I'll CC you, Jagan and Marek
> Szyprowski with a reference to Jagan's series so people wanting to try
> it can apply it to his branch.

The negotiation has to happen between the host and the bridge/panel, 
otherwise you won't be able to support bridge/panel devices which 
require specific clock rate on the DSI. Only the bridge/panel driver 
knows about such requirement.

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

[Adam Ford]

On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
>
> On 12/18/22 05:23, Adam Ford wrote:
> > On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 12/16/22 14:25, Alexander Stein wrote:
> >> Hi,
> >>
> >> [...]
> >>
> >>> Oh, nice, thanks for the pointer. When setting
> >>>> samsung,burst-clock-frequency = <668250000>;
> >>> in imx8mm.dtsi
> >>> I get a non-flickering display using 4 lanes. Although admittedly this is just
> >>> random guessing. I'm not sure which clock exactly has to be in the range
> >>> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
> >>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
> >>> = 16706250
> >>
> >> If I recall it right, minimum PLL frequency is:
> >>
> >> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> >>
> >> the link frequency is then
> >>
> >> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> >>
> >> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
> >> this right. Can you check what is the value of mode->clock, the
> >> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> >> sm65dsi83_get_dsi_range() ?
> >>
> >>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
> >>> properties, while SN65DSI84 is using display mode and number of lanes.
> >>>
> >>> Is it expected that the DSIM PLL frequencies are set in DT for a specific
> >>> bridge/display setup?
> >>
> >> No, there should be negotiation between the host and bridge/panel, I
> >> tried to propose two variants, but they were all rejected.
> >
> > For one of Jagan's previous revisions, I added some code to let the
> > PHY auto adjust the frequencies instead of being fixed.  NXP had this
> > in their downstream kernel, but with this patch and another, I was
> > able to set a variety of pixel clocks from my HDMI monitor and my
> > DSI83. I haven't had time to re-base my work on Jagan's latest work,
> > but you can link to the patch I did for the older stuff here:
> >
> > https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
> > and
> > https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f
> >
> > I've been traveling a lot lately, so I haven't had time to evaluate
> > his series, but I hope to get something like those re-based once the
> > DSI stuff has been accepted.
>
> I have these two attempts, both rejected:
>
> https://patchwork.freedesktop.org/patch/475207/
> https://patchwork.freedesktop.org/patch/496049/

I have some patches re-based to Jagan's latest branch.  It doesn't
impact any drivers other than the new samsung-dsim driver, and it
doesn't touch any of the drm helper functions either.  It adjusts hs
clock based on the connected device.  I am not sure what the impact
will have on the attached Exynos devices, so I am expecting some
iterations.  Right now it's working with my DSI83 chip, but I need to
get it working with my adv7535 part as well.  On the older branch, I
was able to sync the ad7535 with a variety of resolutions using
different pixel clock rates.

Once I get it working again with my adv7535 and cleaned up, I'll
submit the patches to the drm group, and I'll CC you, Jagan and Marek
Szyprowski with a reference to Jagan's series so people wanting to try
it can apply it to his branch.

adam

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

[Adam Ford]

On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
>
> On 12/18/22 05:23, Adam Ford wrote:
> > On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 12/16/22 14:25, Alexander Stein wrote:
> >> Hi,
> >>
> >> [...]
> >>
> >>> Oh, nice, thanks for the pointer. When setting
> >>>> samsung,burst-clock-frequency = <668250000>;
> >>> in imx8mm.dtsi
> >>> I get a non-flickering display using 4 lanes. Although admittedly this is just
> >>> random guessing. I'm not sure which clock exactly has to be in the range
> >>> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
> >>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
> >>> = 16706250
> >>
> >> If I recall it right, minimum PLL frequency is:
> >>
> >> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> >>
> >> the link frequency is then
> >>
> >> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> >>
> >> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
> >> this right. Can you check what is the value of mode->clock, the
> >> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> >> sm65dsi83_get_dsi_range() ?
> >>
> >>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
> >>> properties, while SN65DSI84 is using display mode and number of lanes.
> >>>
> >>> Is it expected that the DSIM PLL frequencies are set in DT for a specific
> >>> bridge/display setup?
> >>
> >> No, there should be negotiation between the host and bridge/panel, I
> >> tried to propose two variants, but they were all rejected.
> >
> > For one of Jagan's previous revisions, I added some code to let the
> > PHY auto adjust the frequencies instead of being fixed.  NXP had this
> > in their downstream kernel, but with this patch and another, I was
> > able to set a variety of pixel clocks from my HDMI monitor and my
> > DSI83. I haven't had time to re-base my work on Jagan's latest work,
> > but you can link to the patch I did for the older stuff here:
> >
> > https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
> > and
> > https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f
> >
> > I've been traveling a lot lately, so I haven't had time to evaluate
> > his series, but I hope to get something like those re-based once the
> > DSI stuff has been accepted.
>
> I have these two attempts, both rejected:
>
> https://patchwork.freedesktop.org/patch/475207/
> https://patchwork.freedesktop.org/patch/496049/

I have some patches re-based to Jagan's latest branch.  It doesn't
impact any drivers other than the new samsung-dsim driver, and it
doesn't touch any of the drm helper functions either.  It adjusts hs
clock based on the connected device.  I am not sure what the impact
will have on the attached Exynos devices, so I am expecting some
iterations.  Right now it's working with my DSI83 chip, but I need to
get it working with my adv7535 part as well.  On the older branch, I
was able to sync the ad7535 with a variety of resolutions using
different pixel clock rates.

Once I get it working again with my adv7535 and cleaned up, I'll
submit the patches to the drm group, and I'll CC you, Jagan and Marek
Szyprowski with a reference to Jagan's series so people wanting to try
it can apply it to his branch.

adam

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

[Adam Ford]

On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut <marex@denx.de> wrote:
>
> On 12/18/22 05:23, Adam Ford wrote:
> > On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 12/16/22 14:25, Alexander Stein wrote:
> >> Hi,
> >>
> >> [...]
> >>
> >>> Oh, nice, thanks for the pointer. When setting
> >>>> samsung,burst-clock-frequency = <668250000>;
> >>> in imx8mm.dtsi
> >>> I get a non-flickering display using 4 lanes. Although admittedly this is just
> >>> random guessing. I'm not sure which clock exactly has to be in the range
> >>> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
> >>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
> >>> = 16706250
> >>
> >> If I recall it right, minimum PLL frequency is:
> >>
> >> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
> >>
> >> the link frequency is then
> >>
> >> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
> >>
> >> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
> >> this right. Can you check what is the value of mode->clock, the
> >> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> >> sm65dsi83_get_dsi_range() ?
> >>
> >>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
> >>> properties, while SN65DSI84 is using display mode and number of lanes.
> >>>
> >>> Is it expected that the DSIM PLL frequencies are set in DT for a specific
> >>> bridge/display setup?
> >>
> >> No, there should be negotiation between the host and bridge/panel, I
> >> tried to propose two variants, but they were all rejected.
> >
> > For one of Jagan's previous revisions, I added some code to let the
> > PHY auto adjust the frequencies instead of being fixed.  NXP had this
> > in their downstream kernel, but with this patch and another, I was
> > able to set a variety of pixel clocks from my HDMI monitor and my
> > DSI83. I haven't had time to re-base my work on Jagan's latest work,
> > but you can link to the patch I did for the older stuff here:
> >
> > https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
> > and
> > https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f
> >
> > I've been traveling a lot lately, so I haven't had time to evaluate
> > his series, but I hope to get something like those re-based once the
> > DSI stuff has been accepted.
>
> I have these two attempts, both rejected:
>
> https://patchwork.freedesktop.org/patch/475207/
> https://patchwork.freedesktop.org/patch/496049/

I have some patches re-based to Jagan's latest branch.  It doesn't
impact any drivers other than the new samsung-dsim driver, and it
doesn't touch any of the drm helper functions either.  It adjusts hs
clock based on the connected device.  I am not sure what the impact
will have on the attached Exynos devices, so I am expecting some
iterations.  Right now it's working with my DSI83 chip, but I need to
get it working with my adv7535 part as well.  On the older branch, I
was able to sync the ad7535 with a variety of resolutions using
different pixel clock rates.

Once I get it working again with my adv7535 and cleaned up, I'll
submit the patches to the drm group, and I'll CC you, Jagan and Marek
Szyprowski with a reference to Jagan's series so people wanting to try
it can apply it to his branch.

adam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marek Vasut]

On 12/18/22 05:23, Adam Ford wrote:
> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 12/16/22 14:25, Alexander Stein wrote:
>> Hi,
>>
>> [...]
>>
>>> Oh, nice, thanks for the pointer. When setting
>>>> samsung,burst-clock-frequency = <668250000>;
>>> in imx8mm.dtsi
>>> I get a non-flickering display using 4 lanes. Although admittedly this is just
>>> random guessing. I'm not sure which clock exactly has to be in the range
>>> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
>>> = 16706250
>>
>> If I recall it right, minimum PLL frequency is:
>>
>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>
>> the link frequency is then
>>
>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>>
>> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
>> this right. Can you check what is the value of mode->clock, the
>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>> sm65dsi83_get_dsi_range() ?
>>
>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
>>> properties, while SN65DSI84 is using display mode and number of lanes.
>>>
>>> Is it expected that the DSIM PLL frequencies are set in DT for a specific
>>> bridge/display setup?
>>
>> No, there should be negotiation between the host and bridge/panel, I
>> tried to propose two variants, but they were all rejected.
> 
> For one of Jagan's previous revisions, I added some code to let the
> PHY auto adjust the frequencies instead of being fixed.  NXP had this
> in their downstream kernel, but with this patch and another, I was
> able to set a variety of pixel clocks from my HDMI monitor and my
> DSI83. I haven't had time to re-base my work on Jagan's latest work,
> but you can link to the patch I did for the older stuff here:
> 
> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
> and
> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f
> 
> I've been traveling a lot lately, so I haven't had time to evaluate
> his series, but I hope to get something like those re-based once the
> DSI stuff has been accepted.

I have these two attempts, both rejected:

https://patchwork.freedesktop.org/patch/475207/
https://patchwork.freedesktop.org/patch/496049/

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

[Marek Vasut]

On 12/18/22 05:23, Adam Ford wrote:
> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 12/16/22 14:25, Alexander Stein wrote:
>> Hi,
>>
>> [...]
>>
>>> Oh, nice, thanks for the pointer. When setting
>>>> samsung,burst-clock-frequency = <668250000>;
>>> in imx8mm.dtsi
>>> I get a non-flickering display using 4 lanes. Although admittedly this is just
>>> random guessing. I'm not sure which clock exactly has to be in the range
>>> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
>>> = 16706250
>>
>> If I recall it right, minimum PLL frequency is:
>>
>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>
>> the link frequency is then
>>
>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>>
>> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
>> this right. Can you check what is the value of mode->clock, the
>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>> sm65dsi83_get_dsi_range() ?
>>
>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
>>> properties, while SN65DSI84 is using display mode and number of lanes.
>>>
>>> Is it expected that the DSIM PLL frequencies are set in DT for a specific
>>> bridge/display setup?
>>
>> No, there should be negotiation between the host and bridge/panel, I
>> tried to propose two variants, but they were all rejected.
> 
> For one of Jagan's previous revisions, I added some code to let the
> PHY auto adjust the frequencies instead of being fixed.  NXP had this
> in their downstream kernel, but with this patch and another, I was
> able to set a variety of pixel clocks from my HDMI monitor and my
> DSI83. I haven't had time to re-base my work on Jagan's latest work,
> but you can link to the patch I did for the older stuff here:
> 
> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
> and
> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f
> 
> I've been traveling a lot lately, so I haven't had time to evaluate
> his series, but I hope to get something like those re-based once the
> DSI stuff has been accepted.

I have these two attempts, both rejected:

https://patchwork.freedesktop.org/patch/475207/
https://patchwork.freedesktop.org/patch/496049/

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

[Marek Vasut]

On 12/18/22 05:23, Adam Ford wrote:
> On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>>
>> On 12/16/22 14:25, Alexander Stein wrote:
>> Hi,
>>
>> [...]
>>
>>> Oh, nice, thanks for the pointer. When setting
>>>> samsung,burst-clock-frequency = <668250000>;
>>> in imx8mm.dtsi
>>> I get a non-flickering display using 4 lanes. Although admittedly this is just
>>> random guessing. I'm not sure which clock exactly has to be in the range
>>> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
>>> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>>>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>>>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
>>> = 16706250
>>
>> If I recall it right, minimum PLL frequency is:
>>
>> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>>
>> the link frequency is then
>>
>> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>>
>> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
>> this right. Can you check what is the value of mode->clock, the
>> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
>> sm65dsi83_get_dsi_range() ?
>>
>>> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
>>> properties, while SN65DSI84 is using display mode and number of lanes.
>>>
>>> Is it expected that the DSIM PLL frequencies are set in DT for a specific
>>> bridge/display setup?
>>
>> No, there should be negotiation between the host and bridge/panel, I
>> tried to propose two variants, but they were all rejected.
> 
> For one of Jagan's previous revisions, I added some code to let the
> PHY auto adjust the frequencies instead of being fixed.  NXP had this
> in their downstream kernel, but with this patch and another, I was
> able to set a variety of pixel clocks from my HDMI monitor and my
> DSI83. I haven't had time to re-base my work on Jagan's latest work,
> but you can link to the patch I did for the older stuff here:
> 
> https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
> and
> https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f
> 
> I've been traveling a lot lately, so I haven't had time to evaluate
> his series, but I hope to get something like those re-based once the
> DSI stuff has been accepted.

I have these two attempts, both rejected:

https://patchwork.freedesktop.org/patch/475207/
https://patchwork.freedesktop.org/patch/496049/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Adam Ford]

On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>
> On 12/16/22 14:25, Alexander Stein wrote:
> Hi,
>
> [...]
>
> > Oh, nice, thanks for the pointer. When setting
> >> samsung,burst-clock-frequency = <668250000>;
> > in imx8mm.dtsi
> > I get a non-flickering display using 4 lanes. Although admittedly this is just
> > random guessing. I'm not sure which clock exactly has to be in the range
> > CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
> > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
> > = 16706250
>
> If I recall it right, minimum PLL frequency is:
>
> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>
> the link frequency is then
>
> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>
> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
> this right. Can you check what is the value of mode->clock, the
> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> sm65dsi83_get_dsi_range() ?
>
> > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
> > properties, while SN65DSI84 is using display mode and number of lanes.
> >
> > Is it expected that the DSIM PLL frequencies are set in DT for a specific
> > bridge/display setup?
>
> No, there should be negotiation between the host and bridge/panel, I
> tried to propose two variants, but they were all rejected.

For one of Jagan's previous revisions, I added some code to let the
PHY auto adjust the frequencies instead of being fixed.  NXP had this
in their downstream kernel, but with this patch and another, I was
able to set a variety of pixel clocks from my HDMI monitor and my
DSI83. I haven't had time to re-base my work on Jagan's latest work,
but you can link to the patch I did for the older stuff here:

https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
and
https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f

I've been traveling a lot lately, so I haven't had time to evaluate
his series, but I hope to get something like those re-based once the
DSI stuff has been accepted.

adam

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

[Adam Ford]

On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>
> On 12/16/22 14:25, Alexander Stein wrote:
> Hi,
>
> [...]
>
> > Oh, nice, thanks for the pointer. When setting
> >> samsung,burst-clock-frequency = <668250000>;
> > in imx8mm.dtsi
> > I get a non-flickering display using 4 lanes. Although admittedly this is just
> > random guessing. I'm not sure which clock exactly has to be in the range
> > CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
> > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
> > = 16706250
>
> If I recall it right, minimum PLL frequency is:
>
> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>
> the link frequency is then
>
> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>
> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
> this right. Can you check what is the value of mode->clock, the
> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> sm65dsi83_get_dsi_range() ?
>
> > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
> > properties, while SN65DSI84 is using display mode and number of lanes.
> >
> > Is it expected that the DSIM PLL frequencies are set in DT for a specific
> > bridge/display setup?
>
> No, there should be negotiation between the host and bridge/panel, I
> tried to propose two variants, but they were all rejected.

For one of Jagan's previous revisions, I added some code to let the
PHY auto adjust the frequencies instead of being fixed.  NXP had this
in their downstream kernel, but with this patch and another, I was
able to set a variety of pixel clocks from my HDMI monitor and my
DSI83. I haven't had time to re-base my work on Jagan's latest work,
but you can link to the patch I did for the older stuff here:

https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
and
https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f

I've been traveling a lot lately, so I haven't had time to evaluate
his series, but I hope to get something like those re-based once the
DSI stuff has been accepted.

adam

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

[Adam Ford]

On Sat, Dec 17, 2022 at 5:56 PM Marek Vasut <marex@denx.de> wrote:
>
> On 12/16/22 14:25, Alexander Stein wrote:
> Hi,
>
> [...]
>
> > Oh, nice, thanks for the pointer. When setting
> >> samsung,burst-clock-frequency = <668250000>;
> > in imx8mm.dtsi
> > I get a non-flickering display using 4 lanes. Although admittedly this is just
> > random guessing. I'm not sure which clock exactly has to be in the range
> > CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
> > 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> >> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> >> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
> > = 16706250
>
> If I recall it right, minimum PLL frequency is:
>
> fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz
>
> the link frequency is then
>
> fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)
>
> So DSI83 should be in the range of 80..85 MHz input clock if I calculate
> this right. Can you check what is the value of mode->clock, the
> mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83
> sm65dsi83_get_dsi_range() ?
>
> > AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
> > properties, while SN65DSI84 is using display mode and number of lanes.
> >
> > Is it expected that the DSIM PLL frequencies are set in DT for a specific
> > bridge/display setup?
>
> No, there should be negotiation between the host and bridge/panel, I
> tried to propose two variants, but they were all rejected.

For one of Jagan's previous revisions, I added some code to let the
PHY auto adjust the frequencies instead of being fixed.  NXP had this
in their downstream kernel, but with this patch and another, I was
able to set a variety of pixel clocks from my HDMI monitor and my
DSI83. I haven't had time to re-base my work on Jagan's latest work,
but you can link to the patch I did for the older stuff here:

https://github.com/aford173/linux/commit/e845274b0f22ba3b24813ffd6bb3cb88ab4b67e4
and
https://github.com/aford173/linux/commit/3f90057eb608f96d106029ef639813475241936f

I've been traveling a lot lately, so I haven't had time to evaluate
his series, but I hope to get something like those re-based once the
DSI stuff has been accepted.

adam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marek Vasut]

On 12/16/22 14:25, Alexander Stein wrote:
Hi,

[...]

> Oh, nice, thanks for the pointer. When setting
>> samsung,burst-clock-frequency = <668250000>;
> in imx8mm.dtsi
> I get a non-flickering display using 4 lanes. Although admittedly this is just
> random guessing. I'm not sure which clock exactly has to be in the range
> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
> = 16706250

If I recall it right, minimum PLL frequency is:

fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz

the link frequency is then

fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)

So DSI83 should be in the range of 80..85 MHz input clock if I calculate 
this right. Can you check what is the value of mode->clock, the 
mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83 
sm65dsi83_get_dsi_range() ?

> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
> properties, while SN65DSI84 is using display mode and number of lanes.
> 
> Is it expected that the DSIM PLL frequencies are set in DT for a specific
> bridge/display setup?

No, there should be negotiation between the host and bridge/panel, I 
tried to propose two variants, but they were all rejected.

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

[Marek Vasut]

On 12/16/22 14:25, Alexander Stein wrote:
Hi,

[...]

> Oh, nice, thanks for the pointer. When setting
>> samsung,burst-clock-frequency = <668250000>;
> in imx8mm.dtsi
> I get a non-flickering display using 4 lanes. Although admittedly this is just
> random guessing. I'm not sure which clock exactly has to be in the range
> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
> = 16706250

If I recall it right, minimum PLL frequency is:

fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz

the link frequency is then

fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)

So DSI83 should be in the range of 80..85 MHz input clock if I calculate 
this right. Can you check what is the value of mode->clock, the 
mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83 
sm65dsi83_get_dsi_range() ?

> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
> properties, while SN65DSI84 is using display mode and number of lanes.
> 
> Is it expected that the DSIM PLL frequencies are set in DT for a specific
> bridge/display setup?

No, there should be negotiation between the host and bridge/panel, I 
tried to propose two variants, but they were all rejected.

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

[Marek Vasut]

On 12/16/22 14:25, Alexander Stein wrote:
Hi,

[...]

> Oh, nice, thanks for the pointer. When setting
>> samsung,burst-clock-frequency = <668250000>;
> in imx8mm.dtsi
> I get a non-flickering display using 4 lanes. Although admittedly this is just
> random guessing. I'm not sure which clock exactly has to be in the range
> CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for
> 205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
>> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
>> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk
> = 16706250

If I recall it right, minimum PLL frequency is:

fPMS=1.2*width*height*bpp*fps=1.2*800*480*24*60=663.5 MHz

the link frequency is then

fHS=fPMS/lanes/2=82.9 MHz (on the DDR clock lane)

So DSI83 should be in the range of 80..85 MHz input clock if I calculate 
this right. Can you check what is the value of mode->clock, the 
mipi_dsi_panel_format_to_bpp() return value, ctx->dsi->lanes in dsi83 
sm65dsi83_get_dsi_range() ?

> AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT
> properties, while SN65DSI84 is using display mode and number of lanes.
> 
> Is it expected that the DSIM PLL frequencies are set in DT for a specific
> bridge/display setup?

No, there should be negotiation between the host and bridge/panel, I 
tried to propose two variants, but they were all rejected.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Alexander Stein]

Hi Marek,

Am Freitag, 16. Dezember 2022, 13:58:13 CET schrieb Marek Vasut:
> On 12/16/22 13:41, Alexander Stein wrote:
> > Hi,
> 
> Hi,
> 
> > thanks for the new update.
> > 
> > Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb 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: adding devm_drm_of_dsi_get_bridge
> >> 
> >> 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
> > 
> > Tested using LVDS bridges and works on:
> > * imx8mp-tqma8mpql-mba8mpxl (i.MX8M Plus)
> > * imx8mm-tqma8mqml-mba8mx (i.MX8M Mini)
> > * imx8mn-tqma8mqnl-mba8mx (i.MX8M Nano)
> > 
> > But I noticed that tqma8mqml and tqma8mqnl only have a stable output if I
> > specify 'data-lanes = <0 1 2>' (not <0 1 2 3>!) on the DSI-LVDS-Bridge (TI
> > SN65DSI83) input endpoint, e.g.
> > 
> > dsi_lvds_bridge: bridge@2d {
> > 
> > 	compatible = "ti,sn65dsi83";
> > 	reg = <0x2d>;
> > 	enable-gpios = <&gpio_delays 0 130000 0>;
> > 	vcc-supply = <&reg_sn65dsi83_1v8>;
> > 	status = "okay";
> > 	ports {
> > 	
> > 		#address-cells = <1>;
> > 		#size-cells = <0>;
> > 		port@0 {
> > 		
> > 			reg = <0>;
> > 			lvds_bridge_in: endpoint {
> > 			
> > 				data-lanes = <0 1 2>;
> > 				remote-endpoint = <&mipi_dsi_out>;
> > 			
> > 			};
> > 		
> > 		};
> > 		port@2 {
> > 		
> > 			reg = <2>;
> > 			lvds_bridge_out: endpoint {
> > 			
> > 				remote-endpoint = <&panel_in_lvds0>;
> > 			
> > 			};
> > 		
> > 		};
> > 	
> > 	};
> > 
> > };
> > 
> > I have no idea if this is on the DSIM side or the DSI-LVDS bridge side.
> > Register 0xe5 on sn65dsi83 shows that CHA_LPP_ERR and CHA_SOT_BIT_ERR
> > error
> > bits are set, indicating there are low level protocol and SoT leader
> > sequence bit errors. I can't find any significant difference in sn65dsi83
> > driver compared to downstream-kernel, so I would assume something in DSIM
> > driver is different.
> 
> Make sure the HS clock rate expected by the DSI83 bridge chip and the
> one generated by the DSIM bridge from PMS PLL match. There is currently
> no negotiation of this frequency and both sides divine it on their own.
> 
> See sn65dsi83_get_dsi_range() and samsung_dsim_set_pll().

Oh, nice, thanks for the pointer. When setting
> samsung,burst-clock-frequency = <668250000>;
in imx8mm.dtsi
I get a non-flickering display using 4 lanes. Although admittedly this is just 
random guessing. I'm not sure which clock exactly has to be in the range 
CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for 
205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk 
= 16706250

AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT 
properties, while SN65DSI84 is using display mode and number of lanes.

Is it expected that the DSIM PLL frequencies are set in DT for a specific 
bridge/display setup?

Best regards,
Alexander

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

[Alexander Stein]

Hi Marek,

Am Freitag, 16. Dezember 2022, 13:58:13 CET schrieb Marek Vasut:
> On 12/16/22 13:41, Alexander Stein wrote:
> > Hi,
> 
> Hi,
> 
> > thanks for the new update.
> > 
> > Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb 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: adding devm_drm_of_dsi_get_bridge
> >> 
> >> 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
> > 
> > Tested using LVDS bridges and works on:
> > * imx8mp-tqma8mpql-mba8mpxl (i.MX8M Plus)
> > * imx8mm-tqma8mqml-mba8mx (i.MX8M Mini)
> > * imx8mn-tqma8mqnl-mba8mx (i.MX8M Nano)
> > 
> > But I noticed that tqma8mqml and tqma8mqnl only have a stable output if I
> > specify 'data-lanes = <0 1 2>' (not <0 1 2 3>!) on the DSI-LVDS-Bridge (TI
> > SN65DSI83) input endpoint, e.g.
> > 
> > dsi_lvds_bridge: bridge@2d {
> > 
> > 	compatible = "ti,sn65dsi83";
> > 	reg = <0x2d>;
> > 	enable-gpios = <&gpio_delays 0 130000 0>;
> > 	vcc-supply = <&reg_sn65dsi83_1v8>;
> > 	status = "okay";
> > 	ports {
> > 	
> > 		#address-cells = <1>;
> > 		#size-cells = <0>;
> > 		port@0 {
> > 		
> > 			reg = <0>;
> > 			lvds_bridge_in: endpoint {
> > 			
> > 				data-lanes = <0 1 2>;
> > 				remote-endpoint = <&mipi_dsi_out>;
> > 			
> > 			};
> > 		
> > 		};
> > 		port@2 {
> > 		
> > 			reg = <2>;
> > 			lvds_bridge_out: endpoint {
> > 			
> > 				remote-endpoint = <&panel_in_lvds0>;
> > 			
> > 			};
> > 		
> > 		};
> > 	
> > 	};
> > 
> > };
> > 
> > I have no idea if this is on the DSIM side or the DSI-LVDS bridge side.
> > Register 0xe5 on sn65dsi83 shows that CHA_LPP_ERR and CHA_SOT_BIT_ERR
> > error
> > bits are set, indicating there are low level protocol and SoT leader
> > sequence bit errors. I can't find any significant difference in sn65dsi83
> > driver compared to downstream-kernel, so I would assume something in DSIM
> > driver is different.
> 
> Make sure the HS clock rate expected by the DSI83 bridge chip and the
> one generated by the DSIM bridge from PMS PLL match. There is currently
> no negotiation of this frequency and both sides divine it on their own.
> 
> See sn65dsi83_get_dsi_range() and samsung_dsim_set_pll().

Oh, nice, thanks for the pointer. When setting
> samsung,burst-clock-frequency = <668250000>;
in imx8mm.dtsi
I get a non-flickering display using 4 lanes. Although admittedly this is just 
random guessing. I'm not sure which clock exactly has to be in the range 
CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for 
205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk 
= 16706250

AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT 
properties, while SN65DSI84 is using display mode and number of lanes.

Is it expected that the DSIM PLL frequencies are set in DT for a specific 
bridge/display setup?

Best regards,
Alexander

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

[Alexander Stein]

Hi Marek,

Am Freitag, 16. Dezember 2022, 13:58:13 CET schrieb Marek Vasut:
> On 12/16/22 13:41, Alexander Stein wrote:
> > Hi,
> 
> Hi,
> 
> > thanks for the new update.
> > 
> > Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb 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: adding devm_drm_of_dsi_get_bridge
> >> 
> >> 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
> > 
> > Tested using LVDS bridges and works on:
> > * imx8mp-tqma8mpql-mba8mpxl (i.MX8M Plus)
> > * imx8mm-tqma8mqml-mba8mx (i.MX8M Mini)
> > * imx8mn-tqma8mqnl-mba8mx (i.MX8M Nano)
> > 
> > But I noticed that tqma8mqml and tqma8mqnl only have a stable output if I
> > specify 'data-lanes = <0 1 2>' (not <0 1 2 3>!) on the DSI-LVDS-Bridge (TI
> > SN65DSI83) input endpoint, e.g.
> > 
> > dsi_lvds_bridge: bridge@2d {
> > 
> > 	compatible = "ti,sn65dsi83";
> > 	reg = <0x2d>;
> > 	enable-gpios = <&gpio_delays 0 130000 0>;
> > 	vcc-supply = <&reg_sn65dsi83_1v8>;
> > 	status = "okay";
> > 	ports {
> > 	
> > 		#address-cells = <1>;
> > 		#size-cells = <0>;
> > 		port@0 {
> > 		
> > 			reg = <0>;
> > 			lvds_bridge_in: endpoint {
> > 			
> > 				data-lanes = <0 1 2>;
> > 				remote-endpoint = <&mipi_dsi_out>;
> > 			
> > 			};
> > 		
> > 		};
> > 		port@2 {
> > 		
> > 			reg = <2>;
> > 			lvds_bridge_out: endpoint {
> > 			
> > 				remote-endpoint = <&panel_in_lvds0>;
> > 			
> > 			};
> > 		
> > 		};
> > 	
> > 	};
> > 
> > };
> > 
> > I have no idea if this is on the DSIM side or the DSI-LVDS bridge side.
> > Register 0xe5 on sn65dsi83 shows that CHA_LPP_ERR and CHA_SOT_BIT_ERR
> > error
> > bits are set, indicating there are low level protocol and SoT leader
> > sequence bit errors. I can't find any significant difference in sn65dsi83
> > driver compared to downstream-kernel, so I would assume something in DSIM
> > driver is different.
> 
> Make sure the HS clock rate expected by the DSI83 bridge chip and the
> one generated by the DSIM bridge from PMS PLL match. There is currently
> no negotiation of this frequency and both sides divine it on their own.
> 
> See sn65dsi83_get_dsi_range() and samsung_dsim_set_pll().

Oh, nice, thanks for the pointer. When setting
> samsung,burst-clock-frequency = <668250000>;
in imx8mm.dtsi
I get a non-flickering display using 4 lanes. Although admittedly this is just 
random guessing. I'm not sure which clock exactly has to be in the range 
CHA_DSI_CLK_RANGE is configured to. With 4 lanes SN65DSI84 is configured for 
205-210 MHz (0x29), while I get these PLL PMS settings on DSIM:
> samsung-dsim 32e10000.dsi: PLL freq 668250000, (p 4, m 99, s 0)
> samsung-dsim 32e10000.dsi: hs_clk = 668250000, byte_clk = 83531250, esc_clk 
= 16706250

AFAICS DSIM bridge is configurung hs_clk, byte_clk and esc_clk just from DT 
properties, while SN65DSI84 is using display mode and number of lanes.

Is it expected that the DSIM PLL frequencies are set in DT for a specific 
bridge/display setup?

Best regards,
Alexander


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Marek Vasut]

On 12/16/22 13:41, Alexander Stein wrote:
> Hi,

Hi,

> thanks for the new update.
> 
> Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb 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: adding devm_drm_of_dsi_get_bridge
>>
>> 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
> 
> Tested using LVDS bridges and works on:
> * imx8mp-tqma8mpql-mba8mpxl (i.MX8M Plus)
> * imx8mm-tqma8mqml-mba8mx (i.MX8M Mini)
> * imx8mn-tqma8mqnl-mba8mx (i.MX8M Nano)
> 
> But I noticed that tqma8mqml and tqma8mqnl only have a stable output if I
> specify 'data-lanes = <0 1 2>' (not <0 1 2 3>!) on the DSI-LVDS-Bridge (TI
> SN65DSI83) input endpoint, e.g.
> 
> dsi_lvds_bridge: bridge@2d {
> 	compatible = "ti,sn65dsi83";
> 	reg = <0x2d>;
> 	enable-gpios = <&gpio_delays 0 130000 0>;
> 	vcc-supply = <&reg_sn65dsi83_1v8>;
> 	status = "okay";
> 	ports {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		port@0 {
> 			reg = <0>;
> 			lvds_bridge_in: endpoint {
> 				data-lanes = <0 1 2>;
> 				remote-endpoint = <&mipi_dsi_out>;
> 			};
> 		};
> 		port@2 {
> 			reg = <2>;
> 			lvds_bridge_out: endpoint {
> 				remote-endpoint = <&panel_in_lvds0>;
> 			};
> 		};
> 	};
> };
> 
> I have no idea if this is on the DSIM side or the DSI-LVDS bridge side.
> Register 0xe5 on sn65dsi83 shows that CHA_LPP_ERR and CHA_SOT_BIT_ERR error
> bits are set, indicating there are low level protocol and SoT leader sequence
> bit errors. I can't find any significant difference in sn65dsi83 driver
> compared to downstream-kernel, so I would assume something in DSIM driver is
> different.

Make sure the HS clock rate expected by the DSI83 bridge chip and the 
one generated by the DSIM bridge from PMS PLL match. There is currently 
no negotiation of this frequency and both sides divine it on their own.

See sn65dsi83_get_dsi_range() and samsung_dsim_set_pll().

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

[Marek Vasut]

On 12/16/22 13:41, Alexander Stein wrote:
> Hi,

Hi,

> thanks for the new update.
> 
> Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb 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: adding devm_drm_of_dsi_get_bridge
>>
>> 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
> 
> Tested using LVDS bridges and works on:
> * imx8mp-tqma8mpql-mba8mpxl (i.MX8M Plus)
> * imx8mm-tqma8mqml-mba8mx (i.MX8M Mini)
> * imx8mn-tqma8mqnl-mba8mx (i.MX8M Nano)
> 
> But I noticed that tqma8mqml and tqma8mqnl only have a stable output if I
> specify 'data-lanes = <0 1 2>' (not <0 1 2 3>!) on the DSI-LVDS-Bridge (TI
> SN65DSI83) input endpoint, e.g.
> 
> dsi_lvds_bridge: bridge@2d {
> 	compatible = "ti,sn65dsi83";
> 	reg = <0x2d>;
> 	enable-gpios = <&gpio_delays 0 130000 0>;
> 	vcc-supply = <&reg_sn65dsi83_1v8>;
> 	status = "okay";
> 	ports {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		port@0 {
> 			reg = <0>;
> 			lvds_bridge_in: endpoint {
> 				data-lanes = <0 1 2>;
> 				remote-endpoint = <&mipi_dsi_out>;
> 			};
> 		};
> 		port@2 {
> 			reg = <2>;
> 			lvds_bridge_out: endpoint {
> 				remote-endpoint = <&panel_in_lvds0>;
> 			};
> 		};
> 	};
> };
> 
> I have no idea if this is on the DSIM side or the DSI-LVDS bridge side.
> Register 0xe5 on sn65dsi83 shows that CHA_LPP_ERR and CHA_SOT_BIT_ERR error
> bits are set, indicating there are low level protocol and SoT leader sequence
> bit errors. I can't find any significant difference in sn65dsi83 driver
> compared to downstream-kernel, so I would assume something in DSIM driver is
> different.

Make sure the HS clock rate expected by the DSI83 bridge chip and the 
one generated by the DSIM bridge from PMS PLL match. There is currently 
no negotiation of this frequency and both sides divine it on their own.

See sn65dsi83_get_dsi_range() and samsung_dsim_set_pll().

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

[Marek Vasut]

On 12/16/22 13:41, Alexander Stein wrote:
> Hi,

Hi,

> thanks for the new update.
> 
> Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb 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: adding devm_drm_of_dsi_get_bridge
>>
>> 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
> 
> Tested using LVDS bridges and works on:
> * imx8mp-tqma8mpql-mba8mpxl (i.MX8M Plus)
> * imx8mm-tqma8mqml-mba8mx (i.MX8M Mini)
> * imx8mn-tqma8mqnl-mba8mx (i.MX8M Nano)
> 
> But I noticed that tqma8mqml and tqma8mqnl only have a stable output if I
> specify 'data-lanes = <0 1 2>' (not <0 1 2 3>!) on the DSI-LVDS-Bridge (TI
> SN65DSI83) input endpoint, e.g.
> 
> dsi_lvds_bridge: bridge@2d {
> 	compatible = "ti,sn65dsi83";
> 	reg = <0x2d>;
> 	enable-gpios = <&gpio_delays 0 130000 0>;
> 	vcc-supply = <&reg_sn65dsi83_1v8>;
> 	status = "okay";
> 	ports {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		port@0 {
> 			reg = <0>;
> 			lvds_bridge_in: endpoint {
> 				data-lanes = <0 1 2>;
> 				remote-endpoint = <&mipi_dsi_out>;
> 			};
> 		};
> 		port@2 {
> 			reg = <2>;
> 			lvds_bridge_out: endpoint {
> 				remote-endpoint = <&panel_in_lvds0>;
> 			};
> 		};
> 	};
> };
> 
> I have no idea if this is on the DSIM side or the DSI-LVDS bridge side.
> Register 0xe5 on sn65dsi83 shows that CHA_LPP_ERR and CHA_SOT_BIT_ERR error
> bits are set, indicating there are low level protocol and SoT leader sequence
> bit errors. I can't find any significant difference in sn65dsi83 driver
> compared to downstream-kernel, so I would assume something in DSIM driver is
> different.

Make sure the HS clock rate expected by the DSI83 bridge chip and the 
one generated by the DSIM bridge from PMS PLL match. There is currently 
no negotiation of this frequency and both sides divine it on their own.

See sn65dsi83_get_dsi_range() and samsung_dsim_set_pll().

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Alexander Stein]

Hi,

thanks for the new update.

Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb 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: adding devm_drm_of_dsi_get_bridge
> 
> 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

Tested using LVDS bridges and works on:
* imx8mp-tqma8mpql-mba8mpxl (i.MX8M Plus)
* imx8mm-tqma8mqml-mba8mx (i.MX8M Mini)
* imx8mn-tqma8mqnl-mba8mx (i.MX8M Nano)

But I noticed that tqma8mqml and tqma8mqnl only have a stable output if I 
specify 'data-lanes = <0 1 2>' (not <0 1 2 3>!) on the DSI-LVDS-Bridge (TI 
SN65DSI83) input endpoint, e.g. 

dsi_lvds_bridge: bridge@2d {
	compatible = "ti,sn65dsi83";
	reg = <0x2d>;
	enable-gpios = <&gpio_delays 0 130000 0>;
	vcc-supply = <&reg_sn65dsi83_1v8>;
	status = "okay";
	ports {
		#address-cells = <1>;
		#size-cells = <0>;
		port@0 {
			reg = <0>;
			lvds_bridge_in: endpoint {
				data-lanes = <0 1 2>;
				remote-endpoint = <&mipi_dsi_out>;
			};
		};
		port@2 {
			reg = <2>;
			lvds_bridge_out: endpoint {
				remote-endpoint = <&panel_in_lvds0>;
			};
		};
	};
};

I have no idea if this is on the DSIM side or the DSI-LVDS bridge side. 
Register 0xe5 on sn65dsi83 shows that CHA_LPP_ERR and CHA_SOT_BIT_ERR error 
bits are set, indicating there are low level protocol and SoT leader sequence 
bit errors. I can't find any significant difference in sn65dsi83 driver 
compared to downstream-kernel, so I would assume something in DSIM driver is 
different.

Best regards,
Alexander

> 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
> 
> v9:
> https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.c
> om/
> 
> Any inputs?
> Jagan.
> 
> Jagan Teki (16):
>   drm: of: Lookup if child node has DSI panel or bridge
>   drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
>   drm: exynos: dsi: Drop explicit call to bridge detach
>   drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
>   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 Exynos based host irq hooks
>   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                |   34 +
>  drivers/gpu/drm/bridge/samsung-dsim.c         | 1883 +++++++++++++++++
>  drivers/gpu/drm/drm_of.c                      |  113 +-
>  drivers/gpu/drm/exynos/Kconfig                |    1 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1793 +---------------
>  include/drm/bridge/samsung-dsim.h             |  119 ++
>  include/drm/drm_bridge.h                      |    2 +
>  include/drm/drm_of.h                          |   12 +
>  12 files changed, 2285 insertions(+), 1696 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>  create mode 100644 include/drm/bridge/samsung-dsim.h

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

[Alexander Stein]

Hi,

thanks for the new update.

Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb 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: adding devm_drm_of_dsi_get_bridge
> 
> 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

Tested using LVDS bridges and works on:
* imx8mp-tqma8mpql-mba8mpxl (i.MX8M Plus)
* imx8mm-tqma8mqml-mba8mx (i.MX8M Mini)
* imx8mn-tqma8mqnl-mba8mx (i.MX8M Nano)

But I noticed that tqma8mqml and tqma8mqnl only have a stable output if I 
specify 'data-lanes = <0 1 2>' (not <0 1 2 3>!) on the DSI-LVDS-Bridge (TI 
SN65DSI83) input endpoint, e.g. 

dsi_lvds_bridge: bridge@2d {
	compatible = "ti,sn65dsi83";
	reg = <0x2d>;
	enable-gpios = <&gpio_delays 0 130000 0>;
	vcc-supply = <&reg_sn65dsi83_1v8>;
	status = "okay";
	ports {
		#address-cells = <1>;
		#size-cells = <0>;
		port@0 {
			reg = <0>;
			lvds_bridge_in: endpoint {
				data-lanes = <0 1 2>;
				remote-endpoint = <&mipi_dsi_out>;
			};
		};
		port@2 {
			reg = <2>;
			lvds_bridge_out: endpoint {
				remote-endpoint = <&panel_in_lvds0>;
			};
		};
	};
};

I have no idea if this is on the DSIM side or the DSI-LVDS bridge side. 
Register 0xe5 on sn65dsi83 shows that CHA_LPP_ERR and CHA_SOT_BIT_ERR error 
bits are set, indicating there are low level protocol and SoT leader sequence 
bit errors. I can't find any significant difference in sn65dsi83 driver 
compared to downstream-kernel, so I would assume something in DSIM driver is 
different.

Best regards,
Alexander

> 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
> 
> v9:
> https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.c
> om/
> 
> Any inputs?
> Jagan.
> 
> Jagan Teki (16):
>   drm: of: Lookup if child node has DSI panel or bridge
>   drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
>   drm: exynos: dsi: Drop explicit call to bridge detach
>   drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
>   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 Exynos based host irq hooks
>   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                |   34 +
>  drivers/gpu/drm/bridge/samsung-dsim.c         | 1883 +++++++++++++++++
>  drivers/gpu/drm/drm_of.c                      |  113 +-
>  drivers/gpu/drm/exynos/Kconfig                |    1 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1793 +---------------
>  include/drm/bridge/samsung-dsim.h             |  119 ++
>  include/drm/drm_bridge.h                      |    2 +
>  include/drm/drm_of.h                          |   12 +
>  12 files changed, 2285 insertions(+), 1696 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>  create mode 100644 include/drm/bridge/samsung-dsim.h

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

[Alexander Stein]

Hi,

thanks for the new update.

Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb 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: adding devm_drm_of_dsi_get_bridge
> 
> 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

Tested using LVDS bridges and works on:
* imx8mp-tqma8mpql-mba8mpxl (i.MX8M Plus)
* imx8mm-tqma8mqml-mba8mx (i.MX8M Mini)
* imx8mn-tqma8mqnl-mba8mx (i.MX8M Nano)

But I noticed that tqma8mqml and tqma8mqnl only have a stable output if I 
specify 'data-lanes = <0 1 2>' (not <0 1 2 3>!) on the DSI-LVDS-Bridge (TI 
SN65DSI83) input endpoint, e.g. 

dsi_lvds_bridge: bridge@2d {
	compatible = "ti,sn65dsi83";
	reg = <0x2d>;
	enable-gpios = <&gpio_delays 0 130000 0>;
	vcc-supply = <&reg_sn65dsi83_1v8>;
	status = "okay";
	ports {
		#address-cells = <1>;
		#size-cells = <0>;
		port@0 {
			reg = <0>;
			lvds_bridge_in: endpoint {
				data-lanes = <0 1 2>;
				remote-endpoint = <&mipi_dsi_out>;
			};
		};
		port@2 {
			reg = <2>;
			lvds_bridge_out: endpoint {
				remote-endpoint = <&panel_in_lvds0>;
			};
		};
	};
};

I have no idea if this is on the DSIM side or the DSI-LVDS bridge side. 
Register 0xe5 on sn65dsi83 shows that CHA_LPP_ERR and CHA_SOT_BIT_ERR error 
bits are set, indicating there are low level protocol and SoT leader sequence 
bit errors. I can't find any significant difference in sn65dsi83 driver 
compared to downstream-kernel, so I would assume something in DSIM driver is 
different.

Best regards,
Alexander

> 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10
> 
> v9:
> https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.c
> om/
> 
> Any inputs?
> Jagan.
> 
> Jagan Teki (16):
>   drm: of: Lookup if child node has DSI panel or bridge
>   drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
>   drm: exynos: dsi: Drop explicit call to bridge detach
>   drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge
>   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 Exynos based host irq hooks
>   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                |   34 +
>  drivers/gpu/drm/bridge/samsung-dsim.c         | 1883 +++++++++++++++++
>  drivers/gpu/drm/drm_of.c                      |  113 +-
>  drivers/gpu/drm/exynos/Kconfig                |    1 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c       | 1793 +---------------
>  include/drm/bridge/samsung-dsim.h             |  119 ++
>  include/drm/drm_bridge.h                      |    2 +
>  include/drm/drm_of.h                          |   12 +
>  12 files changed, 2285 insertions(+), 1696 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>  create mode 100644 include/drm/bridge/samsung-dsim.h


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel