Skip to contentSkip to conversation

drm/bridge: Add mux input selection bridge

RFC PATCH In review Guido Günther 3 participants 13 messages May 15, 2020 – May 30, 2020

Subsystems (5)
lore
Share & tools
lore
#0 lore raw

cover drm/bridge: Add mux input selection bridge

This bridge driver allows to select the input to a downstream bridge (or panel) via device tree.

It can be useful to separate the pixel source selection from the actual bridge processing the pixel data. E.g. NXP's imx8mq has two display controllers. Both can feed the pixel data to the NWL DSI IP core. The input selection is done via a separate mux register elsewhere on the chip, so separating this out avoids SoC specific code in such drivers.

The current implementation allows to select the input source via device tree. The long term goal is to allow to switch the input source at run time. This can be useful to e.g. use the less power hungry display controller for normal operation but switch to a the other display controller when running full screen games (since it can detile textures more efficiently).

This was initially suggested by Laurent Pinchart¹. It is similar in spirit to the video-mux in the media subsystem but for DRM bridges.

Besides the actual driver this series includes the necessary bits to demo the usage for the Librem5 devkit.

The series is based on linux-next as of next-20200512.

¹ https://lore.kernel.org/dri-devel/[email protected]/

Guido Günther (6):
dt-bindings: display/bridge: Add binding for input mux bridge drm/bridge: Add mux-input bridge
dt-bindings: display/bridge/nwl-dsi: Drop mux handling drm/bridge/nwl-dsi: Drop mux handling
arm64: dts: imx8mq: Add NWL dsi controller
arm64: dts: imx8mq-librem5-devkit: Enable MIPI DSI panel

 .../display/bridge/mux-input-bridge.yaml      | 123 +++++++++
 .../bindings/display/bridge/nwl-dsi.yaml      |   6 -
 .../dts/freescale/imx8mq-librem5-devkit.dts   |  81 ++++++
 arch/arm64/boot/dts/freescale/imx8mq.dtsi     |  31 +++
 drivers/gpu/drm/bridge/Kconfig                |  10 +-
 drivers/gpu/drm/bridge/Makefile               |   1 +
 drivers/gpu/drm/bridge/mux-input.c            | 238 ++++++++++++++++++
 drivers/gpu/drm/bridge/nwl-dsi.c              |  61 -----
 8 files changed, 483 insertions(+), 68 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
 create mode 100644 drivers/gpu/drm/bridge/mux-input.c
Signature · 6 lines
2.26.1

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
#1 lore raw

RFC PATCH 1/6 dt-bindings: display/bridge: Add binding for input mux bridge

The bridge allows to select the input source via a mux controller.

---
 .../display/bridge/mux-input-bridge.yaml      | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml new file +123 -0
new file mode 100644
index 000000000000..4029cf63ee5c
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DRM input source selection via multiplexer
+
+maintainers:
+  - Guido Gúnther <[email protected]>
+
+description: |
+  The input multiplexer bridge allows to select an input source
+  via an associated mux controller.
+
+properties:
+  compatible:
+    const: mux-input-bridge
+
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 0
+
+  default-input:
+    description: The default input to use
+
+  mux-controls:
+    description:
+      mux controller node to use for operating the input mux
+
+  ports:
+    type: object
+    properties:
+      '#address-cells':
+        const: 1
+      '#size-cells':
+        const: 0
+
+    patternProperties:
+      "^port@[0-9]+":
+        type: object
+        description:
+          At least three nodes containing endpoints connecting to the
+          pixel data inputs and outputs. The last port is always the
+          output port.
+
+        properties:
+          reg:
+            maxItems: 1
+
+          endpoint:
+            description: sub-node describing the input
+            type: object
+
+        required:
+          - reg
+
+        additionalProperties: false
+
+    required:
+      - port@0
+      - port@1
+      - port@2
+
+    additionalProperties: false
+
+required:
+  - '#address-cells'
+  - '#size-cells'
+  - mux-controls
+  - ports
+
+additionalProperties: false
+
+examples:
+ - |
+   #include <dt-bindings/gpio/gpio.h>
+
+   mux: mux-controller {
+           compatible = "gpio-mux";
+           #mux-control-cells = <0>;
+
+           mux-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+   };
+
+   mipi-mux {
+           compatible = "mux-input-bridge";
+           default-input = <0>;
+           mux-controls = <&mux 0>;
+           #address-cells = <1>;
+           #size-cells = <0>;
+
+           ports {
+                   #address-cells = <1>;
+                   #size-cells = <0>;
+
+                   port@0 {
+                           reg = <0>;
+
+                           dpi_mux_from_lcdif: endpoint {
+                                   remote-endpoint = <&lcdif_dpi_out>;
+                           };
+                   };
+
+                   port@1 {
+                           reg = <1>;
+
+                           dpi_mux_from_dccss: endpoint {
+                                   remote-endpoint = <&dcss_dpi_out>;
+                           };
+                   };
+
+                   port@2 {
+                           reg = <2>;
+
+                           dpi_mux_out: endpoint {
+                                   remote-endpoint = <&nwl_dpi_in>;
+                           };
+                   };
+           };
+   };
Signature · 1 line
2.26.1
maintainer
#2 lore raw

Re: [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge

Quoted 14 lines · Guido Günther

The bridge allows to select the input source via a mux controller.

---
 .../display/bridge/mux-input-bridge.yaml      | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml new file +0 -0
new file mode 100644
index 000000000000..4029cf63ee5c

Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml line 7

Quoted 7 lines
Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml new file +7 -0
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DRM input source selection via multiplexer

DRM is not a hardware thing.

The graph binding is already designed to support muxing. Generally, multiple endpoints on an input node is a mux. So either the device with the input ports knows how to select the input, or you just need a mux-control property for the port to have some other device implement the control.

You could do it like you have below. That would be appropriate if there's a separate h/w device controlling the muxing. Say for example some board level device controlled by i2c.

Rob
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#3 lore raw

Re: [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge

Hi Rob,

Quoted 25 lines · Rob Herring
Quoted 14 lines · Guido Günther

The bridge allows to select the input source via a mux controller.

---
 .../display/bridge/mux-input-bridge.yaml      | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml new file +0 -0
new file mode 100644
index 000000000000..4029cf63ee5c

Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml line 7

Quoted 7 lines
Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml new file +7 -0
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DRM input source selection via multiplexer

DRM is not a hardware thing.

Quoted 5 lines

The graph binding is already designed to support muxing. Generally, multiple endpoints on an input node is a mux. So either the device with the input ports knows how to select the input, or you just need a mux-control property for the port to have some other device implement the control.

The mux modelled by this binding is used by Guido with the NWL DSI bridge integrated in the i.MX8. The NWL DSI is an IP core that has a single input. The i.MX8 has an additional mux in front of the NWL DSI, to select between the two display controllers in the SoC (eLCDIF and DCSS). The mux doesn't belong to any of the display controller, it's really glue logic between the display controllers and the NWL DSI bridge.

I agree that the bindings shouldn't mention DRM. I would however prefer not adding a mux-control property and multiple input ports to the NWL DSI binding, as the mux isn't internal to that IP core (if we go that route, we would need to add mux control to any IP core that would be integrated in an SoC with a mux in front). As DT should describe the hardware, I think describing the standalone mux between the display controllers and the NWL DSI bridge makex sense.

We already have a DT binding for a video mux (Documentation/devicetree/bindings/media/video-mux.txt). From a DT point of view, I see no reason not to reuse that. From a driver point of view that will be messy, as the driver that binds to the video-mux compatible string is part of V4L2. That's a driver issue however (and not a new one, we already have devices that can be part of a video capture pipeline or a video display pipeline), and should be solved on the software side, not the DT side. It will however not be easy work, which explains why, so far, everybody has ignored the issue hoping that someone else would be hit by it first. We may have reached that day.

Quoted 3 lines

You could do it like you have below. That would be appropriate if there's a separate h/w device controlling the muxing. Say for example some board level device controlled by i2c.

Signature · 7 lines
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
#4 lore raw

Re: [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge

In reply to Rob Herring

Hi Rob,

Quoted 9 lines · Rob Herring
Quoted 8 lines · Guido Günther

The bridge allows to select the input source via a mux controller.

---
 .../display/bridge/mux-input-bridge.yaml      | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
Quoted 15 lines

Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml line 7

Quoted 13 lines
Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml new file +7 -0
new file mode 100644
index 000000000000..4029cf63ee5c
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DRM input source selection via multiplexer

DRM is not a hardware thing.

I thought about naming the mux pixel-input-mux (input-mux sounding too generic) but then i hit rockchip-drm and went for that name. The binding itself is not a drm thing in itself it really aims to model how the mux is placed in the 'display pipeline' of the SoC (as Laurent explained). Should I go with pixel-input-mux?

Quoted 5 lines

The graph binding is already designed to support muxing. Generally, multiple endpoints on an input node is a mux. So either the device with the input ports knows how to select the input, or you just need a mux-control property for the port to have some other device implement the control.

A mux control property is how it's modeled at the moment but that is very SoC specific.

Quoted 3 lines

You could do it like you have below. That would be appropriate if there's a separate h/w device controlling the muxing. Say for example some board level device controlled by i2c.

It's a different part of the SoC that lives in a register range very separate (iomuxc_gpr) from MIPI/DSI (nwl). Does that qualify?

Cheers,
-- Guido

Quoted 3 lines

Rob

#5 lore raw

RFC PATCH 2/6 drm/bridge: Add mux-input bridge

In reply to Guido Günther

This bridge allows to select the input source
via a mux controller. The input source is
determined via DT but it could become rutime
selectable in the future.

---
 drivers/gpu/drm/bridge/Kconfig     |   9 ++
 drivers/gpu/drm/bridge/Makefile    |   1 +
 drivers/gpu/drm/bridge/mux-input.c | 238 +++++++++++++++++++++++++++++
 3 files changed, 248 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/mux-input.c
drivers/gpu/drm/bridge/Kconfig +9 -0
index 04f876e985de..3886c0f41bdd 100644
@@ -206,6 +206,15 @@ config DRM_TI_TPD12S015
 	  Texas Instruments TPD12S015 HDMI level shifter and ESD protection
 	  driver.
 
+config DRM_MUX_INPUT
+	tristate "Bridge to select a video input source"
+	depends on OF
+	depends on DRM_BRIDGE
+	select MULTIPLEXER
+	help
+	  Select this option if you want to select the input source to
+	  a DRM bridge or panel via a separate mux chip.
+
 source "drivers/gpu/drm/bridge/analogix/Kconfig"
 
 source "drivers/gpu/drm/bridge/adv7511/Kconfig"
drivers/gpu/drm/bridge/Makefile +1 -0
index d63d4b7e4347..9f3370ce7e07 100644
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
 obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
 obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o
+obj-$(CONFIG_DRM_MUX_INPUT) += mux-input.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
drivers/gpu/drm/bridge/mux-input.c new file +238 -0

238 lines not on this page · raw message

Signature · 1 line
2.26.1
#6 lore raw

RFC PATCH 3/6 dt-bindings: display/bridge/nwl-dsi: Drop mux handling

In reply to Guido Günther

No need to encode the SoC specifics in the bridge driver. For the imx8mq we can use the mux-input-bridge.

---
 .../devicetree/bindings/display/bridge/nwl-dsi.yaml         | 6 ------
 1 file changed, 6 deletions(-)
Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml +0 -6
index 8aff2d68fc33..d2c2d4e19a25 100644
@@ -46,10 +46,6 @@ properties:
       - const: phy_ref
       - const: lcdif
 
-  mux-controls:
-    description:
-      mux controller node to use for operating the input mux
-
   phys:
     maxItems: 1
     description:
@@ -151,7 +147,6 @@ required:
   - clocks
   - compatible
   - interrupts
-  - mux-controls
   - phy-names
   - phys
   - ports
@@ -180,7 +175,6 @@ examples:
                        <&clk IMX8MQ_CLK_LCDIF_PIXEL>;
               clock-names = "core", "rx_esc", "tx_esc", "phy_ref", "lcdif";
               interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
-              mux-controls = <&mux 0>;
               power-domains = <&pgc_mipi>;
               resets = <&src IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N>,
                        <&src IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N>,
Signature · 6 lines
2.26.1

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
maintainer
#7 lore raw

Re: [RFC PATCH 3/6] dt-bindings: display/bridge/nwl-dsi: Drop mux handling

Quoted 2 lines · Guido Günther

No need to encode the SoC specifics in the bridge driver. For the imx8mq we can use the mux-input-bridge.

You can't just change bindings like this. You'd still have to support the "old" way. But IMO, this way is the right way.

Quoted 5 lines
---
 .../devicetree/bindings/display/bridge/nwl-dsi.yaml         | 6 ------
 1 file changed, 6 deletions(-)

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#8 lore raw

Re: [RFC PATCH 3/6] dt-bindings: display/bridge/nwl-dsi: Drop mux handling

Hi Rob,

Quoted 6 lines · Rob Herring
Quoted 2 lines · Guido Günther

No need to encode the SoC specifics in the bridge driver. For the imx8mq we can use the mux-input-bridge.

You can't just change bindings like this. You'd still have to support the "old" way. But IMO, this way is the right way.

My understanding is that binding stability only applies to released kernels and this binding never was in released kernel yet. Does it still apply in this case?
Cheers,
-- Guido

Quoted 7 lines
Quoted 6 lines
---
 .../devicetree/bindings/display/bridge/nwl-dsi.yaml         | 6 ------
 1 file changed, 6 deletions(-)

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#9 lore raw

RFC PATCH 4/6 drm/bridge/nwl-dsi: Drop mux handling

In reply to Guido Günther

This will be handled via the mux-input-bridge.

---
 drivers/gpu/drm/bridge/Kconfig   |  1 -
 drivers/gpu/drm/bridge/nwl-dsi.c | 61 --------------------------------
 2 files changed, 62 deletions(-)
drivers/gpu/drm/bridge/Kconfig +0 -1
index 3886c0f41bdd..11444f841e35 100644
@@ -78,7 +78,6 @@ config DRM_NWL_MIPI_DSI
 	select DRM_PANEL_BRIDGE
 	select GENERIC_PHY_MIPI_DPHY
 	select MFD_SYSCON
-	select MULTIPLEXER
 	select REGMAP_MMIO
 	help
 	  This enables the Northwest Logic MIPI DSI Host controller as
drivers/gpu/drm/bridge/nwl-dsi.c +0 -61

103 lines not on this page · raw message

Signature · 6 lines
2.26.1

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
maintainer
#10 lore raw

Re: [RFC PATCH 4/6] drm/bridge/nwl-dsi: Drop mux handling

Quoted 1 line · Guido Günther

This will be handled via the mux-input-bridge.

You can't do this. What happens booting a kernel with this change and an un-modified dtb? You just broke it.

Quoted 87 lines
---
 drivers/gpu/drm/bridge/Kconfig   |  1 -
 drivers/gpu/drm/bridge/nwl-dsi.c | 61 --------------------------------
 2 files changed, 62 deletions(-)
drivers/gpu/drm/bridge/Kconfig +0 -1
index 3886c0f41bdd..11444f841e35 100644
@@ -78,7 +78,6 @@ config DRM_NWL_MIPI_DSI
 	select DRM_PANEL_BRIDGE
 	select GENERIC_PHY_MIPI_DPHY
 	select MFD_SYSCON
-	select MULTIPLEXER
 	select REGMAP_MMIO
 	help
 	  This enables the Northwest Logic MIPI DSI Host controller as
drivers/gpu/drm/bridge/nwl-dsi.c +0 -32
index b14d725bf609..8839f333f39c 100644
@@ -12,7 +12,6 @@
 #include <linux/math64.h>
 #include <linux/mfd/syscon.h>
 #include <linux/module.h>
-#include <linux/mux/consumer.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/phy/phy.h>
@@ -44,9 +43,6 @@ enum transfer_direction {
 	DSI_PACKET_RECEIVE,
 };
 
-#define NWL_DSI_ENDPOINT_LCDIF 0
-#define NWL_DSI_ENDPOINT_DCSS 1
-
 struct nwl_dsi_plat_clk_config {
 	const char *id;
 	struct clk *clk;
@@ -94,7 +90,6 @@ struct nwl_dsi {
 	struct reset_control *rst_esc;
 	struct reset_control *rst_dpi;
 	struct reset_control *rst_pclk;
-	struct mux_control *mux;
 
 	/* DSI clocks */
 	struct clk *phy_ref_clk;
@@ -1018,14 +1013,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
 	}
 	dsi->tx_esc_clk = clk;
 
-	dsi->mux = devm_mux_control_get(dsi->dev, NULL);
-	if (IS_ERR(dsi->mux)) {
-		ret = PTR_ERR(dsi->mux);
-		if (ret != -EPROBE_DEFER)
-			DRM_DEV_ERROR(dsi->dev, "Failed to get mux: %d\n", ret);
-		return ret;
-	}
-
 	base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(base))
 		return PTR_ERR(base);
@@ -1073,47 +1060,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
 	return 0;
 }
 
-static int nwl_dsi_select_input(struct nwl_dsi *dsi)
-{
-	struct device_node *remote;
-	u32 use_dcss = 1;
-	int ret;
-
-	remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
-					  NWL_DSI_ENDPOINT_LCDIF);
-	if (remote) {
-		use_dcss = 0;
-	} else {
-		remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
-						  NWL_DSI_ENDPOINT_DCSS);
-		if (!remote) {
-			DRM_DEV_ERROR(dsi->dev,
-				      "No valid input endpoint found\n");
-			return -EINVAL;
-		}
-	}

drivers/gpu/drm/bridge/nwl-dsi.c static int nwl_dsi_parse_dt(struct nwl_dsi *dsi) · line 1104

Quoted 10 lines
drivers/gpu/drm/bridge/nwl-dsi.c +0 -10
-
-	DRM_DEV_INFO(dsi->dev, "Using %s as input source\n",
-		     (use_dcss) ? "DCSS" : "LCDIF");
-	ret = mux_control_try_select(dsi->mux, use_dcss);
-	if (ret < 0)
-		DRM_DEV_ERROR(dsi->dev, "Failed to select input: %d\n", ret);
-
-	of_node_put(remote);
-	return ret;
-}

You could however make these functions generic for any bridge to use. Define a function that checks for mux-control property and if found sets up the mux (IIRC, there's already a concept of a default state). That should be callable from somewhere generic too.

Rob
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#11 lore raw

RFC PATCH 5/6 arm64: dts: imx8mq: Add NWL dsi controller

In reply to Guido Günther

Add a node for the Northwestlogic MIPI DSI IP core, "disabled" by default.

---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 +++++++++++++++++++++++
 1 file changed, 31 insertions(+)
arch/arm64/boot/dts/freescale/imx8mq.dtsi +31 -0
index 0142f06ead12..6bbbf44e6be0 100644
@@ -889,6 +889,37 @@ sec_jr2: jr@3000 {
 				};
 			};
 
+			mipi_dsi: mipi-dsi@30a00000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "fsl,imx8mq-nwl-dsi";
+				reg = <0x30a00000 0x300>;
+				clocks = <&clk IMX8MQ_CLK_DSI_CORE>,
+					 <&clk IMX8MQ_CLK_DSI_AHB>,
+					 <&clk IMX8MQ_CLK_DSI_IPG_DIV>,
+					 <&clk IMX8MQ_CLK_DSI_PHY_REF>,
+					 <&clk IMX8MQ_CLK_LCDIF_PIXEL>;
+				clock-names = "core", "rx_esc", "tx_esc", "phy_ref", "lcdif";
+				assigned-clocks = <&clk IMX8MQ_CLK_DSI_AHB>,
+						  <&clk IMX8MQ_CLK_DSI_CORE>,
+						  <&clk IMX8MQ_CLK_DSI_IPG_DIV>;
+				assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>,
+							 <&clk IMX8MQ_SYS1_PLL_266M>;
+				assigned-clock-rates = <80000000>,
+						       <266000000>,
+						       <20000000>;
+				interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+				resets = <&src IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N>,
+					 <&src IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N>,
+					 <&src IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N>,
+					 <&src IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N>;
+				reset-names = "byte", "dpi", "esc", "pclk";
+				phys = <&dphy>;
+				phy-names = "dphy";
+				power-domains = <&pgc_mipi>;
+				status = "disabled";
+			 };
+
 			dphy: dphy@30a00300 {
 				compatible = "fsl,imx8mq-mipi-dphy";
 				reg = <0x30a00300 0x100>;
Signature · 6 lines
2.26.1

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
#12 lore raw

RFC PATCH 6/6 arm64: dts: imx8mq-librem5-devkit: Enable MIPI DSI panel

In reply to Guido Günther

Enable MIPI LCD panel output by adding nodes for the NWL DSI host controller, the mux-input-bridge, the Rocktech panel and the eLCDIF display controller.

---
 .../dts/freescale/imx8mq-librem5-devkit.dts   | 81 +++++++++++++++++++
 1 file changed, 81 insertions(+)
arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts +81 -0
index 7fc31c71a626..d98f9b8dede8 100644
@@ -841,6 +841,87 @@ MX8MQ_IOMUXC_NAND_DATA03_GPIO3_IO9	0x19 /* WWAN_RESET */
 	};
 };
 
+&lcdif {
+	status = "okay";
+
+	port@0 {
+		lcdif_dpi_out: endpoint {
+			remote-endpoint = <&dpi_mux_from_lcdif>;
+		};
+	};
+};
+
+&iomuxc_gpr {
+	mipi_mux: mipi-mux {
+		compatible = "mux-input-bridge";
+		mux-controls = <&mux 0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+		default-input = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				dpi_mux_from_lcdif: endpoint {
+					remote-endpoint = <&lcdif_dpi_out>;
+				};
+			};
+
+			port@1 { /* dcss */
+				reg = <1>;
+			};
+
+			port@2 {
+				reg = <2>;
+				dpi_mux_out: endpoint {
+					remote-endpoint = <&nwl_dpi_in>;
+				};
+
+			};
+		};
+	};
+};
+
+&mipi_dsi {
+	status = "okay";
+	panel@0 {
+		compatible = "rocktech,jh057n00900";
+		reg = <0>;
+		backlight = <&backlight_dsi>;
+		reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
+		vcc-supply = <&reg_2v8_p>;
+		iovcc-supply = <&reg_1v8_p>;
+		port@0 {
+			panel_in: endpoint {
+				remote-endpoint = <&nwl_dsi_out>;
+			};
+		};
+	};
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			reg = <0>;
+			nwl_dpi_in: endpoint {
+				remote-endpoint = <&dpi_mux_out>;
+			};
+		};
+		port@1 {
+			reg = <1>;
+			nwl_dsi_out: endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+	};
+};
+
 &pgc_gpu {
 	power-supply = <&buck3_reg>;
 };
Signature · 6 lines
2.26.1

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel