[PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Guido Günther]

This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
SoCs.

It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
I only have imx8mq boards to test I omitted the platform data for other SoCs.

The code is based on NXPs BSP so I added Robert Chiras as Co-authored-by but
I'm happy to swap Author: and Co-authored-by: if that looks more appropriate.
The most notable changes over the BSP driver are
 - Calculate HS mode timing from phy_configure_opts_mipi_dphy
 - Perform all clock setup via DT
 - Merge nwl-imx and nwl drivers
 - Add B0 silion revision quirk

Posting this is likely a bit premature (hence v0) but I wanted for one show how
this hooks into the mixel dphy posted earlier [1] and avoid duplicating work.
So if there's other code out there doing the same I'm be happy to merge
efforts.

It has been tested quite bit (in a version backported to 4.18) on Librem 5
devkit using DCSS (which is not mainlined yet) and a MIPI DSI panel[2]. In
principle LCDIF can also act as input source. I intend look into next so this
can actually be tested without further patches on mainline kernels.

[1]: https://lists.freedesktop.org/archives/dri-devel/2019-March/209680.html
[2]: https://source.puri.sm/guido.gunther/linux-imx8/tree/imx8-4.18-wip-nwl-dsi-rework

Guido Günther (2):
  dt-bindings: imx: Add binding for IMX NWL mipi dsi host controller
  drm/imx: Add NWL MIPI DSI host controller support

 .../bindings/display/imx/imx-nwl-dsi.txt      |  72 ++
 drivers/gpu/drm/Kconfig                       |   2 +
 drivers/gpu/drm/Makefile                      |   1 +
 drivers/gpu/drm/nwl/Kconfig                   |  12 +
 drivers/gpu/drm/nwl/Makefile                  |   2 +
 drivers/gpu/drm/nwl/nwl-drv.c                 | 594 ++++++++++++++
 drivers/gpu/drm/nwl/nwl-drv.h                 |  68 ++
 drivers/gpu/drm/nwl/nwl-dsi.c                 | 752 ++++++++++++++++++
 drivers/gpu/drm/nwl/nwl-dsi.h                 | 105 +++
 9 files changed, 1608 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/imx/imx-nwl-dsi.txt
 create mode 100644 drivers/gpu/drm/nwl/Kconfig
 create mode 100644 drivers/gpu/drm/nwl/Makefile
 create mode 100644 drivers/gpu/drm/nwl/nwl-drv.c
 create mode 100644 drivers/gpu/drm/nwl/nwl-drv.h
 create mode 100644 drivers/gpu/drm/nwl/nwl-dsi.c
 create mode 100644 drivers/gpu/drm/nwl/nwl-dsi.h

-- 
2.20.1

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

[PATCH 1/2] dt-bindings: imx: Add binding for IMX NWL mipi dsi host controller

[Guido Günther]

The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8
Socs.

Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
 .../bindings/display/imx/imx-nwl-dsi.txt      | 72 +++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/imx/imx-nwl-dsi.txt

diff --git a/Documentation/devicetree/bindings/display/imx/imx-nwl-dsi.txt b/Documentation/devicetree/bindings/display/imx/imx-nwl-dsi.txt
new file mode 100644
index 000000000000..d74b9e303417
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/imx-nwl-dsi.txt
@@ -0,0 +1,72 @@
+Northwest Logic MIPI-DSI on imx SoCs
+=====================================
+
+NWL MIPI-DSI host controller found in i.MX8 platforms. This is an
+encoder/connector for the for the NWL MIPI-DSI host.
+
+Required properties:
+- compatible: 		"fsl,<chip>-mipi-dsi"
+	The following strings are expected:
+			"fsl,imx8mq-mipi-dsi_drm"
+- reg: 			the register range of the MIPI-DSI controller
+- interrupts: 		the interrupt number for this module
+- clock, clock-names: 	phandles to the MIPI-DSI clocks
+	The following clocks are expected on all platforms:
+                "core"    - DSI core clock
+		"tx_esc"  - TX_ESC clock (used in escape mode)
+		"rx_esc"  - RX_ESC clock (used in escape mode)
+		"phy_ref" - PHY_REF clock. Clock is managed by the phy. Only
+                            used to read the clock rate.
+	The following clocks are expected on i.MX8mq:
+		"cosre"  - DSI core clock
+- assigned-clocks:	phandles to clocks that requires initial configuration
+- assigned-clock-rates:	rates of the clocks that requires initial configuration
+	The following clocks needs to have an initial configuration:
+	"tx_esc" (20 MHz) and "rx_esc" (80 Mhz).
+- phys: 		phandle to the phy module representing the DPHY
+			inside the MIPI-DSI IP block
+- phy-names: 		should be "dphy"
+
+Optional properties:
+- power-domains 	phandle to the power domain
+- src			phandle to the system reset controller (required on
+			i.MX8mq)
+- mux-sel		phandle to the MUX register set (required on i.MX8mq)
+- assigned-clock-parents phandles to parent clocks that needs to be assigned as
+			parents to clocks defined in assigned-clocks
+
+Example:
+	mipi_dsi: mipi_dsi@30A00000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "fsl,imx8mq-nwl-dsi";
+		reg = <0x0 0x30A00000 0x0 0x300>;
+		clocks = <&clk IMX8MQ_CLK_DSI_CORE_DIV>,
+			 <&clk IMX8MQ_CLK_DSI_AHB_DIV>,
+		         <&clk IMX8MQ_CLK_DSI_IPG_DIV>,
+			 <&clk IMX8MQ_CLK_DSI_PHY_REF_DIV>;
+		clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
+		assigned-clocks = <&clk IMX8MQ_CLK_DSI_AHB_SRC>,
+				  <&clk IMX8MQ_CLK_DSI_CORE_SRC>,
+				  <&clk IMX8MQ_VIDEO_PLL1_REF_SEL>,
+				  <&clk IMX8MQ_VIDEO_PLL1>,
+				  <&clk IMX8MQ_CLK_DSI_IPG_DIV>,
+				  <&clk IMX8MQ_CLK_DSI_AHB_DIV>;
+		assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>,
+					 <&clk IMX8MQ_SYS1_PLL_266M>,
+					 <&clk IMX8MQ_CLK_25M>,
+					 <&clk IMX8MQ_CLK_DSI_AHB_DIV>;
+		assigned-clock-rates = <80000000>,
+				       <266000000>,
+				       <0>,
+				       <599999999>,
+				       <20000000>,
+				       <80000000>;
+		interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+		power-domains = <&mipi_pd>;
+		src = <&src>;
+		mux-sel = <&gpr>;
+		phys = <&mipi_dsi_phy>;
+		phy-names = "dphy";
+		status = "okay";
+	};
-- 
2.20.1

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

[PATCH 2/2] drm/imx: Add NWL MIPI DSI host controller support

[Guido Günther]

This adds initial support for the NWL MIPI DSI Host controller found on
i.MX8 SoCs.

It adds support for the i.MX8MQ but the same IP can be found on
i.MX8QXP.

It has been tested on the Librem 5 devkit using DCSS.

Co-authored-by: Robert Chiras <robert.chiras@nxp.com>
Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
 drivers/gpu/drm/Kconfig       |   2 +
 drivers/gpu/drm/Makefile      |   1 +
 drivers/gpu/drm/nwl/Kconfig   |  12 +
 drivers/gpu/drm/nwl/Makefile  |   2 +
 drivers/gpu/drm/nwl/nwl-drv.c | 594 +++++++++++++++++++++++++++
 drivers/gpu/drm/nwl/nwl-drv.h |  68 +++
 drivers/gpu/drm/nwl/nwl-dsi.c | 752 ++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/nwl/nwl-dsi.h | 105 +++++
 8 files changed, 1536 insertions(+)
 create mode 100644 drivers/gpu/drm/nwl/Kconfig
 create mode 100644 drivers/gpu/drm/nwl/Makefile
 create mode 100644 drivers/gpu/drm/nwl/nwl-drv.c
 create mode 100644 drivers/gpu/drm/nwl/nwl-drv.h
 create mode 100644 drivers/gpu/drm/nwl/nwl-dsi.c
 create mode 100644 drivers/gpu/drm/nwl/nwl-dsi.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index bd943a71756c..0c9ee3ef55c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -303,6 +303,8 @@ source "drivers/gpu/drm/sti/Kconfig"
 
 source "drivers/gpu/drm/imx/Kconfig"
 
+source "drivers/gpu/drm/nwl/Kconfig"
+
 source "drivers/gpu/drm/v3d/Kconfig"
 
 source "drivers/gpu/drm/vc4/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f0c1f8731a27..169dd8062964 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -96,6 +96,7 @@ obj-$(CONFIG_DRM_STI) += sti/
 obj-$(CONFIG_DRM_IMX) += imx/
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
 obj-$(CONFIG_DRM_MESON)	+= meson/
+obj-$(CONFIG_DRM_IMX_NWL_DSI) += nwl/
 obj-y			+= i2c/
 obj-y			+= panel/
 obj-y			+= bridge/
