[PATCH 1/2] ARM: dts: imx6qdl-sabrelite: add supported LVDS displays

[PATCH 1/2] ARM: dts: imx6qdl-sabrelite: add supported LVDS displays

[Eric Nelson]

Hi Philipp,

Sorry for the delayed response. I missed your reply and Shawn pointed
it out.

On Feb. 20, 2015, 8:53 a.m., Philipp Zabel wrote:
>
> Am Donnerstag, den 19.02.2015, 16:53 -0700 schrieb Eric Nelson:
>
>> The BD-SL-i.MX6 (SABRE Lite board) supports three companion displays:
>> 	Okaya 1024x600
>> 	Hannstar 1024x768
>> 	LG 1280x800
>> 
>> This patch adds timing entries into the LDB device tree and aliasesl
>> for them and HDMI to make it easy for the boot loader to configure them.
>>
>> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
> 
> Could you please have a look at the simple-panel driver and add these
> panels there instead? This allows to handle enable/disable timings,
> backlights and regulators or enable GPIOs properly.
> 
> I have a patch to add drm_panel support to the imx-ldb driver (see
> below). It depends on this of-graph series:
> 
>     https://lkml.org/lkml/2015/1/22/104
> 

The use of simple panel seems to add and remove functionality:
	- adds backlight, regulators and enable GPIOs!
	- loses the ability to express timings in DT

> regards
> Philipp
> 
> -----8<-----
> From: Philipp Zabel <p.zabel@pengutronix.de>
> Date: Thu, 6 Mar 2014 14:54:39 +0100
> Subject: [PATCH] drm/imx: imx-ldb: add drm_panel support
> 
> This patch allows to optionally attach the lvds-channel to a panel
> supported by a drm_panel driver using of-graph bindings, instead of
> supplying the modes via display-timings in the device tree.
> 
> This depends on of_graph_get_port_by_id and uses the OF graph to
> link the optional DRM panel to the LDB lvds-channel. The output
> port number is 2 on devices without the external 4-port input
> multiplexer (i.MX5) and 4 on devices with the mux (i.MX6).
> 
> Before:
> 
> 	ldb {
> 		...
> 
> 		lvds-channel at 0 {
> 			...
> 
> 			display-timings {
> 				native-timing = <&timing1>;
> 				timing1: etm0700g0dh6 {
> 					hactive = <800>;
> 					vactive = <480>;
> 					clock-frequency = <33260000>;
> 					hsync-len = <128>;
> 					hback-porch = <88>;
> 					hfront-porch = <40>;
> 					vsync-len = <2>;
> 					vback-porch = <33>;
> 					vfront-porch = <10>;
> 					hsync-active = <0>;
> 					vsync-active = <0>;
> 					...
> 				};
> 			};
> 			...
> 		};
> 	};
> 
> After:
> 	ldb {
> 		...
> 
> 		lvds-channel at 0 {
> 			...
> 

Using port here to point at the panel seems to conflict
with the use of ports to point at the IPU.

> 			port at 4 {
> 				reg = <4>;
> 
> 				lvds_out: endpoint {
> 					remote_endpoint = <&panel_in>;
> 				};
> 			};
> 		};
> 	};
> 
> 	panel {
> 		compatible = "edt,etm0700g0dh6", "simple-panel";
> 		...
> 

And why would the panel need to point back to the LVDS
channel?

> 		port {
> 			panel_in: endpoint {
> 				remote-endpoint = <&lvds_out>;
> 			};
> 		};
> 	}; 
> 

Do you have a working example of how this should be used?

My attempts to follow the notes above results in a failure
to find a crtc for the LVDS channel.

Please advise,


Eric Nelson

[PATCH 1/2] ARM: dts: imx6qdl-sabrelite: add supported LVDS displays

[Philipp Zabel]

Hi Eric,

Am Sonntag, den 05.04.2015, 18:25 -0700 schrieb Eric Nelson:
> Hi Philipp,
> 
> Sorry for the delayed response. I missed your reply and Shawn pointed
> it out.
[...]
> The use of simple panel seems to add and remove functionality:
> 	- adds backlight, regulators and enable GPIOs!
> 	- loses the ability to express timings in DT

For the simple panel driver Thierry preferred to have a panel database
in the driver and uniquely identify the panel by its compatible value.
This will also allow to infer the data mapping and width from
the panel, and the panel timings are available for the next hardware to
reuse the same panel (however likely that is).

The old method with display-timings will stay available, but for
mainline I think it is better to add the panel to the driver.

> > After:
> > 	ldb {
> > 		...
> > 
> > 		lvds-channel at 0 {
> > 			...
> > 
> 
> Using port here to point at the panel seems to conflict
> with the use of ports to point at the IPU.

I'm sorry, I don't understand what you mean exactly. There are some
input ports (two on i.MX5, four on i.MX6) that are connected to the IPU,
and one output port that is connected to the panel, in that order by
convention. The port id 4 (reg = <4>) uniquely identifies the output
port on i.MX6.

> > 			port at 4 {
> > 				reg = <4>;
> > 
> > 				lvds_out: endpoint {
> > 					remote_endpoint = <&panel_in>;
> > 				};
> > 			};
> > 		};
> > 	};
> > 
> > 	panel {
> > 		compatible = "edt,etm0700g0dh6", "simple-panel";
> > 		...
> > 
> 
> And why would the panel need to point back to the LVDS
> channel?

This is the way the bindings are defined right now in
Documentation/devicetree/bindings/graph.txt, section "Links between
endpoints". The panel driver itself doesn't use the backlink, but the
endpoint needs to exist anyway.

> > 		port {
> > 			panel_in: endpoint {
> > 				remote-endpoint = <&lvds_out>;
> > 			};
> > 		};
> > 	}; 
> > 
> 
> Do you have a working example of how this should be used?
> 
> My attempts to follow the notes above results in a failure
> to find a crtc for the LVDS channel.
> 
> Please advise,

I have used this patch to connect a HannStar HSD070PWW1 LVDS panel to a
Nitrogen6X board:

-----8<-----
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index 0821812..9e52adf 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -122,7 +122,7 @@
 		status = "okay";
 	};
 
-	backlight_lvds {
+	backlight_lvds: backlight_lvds {
 		compatible = "pwm-backlight";
 		pwms = <&pwm4 0 5000000>;
 		brightness-levels = <0 4 8 16 32 64 128 255>;
@@ -130,6 +130,17 @@
 		power-supply = <&reg_3p3v>;
 		status = "okay";
 	};
+
+	panel {
+		compatible = "hannstar,hsd070pww1";
+		backlight = <&backlight_lvds>;
+
+		port {
+			panel_in: endpoint {
+				remote-endpoint = <&lvds0_out>;
+			};
+		};
+	};
 };
 
 &audmux {
@@ -379,18 +390,11 @@
 		fsl,data-width = <18>;
 		status = "okay";
 
-		display-timings {
-			native-mode = <&timing0>;
-			timing0: hsd100pxn1 {
-				clock-frequency = <65000000>;
-				hactive = <1024>;
-				vactive = <768>;
-				hback-porch = <220>;
-				hfront-porch = <40>;
-				vback-porch = <21>;
-				vfront-porch = <7>;
-				hsync-len = <60>;
-				vsync-len = <10>;
+		port at 4 {
+			reg = <4>;
+
+			lvds0_out: endpoint {
+				remote-endpoint = <&panel_in>;
 			};
 		};
 	};
----->8-----

regards
Philipp

[PATCH 1/2] ARM: dts: imx6qdl-sabrelite: add supported LVDS displays

[Eric Nelson]

Thanks Philipp,

On 04/13/2015 03:22 AM, Philipp Zabel wrote:
> Hi Eric,
> 
> Am Sonntag, den 05.04.2015, 18:25 -0700 schrieb Eric Nelson:
>> Hi Philipp,
>>
>> Sorry for the delayed response. I missed your reply and Shawn pointed
>> it out.
> [...]
>> The use of simple panel seems to add and remove functionality:
>> 	- adds backlight, regulators and enable GPIOs!
>> 	- loses the ability to express timings in DT
> 
> For the simple panel driver Thierry preferred to have a panel database
> in the driver and uniquely identify the panel by its compatible value.
> This will also allow to infer the data mapping and width from
> the panel, and the panel timings are available for the next hardware to
> reuse the same panel (however likely that is).
> 
> The old method with display-timings will stay available, but for
> mainline I think it is better to add the panel to the driver.
> 

I predict that panel-simple.c will get really big, really fast.

Scanning it for panels that match our Okaya 1024x600 panel shows
that there already four with that resolution which seem to differ
only in margin timings.

I think the addition of an optional display-timings node and/or
a VESA GTF mode string would prevent a lot of churn, but this is
a separate topic.

>>> After:
>>> 	ldb {
>>> 		...
>>>
>>> 		lvds-channel at 0 {
>>> 			...
>>>
>>
>> Using port here to point at the panel seems to conflict
>> with the use of ports to point at the IPU.
> 
> I'm sorry, I don't understand what you mean exactly. There are some
> input ports (two on i.MX5, four on i.MX6) that are connected to the IPU,
> and one output port that is connected to the panel, in that order by
> convention. The port id 4 (reg = <4>) uniquely identifies the output
> port on i.MX6.
> 

The full DT for an LVDS channel looks like this:

...	
lvds-channel at 0 {
	#address-cells = <0x00000001>;
	#size-cells = <0x00000000>;
	...
	port at 0 {
		reg = <0x00000000>;
		endpoint {
			remote-endpoint = <0x00000013>;
			linux,phandle = <0x00000039>;
			phandle = <0x00000039>;
		};
	};
	port at 1 {
...	};
	port at 2 {
...	};
	port at 3 {
...	};
	port at 4 {
		reg = <0x00000004>;
		endpoint {
			remote-endpoint = <0x00000017>;
			linux,phandle = <0x00000053>;
			phandle = <0x00000053>;
		};
	};
};

ports 0-3 refer to the LVDS mux and which IPU and display
interface is connected up to the LVDS channel (i.e. the
input to the LVDS display bridge) and port at 4 refer to the
panel.

>>> [snip]
>>>
>>> 	panel {
>>> 		compatible = "edt,etm0700g0dh6", "simple-panel";
>>> 		...
>>>
>>
>> And why would the panel need to point back to the LVDS
>> channel?
> 
> This is the way the bindings are defined right now in
> Documentation/devicetree/bindings/graph.txt, section "Links between
> endpoints". The panel driver itself doesn't use the backlink, but the
> endpoint needs to exist anyway.
> 

Thanks for the reference.

I'm not following the rationale  since in this case, the communication
needs seem to be uni-directional, but okay.

>> [snip]
>>
>> Do you have a working example of how this should be used?
>>
>> My attempts to follow the notes above results in a failure
>> to find a crtc for the LVDS channel.
>>
>> Please advise,
> 
> I have used this patch to connect a HannStar HSD070PWW1 LVDS panel to a
> Nitrogen6X board:
> 

Thanks again. This patch works for me with your prior patch applied:

	https://patchwork.kernel.org/patch/5854771/

> -----8<-----
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> index 0821812..9e52adf 100644
> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> @@ -122,7 +122,7 @@
>  		status = "okay";
>  	};
>  
> -	backlight_lvds {
> +	backlight_lvds: backlight_lvds {
>  		compatible = "pwm-backlight";
>  		pwms = <&pwm4 0 5000000>;
>  		brightness-levels = <0 4 8 16 32 64 128 255>;
> @@ -130,6 +130,17 @@
>  		power-supply = <&reg_3p3v>;
>  		status = "okay";
>  	};
> +
> +	panel {
> +		compatible = "hannstar,hsd070pww1";
> +		backlight = <&backlight_lvds>;
> +
> +		port {
> +			panel_in: endpoint {
> +				remote-endpoint = <&lvds0_out>;
> +			};
> +		};
> +	};
>  };
>  

This does give me a path to get the equivalent functionality
as my original patches:

	- (if needed) add displays to panel-simple.c
	- update DT in boot loader to fix up displays based on panel
	detection by setting the panel.compatible string value.

I am still left with a quandary, which relates to my comment about
the port selection.

With our current device tree, both the HDMI and LVDS devices
are being mapped to IPU1/DI0 and the same DRM "card":

	~# ls  /sys/class/graphics/fb0/device/drm/card0/card*
	card0-HDMI-A-1	card0-LVDS-1

Since the default i.MX6 graph appears to have links for all four LVDS
mux options, and the path to binding to one of the IPU/DI -> LVDS
channel mappings isn't clear to me.

I have the same question for HDMI and LCD interfaces though, and
this is a separate topic.

Regards,


Eric

[PATCH 1/2] ARM: dts: imx6qdl-sabrelite: add supported LVDS displays

[Philipp Zabel]

Hi Eric,

Am Montag, den 13.04.2015, 12:48 -0700 schrieb Eric Nelson:
[...]
> The full DT for an LVDS channel looks like this:
> 
> ...	
> lvds-channel at 0 {
> 	#address-cells = <0x00000001>;
> 	#size-cells = <0x00000000>;
> 	...
> 	port at 0 {
> 		reg = <0x00000000>;
> 		endpoint {
> 			remote-endpoint = <0x00000013>;
> 			linux,phandle = <0x00000039>;
> 			phandle = <0x00000039>;
> 		};
> 	};
> 	port at 1 {
> ...	};
> 	port at 2 {
> ...	};
> 	port at 3 {
> ...	};
> 	port at 4 {
> 		reg = <0x00000004>;
> 		endpoint {
> 			remote-endpoint = <0x00000017>;
> 			linux,phandle = <0x00000053>;
> 			phandle = <0x00000053>;
> 		};
> 	};
> };
> 
> ports 0-3 refer to the LVDS mux and which IPU and display
> interface is connected up to the LVDS channel (i.e. the
> input to the LVDS display bridge) and port at 4 refer to the
> panel.

Yes. I still don't understand what you think is the problem with that.

> >>> [snip]
> >>>
> >>> 	panel {
> >>> 		compatible = "edt,etm0700g0dh6", "simple-panel";
> >>> 		...
> >>>
> >>
> >> And why would the panel need to point back to the LVDS
> >> channel?
> > 
> > This is the way the bindings are defined right now in
> > Documentation/devicetree/bindings/graph.txt, section "Links between
> > endpoints". The panel driver itself doesn't use the backlink, but the
> > endpoint needs to exist anyway.
> > 
> 
> Thanks for the reference.
> 
> I'm not following the rationale  since in this case, the communication
> needs seem to be uni-directional, but okay.

The binding as currently defined describes an undirected graph, set up
in a way that each node can find its peers without knowing anything
about the peer's bindings and without scanning the whole device tree.
So far there has been no consensus whether a direction should be added,
if it should be marked by leaving out one of the phandles, and if so,
what this direction should represent.

[...]
> This does give me a path to get the equivalent functionality
> as my original patches:
> 
> 	- (if needed) add displays to panel-simple.c
> 	- update DT in boot loader to fix up displays based on panel
> 	detection by setting the panel.compatible string value.
> 
> I am still left with a quandary, which relates to my comment about
> the port selection.
>
> With our current device tree, both the HDMI and LVDS devices
> are being mapped to IPU1/DI0 and the same DRM "card":
> 
> 	~# ls  /sys/class/graphics/fb0/device/drm/card0/card*
> 	card0-HDMI-A-1	card0-LVDS-1

There is only one "card" representing both IPUs and everything connected
to their DI outputs. Both connectors being mapped to the same frame
buffer is a property of drm_fb_helper_initial_config, as described in
its kerneldoc comment:

 "At the moment, this is a cloned configuration across all heads with
  a new framebuffer object as the backing store."

> Since the default i.MX6 graph appears to have links for all four LVDS
> mux options, and the path to binding to one of the IPU/DI -> LVDS
> channel mappings isn't clear to me.

All four LVDS mux options are connected in hardware, so that's what the
device tree describes. The path can be chosen dynamically via CRTC
modeset.

regards
Philipp

[PATCH 1/2] ARM: dts: imx6qdl-sabrelite: add supported LVDS displays

[Eric Nelson]

The BD-SL-i.MX6 (SABRE Lite board) supports three companion displays:
	Okaya 1024x600
	Hannstar 1024x768
	LG 1280x800

This patch adds timing entries into the LDB device tree and aliases
for them and HDMI to make it easy for the boot loader to configure them.

Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
---
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 3bddc8f..5f77dc0 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -13,6 +13,13 @@
 #include <dt-bindings/input/input.h>
 
 / {
+	aliases {
+		hdmi = &hdmi;
+		hannstar = &hannstar;
+		lg1280x800 = &lg1280x800;
+		okaya1024x600 = &okaya1024x600;
+	};
+
 	chosen {
 		stdout-path = &uart2;
 	};
@@ -361,8 +368,29 @@
 		status = "okay";
 
 		display-timings {
-			native-mode = <&timing0>;
-			timing0: hsd100pxn1 {
+			lg1280x800: lp101wx1 {
+				clock-frequency = <72000000>;
+				hactive = <1280>;
+				vactive = <800>;
+				hback-porch = <48>;
+				hfront-porch = <80>;
+				vback-porch = <15>;
+				vfront-porch = <2>;
+				hsync-len = <32>;
+				vsync-len = <6>;
+			};
+			okaya1024x600: okaya7x0WP {
+				clock-frequency = <52000000>;
+				hactive = <1024>;
+				vactive = <600>;
+				hback-porch = <220>;
+				hfront-porch = <40>;
+				vback-porch = <7>;
+				vfront-porch = <21>;
+				hsync-len = <60>;
+				vsync-len = <10>;
+			};
+			hannstar: hsd100pxn1 {
 				clock-frequency = <65000000>;
 				hactive = <1024>;
 				vactive = <768>;
-- 
1.9.1

[PATCH 1/2] ARM: dts: imx6qdl-sabrelite: add supported LVDS displays

[Philipp Zabel]

Hi Eric,

Am Donnerstag, den 19.02.2015, 16:53 -0700 schrieb Eric Nelson:
> The BD-SL-i.MX6 (SABRE Lite board) supports three companion displays:
> 	Okaya 1024x600
> 	Hannstar 1024x768
> 	LG 1280x800
> 
> This patch adds timing entries into the LDB device tree and aliases
> for them and HDMI to make it easy for the boot loader to configure them.
>
> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>

Could you please have a look at the simple-panel driver and add these
panels there instead? This allows to handle enable/disable timings,
backlights and regulators or enable GPIOs properly.

I have a patch to add drm_panel support to the imx-ldb driver (see
below). It depends on this of-graph series:

    https://lkml.org/lkml/2015/1/22/104

regards
Philipp

-----8<-----
From: Philipp Zabel <p.zabel@pengutronix.de>
Date: Thu, 6 Mar 2014 14:54:39 +0100
Subject: [PATCH] drm/imx: imx-ldb: add drm_panel support

This patch allows to optionally attach the lvds-channel to a panel
supported by a drm_panel driver using of-graph bindings, instead of
supplying the modes via display-timings in the device tree.

This depends on of_graph_get_port_by_id and uses the OF graph to
link the optional DRM panel to the LDB lvds-channel. The output
port number is 2 on devices without the external 4-port input
multiplexer (i.MX5) and 4 on devices with the mux (i.MX6).

Before:

	ldb {
		...

		lvds-channel at 0 {
			...

			display-timings {
				native-timing = <&timing1>;
				timing1: etm0700g0dh6 {
					hactive = <800>;
					vactive = <480>;
					clock-frequency = <33260000>;
					hsync-len = <128>;
					hback-porch = <88>;
					hfront-porch = <40>;
					vsync-len = <2>;
					vback-porch = <33>;
					vfront-porch = <10>;
					hsync-active = <0>;
					vsync-active = <0>;
					...
				};
			};
			...
		};
	};

After:
	ldb {
		...

		lvds-channel at 0 {
			...

			port at 4 {
				reg = <4>;

				lvds_out: endpoint {
					remote_endpoint = <&panel_in>;
				};
			};
		};
	};

	panel {
		compatible = "edt,etm0700g0dh6", "simple-panel";
		...

		port {
			panel_in: endpoint {
				remote-endpoint = <&lvds_out>;
			};
		};
	};

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
[Fixed build error due to missing select on DRM_PANEL --rmk]
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 drivers/gpu/drm/imx/Kconfig   |  1 +
 drivers/gpu/drm/imx/imx-ldb.c | 45 +++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index ab31848..1a5dbdb 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -36,6 +36,7 @@ config DRM_IMX_TVE
 config DRM_IMX_LDB
 	tristate "Support for LVDS displays"
 	depends on DRM_IMX && MFD_SYSCON
+	select DRM_PANEL
 	help
 	  Choose this to enable the internal LVDS Display Bridge (LDB)
 	  found on i.MX53 and i.MX6 processors.
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index c604600..e3cd148 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -19,10 +19,11 @@
 #include <drm/drmP.h>
 #include <drm/drm_fb_helper.h>
 #include <drm/drm_crtc_helper.h>
+#include <drm/drm_panel.h>
 #include <linux/mfd/syscon.h>
 #include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
-#include <linux/of_address.h>
 #include <linux/of_device.h>
+#include <linux/of_graph.h>
 #include <video/of_videomode.h>
 #include <linux/regmap.h>
 #include <linux/videodev2.h>
@@ -55,6 +56,7 @@ struct imx_ldb_channel {
 	struct imx_ldb *ldb;
 	struct drm_connector connector;
 	struct drm_encoder encoder;
+	struct drm_panel *panel;
 	struct device_node *child;
 	int chno;
 	void *edid;
@@ -91,6 +93,13 @@ static int imx_ldb_connector_get_modes(struct drm_connector *connector)
 	struct imx_ldb_channel *imx_ldb_ch = con_to_imx_ldb_ch(connector);
 	int num_modes = 0;
 
+	if (imx_ldb_ch->panel && imx_ldb_ch->panel->funcs &&
+	    imx_ldb_ch->panel->funcs->get_modes) {
+		num_modes = imx_ldb_ch->panel->funcs->get_modes(imx_ldb_ch->panel);
+		if (num_modes > 0)
+			return num_modes;
+	}
+
 	if (imx_ldb_ch->edid) {
 		drm_mode_connector_update_edid_property(connector,
 							imx_ldb_ch->edid);
@@ -205,6 +214,8 @@ static void imx_ldb_encoder_commit(struct drm_encoder *encoder)
 	int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
 	int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch->child, encoder);
 
+	drm_panel_prepare(imx_ldb_ch->panel);
+
 	if (dual) {
 		clk_prepare_enable(ldb->clk[0]);
 		clk_prepare_enable(ldb->clk[1]);
@@ -238,6 +249,8 @@ static void imx_ldb_encoder_commit(struct drm_encoder *encoder)
 	}
 
 	regmap_write(ldb->regmap, IOMUXC_GPR2, ldb->ldb_ctrl);
+
+	drm_panel_enable(imx_ldb_ch->panel);
 }
 
 static void imx_ldb_encoder_mode_set(struct drm_encoder *encoder,
@@ -289,6 +302,8 @@ static void imx_ldb_encoder_disable(struct drm_encoder *encoder)
 		 (ldb->ldb_ctrl & LDB_CH1_MODE_EN_MASK) == 0)
 		return;
 
+	drm_panel_disable(imx_ldb_ch->panel);
+
 	if (imx_ldb_ch == &ldb->channel[0])
 		ldb->ldb_ctrl &= ~LDB_CH0_MODE_EN_MASK;
 	else if (imx_ldb_ch == &ldb->channel[1])
@@ -300,6 +315,8 @@ static void imx_ldb_encoder_disable(struct drm_encoder *encoder)
 		clk_disable_unprepare(ldb->clk[0]);
 		clk_disable_unprepare(ldb->clk[1]);
 	}
+
+	drm_panel_unprepare(imx_ldb_ch->panel);
 }
 
 static struct drm_connector_funcs imx_ldb_connector_funcs = {
@@ -373,6 +390,9 @@ static int imx_ldb_register(struct drm_device *drm,
 	drm_connector_init(drm, &imx_ldb_ch->connector,
 			   &imx_ldb_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
 
+	if (imx_ldb_ch->panel)
+		drm_panel_attach(imx_ldb_ch->panel, &imx_ldb_ch->connector);
+
 	drm_mode_connector_attach_encoder(&imx_ldb_ch->connector,
 			&imx_ldb_ch->encoder);
 
@@ -487,6 +507,7 @@ static int imx_ldb_bind(struct device *dev, struct device *master, void *data)
 
 	for_each_child_of_node(np, child) {
 		struct imx_ldb_channel *channel;
+		struct device_node *port;
 
 		ret = of_property_read_u32(child, "reg", &i);
 		if (ret || i < 0 || i > 1)
@@ -505,11 +526,31 @@ static int imx_ldb_bind(struct device *dev, struct device *master, void *data)
 		channel->chno = i;
 		channel->child = child;
 
+		/* The output port is port at 4 on i.MX6 or port at 2 on i.MX53 */
+		port = of_graph_get_port_by_id(child, imx_ldb->lvds_mux ? 4 : 2);
+		if (port) {
+			struct device_node *endpoint, *remote;
+
+			endpoint = of_get_child_by_name(port, "endpoint");
+			if (endpoint) {
+				remote = of_graph_get_remote_port_parent(endpoint);
+				if (remote)
+					channel->panel = of_drm_find_panel(remote);
+				else
+					return -EPROBE_DEFER;
+				if (!channel->panel) {
+					dev_err(dev, "panel not found: %s\n",
+						remote->full_name);
+					return -EPROBE_DEFER;
+				}
+			}
+		}
+
 		edidp = of_get_property(child, "edid", &channel->edid_len);
 		if (edidp) {
 			channel->edid = kmemdup(edidp, channel->edid_len,
 						GFP_KERNEL);
-		} else {
+		} else if (!channel->panel) {
 			ret = of_get_drm_display_mode(child, &channel->mode, 0);
 			if (!ret)
 				channel->mode_valid = 1;
-- 
2.1.4