diff --git a/drivers/gpu/drm/nwl/Kconfig b/drivers/gpu/drm/nwl/Kconfig
new file mode 100644
index 000000000000..9a6d275c8119
--- /dev/null
+++ b/drivers/gpu/drm/nwl/Kconfig
@@ -0,0 +1,12 @@
+config DRM_IMX_NWL_DSI
+	tristate "Support for Northwest Logic MIPI DSI Host controller"
+	depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM || COMPILE_TEST)
+	depends on COMMON_CLK
+	depends on MFD_SYSCON
+	depends on OF
+	select DRM_PANEL
+	select GENERIC_PHY
+	help
+	  This enables the Northwest Logic MIPI DSI Host controller as
+	  found on NXP's i.MX8 Processors.
+
diff --git a/drivers/gpu/drm/nwl/Makefile b/drivers/gpu/drm/nwl/Makefile
new file mode 100644
index 000000000000..9fa63483da5b
--- /dev/null
+++ b/drivers/gpu/drm/nwl/Makefile
@@ -0,0 +1,2 @@
+imx-nwl-objs := nwl-drv.o nwl-dsi.o
+obj-$(CONFIG_DRM_IMX_NWL_DSI) += imx-nwl.o
diff --git a/drivers/gpu/drm/nwl/nwl-drv.c b/drivers/gpu/drm/nwl/nwl-drv.c
new file mode 100644
index 000000000000..d1f0eb6fdbb1
--- /dev/null
+++ b/drivers/gpu/drm/nwl/nwl-drv.c
@@ -0,0 +1,594 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 NWL MIPI DSI host driver
+ *
+ * Copyright (C) 2017 NXP
+ * Copyright (C) 2019 Purism SPC
+ */
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_probe_helper.h>
+#include <linux/clk-provider.h>
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/gpio/consumer.h>
+#include <linux/irq.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/phy/phy.h>
+#include <linux/regmap.h>
+#include <linux/sys_soc.h>
+#include <video/videomode.h>
+
+#include "nwl-drv.h"
+#include "nwl-dsi.h"
+
+#define DRV_NAME "imx-nwl-dsi"
+
+/* 8MQ SRC specific registers */
+#define SRC_MIPIPHY_RCR	0x28
+#define RESET_BYTE_N	BIT(1)
+#define RESET_N		BIT(2)
+#define DPI_RESET_N	BIT(3)
+#define ESC_RESET_N	BIT(4)
+#define PCLK_RESET_N	BIT(5)
+
+#define IOMUXC_GPR13	0x34
+#define IMX8MQ_GPR13_MIPI_MUX_SEL BIT(2)
+
+/* Possible clocks */
+#define CLK_PIXEL	"pixel"
+#define CLK_CORE	"core"
+#define CLK_BYPASS	"bypass"
+
+enum imx_ext_regs {
+	IMX_REG_CSR = BIT(1),
+	IMX_REG_SRC = BIT(2),
+	IMX_REG_GPR = BIT(3),
+};
+
+static const struct regmap_config nwl_dsi_regmap_config = {
+	.reg_bits = 16,
+	.val_bits = 32,
+	.reg_stride = 4,
+	.max_register = IRQ_MASK2,
+	.name = DRV_NAME,
+};
+
+struct imx_nwl_platform_data {
+	int (*poweron)(struct imx_nwl_dsi *dsi);
+	int (*poweroff)(struct imx_nwl_dsi *dsi);
+	u32 ext_regs; /* required external registers */
+	struct imx_nwl_clk_config clk_config[NWL_MAX_PLATFORM_CLOCKS];
+};
+
+
+static inline struct imx_nwl_dsi *encoder_to_dsi(struct drm_encoder *encoder)
+{
+	return container_of(encoder, struct imx_nwl_dsi, encoder);
+}
+
+static inline struct imx_nwl_dsi *connector_to_dsi(struct drm_connector *con)
+{
+	return container_of(con, struct imx_nwl_dsi, connector);
+}
+
+static void imx_nwl_dsi_set_clocks(struct imx_nwl_dsi *dsi, bool enable)
+{
+	struct device *dev = dsi->dev;
+	const char *id;
+	struct clk *clk;
+	unsigned long new_rate, cur_rate;
+	bool enabled;
+	size_t i;
+	int ret;
+
+	DRM_DEV_DEBUG_DRIVER(dev, "%sabling platform clocks",
+			     enable ? "en" : "dis");
+	for (i = 0; i < ARRAY_SIZE(dsi->pdata->clk_config); i++) {
+		if (!dsi->clk_config[i].present)
+			continue;
+		id = dsi->clk_config[i].id;
+		clk = dsi->clk_config[i].clk;
+		new_rate = dsi->clk_config[i].rate;
+		cur_rate = clk_get_rate(clk);
+		enabled = dsi->clk_config[i].enabled;
+
+		/* BYPASS clk must have the same rate as PHY_REF clk */
+		if (!strcmp(id, CLK_BYPASS))
+			new_rate = clk_get_rate(dsi->phy_ref_clk);
+
+		if (enable) {
+			if (enabled && new_rate != cur_rate)
+				clk_disable_unprepare(clk);
+			else if (enabled && new_rate == cur_rate)
+				continue;
+			if (new_rate > 0)
+				clk_set_rate(clk, new_rate);
+			ret = clk_prepare_enable(clk);
+			if (ret < 0) {
+				DRM_DEV_ERROR(dev, "Failed to enable clock %s",
+					      id);
+			}
+			dsi->clk_config[i].enabled = true;
+			cur_rate = clk_get_rate(clk);
+			DRM_DEV_DEBUG_DRIVER(dev,
+				"Enabled %s clk (rate: req=%lu act=%lu)\n",
+				id, new_rate, cur_rate);
+		} else if (enabled) {
+			clk_disable_unprepare(clk);
+			dsi->clk_config[i].enabled = false;
+			DRM_DEV_DEBUG_DRIVER(dev, "Disabled %s clk\n", id);
+		}
+	}
+}
+
+static void imx_nwl_dsi_enable(struct imx_nwl_dsi *dsi)
+{
+	struct device *dev = dsi->dev;
+	int ret;
+
+	imx_nwl_dsi_set_clocks(dsi, true);
+
+	ret = dsi->pdata->poweron(dsi);
+	if (ret < 0)
+		DRM_DEV_ERROR(dev, "Failed to power on DSI (%d)\n", ret);
+}
+
+static void imx_nwl_dsi_disable(struct imx_nwl_dsi *dsi)
+{
+	struct device *dev = dsi->dev;
+
+	if (dsi->dpms_mode != DRM_MODE_DPMS_ON)
+		return;
+
+	DRM_DEV_DEBUG_DRIVER(dev, "disable");
+	dsi->pdata->poweroff(dsi);
+	imx_nwl_dsi_set_clocks(dsi, false);
+}
+
+static void imx_nwl_set_input_source(struct imx_nwl_dsi *dsi, bool dcss)
+{
+	u32 mux_val;
+
+	mux_val = dcss ? IMX8MQ_GPR13_MIPI_MUX_SEL : 0;
+	DRM_DEV_INFO(dsi->dev, "Using %s as input source\n",
+		     (mux_val) ? "DCSS" : "LCDIF");
+	regmap_update_bits(dsi->mux_sel,
+			   IOMUXC_GPR13,
+			   IMX8MQ_GPR13_MIPI_MUX_SEL,
+			   mux_val);
+}
+
+static void imx_nwl_dsi_encoder_enable(struct drm_encoder *encoder)
+{
+	struct imx_nwl_dsi *dsi = encoder_to_dsi(encoder);
+
+	if (dsi->dpms_mode == DRM_MODE_DPMS_ON)
+		return;
+
+	/* Use DCSS, for LCDIF we'll act as a bridge (tbd) */
+	imx_nwl_set_input_source(dsi, true);
+
+	pm_runtime_get_sync(dsi->dev);
+	imx_nwl_dsi_enable(dsi);
+	nwl_dsi_enable(dsi);
+	dsi->dpms_mode = DRM_MODE_DPMS_ON;
+}
+
+static void imx_nwl_dsi_encoder_disable(struct drm_encoder *encoder)
+{
+	struct imx_nwl_dsi *dsi = encoder_to_dsi(encoder);
+
+	if (dsi->dpms_mode != DRM_MODE_DPMS_ON)
+		return;
+
+	nwl_dsi_disable(dsi);
+	imx_nwl_dsi_disable(dsi);
+	pm_runtime_put_sync(dsi->dev);
+	dsi->dpms_mode = DRM_MODE_DPMS_OFF;
+}
+
+static int imx_nwl_dsi_encoder_atomic_check(struct drm_encoder *encoder,
+					struct drm_crtc_state *crtc_state,
+					struct drm_connector_state *conn_state)
+{
+	struct imx_nwl_dsi *dsi = encoder_to_dsi(encoder);
+	struct device *dev = dsi->dev;
+	struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+	union phy_configure_opts new_cfg;
+	unsigned long phy_ref_rate;
+	int ret;
+
+	ret = nwl_dsi_get_dphy_params(dsi, mode, &new_cfg);
+	if (ret < 0)
+		return ret;
+
+	/*
+	 * If hs clock is unchanged, we're all good - all parameters are
+	 * derived from it atm.
+	 */
+	if (new_cfg.mipi_dphy.hs_clk_rate == dsi->phy_cfg.mipi_dphy.hs_clk_rate)
+		return 0;
+
+	phy_ref_rate = clk_get_rate(dsi->phy_ref_clk);
+	DRM_DEV_DEBUG_DRIVER(dev, "PHY at ref rate: %lu\n", phy_ref_rate);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dsi->dev,
+			      "Cannot setup PHY for mode: %ux%u @%d Hz\n",
+			      mode->hdisplay, mode->vdisplay, mode->clock);
+		DRM_DEV_ERROR(dsi->dev, "PHY ref clk: %lu, bit clk: %lu\n",
+			      phy_ref_rate, new_cfg.mipi_dphy.hs_clk_rate);
+	} else {
+		/* Save the new desired phy config */
+		memcpy(&dsi->phy_cfg, &new_cfg, sizeof(new_cfg));
+	}
+	return ret;
+}
+
+static void imx_nwl_dsi_encoder_mode_set(struct drm_encoder *encoder,
+					 struct drm_display_mode *mode,
+					 struct drm_display_mode *adjusted)
+{
+	struct imx_nwl_dsi *dsi = encoder_to_dsi(encoder);
+
+	drm_display_mode_to_videomode(adjusted, &dsi->vm);
+	drm_mode_debug_printmodeline(adjusted);
+}
+
+static const struct drm_encoder_helper_funcs
+imx_nwl_dsi_encoder_helper_funcs = {
+	.enable = imx_nwl_dsi_encoder_enable,
+	.disable = imx_nwl_dsi_encoder_disable,
+	.atomic_check = imx_nwl_dsi_encoder_atomic_check,
+	.mode_set = imx_nwl_dsi_encoder_mode_set,
+};
+
+static const struct drm_encoder_funcs imx_nwl_dsi_encoder_funcs = {
+	.destroy = drm_encoder_cleanup,
+};
+
+static int imx_nwl_dsi_connector_get_modes(struct drm_connector *connector)
+{
+	struct imx_nwl_dsi *dsi = connector_to_dsi(connector);
+
+	return drm_panel_get_modes(dsi->panel);
+}
+
+static struct drm_connector_helper_funcs imx_nwl_dsi_connector_helper_funcs = {
+	.get_modes = imx_nwl_dsi_connector_get_modes,
+};
+
+static void imx_nwl_dsi_drm_connector_destroy(struct drm_connector *connector)
+{
+	drm_connector_unregister(connector);
+	drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs imx_nwl_dsi_atomic_connector_funcs = {
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.destroy = imx_nwl_dsi_drm_connector_destroy,
+	.reset = drm_atomic_helper_connector_reset,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int imx_nwl_mipi_dsi_register(struct drm_device *drm,
+				     struct imx_nwl_dsi *dsi)
+{
+	struct drm_encoder *encoder = &dsi->encoder;
+	struct drm_connector *connector = &dsi->connector;
+	struct device *dev = dsi->dev;
+	int ret;
+
+	DRM_DEV_DEBUG_DRIVER(dev, "%s: line: %d", __func__, __LINE__);
+	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm,
+							     dev->of_node);
+	if (encoder->possible_crtcs == 0) {
+		DRM_DEV_DEBUG_DRIVER(dev, "No CRTČs found yet\n");
+		return -EPROBE_DEFER;
+	}
+
+	drm_encoder_helper_add(&dsi->encoder,
+			       &imx_nwl_dsi_encoder_helper_funcs);
+	ret = drm_encoder_init(drm, &dsi->encoder, &imx_nwl_dsi_encoder_funcs,
+			       DRM_MODE_ENCODER_DSI, NULL);
+	if (ret)
+		return ret;
+
+	drm_connector_helper_add(connector,
+				 &imx_nwl_dsi_connector_helper_funcs);
+
+	ret = drm_connector_init(drm, &dsi->connector,
+				 &imx_nwl_dsi_atomic_connector_funcs,
+				 DRM_MODE_CONNECTOR_DSI);
+	if (ret)
+		return ret;
+
+	ret = drm_connector_attach_encoder(connector, encoder);
+	if (ret)
+		return ret;
+
+	DRM_DEV_DEBUG_DRIVER(dev, "%s: line: %d", __func__, __LINE__);
+	return 0;
+}
+
+static int imx_nwl_dsi_parse_dt(struct imx_nwl_dsi *dsi)
+{
+	struct device_node *np = dsi->dev->of_node;
+	struct platform_device *pdev = to_platform_device(dsi->dev);
+	struct resource *res;
+	struct clk *clk;
+	const char *clk_id;
+	void __iomem *regs;
+	int i, ret;
+
+	dsi->phy = devm_phy_get(dsi->dev, "dphy");
+	if (IS_ERR(dsi->phy)) {
+		ret = PTR_ERR(dsi->phy);
+		dev_err(dsi->dev, "Could not get PHY (%d)\n", ret);
+		return ret;
+	}
+
+	/* Platform dependent clocks */
+	memcpy(dsi->clk_config, dsi->pdata->clk_config,
+	       sizeof(dsi->pdata->clk_config));
+
+	for (i = 0; i < ARRAY_SIZE(dsi->pdata->clk_config); i++) {
+		if (!dsi->clk_config[i].present)
+			continue;
+
+		clk_id = dsi->clk_config[i].id;
+		clk = devm_clk_get(dsi->dev, clk_id);
+		if (IS_ERR(clk)) {
+			ret = PTR_ERR(clk);
+			dev_err(dsi->dev, "Failed to get %s clock (%d)\n",
+				clk_id, ret);
+			return ret;
+		}
+		DRM_DEV_DEBUG_DRIVER(dsi->dev, "Setup clk %s (rate: %lu)\n",
+				     clk_id, clk_get_rate(clk));
+		dsi->clk_config[i].clk = clk;
+	}
+
+	/* DSI clocks */
+	clk = devm_clk_get(dsi->dev, "phy_ref");
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		dev_err(dsi->dev, "Failed to get phy_ref clock: %d\n", ret);
+		return ret;
+	}
+	dsi->phy_ref_clk = clk;
+
+	clk = devm_clk_get(dsi->dev, "rx_esc");
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		dev_err(dsi->dev, "Failed to get rx_esc clock: %d\n", ret);
+		return ret;
+	}
+	dsi->rx_esc_clk = clk;
+
+	clk = devm_clk_get(dsi->dev, "tx_esc");
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		dev_err(dsi->dev, "Failed to get tx_esc clock: %d\n", ret);
+		return ret;
+	}
+	dsi->tx_esc_clk = clk;
+
+	/* Look for required regmaps */
+	dsi->csr = syscon_regmap_lookup_by_phandle(np, "csr");
+	if (IS_ERR(dsi->csr) && dsi->pdata->ext_regs & IMX_REG_CSR) {
+		ret = PTR_ERR(dsi->csr);
+		DRM_DEV_ERROR(dsi->dev, "Failed to get CSR regmap (%d).\n",
+			      ret);
+		return ret;
+	}
+	dsi->reset = syscon_regmap_lookup_by_phandle(np, "src");
+	if (IS_ERR(dsi->reset) && (dsi->pdata->ext_regs & IMX_REG_SRC)) {
+		ret = PTR_ERR(dsi->reset);
+		DRM_DEV_ERROR(dsi->dev, "Failed to get SRC regmap (%d).\n",
+			      ret);
+		return ret;
+	}
+	dsi->mux_sel = syscon_regmap_lookup_by_phandle(np, "mux-sel");
+	if (IS_ERR(dsi->mux_sel) && (dsi->pdata->ext_regs & IMX_REG_GPR)) {
+		ret = PTR_ERR(dsi->mux_sel);
+		DRM_DEV_ERROR(dsi->dev, "Failed to get GPR regmap (%d).\n",
+			      ret);
+		return ret;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	regs = devm_ioremap_resource(dsi->dev, res);
+	if (IS_ERR(regs)) {
+		DRM_DEV_ERROR(dsi->dev, "Failed to map NWL DSI registers.\n");
+		return PTR_ERR(regs);
+	}
+
+	dsi->regs = devm_regmap_init_mmio(dsi->dev, regs,
+					  &nwl_dsi_regmap_config);
+	if (IS_ERR(dsi->regs)) {
+		DRM_DEV_ERROR(dsi->dev, "Failed to create NWL DSI regmap.\n");
+		return PTR_ERR(dsi->regs);
+	}
+
+	dsi->irq = platform_get_irq(pdev, 0);
+	if (dsi->irq < 0) {
+		DRM_DEV_ERROR(dsi->dev, "Failed to get device IRQ.\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int imx8mq_dsi_poweron(struct imx_nwl_dsi *dsi)
+{
+	/* otherwise the display stays blank */
+	usleep_range(200, 300);
+
+	regmap_update_bits(dsi->reset, SRC_MIPIPHY_RCR,
+			   PCLK_RESET_N, PCLK_RESET_N);
+	regmap_update_bits(dsi->reset, SRC_MIPIPHY_RCR,
+			   ESC_RESET_N, ESC_RESET_N);
+	regmap_update_bits(dsi->reset, SRC_MIPIPHY_RCR,
+			   RESET_BYTE_N, RESET_BYTE_N);
+	regmap_update_bits(dsi->reset, SRC_MIPIPHY_RCR,
+			   DPI_RESET_N, DPI_RESET_N);
+
+	return 0;
+}
+
+static int imx8mq_dsi_poweroff(struct imx_nwl_dsi *dsi)
+{
+	regmap_update_bits(dsi->reset, SRC_MIPIPHY_RCR,
+			   PCLK_RESET_N, 0);
+	regmap_update_bits(dsi->reset, SRC_MIPIPHY_RCR,
+			   ESC_RESET_N, 0);
+	regmap_update_bits(dsi->reset, SRC_MIPIPHY_RCR,
+			   RESET_BYTE_N, 0);
+	regmap_update_bits(dsi->reset, SRC_MIPIPHY_RCR,
+			   DPI_RESET_N, 0);
+
+	return 0;
+}
+
+static struct imx_nwl_platform_data imx8mq_dev = {
+	.poweron = &imx8mq_dsi_poweron,
+	.poweroff = &imx8mq_dsi_poweroff,
+	.clk_config = {
+		{ .id = CLK_CORE,   .present = true },
+		{ .id = CLK_PIXEL,  .present = false },
+		{ .id = CLK_BYPASS, .present = false },
+	},
+	.ext_regs = IMX_REG_SRC | IMX_REG_GPR,
+};
+
+static const struct of_device_id imx_nwl_dsi_dt_ids[] = {
+	{ .compatible = "fsl,imx8mq-nwl-dsi", .data = &imx8mq_dev, },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx_nwl_dsi_dt_ids);
+
+static const struct soc_device_attribute imx_nwl_quirks_match[] = {
+	{ .soc_id = "i.MX8MQ", .revision = "2.0",
+	  .data = (void *)E11418_HS_MODE_QUIRK },
+	{ /* sentinel. */ },
+};
+
+static int imx_nwl_dsi_bind(struct device *dev,	struct device *master,
+			    void *data)
+{
+	struct drm_device *drm = data;
+	const struct of_device_id *of_id =
+		of_match_device(imx_nwl_dsi_dt_ids, dev);
+	const struct imx_nwl_platform_data *pdata = of_id->data;
+	const struct soc_device_attribute *attr;
+	struct imx_nwl_dsi *dsi;
+	int ret;
+
+	dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
+	if (!dsi)
+		return -ENOMEM;
+
+	dsi->dev = dev;
+	dsi->pdata = pdata;
+	dsi->dpms_mode = DRM_MODE_DPMS_OFF;
+
+	ret = imx_nwl_dsi_parse_dt(dsi);
+	if (ret)
+		return ret;
+
+	ret = devm_request_irq(dev, dsi->irq, nwl_dsi_irq_handler, 0,
+			       dev_name(dev), dsi);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dev, "Failed to request IRQ: %d (%d)\n",
+			      dsi->irq, ret);
+		return ret;
+	}
+
+	ret = imx_nwl_mipi_dsi_register(drm, dsi);
+	if (ret) {
+		DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
+		goto err_cleanup;
+	}
+
+	dsi->dsi_host.ops = &nwl_dsi_host_ops;
+	dsi->dsi_host.dev = dev;
+	ret = mipi_dsi_host_register(&dsi->dsi_host);
+
+	if (ret) {
+		DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
+		goto err_cleanup;
+	}
+
+	attr = soc_device_match(imx_nwl_quirks_match);
+	if (attr)
+		dsi->quirks = (uintptr_t)attr->data;
+
+	if (!dsi->panel) {
+		ret = -EPROBE_DEFER;
+		goto err_mipi_dsi_host;
+	}
+
+	dev_set_drvdata(dev, dsi);
+	pm_runtime_enable(dev);
+	return 0;
+
+err_mipi_dsi_host:
+	mipi_dsi_host_unregister(&dsi->dsi_host);
+err_cleanup:
+	devm_free_irq(dev, dsi->irq, dsi);
+	dsi->connector.funcs->destroy(&dsi->connector);
+	dsi->encoder.funcs->destroy(&dsi->encoder);
+	return ret;
+}
+
+static void imx_nwl_dsi_unbind(struct device *dev,
+			   struct device *master,
+			   void *data)
+{
+	struct imx_nwl_dsi *dsi = dev_get_drvdata(dev);
+
+	if (dsi->dpms_mode == DRM_MODE_DPMS_ON)
+		imx_nwl_dsi_encoder_disable(&dsi->encoder);
+
+	if (dsi->encoder.dev)
+		drm_encoder_cleanup(&dsi->encoder);
+}
+
+static const struct component_ops imx_nwl_dsi_component_ops = {
+	.bind	= imx_nwl_dsi_bind,
+	.unbind	= imx_nwl_dsi_unbind,
+};
+
+static int imx_nwl_dsi_probe(struct platform_device *pdev)
+{
+	return component_add(&pdev->dev, &imx_nwl_dsi_component_ops);
+}
+
+static int imx_nwl_dsi_remove(struct platform_device *pdev)
+{
+	component_del(&pdev->dev, &imx_nwl_dsi_component_ops);
+	return 0;
+}
+
+static struct platform_driver imx_nwl_dsi_driver = {
+	.probe		= imx_nwl_dsi_probe,
+	.remove		= imx_nwl_dsi_remove,
+	.driver		= {
+		.of_match_table = imx_nwl_dsi_dt_ids,
+		.name	= DRV_NAME,
+	},
+};
+
+module_platform_driver(imx_nwl_dsi_driver);
+
+MODULE_AUTHOR("NXP Semiconductor");
+MODULE_AUTHOR("Purism SPC");
+MODULE_DESCRIPTION("i.MX8 Northwest Logic MIPI-DSI driver");
+MODULE_LICENSE("GPL"); /* GPLv2 or later */
diff --git a/drivers/gpu/drm/nwl/nwl-drv.h b/drivers/gpu/drm/nwl/nwl-drv.h
new file mode 100644
index 000000000000..9f0347d4cafe
--- /dev/null
+++ b/drivers/gpu/drm/nwl/nwl-drv.h
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 NWL MIPI DSI host driver
+ *
+ * Copyright (C) 2017 NXP
+ * Copyright (C) 2019 Purism SPC
+ */
+
+#ifndef __NWL_DRV_H__
+#define __NWL_DRV_H__
+
+#include <linux/phy/phy.h>
+#include <drm/drm_mipi_dsi.h>
+
+struct imx_nwl_platform_data;
+
+/* imx nwl quirks */
+#define E11418_HS_MODE_QUIRK BIT(0)
+#define USE_E11418_HS_MODE_QUIRK(x) ((x) & E11418_HS_MODE_QUIRK)
+
+#define NWL_MAX_PLATFORM_CLOCKS 3
+struct imx_nwl_clk_config {
+	const char *id;
+	struct clk *clk;
+	bool present;
+	bool enabled;
+	u32 rate;
+};
+
+struct imx_nwl_dsi {
+	struct drm_encoder encoder;
+	struct drm_connector connector;
+	struct mipi_dsi_host dsi_host;
+	struct drm_panel *panel;
+	struct device *dev;
+	struct phy *phy;
+	union phy_configure_opts phy_cfg;
+	unsigned int quirks;
+
+	struct regmap *regs;
+	int irq;
+
+	/* External registers */
+	struct regmap *csr;
+	struct regmap *mux_sel;
+	struct regmap *reset;
+
+	/* Platform dependent clocks */
+	struct imx_nwl_clk_config clk_config[3];
+	/* DSI clocks */
+	struct clk *phy_ref_clk;
+	struct clk *rx_esc_clk;
+	struct clk *tx_esc_clk;
+
+	/* dsi lanes */
+	u32 lanes;
+	enum mipi_dsi_pixel_format format;
+	struct videomode vm;
+	unsigned long dsi_mode_flags;
+
+	int dpms_mode;
+
+	struct mipi_dsi_transfer *xfer;
+
+	const struct imx_nwl_platform_data *pdata;
+};
+
+#endif /* __NWL_DRV_H__ */
diff --git a/drivers/gpu/drm/nwl/nwl-dsi.c b/drivers/gpu/drm/nwl/nwl-dsi.c
new file mode 100644
index 000000000000..d6d33239cb07
--- /dev/null
+++ b/drivers/gpu/drm/nwl/nwl-dsi.c
@@ -0,0 +1,752 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * NWL DSI host driver
+ *
+ * Copyright (C) 2017 NXP
+ * Copyright (C) 2019 Purism SPC
+ */
+
+#include <asm/unaligned.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+#include <linux/clk.h>
+#include <linux/irq.h>
+#include <linux/regmap.h>
+#include <video/mipi_display.h>
+#include <video/videomode.h>
+
+#include "nwl-drv.h"
+#include "nwl-dsi.h"
+
+#define MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
+
+/* PKT reg bit manipulation */
+#define REG_MASK(e, s) (((1 << ((e) - (s) + 1)) - 1) << (s))
+#define REG_PUT(x, e, s) (((x) << (s)) & REG_MASK(e, s))
+#define REG_GET(x, e, s) (((x) & REG_MASK(e, s)) >> (s))
+
+/*
+ * PKT_CONTROL format:
+ * [15: 0] - word count
+ * [17:16] - virtual channel
+ * [23:18] - data type
+ * [24]    - LP or HS select (0 - LP, 1 - HS)
+ * [25]    - perform BTA after packet is sent
+ * [26]    - perform BTA only, no packet tx
+ */
+#define WC(x)		REG_PUT((x), 15,  0)
+#define TX_VC(x)	REG_PUT((x), 17, 16)
+#define TX_DT(x)	REG_PUT((x), 23, 18)
+#define HS_SEL(x)	REG_PUT((x), 24, 24)
+#define BTA_TX(x)	REG_PUT((x), 25, 25)
+#define BTA_NO_TX(x)	REG_PUT((x), 26, 26)
+
+/*
+ * RX_PKT_HEADER format:
+ * [15: 0] - word count
+ * [21:16] - data type
+ * [23:22] - virtual channel
+ */
+#define RX_DT(x)	REG_GET((x), 21, 16)
+#define RX_VC(x)	REG_GET((x), 23, 22)
+
+/*
+ * DSI Video mode
+ */
+#define VIDEO_MODE_BURST_MODE_WITH_SYNC_PULSES      0
+#define VIDEO_MODE_NON_BURST_MODE_WITH_SYNC_EVENTS  BIT(0)
+#define VIDEO_MODE_BURST_MODE                       BIT(1)
+
+/*
+ * DPI color coding
+ */
+#define	DPI_16_BIT_565_PACKED  0
+#define	DPI_16_BIT_565_ALIGNED 1
+#define	DPI_16_BIT_565_SHIFTED 2
+#define	DPI_18_BIT_PACKED      3
+#define	DPI_18_BIT_ALIGNED     4
+#define	DPI_24_BIT	       5
+
+/*
+ * DPI Pixel format
+ */
+#define PIXEL_FORMAT_16                 0
+#define PIXEL_FORMAT_18                 BIT(0)
+#define PIXEL_FORMAT_18L                BIT(1)
+#define PIXEL_FORMAT_24                 (BIT(0) | BIT(1))
+
+enum transfer_direction {
+	DSI_PACKET_SEND,
+	DSI_PACKET_RECEIVE
+};
+
+struct mipi_dsi_transfer {
+	const struct mipi_dsi_msg *msg;
+	struct mipi_dsi_packet packet;
+	struct completion completed;
+
+	int status;    /* status of transmission */
+	enum transfer_direction direction;
+	bool need_bta;
+	u8 cmd;
+	u16 rx_word_count;
+	size_t tx_len; /* bytes sent */
+	size_t rx_len; /* bytes received */
+};
+
+static inline int nwl_dsi_write(struct imx_nwl_dsi *dsi, unsigned int reg,
+				u32 val)
+{
+	int ret;
+
+	ret = regmap_write(dsi->regs, reg, val);
+	if (ret < 0)
+		DRM_DEV_ERROR(dsi->dev, "Failed to write NWL DSI reg 0x%x: %d",
+			      reg, ret);
+	return ret;
+}
+
+static inline u32 nwl_dsi_read(struct imx_nwl_dsi *dsi, u32 reg)
+{
+	unsigned int val;
+	int ret;
+
+	ret = regmap_read(dsi->regs, reg, &val);
+	if (ret < 0)
+		DRM_DEV_ERROR(dsi->dev, "Failed to read NWL DSI reg 0x%x: %d",
+			      reg, ret);
+
+	return val;
+}
+
+static u32 nwl_dsi_get_dpi_pixel_format(enum mipi_dsi_pixel_format format)
+{
+
+	switch (format) {
+	case MIPI_DSI_FMT_RGB565:
+		return PIXEL_FORMAT_16;
+	case MIPI_DSI_FMT_RGB666:
+		return PIXEL_FORMAT_18L;
+	case MIPI_DSI_FMT_RGB666_PACKED:
+		return PIXEL_FORMAT_18;
+	case MIPI_DSI_FMT_RGB888:
+		return PIXEL_FORMAT_24;
+	default:
+		return -EINVAL;
+	}
+}
+
+int nwl_dsi_get_dphy_params(struct imx_nwl_dsi *dsi,
+			   struct drm_display_mode *mode,
+			   union phy_configure_opts *phy_opts)
+{
+	unsigned long rate;
+
+	if (dsi->lanes < 1 || dsi->lanes > 4)
+		return -EINVAL;
+
+	/*
+	 * So far the DPHY spec minimal timings work for both mixel
+	 * dphy and nwl dsi host
+	 */
+	phy_mipi_dphy_get_default_config(
+		mode->crtc_clock * 1000,
+		mipi_dsi_pixel_format_to_bpp(dsi->format),
+		dsi->lanes, &phy_opts->mipi_dphy);
+	rate = clk_get_rate(dsi->tx_esc_clk);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "LP clk is @%lu Hz\n", rate);
+	phy_opts->mipi_dphy.lp_clk_rate = rate;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(nwl_dsi_get_dphy_params);
+
+#define PSEC_PER_SEC	1000000000000LL
+/*
+ * ps2bc - Picoseconds to byte clock cycles
+ */
+static unsigned int ps2bc(struct imx_nwl_dsi *dsi, unsigned long long ps)
+{
+	int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+
+	return DIV_ROUND_UP(ps * dsi->vm.pixelclock * bpp,
+			    dsi->lanes * 8 * PSEC_PER_SEC);
+}
+
+/**
+ * ui2bc - UI time periods to byte clock cycles
+ */
+static unsigned int ui2bc(struct imx_nwl_dsi *dsi, unsigned long long ui)
+{
+	int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+
+	return DIV_ROUND_UP(ui * dsi->lanes,
+			    dsi->vm.pixelclock * bpp);
+}
+
+#define USEC_PER_SEC	1000000L
+/*
+ * us2bc - micro seconds to lp clock cycles
+ */
+static unsigned int us2lp(unsigned int lp_clk_rate, unsigned long us)
+{
+	return DIV_ROUND_UP(us * lp_clk_rate, USEC_PER_SEC);
+}
+
+static int nwl_dsi_config_host(struct imx_nwl_dsi *dsi)
+{
+	u32 cycles;
+	struct phy_configure_opts_mipi_dphy *cfg = &dsi->phy_cfg.mipi_dphy;
+
+	if (dsi->lanes < 1 || dsi->lanes > 4)
+		return -EINVAL;
+
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "DSI Lanes %d", dsi->lanes);
+	nwl_dsi_write(dsi, CFG_NUM_LANES, dsi->lanes - 1);
+
+	if (dsi->dsi_mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
+		nwl_dsi_write(dsi, CFG_NONCONTINUOUS_CLK, 0x01);
+		nwl_dsi_write(dsi, CFG_AUTOINSERT_EOTP, 0x01);
+	} else {
+		nwl_dsi_write(dsi, CFG_NONCONTINUOUS_CLK, 0x00);
+		nwl_dsi_write(dsi, CFG_AUTOINSERT_EOTP, 0x00);
+	}
+
+	/* values in byte clock cycles */
+	cycles = ui2bc(dsi, cfg->clk_pre);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_t_pre: 0x%x", cycles);
+	nwl_dsi_write(dsi, CFG_T_PRE, cycles);
+	cycles = ps2bc(dsi, cfg->lpx + cfg->clk_prepare + cfg->clk_zero);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap (pre): 0x%x", cycles);
+	cycles += ui2bc(dsi, cfg->clk_pre);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap: 0x%x", cycles);
+	nwl_dsi_write(dsi, CFG_T_POST, cycles);
+	cycles = ps2bc(dsi, cfg->hs_exit);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_tx_gap: 0x%x", cycles);
+	nwl_dsi_write(dsi, CFG_TX_GAP, cycles);
+
+	nwl_dsi_write(dsi, CFG_EXTRA_CMDS_AFTER_EOTP, 0x01);
+	nwl_dsi_write(dsi, CFG_HTX_TO_COUNT, 0x00);
+	nwl_dsi_write(dsi, CFG_LRX_H_TO_COUNT, 0x00);
+	nwl_dsi_write(dsi, CFG_BTA_H_TO_COUNT, 0x00);
+	/* In LP clock cycles */
+	cycles = us2lp(cfg->lp_clk_rate, cfg->wakeup);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "cfg_twakeup: 0x%x", cycles);
+	nwl_dsi_write(dsi, CFG_TWAKEUP, cycles);
+
+	return 0;
+}
+
+static int nwl_dsi_config_dpi(struct imx_nwl_dsi *dsi)
+{
+	struct videomode *vm = &dsi->vm;
+	u32 color_format, mode;
+	bool burst_mode;
+
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "hfront_porch = %d", vm->hfront_porch);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "hback_porch = %d", vm->hback_porch);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "hsync_len = %d", vm->hsync_len);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "hactive = %d", vm->hactive);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "vfront_porch = %d", vm->vfront_porch);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "vback_porch = %d", vm->vback_porch);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "vsync_len = %d", vm->vsync_len);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "vactive = %d", vm->vactive);
+	DRM_DEV_DEBUG_DRIVER(dsi->dev, "clock = %lu kHz",
+			     vm->pixelclock / 1000);
+
+	color_format = nwl_dsi_get_dpi_pixel_format(dsi->format);
+	if (color_format < 0) {
+		DRM_DEV_ERROR(dsi->dev, "Invalid color format 0x%x",
+			      dsi->format);
+		return color_format;
+	}
+
+	nwl_dsi_write(dsi, INTERFACE_COLOR_CODING, DPI_24_BIT);
+	nwl_dsi_write(dsi, PIXEL_FORMAT, color_format);
+	nwl_dsi_write(dsi, VSYNC_POLARITY,
+		      !!(vm->flags & DISPLAY_FLAGS_VSYNC_HIGH));
+	nwl_dsi_write(dsi, HSYNC_POLARITY,
+		      !!(vm->flags & DISPLAY_FLAGS_HSYNC_HIGH));
+
+	burst_mode = (dsi->dsi_mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
+		!(dsi->dsi_mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE);
+
+	if (burst_mode) {
+		nwl_dsi_write(dsi, VIDEO_MODE, VIDEO_MODE_BURST_MODE);
+		nwl_dsi_write(dsi, PIXEL_FIFO_SEND_LEVEL, 256);
+	} else {
+		mode = ((dsi->dsi_mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE) ?
+			VIDEO_MODE_BURST_MODE_WITH_SYNC_PULSES :
+			VIDEO_MODE_NON_BURST_MODE_WITH_SYNC_EVENTS);
+		nwl_dsi_write(dsi, VIDEO_MODE, mode);
+		nwl_dsi_write(dsi, PIXEL_FIFO_SEND_LEVEL, vm->hactive);
+	}
+
+	nwl_dsi_write(dsi, HFP, vm->hfront_porch);
+	nwl_dsi_write(dsi, HBP, vm->hback_porch);
+	nwl_dsi_write(dsi, HSA, vm->hsync_len);
+
+	nwl_dsi_write(dsi, ENABLE_MULT_PKTS, 0x0);
+	nwl_dsi_write(dsi, BLLP_MODE, 0x1);
+	nwl_dsi_write(dsi, ENABLE_MULT_PKTS, 0x0);
+	nwl_dsi_write(dsi, USE_NULL_PKT_BLLP, 0x0);
+	nwl_dsi_write(dsi, VC, 0x0);
+
+	nwl_dsi_write(dsi, PIXEL_PAYLOAD_SIZE, vm->hactive);
+	nwl_dsi_write(dsi, VACTIVE, vm->vactive - 1);
+	nwl_dsi_write(dsi, VBP, vm->vback_porch);
+	nwl_dsi_write(dsi, VFP, vm->vfront_porch);
+
+	return 0;
+}
+
+static int nwl_dsi_enable_tx_clock(struct imx_nwl_dsi *dsi)
+{
+	struct device *dev = dsi->dev;
+	int ret;
+
+	ret = clk_prepare_enable(dsi->tx_esc_clk);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dev, "Failed to enable tx_esc clk: %d\n", ret);
+		return ret;
+	}
+
+	DRM_DEV_DEBUG_DRIVER(dev, "Enabled tx_esc clk @%lu Hz\n",
+			     clk_get_rate(dsi->tx_esc_clk));
+	return 0;
+}
+
+static int nwl_dsi_enable_rx_clock(struct imx_nwl_dsi *dsi)
+{
+	struct device *dev = dsi->dev;
+	int ret;
+
+	ret = clk_prepare_enable(dsi->rx_esc_clk);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dev, "Failed to enable rx_esc clk: %d\n", ret);
+		return ret;
+	}
+
+	DRM_DEV_DEBUG_DRIVER(dev, "Enabled rx_esc clk @%lu Hz\n",
+			     clk_get_rate(dsi->rx_esc_clk));
+	return 0;
+}
+
+static void nwl_dsi_init_interrupts(struct imx_nwl_dsi *dsi)
+{
+	u32 irq_enable;
+
+	nwl_dsi_write(dsi, IRQ_MASK, 0xffffffff);
+	nwl_dsi_write(dsi, IRQ_MASK2, 0x7);
+
+	irq_enable = ~(u32)(TX_PKT_DONE_MASK | RX_PKT_HDR_RCVD_MASK |
+			    TX_FIFO_OVFLW_MASK | HS_TX_TIMEOUT_MASK);
+
+	nwl_dsi_write(dsi, IRQ_MASK, irq_enable);
+}
+
+static int nwl_dsi_host_attach(struct mipi_dsi_host *dsi_host,
+			       struct mipi_dsi_device *device)
+{
+	struct imx_nwl_dsi *dsi = container_of(dsi_host,
+						struct imx_nwl_dsi,
+						dsi_host);
+	struct device *dev = dsi->dev;
+
+	DRM_DEV_INFO(dev, "lanes=%u, format=0x%x flags=0x%lx\n",
+		     device->lanes, device->format, device->mode_flags);
+
+	if (device->lanes < 1 || device->lanes > 4)
+		return -EINVAL;
+
+	dsi->lanes = device->lanes;
+	dsi->format = device->format;
+	dsi->dsi_mode_flags = device->mode_flags;
+	dsi->panel = of_drm_find_panel(device->dev.of_node);
+	if (dsi->panel)
+		return drm_panel_attach(dsi->panel, &dsi->connector);
+
+	return -EINVAL;
+}
+
+static int nwl_dsi_host_detach(struct mipi_dsi_host *dsi_host,
+			       struct mipi_dsi_device *device)
+{
+	struct imx_nwl_dsi *dsi = container_of(dsi_host,
+						struct imx_nwl_dsi,
+						dsi_host);
+	drm_panel_detach(dsi->panel);
+	return 0;
+}
+
+static bool nwl_dsi_read_packet(struct imx_nwl_dsi *dsi, u32 status)
+{
+	struct device *dev = dsi->dev;
+	struct mipi_dsi_transfer *xfer = dsi->xfer;
+	u8 *payload = xfer->msg->rx_buf;
+	u32 val;
+	u16 word_count;
+	u8 channel;
+	u8 data_type;
+
+	xfer->status = 0;
+
+	if (xfer->rx_word_count == 0) {
+		if (!(status & RX_PKT_HDR_RCVD))
+			return false;
+		/* Get the RX header and parse it */
+		val = nwl_dsi_read(dsi, RX_PKT_HEADER);
+		word_count = WC(val);
+		channel	= RX_VC(val);
+		data_type = RX_DT(val);
+
+		if (channel != xfer->msg->channel) {
+			DRM_DEV_ERROR(dev,
+				"[%02X] Channel mismatch (%u != %u)\n",
+				 xfer->cmd, channel, xfer->msg->channel);
+			return true;
+		}
+
+		switch (data_type) {
+		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
+			/* Fall through */
+		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
+			if (xfer->msg->rx_len > 1) {
+				/* read second byte */
+				payload[1] = word_count >> 8;
+				++xfer->rx_len;
+			}
+			/* Fall through */
+		case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
+			/* Fall through */
+		case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
+			if (xfer->msg->rx_len > 0) {
+				/* read first byte */
+				payload[0] = word_count & 0xff;
+				++xfer->rx_len;
+			}
+			xfer->status = xfer->rx_len;
+			return true;
+		case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
+			word_count &= 0xff;
+			DRM_DEV_ERROR(dev,
+				"[%02X] DSI error report: 0x%02x\n",
+				xfer->cmd, word_count);
+			xfer->status = -EPROTO;
+			return true;
+
+		}
+
+		if (word_count > xfer->msg->rx_len) {
+			DRM_DEV_ERROR(dev,
+				"[%02X] Receive buffer too small: %lu (< %u)\n",
+				 xfer->cmd,
+				 xfer->msg->rx_len,
+				 word_count);
+			return true;
+		}
+
+		xfer->rx_word_count = word_count;
+	} else {
+		/* Set word_count from previous header read */
+		word_count = xfer->rx_word_count;
+	}
+
+	/* If RX payload is not yet received, wait for it */
+	if (!(status & RX_PKT_PAYLOAD_DATA_RCVD))
+		return false;
+
+	/* Read the RX payload */
+	while (word_count >= 4) {
+		val = nwl_dsi_read(dsi, RX_PAYLOAD);
+		payload[0] = (val >>  0) & 0xff;
+		payload[1] = (val >>  8) & 0xff;
+		payload[2] = (val >> 16) & 0xff;
+		payload[3] = (val >> 24) & 0xff;
+		payload += 4;
+		xfer->rx_len += 4;
+		word_count -= 4;
+	}
+
+	if (word_count > 0) {
+		val = nwl_dsi_read(dsi, RX_PAYLOAD);
+		switch (word_count) {
+		case 3:
+			payload[2] = (val >> 16) & 0xff;
+			++xfer->rx_len;
+			/* Fall through */
+		case 2:
+			payload[1] = (val >>  8) & 0xff;
+			++xfer->rx_len;
+			/* Fall through */
+		case 1:
+			payload[0] = (val >>  0) & 0xff;
+			++xfer->rx_len;
+			break;
+		}
+	}
+
+	xfer->status = xfer->rx_len;
+
+	return true;
+}
+
+static void nwl_dsi_finish_transmission(struct imx_nwl_dsi *dsi, u32 status)
+{
+	struct mipi_dsi_transfer *xfer = dsi->xfer;
+	bool end_packet = false;
+
+	if (!xfer)
+		return;
+
+	if (status & TX_FIFO_OVFLW) {
+		DRM_DEV_ERROR_RATELIMITED(dsi->dev, "tx fifo overflow");
+		return;
+	}
+
+	if (status & HS_TX_TIMEOUT) {
+		DRM_DEV_ERROR_RATELIMITED(dsi->dev, "HS tx timeout");
+		return;
+	}
+
+	if (xfer->direction == DSI_PACKET_SEND && status & TX_PKT_DONE) {
+		xfer->status = xfer->tx_len;
+		end_packet = true;
+	} else if (status & DPHY_DIRECTION &&
+		   ((status & (RX_PKT_HDR_RCVD | RX_PKT_PAYLOAD_DATA_RCVD)))) {
+		end_packet = nwl_dsi_read_packet(dsi, status);
+	}
+
+	if (end_packet)
+		complete(&xfer->completed);
+}
+
+static void nwl_dsi_begin_transmission(struct imx_nwl_dsi *dsi)
+{
+	struct mipi_dsi_transfer *xfer = dsi->xfer;
+	struct mipi_dsi_packet *pkt = &xfer->packet;
+	const u8 *payload;
+	size_t length;
+	u16 word_count;
+	u8 hs_mode;
+	u32 val;
+	u32 hs_workaround = 0;
+
+	/* Send the payload, if any */
+	length = pkt->payload_length;
+	payload = pkt->payload;
+
+	while (length >= 4) {
+		val = get_unaligned_le32(payload);
+		hs_workaround |= !(val & 0xFFFF00);
+		nwl_dsi_write(dsi, TX_PAYLOAD, val);
+		payload += 4;
+		length -= 4;
+	}
+	/* Send the rest of the payload */
+	val = 0;
+	switch (length) {
+	case 3:
+		val |= payload[2] << 16;
+		/* Fall through */
+	case 2:
+		val |= payload[1] << 8;
+		hs_workaround |= !(val & 0xFFFF00);
+		/* Fall through */
+	case 1:
+		val |= payload[0];
+		nwl_dsi_write(dsi, TX_PAYLOAD, val);
+		break;
+	}
+	xfer->tx_len = pkt->payload_length;
+
+	/*
+	 * Send the header
+	 * header[0] = Virtual Channel + Data Type
+	 * header[1] = Word Count LSB (LP) or first param (SP)
+	 * header[2] = Word Count MSB (LP) or second param (SP)
+	 */
+	word_count = pkt->header[1] | (pkt->header[2] << 8);
+	if ((hs_workaround && USE_E11418_HS_MODE_QUIRK(dsi->quirks))) {
+		DRM_DEV_DEBUG_DRIVER(dsi->dev,
+				     "Using hs mode workaround for cmd 0x%x",
+				     xfer->cmd);
+		hs_mode = 1;
+	} else {
+		hs_mode = (xfer->msg->flags & MIPI_DSI_MSG_USE_LPM) ? 0 : 1;
+	}
+	val = WC(word_count) |
+		TX_VC(xfer->msg->channel) |
+		TX_DT(xfer->msg->type) |
+		HS_SEL(hs_mode) |
+		BTA_TX(xfer->need_bta);
+	nwl_dsi_write(dsi, PKT_CONTROL, val);
+
+	/* Send packet command */
+	nwl_dsi_write(dsi, SEND_PACKET, 0x1);
+}
+
+static ssize_t nwl_dsi_host_transfer(struct mipi_dsi_host *dsi_host,
+				     const struct mipi_dsi_msg *msg)
+{
+	struct imx_nwl_dsi *dsi = container_of(dsi_host,
+					       struct imx_nwl_dsi,
+					       dsi_host);
+	struct mipi_dsi_transfer xfer;
+	ssize_t ret = 0;
+
+	/* Create packet to be sent */
+	dsi->xfer = &xfer;
+	ret = mipi_dsi_create_packet(&xfer.packet, msg);
+	if (ret < 0) {
+		dsi->xfer = NULL;
+		return ret;
+	}
+
+	if ((msg->type & MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM ||
+	    msg->type & MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM ||
+	    msg->type & MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM ||
+	    msg->type & MIPI_DSI_DCS_READ) &&
+	    msg->rx_len > 0 &&
+	    msg->rx_buf != NULL)
+		xfer.direction = DSI_PACKET_RECEIVE;
+	else
+		xfer.direction = DSI_PACKET_SEND;
+
+	xfer.need_bta = (xfer.direction == DSI_PACKET_RECEIVE);
+	xfer.need_bta |= (msg->flags & MIPI_DSI_MSG_REQ_ACK)?1:0;
+	xfer.msg = msg;
+	xfer.status = -ETIMEDOUT;
+	xfer.rx_word_count = 0;
+	xfer.rx_len = 0;
+	xfer.cmd = 0x00;
+	if (msg->tx_len > 0)
+		xfer.cmd = ((u8 *)(msg->tx_buf))[0];
+	init_completion(&xfer.completed);
+
+	nwl_dsi_enable_rx_clock(dsi);
+
+	/* Initiate the DSI packet transmision */
+	nwl_dsi_begin_transmission(dsi);
+
+	if (!wait_for_completion_timeout(&xfer.completed, MIPI_FIFO_TIMEOUT)) {
+		DRM_DEV_ERROR(dsi_host->dev,
+			      "[%02X] DSI transfer timed out\n", xfer.cmd);
+		ret = -ETIMEDOUT;
+	} else {
+		ret = xfer.status;
+	}
+
+	clk_disable_unprepare(dsi->rx_esc_clk);
+
+	return ret;
+}
+
+const struct mipi_dsi_host_ops nwl_dsi_host_ops = {
+	.attach = nwl_dsi_host_attach,
+	.detach = nwl_dsi_host_detach,
+	.transfer = nwl_dsi_host_transfer,
+};
+
+
+irqreturn_t nwl_dsi_irq_handler(int irq, void *data)
+{
+	u32 irq_status;
+	struct imx_nwl_dsi *dsi = data;
+
+	irq_status = nwl_dsi_read(dsi, IRQ_STATUS);
+
+	if (irq_status & TX_PKT_DONE ||
+	    irq_status & RX_PKT_HDR_RCVD ||
+	    irq_status & RX_PKT_PAYLOAD_DATA_RCVD)
+		nwl_dsi_finish_transmission(dsi, irq_status);
+
+	return IRQ_HANDLED;
+}
+EXPORT_SYMBOL_GPL(nwl_dsi_irq_handler);
+
+int nwl_dsi_enable(struct imx_nwl_dsi *dsi)
+{
+	struct device *dev = dsi->dev;
+	union phy_configure_opts *phy_cfg = &dsi->phy_cfg;
+	int ret;
+
+	if (!dsi->lanes) {
+		DRM_DEV_ERROR(dev, "Need DSI lanes: %d\n", dsi->lanes);
+		return -EINVAL;
+	}
+
+	ret = phy_init(dsi->phy);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dev, "Failed to init DSI phy: %d\n", ret);
+		return ret;
+	}
+
+	ret = phy_configure(dsi->phy, phy_cfg);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dev, "Failed to configure DSI phy: %d\n", ret);
+		return ret;
+	}
+
+	ret = nwl_dsi_enable_tx_clock(dsi);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dev, "Failed to enable tx clock: %d\n", ret);
+		return ret;
+	}
+
+	ret = nwl_dsi_config_host(dsi);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dev, "Failed to set up DSI: %d", ret);
+		return ret;
+	}
+
+	ret = nwl_dsi_config_dpi(dsi);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dev, "Failed to set up DPI: %d", ret);
+		return ret;
+	}
+
+	ret = phy_power_on(dsi->phy);
+	if (ret < 0) {
+		DRM_DEV_ERROR(dev, "Failed to power on DPHY (%d)\n", ret);
+		return ret;
+	}
+
+	nwl_dsi_init_interrupts(dsi);
+
+	ret = drm_panel_prepare(dsi->panel);
+	if (ret) {
+		DRM_DEV_ERROR(dev, "Failed to setup panel\n");
+		return ret;
+	}
+
+	nwl_dsi_write(dsi, CFG_NONCONTINUOUS_CLK,
+		      !!(dsi->dsi_mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS));
+
+	DRM_DEV_DEBUG_DRIVER(dev, "Enabling the panel\n");
+	ret = drm_panel_enable(dsi->panel);
+	if (ret) {
+		DRM_DEV_ERROR(dev, "Failed to enable panel\n");
+		drm_panel_unprepare(dsi->panel);
+		return ret;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(nwl_dsi_enable);
+
+int nwl_dsi_disable(struct imx_nwl_dsi *dsi)
+{
+	struct device *dev = dsi->dev;
+
+	clk_disable_unprepare(dsi->tx_esc_clk);
+	devm_free_irq(dev, dsi->irq, dsi);
+
+	phy_power_off(dsi->phy);
+	phy_exit(dsi->phy);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(nwl_dsi_disable);
diff --git a/drivers/gpu/drm/nwl/nwl-dsi.h b/drivers/gpu/drm/nwl/nwl-dsi.h
new file mode 100644
index 000000000000..bbb9ac1fc8c8
--- /dev/null
+++ b/drivers/gpu/drm/nwl/nwl-dsi.h
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 NWL MIPI DSI host driver
+ *
+ * Copyright (C) 2017 NXP
+ * Copyright (C) 2019 Purism SPC
+ */
+#ifndef __NWL_DSI_H__
+#define __NWL_DSI_H__
+
+#include <drm/drm_mipi_dsi.h>
+
+/* DSI HOST registers */
+#define CFG_NUM_LANES			0x0
+#define CFG_NONCONTINUOUS_CLK		0x4
+#define CFG_T_PRE			0x8
+#define CFG_T_POST			0xc
+#define CFG_TX_GAP			0x10
+#define CFG_AUTOINSERT_EOTP		0x14
+#define CFG_EXTRA_CMDS_AFTER_EOTP	0x18
+#define CFG_HTX_TO_COUNT		0x1c
+#define CFG_LRX_H_TO_COUNT		0x20
+#define CFG_BTA_H_TO_COUNT		0x24
+#define CFG_TWAKEUP			0x28
+#define CFG_STATUS_OUT			0x2c
+#define RX_ERROR_STATUS			0x30
+
+/* DSI DPI registers */
+#define PIXEL_PAYLOAD_SIZE		0x200
+#define PIXEL_FIFO_SEND_LEVEL		0x204
+#define INTERFACE_COLOR_CODING		0x208
+#define PIXEL_FORMAT			0x20c
+#define VSYNC_POLARITY			0x210
+#define HSYNC_POLARITY			0x214
+#define VIDEO_MODE			0x218
+#define HFP				0x21c
+#define HBP				0x220
+#define HSA				0x224
+#define ENABLE_MULT_PKTS		0x228
+#define VBP				0x22c
+#define VFP				0x230
+#define BLLP_MODE			0x234
+#define USE_NULL_PKT_BLLP		0x238
+#define VACTIVE				0x23c
+#define VC				0x240
+
+/* DSI APB PKT control */
+#define TX_PAYLOAD			0x280
+#define PKT_CONTROL			0x284
+#define SEND_PACKET			0x288
+#define PKT_STATUS			0x28c
+#define PKT_FIFO_WR_LEVEL		0x290
+#define PKT_FIFO_RD_LEVEL		0x294
+#define RX_PAYLOAD			0x298
+#define RX_PKT_HEADER			0x29c
+
+/* DSI IRQ handling */
+#define IRQ_STATUS			0x2a0
+#define SM_NOT_IDLE			BIT(0)
+#define TX_PKT_DONE			BIT(1)
+#define DPHY_DIRECTION			BIT(2)
+#define TX_FIFO_OVFLW			BIT(3)
+#define TX_FIFO_UDFLW			BIT(4)
+#define RX_FIFO_OVFLW			BIT(5)
+#define RX_FIFO_UDFLW			BIT(6)
+#define RX_PKT_HDR_RCVD			BIT(7)
+#define RX_PKT_PAYLOAD_DATA_RCVD	BIT(8)
+#define BTA_TIMEOUT			BIT(29)
+#define LP_RX_TIMEOUT			BIT(30)
+#define HS_TX_TIMEOUT			BIT(31)
+
+#define IRQ_STATUS2			0x2a4
+#define SINGLE_BIT_ECC_ERR		BIT(0)
+#define MULTI_BIT_ECC_ERR		BIT(1)
+#define CRC_ERR				BIT(2)
+
+#define IRQ_MASK			0x2a8
+#define SM_NOT_IDLE_MASK		BIT(0)
+#define TX_PKT_DONE_MASK		BIT(1)
+#define DPHY_DIRECTION_MASK		BIT(2)
+#define TX_FIFO_OVFLW_MASK		BIT(3)
+#define TX_FIFO_UDFLW_MASK		BIT(4)
+#define RX_FIFO_OVFLW_MASK		BIT(5)
+#define RX_FIFO_UDFLW_MASK		BIT(6)
+#define RX_PKT_HDR_RCVD_MASK		BIT(7)
+#define RX_PKT_PAYLOAD_DATA_RCVD_MASK	BIT(8)
+#define BTA_TIMEOUT_MASK		BIT(29)
+#define LP_RX_TIMEOUT_MASK		BIT(30)
+#define HS_TX_TIMEOUT_MASK		BIT(31)
+
+#define IRQ_MASK2			0x2ac
+#define SINGLE_BIT_ECC_ERR_MASK		BIT(0)
+#define MULTI_BIT_ECC_ERR_MASK		BIT(1)
+#define CRC_ERR_MASK			BIT(2)
+
+extern const struct mipi_dsi_host_ops nwl_dsi_host_ops;
+
+irqreturn_t nwl_dsi_irq_handler(int irq, void *data);
+int nwl_dsi_enable(struct imx_nwl_dsi *dsi);
+int nwl_dsi_disable(struct imx_nwl_dsi *dsi);
+int nwl_dsi_get_dphy_params(struct imx_nwl_dsi *dsi,
+			    struct drm_display_mode *mode,
+			    union phy_configure_opts *phy_opts);
+
+#endif /* __NWL_DSI_H__ */
-- 
2.20.1


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

Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Guido Günther]

Hi,
On Thu, Mar 07, 2019 at 11:30:51AM +0100, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
> SoCs.
> 
> It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
> i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
> I only have imx8mq boards to test I omitted the platform data for other SoCs.
> 
> The code is based on NXPs BSP so I added Robert Chiras as Co-authored-by but
> I'm happy to swap Author: and Co-authored-by: if that looks more appropriate.
> The most notable changes over the BSP driver are
>  - Calculate HS mode timing from phy_configure_opts_mipi_dphy
>  - Perform all clock setup via DT
>  - Merge nwl-imx and nwl drivers
>  - Add B0 silion revision quirk
> 
> Posting this is likely a bit premature (hence v0) but I wanted for one show how
> this hooks into the mixel dphy posted earlier [1] and avoid duplicating work.
> So if there's other code out there doing the same I'm be happy to merge
> efforts.

Since this is likely not going anywhere until we have a dcss driver aimed
for mainline I'm not going spam the list with further revisions. However
the 5.x version is maintained here:

    https://source.puri.sm/guido.gunther/linux-imx8/tree/forward-upstream/next-20190506/imx-nwl/v1-wip

Feedback is still welcome. It'll eventually be forwarded to newer
linux-next versions.

Changes over the posted version are:

- Add quirk for IMQ8MQ silicon B0 revision to not mess with the
  system reset controller on power down since enable won't work
  afterwards otherwise.
- Disable tx esc clock *after* the phy power down to unbreak
  disable/enable (unblank/blank)
- Drop devm_free_irq() handled by the device driver core
- Add ports to dt binding docs
- Select GENERIC_PHY_MIPI_DPHY instead of GENERIC_PHY for
  phy_mipi_dphy_get_default_config
- Include drm_print.h to fix build on next-20190408
- Drop some debugging messages
- Newline terminate all DRM_ printouts

If somebody is working on DCSS support it'd be cool to know since this
driver is currently a component of imx-display-subsystem which will only
work out if dcss is handled like this as well.
Cheers,
 -- Guido

> 
> It has been tested quite bit (in a version backported to 4.18) on Librem 5
> devkit using DCSS (which is not mainlined yet) and a MIPI DSI panel[2]. In
> principle LCDIF can also act as input source. I intend look into next so this
> can actually be tested without further patches on mainline kernels.
> 
> [1]: https://lists.freedesktop.org/archives/dri-devel/2019-March/209680.html
> [2]: https://source.puri.sm/guido.gunther/linux-imx8/tree/imx8-4.18-wip-nwl-dsi-rework
> 
> Guido Günther (2):
>   dt-bindings: imx: Add binding for IMX NWL mipi dsi host controller
>   drm/imx: Add NWL MIPI DSI host controller support
> 
>  .../bindings/display/imx/imx-nwl-dsi.txt      |  72 ++
>  drivers/gpu/drm/Kconfig                       |   2 +
>  drivers/gpu/drm/Makefile                      |   1 +
>  drivers/gpu/drm/nwl/Kconfig                   |  12 +
>  drivers/gpu/drm/nwl/Makefile                  |   2 +
>  drivers/gpu/drm/nwl/nwl-drv.c                 | 594 ++++++++++++++
>  drivers/gpu/drm/nwl/nwl-drv.h                 |  68 ++
>  drivers/gpu/drm/nwl/nwl-dsi.c                 | 752 ++++++++++++++++++
>  drivers/gpu/drm/nwl/nwl-dsi.h                 | 105 +++
>  9 files changed, 1608 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/imx/imx-nwl-dsi.txt
>  create mode 100644 drivers/gpu/drm/nwl/Kconfig
>  create mode 100644 drivers/gpu/drm/nwl/Makefile
>  create mode 100644 drivers/gpu/drm/nwl/nwl-drv.c
>  create mode 100644 drivers/gpu/drm/nwl/nwl-drv.h
>  create mode 100644 drivers/gpu/drm/nwl/nwl-dsi.c
>  create mode 100644 drivers/gpu/drm/nwl/nwl-dsi.h
> 
> -- 
> 2.20.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Shawn Guo]

On Wed, May 08, 2019 at 07:18:27PM +0200, Guido Günther wrote:
> If somebody is working on DCSS support it'd be cool to know since this

I have some time slots here and will start looking at it, if no one else
is already working on it.

Shawn

> driver is currently a component of imx-display-subsystem which will only
> work out if dcss is handled like this as well.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Guido Günther]

Hi,
On Mon, May 27, 2019 at 10:24:02AM +0800, Shawn Guo wrote:
> On Wed, May 08, 2019 at 07:18:27PM +0200, Guido Günther wrote:
> > If somebody is working on DCSS support it'd be cool to know since this
> 
> I have some time slots here and will start looking at it, if no one else
> is already working on it.

Nice. My current forward port of a minimal DCSS needed for DSI is here:

    https://source.puri.sm/guido.gunther/linux-imx8/tree/imx8-5.x-drm

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

Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Lucas Stach]

Am Mittwoch, den 08.05.2019, 19:18 +0200 schrieb Guido Günther:
> Hi,
> On Thu, Mar 07, 2019 at 11:30:51AM +0100, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
> > SoCs.
> > 
> > It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
> > i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
> > I only have imx8mq boards to test I omitted the platform data for other SoCs.
> > 
> > The code is based on NXPs BSP so I added Robert Chiras as Co-authored-by but
> > I'm happy to swap Author: and Co-authored-by: if that looks more appropriate.
> > The most notable changes over the BSP driver are
> >  - Calculate HS mode timing from phy_configure_opts_mipi_dphy
> >  - Perform all clock setup via DT
> >  - Merge nwl-imx and nwl drivers
> >  - Add B0 silion revision quirk
> > 
> > Posting this is likely a bit premature (hence v0) but I wanted for one show how
> > this hooks into the mixel dphy posted earlier [1] and avoid duplicating work.
> > So if there's other code out there doing the same I'm be happy to merge
> > efforts.
> 
> Since this is likely not going anywhere until we have a dcss driver aimed
> for mainline I'm not going spam the list with further revisions. However
> the 5.x version is maintained here:
> 
>     https://source.puri.sm/guido.gunther/linux-imx8/tree/forward-upstream/next-20190506/imx-nwl/v1-wip
> 
> Feedback is still welcome. It'll eventually be forwarded to newer
> linux-next versions.
> 
> Changes over the posted version are:
> 
> - Add quirk for IMQ8MQ silicon B0 revision to not mess with the
>   system reset controller on power down since enable won't work
>   afterwards otherwise.
> - Disable tx esc clock *after* the phy power down to unbreak
>   disable/enable (unblank/blank)
> - Drop devm_free_irq() handled by the device driver core
> - Add ports to dt binding docs
> - Select GENERIC_PHY_MIPI_DPHY instead of GENERIC_PHY for
>   phy_mipi_dphy_get_default_config
> - Include drm_print.h to fix build on next-20190408
> - Drop some debugging messages
> - Newline terminate all DRM_ printouts
> 
> If somebody is working on DCSS support it'd be cool to know since this
> driver is currently a component of imx-display-subsystem which will only
> work out if dcss is handled like this as well.

We have been looking at how to support DCSS in mainline for a while,
but most of the actual work got pushed behind in schedule due to other
priorities.

One thing I can can say for certain is that DCSS should not be
integrated into imx-drm. It's a totally different hardware and
downstream clearly shows that it's not a good idea to cram it into imx-
drm.

Also the artificial split between hardware control in
drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
DRM for the output parts and V4L2 for the input parts. As the DCSS has
no video input capabilities the driver could be simplified a lot by
moving it all into a single DRM driver.

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

Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Guido Günther]

Hi Lucas,
On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 08.05.2019, 19:18 +0200 schrieb Guido Günther:
> > Hi,
> > On Thu, Mar 07, 2019 at 11:30:51AM +0100, Guido Günther wrote:
> > > This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
> > > SoCs.
> > > 
> > > It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
> > > i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
> > > I only have imx8mq boards to test I omitted the platform data for other SoCs.
> > > 
> > > The code is based on NXPs BSP so I added Robert Chiras as Co-authored-by but
> > > I'm happy to swap Author: and Co-authored-by: if that looks more appropriate.
> > > The most notable changes over the BSP driver are
> > >  - Calculate HS mode timing from phy_configure_opts_mipi_dphy
> > >  - Perform all clock setup via DT
> > >  - Merge nwl-imx and nwl drivers
> > >  - Add B0 silion revision quirk
> > > 
> > > Posting this is likely a bit premature (hence v0) but I wanted for one show how
> > > this hooks into the mixel dphy posted earlier [1] and avoid duplicating work.
> > > So if there's other code out there doing the same I'm be happy to merge
> > > efforts.
> > 
> > Since this is likely not going anywhere until we have a dcss driver aimed
> > for mainline I'm not going spam the list with further revisions. However
> > the 5.x version is maintained here:
> > 
> >     https://source.puri.sm/guido.gunther/linux-imx8/tree/forward-upstream/next-20190506/imx-nwl/v1-wip
> > 
> > Feedback is still welcome. It'll eventually be forwarded to newer
> > linux-next versions.
> > 
> > Changes over the posted version are:
> > 
> > - Add quirk for IMQ8MQ silicon B0 revision to not mess with the
> >   system reset controller on power down since enable won't work
> >   afterwards otherwise.
> > - Disable tx esc clock *after* the phy power down to unbreak
> >   disable/enable (unblank/blank)
> > - Drop devm_free_irq() handled by the device driver core
> > - Add ports to dt binding docs
> > - Select GENERIC_PHY_MIPI_DPHY instead of GENERIC_PHY for
> >   phy_mipi_dphy_get_default_config
> > - Include drm_print.h to fix build on next-20190408
> > - Drop some debugging messages
> > - Newline terminate all DRM_ printouts
> > 
> > If somebody is working on DCSS support it'd be cool to know since this
> > driver is currently a component of imx-display-subsystem which will only
> > work out if dcss is handled like this as well.
> 
> We have been looking at how to support DCSS in mainline for a while,
> but most of the actual work got pushed behind in schedule due to other
> priorities.
> 
> One thing I can can say for certain is that DCSS should not be
> integrated into imx-drm. It's a totally different hardware and
> downstream clearly shows that it's not a good idea to cram it into imx-
> drm.
> 
> Also the artificial split between hardware control in
> drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> DRM for the output parts and V4L2 for the input parts. As the DCSS has
> no video input capabilities the driver could be simplified a lot by
> moving it all into a single DRM driver.

I agree. While moving if forward from NXPs tree this caused more trouble
than good so let's keep it separate form imx-drm.
Cheers,
 -- Guido
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Shawn Guo]

Hi Lucas,

On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> We have been looking at how to support DCSS in mainline for a while,
> but most of the actual work got pushed behind in schedule due to other
> priorities.

I have some time to contribute.  Would you suggest how I should help
here?

1. You guys already have something close to completion and do not need
   more hands.
2. You guys already have some preliminary code and can use help from
   others.
3. You guys haven't got anything to start with, but just some design
   principles that anyone who wants to work on it should consider.

Which is the one that you want me to read?

> One thing I can can say for certain is that DCSS should not be
> integrated into imx-drm. It's a totally different hardware and
> downstream clearly shows that it's not a good idea to cram it into imx-
> drm.

I haven't gone deeper into the vendor code, but from a brief looking I
didn't see so many problems with integrating DCSS into imx-drm.  It's
not so unreasonable to take imx-drm as an imx-display-subsystem which
can have multiple CRTCs.  So can you please elaborate a bit on why it's
really a bad idea?

> Also the artificial split between hardware control in
> drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> DRM for the output parts and V4L2 for the input parts. As the DCSS has
> no video input capabilities the driver could be simplified a lot by
> moving it all into a single DRM driver.

Agreed on this.

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

Re: [EXT] Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Laurentiu Palcu]

Hi Shawn, Lucas,

On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> Caution: EXT Email
> 
> Hi Lucas,
> 
> On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > We have been looking at how to support DCSS in mainline for a while,
> > but most of the actual work got pushed behind in schedule due to other
> > priorities.
> 
> I have some time to contribute.  Would you suggest how I should help
> here?
> 
> 1. You guys already have something close to completion and do not need
>    more hands.
> 2. You guys already have some preliminary code and can use help from
>    others.
> 3. You guys haven't got anything to start with, but just some design
>    principles that anyone who wants to work on it should consider.
> 
> Which is the one that you want me to read?

We're already working on clearing up the DCSS code and preparing it for
upstreaming. It should be done in the following weeks. The reason we've
been delaying this is because neither HDMI nor MIPI support was present
and, until these are upstream, testing DCSS would be quite impossible.

> 
> > One thing I can can say for certain is that DCSS should not be
> > integrated into imx-drm. It's a totally different hardware and
> > downstream clearly shows that it's not a good idea to cram it into imx-
> > drm.
> 
> I haven't gone deeper into the vendor code, but from a brief looking I
> didn't see so many problems with integrating DCSS into imx-drm.  It's
> not so unreasonable to take imx-drm as an imx-display-subsystem which
> can have multiple CRTCs.  So can you please elaborate a bit on why it's
> really a bad idea?

I'd be interested to hear about this as well.

> 
> > Also the artificial split between hardware control in
> > drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> > IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> > DRM for the output parts and V4L2 for the input parts. As the DCSS has
> > no video input capabilities the driver could be simplified a lot by
> > moving it all into a single DRM driver.
> 
> Agreed on this.

I also agree on this. DCSS core code will probably be moved inside the
same directory: drivers/gpu/drm/imx/dcss.

Thanks,
laurentiu

> 
> Shawn
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Claurentiu.palcu%40nxp.com%7Cda7e62c6b69f4e0c800408d6e30d4dfc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946043619737103&sdata=bnr9EJG5y4Hqr%2FUT5T3EfvWIQKAvkVCZGhdPwEPJQOw%3D&reserved=0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EXT] Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Shawn Guo]

Hi Laurentiu,

On Tue, May 28, 2019 at 07:03:54AM +0000, Laurentiu Palcu wrote:
> Hi Shawn, Lucas,
> 
> On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> > Caution: EXT Email
> > 
> > Hi Lucas,
> > 
> > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > We have been looking at how to support DCSS in mainline for a while,
> > > but most of the actual work got pushed behind in schedule due to other
> > > priorities.
> > 
> > I have some time to contribute.  Would you suggest how I should help
> > here?
> > 
> > 1. You guys already have something close to completion and do not need
> >    more hands.
> > 2. You guys already have some preliminary code and can use help from
> >    others.
> > 3. You guys haven't got anything to start with, but just some design
> >    principles that anyone who wants to work on it should consider.
> > 
> > Which is the one that you want me to read?
> 
> We're already working on clearing up the DCSS code and preparing it for
> upstreaming. It should be done in the following weeks.

Great!  I will stay away from this then :)

> The reason we've
> been delaying this is because neither HDMI nor MIPI support was present
> and, until these are upstream, testing DCSS would be quite impossible.

Well, they have to be done one by one, and I guess DCSS should be the
first one.  I think it's fine to test DCSS with out-of-tree HDMI or
MIPI driver which is not ready for submission yet.

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

Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Lucas Stach]

Hi Shawn,

Am Dienstag, den 28.05.2019, 09:38 +0800 schrieb Shawn Guo:
> Hi Lucas,
> 
> On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > We have been looking at how to support DCSS in mainline for a while,
> > but most of the actual work got pushed behind in schedule due to other
> > priorities.
> 
> I have some time to contribute.  Would you suggest how I should help
> here?
> 
> 1. You guys already have something close to completion and do not need
>    more hands.
> 2. You guys already have some preliminary code and can use help from
>    others.
> 3. You guys haven't got anything to start with, but just some design
>    principles that anyone who wants to work on it should consider.
> 
> Which is the one that you want me to read?

Mostly the 3rd. We spent some time on getting the DCSS driver to work
on upstream kernel and familiarize with the hardware, but we don't have
any close to mainline quality code.

> > One thing I can can say for certain is that DCSS should not be
> > integrated into imx-drm. It's a totally different hardware and
> > downstream clearly shows that it's not a good idea to cram it into imx-
> > drm.
> 
> I haven't gone deeper into the vendor code, but from a brief looking I
> didn't see so many problems with integrating DCSS into imx-drm.  It's
> not so unreasonable to take imx-drm as an imx-display-subsystem which
> can have multiple CRTCs.  So can you please elaborate a bit on why it's
> really a bad idea?

It's a totally different hardware, with very different behavior, so
there is basically no potential for any code sharing. The downstream
driver is a hell of "oh, things are different here, let's introduce yet
another function pointer to make the distinction between the HW". It
complicates the imx-drm for no good reason. Our experience with imx-drm 
is that it is already at a complexity level that makes it hard to
reason about things when hunting bugs.

The boiler plate required to write a atomic KMS driver is not that
much, so I would rather have a clean split between the two hardware
drivers. Frankly they don't share anything except both being a atomic
KMS driver and running on a SoC called i.MX.

> > Also the artificial split between hardware control in
> > drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> > IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> > DRM for the output parts and V4L2 for the input parts. As the DCSS has
> > no video input capabilities the driver could be simplified a lot by
> > moving it all into a single DRM driver.
> 
> Agreed on this.

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

Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Daniel Vetter]

On Tue, May 28, 2019 at 10:20 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Hi Shawn,
>
> Am Dienstag, den 28.05.2019, 09:38 +0800 schrieb Shawn Guo:
> > Hi Lucas,
> >
> > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > We have been looking at how to support DCSS in mainline for a while,
> > > but most of the actual work got pushed behind in schedule due to other
> > > priorities.
> >
> > I have some time to contribute.  Would you suggest how I should help
> > here?
> >
> > 1. You guys already have something close to completion and do not need
> >    more hands.
> > 2. You guys already have some preliminary code and can use help from
> >    others.
> > 3. You guys haven't got anything to start with, but just some design
> >    principles that anyone who wants to work on it should consider.
> >
> > Which is the one that you want me to read?
>
> Mostly the 3rd. We spent some time on getting the DCSS driver to work
> on upstream kernel and familiarize with the hardware, but we don't have
> any close to mainline quality code.
>
> > > One thing I can can say for certain is that DCSS should not be
> > > integrated into imx-drm. It's a totally different hardware and
> > > downstream clearly shows that it's not a good idea to cram it into imx-
> > > drm.
> >
> > I haven't gone deeper into the vendor code, but from a brief looking I
> > didn't see so many problems with integrating DCSS into imx-drm.  It's
> > not so unreasonable to take imx-drm as an imx-display-subsystem which
> > can have multiple CRTCs.  So can you please elaborate a bit on why it's
> > really a bad idea?
>
> It's a totally different hardware, with very different behavior, so
> there is basically no potential for any code sharing. The downstream
> driver is a hell of "oh, things are different here, let's introduce yet
> another function pointer to make the distinction between the HW". It
> complicates the imx-drm for no good reason. Our experience with imx-drm
> is that it is already at a complexity level that makes it hard to
> reason about things when hunting bugs.
>
> The boiler plate required to write a atomic KMS driver is not that
> much, so I would rather have a clean split between the two hardware
> drivers. Frankly they don't share anything except both being a atomic
> KMS driver and running on a SoC called i.MX.

We've also made lots of improvements in the helpers, I think a clean
driver will be quiet a bit smaller than an imx based one. ARM is doing
the same with komeda and the malidp driver btw. Another option would
be 2 kms drivers in one .ko, which is what nouveau does with pre-nv50
and post-nv50. But that only makes sense if you have also the render
side in the same driver because it's all from the same vendor. msm is
similar, with msm4 vs msm5.

But for soc display-only I think two separate drivers, if the hw
really changed enough, is the best option. You can still stuff them
into the same subdir ofc.

Cheers, Daniel

> > > Also the artificial split between hardware control in
> > > drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> > > IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> > > DRM for the output parts and V4L2 for the input parts. As the DCSS has
> > > no video input capabilities the driver could be simplified a lot by
> > > moving it all into a single DRM driver.
> >
> > Agreed on this.
>
> Regards,
> Lucas
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EXT] Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Guido Günther]

Hi Laurentiu,
On Tue, May 28, 2019 at 07:03:54AM +0000, Laurentiu Palcu wrote:
> Hi Shawn, Lucas,
> 
> On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> > Caution: EXT Email
> > 
> > Hi Lucas,
> > 
> > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > We have been looking at how to support DCSS in mainline for a while,
> > > but most of the actual work got pushed behind in schedule due to other
> > > priorities.
> > 
> > I have some time to contribute.  Would you suggest how I should help
> > here?
> > 
> > 1. You guys already have something close to completion and do not need
> >    more hands.
> > 2. You guys already have some preliminary code and can use help from
> >    others.
> > 3. You guys haven't got anything to start with, but just some design
> >    principles that anyone who wants to work on it should consider.
> > 
> > Which is the one that you want me to read?
> 
> We're already working on clearing up the DCSS code and preparing it for
> upstreaming. It should be done in the following weeks. The reason we've
> been delaying this is because neither HDMI nor MIPI support was present
> and, until these are upstream, testing DCSS would be quite impossible.

MIPI support is here:

  mixel:  https://patchwork.freedesktop.org/series/58817/
  nwl:  https://patchwork.freedesktop.org/series/57686/

The NWL driver needs to be adjusted depending on whether we hook into
imx-display-subsystem or not (and then likely moved to the right
subdir). Can we somehow get this moving in sync (even in a non public
tree if necessary).
Cheers,
 -- Guido


> > > One thing I can can say for certain is that DCSS should not be
> > > integrated into imx-drm. It's a totally different hardware and
> > > downstream clearly shows that it's not a good idea to cram it into imx-
> > > drm.
> > 
> > I haven't gone deeper into the vendor code, but from a brief looking I
> > didn't see so many problems with integrating DCSS into imx-drm.  It's
> > not so unreasonable to take imx-drm as an imx-display-subsystem which
> > can have multiple CRTCs.  So can you please elaborate a bit on why it's
> > really a bad idea?
> 
> I'd be interested to hear about this as well.
> 
> > 
> > > Also the artificial split between hardware control in
> > > drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> > > IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> > > DRM for the output parts and V4L2 for the input parts. As the DCSS has
> > > no video input capabilities the driver could be simplified a lot by
> > > moving it all into a single DRM driver.
> > 
> > Agreed on this.
> 
> I also agree on this. DCSS core code will probably be moved inside the
> same directory: drivers/gpu/drm/imx/dcss.
> 
> Thanks,
> laurentiu
> 
> > 
> > Shawn
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Claurentiu.palcu%40nxp.com%7Cda7e62c6b69f4e0c800408d6e30d4dfc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946043619737103&sdata=bnr9EJG5y4Hqr%2FUT5T3EfvWIQKAvkVCZGhdPwEPJQOw%3D&reserved=0
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EXT] Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Laurentiu Palcu]

Lucas and Daniel,

On Tue, May 28, 2019 at 10:36:43AM +0200, Daniel Vetter wrote:
> Caution: EXT Email
> 
> On Tue, May 28, 2019 at 10:20 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >
> > Hi Shawn,
> >
> > Am Dienstag, den 28.05.2019, 09:38 +0800 schrieb Shawn Guo:
> > > Hi Lucas,
> > >
> > > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > > We have been looking at how to support DCSS in mainline for a while,
> > > > but most of the actual work got pushed behind in schedule due to other
> > > > priorities.
> > >
> > > I have some time to contribute.  Would you suggest how I should help
> > > here?
> > >
> > > 1. You guys already have something close to completion and do not need
> > >    more hands.
> > > 2. You guys already have some preliminary code and can use help from
> > >    others.
> > > 3. You guys haven't got anything to start with, but just some design
> > >    principles that anyone who wants to work on it should consider.
> > >
> > > Which is the one that you want me to read?
> >
> > Mostly the 3rd. We spent some time on getting the DCSS driver to work
> > on upstream kernel and familiarize with the hardware, but we don't have
> > any close to mainline quality code.
> >
> > > > One thing I can can say for certain is that DCSS should not be
> > > > integrated into imx-drm. It's a totally different hardware and
> > > > downstream clearly shows that it's not a good idea to cram it into imx-
> > > > drm.
> > >
> > > I haven't gone deeper into the vendor code, but from a brief looking I
> > > didn't see so many problems with integrating DCSS into imx-drm.  It's
> > > not so unreasonable to take imx-drm as an imx-display-subsystem which
> > > can have multiple CRTCs.  So can you please elaborate a bit on why it's
> > > really a bad idea?
> >
> > It's a totally different hardware, with very different behavior, so
> > there is basically no potential for any code sharing. The downstream
> > driver is a hell of "oh, things are different here, let's introduce yet
> > another function pointer to make the distinction between the HW". It
> > complicates the imx-drm for no good reason. Our experience with imx-drm
> > is that it is already at a complexity level that makes it hard to
> > reason about things when hunting bugs.
> >
> > The boiler plate required to write a atomic KMS driver is not that
> > much, so I would rather have a clean split between the two hardware
> > drivers. Frankly they don't share anything except both being a atomic
> > KMS driver and running on a SoC called i.MX.
> 
> We've also made lots of improvements in the helpers, I think a clean
> driver will be quiet a bit smaller than an imx based one. ARM is doing
> the same with komeda and the malidp driver btw. Another option would
> be 2 kms drivers in one .ko, which is what nouveau does with pre-nv50
> and post-nv50. But that only makes sense if you have also the render
> side in the same driver because it's all from the same vendor. msm is
> similar, with msm4 vs msm5.
> 
> But for soc display-only I think two separate drivers, if the hw
> really changed enough, is the best option. You can still stuff them
> into the same subdir ofc.

Sounds good to me. I'll rewrite the DCSS driver and make it separate
from imx-drm. Though, to be honest, this defeats the whole purpose of
imx-drm in the first place... Wasn't this supposed to act like a glue
and gather all i.MX related display controllers under the imx-drm
umbrella?

But, on the other hand, I agree it would be best, going forward, to have
it separate. Easier to maintain and, most likely, simpler.

thanks,
laurentiu

> 
> Cheers, Daniel
> 
> > > > Also the artificial split between hardware control in
> > > > drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> > > > IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> > > > DRM for the output parts and V4L2 for the input parts. As the DCSS has
> > > > no video input capabilities the driver could be simplified a lot by
> > > > moving it all into a single DRM driver.
> > >
> > > Agreed on this.
> >
> > Regards,
> > Lucas
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=02%7C01%7Claurentiu.palcu%40nxp.com%7C8dca19419c7e49bd10f608d6e347a6e9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946294240955699&amp;sdata=jaSgJsk2LinqaCbUxe6aIvkM6oasWFgezfTZMEMo5Uo%3D&amp;reserved=0
> 
> 
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch&amp;data=02%7C01%7Claurentiu.palcu%40nxp.com%7C8dca19419c7e49bd10f608d6e347a6e9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946294240965691&amp;sdata=ObCThdTNsTYvJ75nnLQe4G7HToiIFseQgJoaeljZn6M%3D&amp;reserved=0
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=02%7C01%7Claurentiu.palcu%40nxp.com%7C8dca19419c7e49bd10f608d6e347a6e9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946294240965691&amp;sdata=n9a86mh1apiyDgv3rSJ7G3fz1k22x%2B%2Bu31uxZAI9N0Q%3D&amp;reserved=0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EXT] Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Laurentiu Palcu]

Hi Guido,

On Tue, May 28, 2019 at 11:33:00AM +0200, Guido Günther wrote:
> Caution: EXT Email
> 
> Hi Laurentiu,
> On Tue, May 28, 2019 at 07:03:54AM +0000, Laurentiu Palcu wrote:
> > Hi Shawn, Lucas,
> >
> > On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> > > Caution: EXT Email
> > >
> > > Hi Lucas,
> > >
> > > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > > We have been looking at how to support DCSS in mainline for a while,
> > > > but most of the actual work got pushed behind in schedule due to other
> > > > priorities.
> > >
> > > I have some time to contribute.  Would you suggest how I should help
> > > here?
> > >
> > > 1. You guys already have something close to completion and do not need
> > >    more hands.
> > > 2. You guys already have some preliminary code and can use help from
> > >    others.
> > > 3. You guys haven't got anything to start with, but just some design
> > >    principles that anyone who wants to work on it should consider.
> > >
> > > Which is the one that you want me to read?
> >
> > We're already working on clearing up the DCSS code and preparing it for
> > upstreaming. It should be done in the following weeks. The reason we've
> > been delaying this is because neither HDMI nor MIPI support was present
> > and, until these are upstream, testing DCSS would be quite impossible.
> 
> MIPI support is here:
> 
>   mixel:  https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F58817%2F&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839828366&sdata=VZvvhe2WkMVCSOEw5oZDJfy7rsqF7YaEirrkLFC8Icw%3D&reserved=0
>   nwl:  https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F57686%2F&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839838359&sdata=Q4s6OZq1KElktjSXRd2lKBMdg1yPJsWGm8UrSPqqTiE%3D&reserved=0
> 
> The NWL driver needs to be adjusted depending on whether we hook into
> imx-display-subsystem or not (and then likely moved to the right
> subdir). Can we somehow get this moving in sync (even in a non public
> tree if necessary).

I guess we could do that as well. I'll start adjusting the driver and
take it out of imx-drm, as suggested by Lucas and Daniel. I'll use your
MIPI patches to test with.

thanks,
laurentiu

> Cheers,
>  -- Guido
> 
> 
> > > > One thing I can can say for certain is that DCSS should not be
> > > > integrated into imx-drm. It's a totally different hardware and
> > > > downstream clearly shows that it's not a good idea to cram it into imx-
> > > > drm.
> > >
> > > I haven't gone deeper into the vendor code, but from a brief looking I
> > > didn't see so many problems with integrating DCSS into imx-drm.  It's
> > > not so unreasonable to take imx-drm as an imx-display-subsystem which
> > > can have multiple CRTCs.  So can you please elaborate a bit on why it's
> > > really a bad idea?
> >
> > I'd be interested to hear about this as well.
> >
> > >
> > > > Also the artificial split between hardware control in
> > > > drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> > > > IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> > > > DRM for the output parts and V4L2 for the input parts. As the DCSS has
> > > > no video input capabilities the driver could be simplified a lot by
> > > > moving it all into a single DRM driver.
> > >
> > > Agreed on this.
> >
> > I also agree on this. DCSS core code will probably be moved inside the
> > same directory: drivers/gpu/drm/imx/dcss.
> >
> > Thanks,
> > laurentiu
> >
> > >
> > > Shawn
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839838359&sdata=6I8MCXrt3y4nX20SnpfoSwEZkg%2B1zP3AFLGHUNaI%2Fls%3D&reserved=0
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839838359&sdata=6I8MCXrt3y4nX20SnpfoSwEZkg%2B1zP3AFLGHUNaI%2Fls%3D&reserved=0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EXT] Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Lucas Stach]

Hi Laurentiu,

Am Dienstag, den 28.05.2019, 10:04 +0000 schrieb Laurentiu Palcu:
> Lucas and Daniel,

[...]

> > > It's a totally different hardware, with very different behavior, so
> > > there is basically no potential for any code sharing. The downstream
> > > driver is a hell of "oh, things are different here, let's introduce yet
> > > another function pointer to make the distinction between the HW". It
> > > complicates the imx-drm for no good reason. Our experience with imx-drm
> > > is that it is already at a complexity level that makes it hard to
> > > reason about things when hunting bugs.
> > > 
> > > The boiler plate required to write a atomic KMS driver is not that
> > > much, so I would rather have a clean split between the two hardware
> > > drivers. Frankly they don't share anything except both being a atomic
> > > KMS driver and running on a SoC called i.MX.
> > 
> > We've also made lots of improvements in the helpers, I think a clean
> > driver will be quiet a bit smaller than an imx based one. ARM is doing
> > the same with komeda and the malidp driver btw. Another option would
> > be 2 kms drivers in one .ko, which is what nouveau does with pre-nv50
> > and post-nv50. But that only makes sense if you have also the render
> > side in the same driver because it's all from the same vendor. msm is
> > similar, with msm4 vs msm5.
> > 
> > But for soc display-only I think two separate drivers, if the hw
> > really changed enough, is the best option. You can still stuff them
> > into the same subdir ofc.
> 
> Sounds good to me. I'll rewrite the DCSS driver and make it separate
> from imx-drm. Though, to be honest, this defeats the whole purpose of
> imx-drm in the first place... Wasn't this supposed to act like a glue
> and gather all i.MX related display controllers under the imx-drm
> umbrella?

Not really. We never had a plan to support all kinds of i.MX display
hardware in a single driver.

At some point imx-drm acted as the glue to bring all the components of
the i.MX display pipeline together, but much of that functionality has
since been split out and is now available as infrastructure in the
kernel, like the DRM bridges, devicetree graph bindings and device
links. All those infrastructure parts make it easy to write a separate
DRM driver, without duplicating lots of code from imx-drm.

It made sense to extend imx-drm as long as the hardware was close
and/or an extension to already existing hardware. But DCSS is totally
different from the currently supported IPU design.

> But, on the other hand, I agree it would be best, going forward, to have
> it separate. Easier to maintain and, most likely, simpler.

Seems we agree on the direction this should take. :)

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

Re: [EXT] Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Guido Günther]

Hi,
On Tue, May 28, 2019 at 10:10:11AM +0000, Laurentiu Palcu wrote:
> Hi Guido,
> 
> On Tue, May 28, 2019 at 11:33:00AM +0200, Guido Günther wrote:
> > Caution: EXT Email
> > 
> > Hi Laurentiu,
> > On Tue, May 28, 2019 at 07:03:54AM +0000, Laurentiu Palcu wrote:
> > > Hi Shawn, Lucas,
> > >
> > > On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> > > > Caution: EXT Email
> > > >
> > > > Hi Lucas,
> > > >
> > > > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > > > We have been looking at how to support DCSS in mainline for a while,
> > > > > but most of the actual work got pushed behind in schedule due to other
> > > > > priorities.
> > > >
> > > > I have some time to contribute.  Would you suggest how I should help
> > > > here?
> > > >
> > > > 1. You guys already have something close to completion and do not need
> > > >    more hands.
> > > > 2. You guys already have some preliminary code and can use help from
> > > >    others.
> > > > 3. You guys haven't got anything to start with, but just some design
> > > >    principles that anyone who wants to work on it should consider.
> > > >
> > > > Which is the one that you want me to read?
> > >
> > > We're already working on clearing up the DCSS code and preparing it for
> > > upstreaming. It should be done in the following weeks. The reason we've
> > > been delaying this is because neither HDMI nor MIPI support was present
> > > and, until these are upstream, testing DCSS would be quite impossible.
> > 
> > MIPI support is here:
> > 
> >   mixel:  https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F58817%2F&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839828366&sdata=VZvvhe2WkMVCSOEw5oZDJfy7rsqF7YaEirrkLFC8Icw%3D&reserved=0
> >   nwl:  https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F57686%2F&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839838359&sdata=Q4s6OZq1KElktjSXRd2lKBMdg1yPJsWGm8UrSPqqTiE%3D&reserved=0
> > 
> > The NWL driver needs to be adjusted depending on whether we hook into
> > imx-display-subsystem or not (and then likely moved to the right
> > subdir). Can we somehow get this moving in sync (even in a non public
> > tree if necessary).
> 
> I guess we could do that as well. I'll start adjusting the driver and
> take it out of imx-drm, as suggested by Lucas and Daniel. I'll use your
> MIPI patches to test with.

Cool. this will likely mean turning the NWL part into a bridge which I
can look into. We want that when interfacing with mxsfb anyway.
Cheers,
 -- Guido
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EXT] Re: [PATCH 0/2] drm: imx: Add NWL MIPI DSI host controller support

[Guido Günther]

Hi Laurentiu,
On Tue, May 28, 2019 at 10:10:11AM +0000, Laurentiu Palcu wrote:
> Hi Guido,
> 
> On Tue, May 28, 2019 at 11:33:00AM +0200, Guido Günther wrote:
> > Caution: EXT Email
> > 
> > Hi Laurentiu,
> > On Tue, May 28, 2019 at 07:03:54AM +0000, Laurentiu Palcu wrote:
> > > Hi Shawn, Lucas,
> > >
> > > On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> > > > Caution: EXT Email
> > > >
> > > > Hi Lucas,
> > > >
> > > > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > > > We have been looking at how to support DCSS in mainline for a while,
> > > > > but most of the actual work got pushed behind in schedule due to other
> > > > > priorities.
> > > >
> > > > I have some time to contribute.  Would you suggest how I should help
> > > > here?
> > > >
> > > > 1. You guys already have something close to completion and do not need
> > > >    more hands.
> > > > 2. You guys already have some preliminary code and can use help from
> > > >    others.
> > > > 3. You guys haven't got anything to start with, but just some design
> > > >    principles that anyone who wants to work on it should consider.
> > > >
> > > > Which is the one that you want me to read?
> > >
> > > We're already working on clearing up the DCSS code and preparing it for
> > > upstreaming. It should be done in the following weeks. The reason we've
> > > been delaying this is because neither HDMI nor MIPI support was present
> > > and, until these are upstream, testing DCSS would be quite impossible.
> > 
> > MIPI support is here:
> > 
> >   mixel:  https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F58817%2F&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839828366&sdata=VZvvhe2WkMVCSOEw5oZDJfy7rsqF7YaEirrkLFC8Icw%3D&reserved=0
> >   nwl:  https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F57686%2F&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839838359&sdata=Q4s6OZq1KElktjSXRd2lKBMdg1yPJsWGm8UrSPqqTiE%3D&reserved=0
> > 
> > The NWL driver needs to be adjusted depending on whether we hook into
> > imx-display-subsystem or not (and then likely moved to the right
> > subdir). Can we somehow get this moving in sync (even in a non public
> > tree if necessary).
> 
> I guess we could do that as well. I'll start adjusting the driver and
> take it out of imx-drm, as suggested by Lucas and Daniel. I'll use your
> MIPI patches to test with.

Is there anything I could test against v1 of the imx-nwl driver to make
sure that works as well:

    https://patchwork.freedesktop.org/series/64185/

Is your focus more towards DSI or HDMI / DP for inital submission?

Cheers,
 -- Guido

> 
> thanks,
> laurentiu
> 
> > Cheers,
> >  -- Guido
> > 
> > 
> > > > > One thing I can can say for certain is that DCSS should not be
> > > > > integrated into imx-drm. It's a totally different hardware and
> > > > > downstream clearly shows that it's not a good idea to cram it into imx-
> > > > > drm.
> > > >
> > > > I haven't gone deeper into the vendor code, but from a brief looking I
> > > > didn't see so many problems with integrating DCSS into imx-drm.  It's
> > > > not so unreasonable to take imx-drm as an imx-display-subsystem which
> > > > can have multiple CRTCs.  So can you please elaborate a bit on why it's
> > > > really a bad idea?
> > >
> > > I'd be interested to hear about this as well.
> > >
> > > >
> > > > > Also the artificial split between hardware control in
> > > > > drivers/gpu/imx/dcss and the DRM driver is just cargo-cult from the
> > > > > IPU/imx-drm split. For the IPU we did it as the IPU has legs in both
> > > > > DRM for the output parts and V4L2 for the input parts. As the DCSS has
> > > > > no video input capabilities the driver could be simplified a lot by
> > > > > moving it all into a single DRM driver.
> > > >
> > > > Agreed on this.
> > >
> > > I also agree on this. DCSS core code will probably be moved inside the
> > > same directory: drivers/gpu/drm/imx/dcss.
> > >
> > > Thanks,
> > > laurentiu
> > >
> > > >
> > > > Shawn
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839838359&sdata=6I8MCXrt3y4nX20SnpfoSwEZkg%2B1zP3AFLGHUNaI%2Fls%3D&reserved=0
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Claurentiu.palcu%40nxp.com%7C9924c4628d5f4f98d8a808d6e34f7b26%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636946327839838359&sdata=6I8MCXrt3y4nX20SnpfoSwEZkg%2B1zP3AFLGHUNaI%2Fls%3D&reserved=0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel