diff mbox series

[v3,10/10,HACK] arm64: dts: renesas: ebisu: Enable LVDS dual-link operation

Message ID 20190528141234.15425-11-laurent.pinchart+renesas@ideasonboard.com (mailing list archive)
State RFC
Delegated to: Simon Horman
Headers show
Series R-Car DU: LVDS dual-link mode support | expand

Commit Message

Laurent Pinchart May 28, 2019, 2:12 p.m. UTC 
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 24 +++++++++++++------
 1 file changed, 17 insertions(+), 7 deletions(-)

Comments

Fabrizio Castro July 22, 2019, 11:27 a.m. UTC | #1 
Hello Jacopo,

> From: linux-renesas-soc-owner@vger.kernel.org <linux-renesas-soc-owner@vger.kernel.org> On Behalf Of Laurent Pinchart
> Sent: 28 May 2019 15:13
> Subject: [PATCH v3 10/10] [HACK] arm64: dts: renesas: ebisu: Enable LVDS dual-link operation
> 
> Enable and connect the second LVDS encoder to the second LVDS input of
> the THC63LVD1024 for dual-link LVDS operation. This requires changing
> the default settings of SW45 and SW47 to OFF and ON respectively.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

How did you test this patch on Ebisu (kernel branch, configuration, switches,etc.)?

I tested both linux-next and drm/du/lvds/dual-link and they are not working for me.
The base configuration I am using is coming from arch/arm64/configs/defconfig from each respective branch, on top of that I am enabling the remaining bits and pieces.
I have tried the suggested configuration of the switches for this patch, basically nothing is happening. I have also tried reverting the changes made by this patch (on both branches), and of course I have reverted the selection for the switches as well, and even single-link doesn't work for me. Single-link support from the BSP version of the kernel (4.14.75-ltsi) works for me, that confirms the configuration of the switches I am using when testing single-link should be okay.

If, in the single-link use case from drm/du/lvds/dual-link, I connect lvds1 to the vga-encoder in the DT (like for the BSP DT, but I can see from the schematics that ADV7123 is actually connected to DU, like the configuration in the DT upstream), then HDMI works as expected (most of the time). 

I wonder if for some reason we may end up using the wrong lvds encoder at times, or no encoder at all?

Have you seen this problem? Am I missing something obvious here?

Thanks,
Fab

> ---
>  .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 24 +++++++++++++------
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> index c72772589953..988d82609f41 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> @@ -93,11 +93,18 @@
> 
>  			port@0 {
>  				reg = <0>;
> -				thc63lvd1024_in: endpoint {
> +				thc63lvd1024_in0: endpoint {
>  					remote-endpoint = <&lvds0_out>;
>  				};
>  			};
> 
> +			port@1 {
> +				reg = <1>;
> +				thc63lvd1024_in1: endpoint {
> +					remote-endpoint = <&lvds1_out>;
> +				};
> +			};
> +
>  			port@2 {
>  				reg = <2>;
>  				thc63lvd1024_out: endpoint {
> @@ -482,24 +489,27 @@
>  	ports {
>  		port@1 {
>  			lvds0_out: endpoint {
> -				remote-endpoint = <&thc63lvd1024_in>;
> +				remote-endpoint = <&thc63lvd1024_in0>;
>  			};
>  		};
>  	};
>  };
> 
>  &lvds1 {
> -	/*
> -	 * Even though the LVDS1 output is not connected, the encoder must be
> -	 * enabled to supply a pixel clock to the DU for the DPAD output when
> -	 * LVDS0 is in use.
> -	 */
>  	status = "okay";
> 
>  	clocks = <&cpg CPG_MOD 727>,
>  		 <&x13_clk>,
>  		 <&extal_clk>;
>  	clock-names = "fck", "dclkin.0", "extal";
> +
> +	ports {
> +		port@1 {
> +			lvds1_out: endpoint {
> +				remote-endpoint = <&thc63lvd1024_in1>;
> +			};
> +		};
> +	};
>  };
> 
>  &ohci0 {
> --
> Regards,
> 
> Laurent Pinchart
Jacopo Mondi July 23, 2019, 10:30 a.m. UTC | #2 
HI Fabrizio,

On Mon, Jul 22, 2019 at 11:27:26AM +0000, Fabrizio Castro wrote:
> Hello Jacopo,
>
> > From: linux-renesas-soc-owner@vger.kernel.org <linux-renesas-soc-owner@vger.kernel.org> On Behalf Of Laurent Pinchart
> > Sent: 28 May 2019 15:13
> > Subject: [PATCH v3 10/10] [HACK] arm64: dts: renesas: ebisu: Enable LVDS dual-link operation
> >
> > Enable and connect the second LVDS encoder to the second LVDS input of
> > the THC63LVD1024 for dual-link LVDS operation. This requires changing
> > the default settings of SW45 and SW47 to OFF and ON respectively.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> How did you test this patch on Ebisu (kernel branch, configuration, switches,etc.)?
>

I tested the branch provided by Laurent and mentioned in this cover
letter.

The branch is now rebased on v5.2-rc1 as you can see, I cannot tell at
the time which one was the release tag on which it was based on, but I
suspect 5.0 or either v4.20. Maye Laurent remembers it.

> I tested both linux-next and drm/du/lvds/dual-link and they are not working for me.
> The base configuration I am using is coming from arch/arm64/configs/defconfig from each respective branch, on top of that I am enabling the remaining bits and pieces.
> I have tried the suggested configuration of the switches for this patch, basically nothing is happening. I have also tried reverting the changes made by this patch (on both branches), and of course I have reverted the selection for the switches as well, and even single-link doesn't work for me. Single-link support from the BSP version of the kernel (4.14.75-ltsi) works for me, that confirms the configuration of the switches I am using when testing single-link should be okay.
>
> If, in the single-link use case from drm/du/lvds/dual-link, I connect lvds1 to the vga-encoder in the DT (like for the BSP DT, but I can see from the schematics that ADV7123 is actually connected to DU, like the configuration in the DT upstream), then HDMI works as expected (most of the time).
>
> I wonder if for some reason we may end up using the wrong lvds encoder at times, or no encoder at all?
>
> Have you seen this problem? Am I missing something obvious here?

The branch I tested at the time worked out the box, but now, I see
several different problems, and this morning I ran severl tests. Here
it is a summary:

Laurent's drm/du/lvds/dual-link and drm/du/next are v5.2-rc1 based.
I see an error which makes Ebisu fail to boot on those branches and
plain v5.2 (both -rc1 and final v5.2)

The issue is related to bd9571 which seems to be an MFD gpio expander:

[    2.748694] bd9571mwv 8-0030: Device: BD9571MWV rev. 4
[   28.754865] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[   28.761094] rcu:     1-...0: (2 ticks this GP) idle=352/1/0x4000000000000000 softirq=45/46 fqs=3250

sometimes it even fail when detecting the chip:
        i2c-sh_mobile e60b0000.i2c: Transfer request timed out                                                                                                       │
        bd9571mwv 8-0030: Failed to read vendor code register (ret=-110)

I managed to boot the board once with no error, so I wonder if it is
not my board which has issues?

Anyway, this seems unrelated to the lvds dual link mode, but prevents
me from testing anything on v5.2. I wonder if you ever seen anything similar...

So I went and tested v5.1. Plain v5.1 with SW45 and SW47 in their
'default' position gives me a working output with single mode.

I then cherry-picked the patches from Laurent's drm/du/lvds/dual-link
and applied on top of v5.1 and it seems like DU does not get probed
there.

To be sure I was testing the same patches I tested at the time I gave
my tag to this series I manually applied the patches from this series
(not the one in Laurent's tree, but the ones here sent) on top of v5.1
and I got the same result, DU was not probed correctly.

I had a look at diff in the encoder registration process between 5.0 and
5.2 and I don't see much differences, so I suspect it might be some
config option I have missed as well?

Could you be a bit more precise on which tools are you using for
testing and which failures you see? Are those the same I see here?

I'm testing using kms-tests or kmsxx alternatively, and made sure the
DU driver was loaded (or not) with modeprint from drm's modetest
suite.  Basically, everything is mentioned here:
uttps://elinux.org/R-Car/Devices#DU

I could start reporting the v5.2 failure on Ebisu if you confirm me
you see the same on your side, then trying to get to the bottom of the
DU/lvds issue.

Thanks
   j

>
> Thanks,
> Fab
>
> > ---
> >  .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 24 +++++++++++++------
> >  1 file changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> > index c72772589953..988d82609f41 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> > @@ -93,11 +93,18 @@
> >
> >  			port@0 {
> >  				reg = <0>;
> > -				thc63lvd1024_in: endpoint {
> > +				thc63lvd1024_in0: endpoint {
> >  					remote-endpoint = <&lvds0_out>;
> >  				};
> >  			};
> >
> > +			port@1 {
> > +				reg = <1>;
> > +				thc63lvd1024_in1: endpoint {
> > +					remote-endpoint = <&lvds1_out>;
> > +				};
> > +			};
> > +
> >  			port@2 {
> >  				reg = <2>;
> >  				thc63lvd1024_out: endpoint {
> > @@ -482,24 +489,27 @@
> >  	ports {
> >  		port@1 {
> >  			lvds0_out: endpoint {
> > -				remote-endpoint = <&thc63lvd1024_in>;
> > +				remote-endpoint = <&thc63lvd1024_in0>;
> >  			};
> >  		};
> >  	};
> >  };
> >
> >  &lvds1 {
> > -	/*
> > -	 * Even though the LVDS1 output is not connected, the encoder must be
> > -	 * enabled to supply a pixel clock to the DU for the DPAD output when
> > -	 * LVDS0 is in use.
> > -	 */
> >  	status = "okay";
> >
> >  	clocks = <&cpg CPG_MOD 727>,
> >  		 <&x13_clk>,
> >  		 <&extal_clk>;
> >  	clock-names = "fck", "dclkin.0", "extal";
> > +
> > +	ports {
> > +		port@1 {
> > +			lvds1_out: endpoint {
> > +				remote-endpoint = <&thc63lvd1024_in1>;
> > +			};
> > +		};
> > +	};
> >  };
> >
> >  &ohci0 {
> > --
> > Regards,
> >
> > Laurent Pinchart
>
Fabrizio Castro July 23, 2019, 12:16 p.m. UTC | #3 
Hello Jacopo,

Thank you for getting back to me!

> From: linux-renesas-soc-owner@vger.kernel.org <linux-renesas-soc-owner@vger.kernel.org> On Behalf Of Jacopo Mondi
> Sent: 23 July 2019 11:30
> Subject: Re: [PATCH v3 10/10] [HACK] arm64: dts: renesas: ebisu: Enable LVDS dual-link operation
> 
> HI Fabrizio,
> 
> On Mon, Jul 22, 2019 at 11:27:26AM +0000, Fabrizio Castro wrote:
> > Hello Jacopo,
> >
> > > From: linux-renesas-soc-owner@vger.kernel.org <linux-renesas-soc-owner@vger.kernel.org> On Behalf Of Laurent Pinchart
> > > Sent: 28 May 2019 15:13
> > > Subject: [PATCH v3 10/10] [HACK] arm64: dts: renesas: ebisu: Enable LVDS dual-link operation
> > >
> > > Enable and connect the second LVDS encoder to the second LVDS input of
> > > the THC63LVD1024 for dual-link LVDS operation. This requires changing
> > > the default settings of SW45 and SW47 to OFF and ON respectively.
> > >
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > How did you test this patch on Ebisu (kernel branch, configuration, switches,etc.)?
> >
> 
> I tested the branch provided by Laurent and mentioned in this cover
> letter.
> 
> The branch is now rebased on v5.2-rc1 as you can see, I cannot tell at
> the time which one was the release tag on which it was based on, but I
> suspect 5.0 or either v4.20. Maye Laurent remembers it.
> 
> > I tested both linux-next and drm/du/lvds/dual-link and they are not working for me.
> > The base configuration I am using is coming from arch/arm64/configs/defconfig from each respective branch, on top of that I am
> enabling the remaining bits and pieces.
> > I have tried the suggested configuration of the switches for this patch, basically nothing is happening. I have also tried reverting the
> changes made by this patch (on both branches), and of course I have reverted the selection for the switches as well, and even single-
> link doesn't work for me. Single-link support from the BSP version of the kernel (4.14.75-ltsi) works for me, that confirms the
> configuration of the switches I am using when testing single-link should be okay.
> >
> > If, in the single-link use case from drm/du/lvds/dual-link, I connect lvds1 to the vga-encoder in the DT (like for the BSP DT, but I can
> see from the schematics that ADV7123 is actually connected to DU, like the configuration in the DT upstream), then HDMI works as
> expected (most of the time).
> >
> > I wonder if for some reason we may end up using the wrong lvds encoder at times, or no encoder at all?
> >
> > Have you seen this problem? Am I missing something obvious here?
> 
> The branch I tested at the time worked out the box, but now, I see
> several different problems, and this morning I ran severl tests. Here
> it is a summary:
> 
> Laurent's drm/du/lvds/dual-link and drm/du/next are v5.2-rc1 based.
> I see an error which makes Ebisu fail to boot on those branches and
> plain v5.2 (both -rc1 and final v5.2)
> 
> The issue is related to bd9571 which seems to be an MFD gpio expander:
> 
> [    2.748694] bd9571mwv 8-0030: Device: BD9571MWV rev. 4
> [   28.754865] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> [   28.761094] rcu:     1-...0: (2 ticks this GP) idle=352/1/0x4000000000000000 softirq=45/46 fqs=3250
> 
> sometimes it even fail when detecting the chip:
>         i2c-sh_mobile e60b0000.i2c: Transfer request timed out                                                                                                       │
>         bd9571mwv 8-0030: Failed to read vendor code register (ret=-110)
> 
> I managed to boot the board once with no error, so I wonder if it is
> not my board which has issues?
> 
> Anyway, this seems unrelated to the lvds dual link mode, but prevents
> me from testing anything on v5.2. I wonder if you ever seen anything similar...

I have just retested plain v5.2 on the Ebisu board (I am using the 4D, which
version of Ebisu are you using?) and I don't seem to have that specific issue.
Also, this time around the single-link configuration is working out of the box,
which is interesting.

> 
> So I went and tested v5.1. Plain v5.1 with SW45 and SW47 in their
> 'default' position gives me a working output with single mode.
> 
> I then cherry-picked the patches from Laurent's drm/du/lvds/dual-link
> and applied on top of v5.1 and it seems like DU does not get probed
> there.
> 
> To be sure I was testing the same patches I tested at the time I gave
> my tag to this series I manually applied the patches from this series
> (not the one in Laurent's tree, but the ones here sent) on top of v5.1
> and I got the same result, DU was not probed correctly.
> 
> I had a look at diff in the encoder registration process between 5.0 and
> 5.2 and I don't see much differences, so I suspect it might be some
> config option I have missed as well?
> 
> Could you be a bit more precise on which tools are you using for
> testing and which failures you see? Are those the same I see here?

Even in my case DU doesn't get probed correctly either, rcar_du_probe
gets called into a couple of times, and both times it returns -EPROBE_DEFER.

I am using kms-tests at the moment.

> 
> I'm testing using kms-tests or kmsxx alternatively, and made sure the
> DU driver was loaded (or not) with modeprint from drm's modetest
> suite.  Basically, everything is mentioned here:
> uttps://elinux.org/R-Car/Devices#DU
> 
> I could start reporting the v5.2 failure on Ebisu if you confirm me
> you see the same on your side, then trying to get to the bottom of the
> DU/lvds issue.

I am looking into dual-link support for RZ/G2E, and that's why I am interested
in seeing dual-link working on Ebisu. I am going to have a deeper look into
what's happening on Ebisu now that I know that you are having similar troubles
(besides bd9571mwv), but I may have more questions soon for you if you don't
mind?

Thanks,
Fab

> 
> Thanks
>    j
> 
> >
> > Thanks,
> > Fab
> >
> > > ---
> > >  .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 24 +++++++++++++------
> > >  1 file changed, 17 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> > > index c72772589953..988d82609f41 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
> > > @@ -93,11 +93,18 @@
> > >
> > >  			port@0 {
> > >  				reg = <0>;
> > > -				thc63lvd1024_in: endpoint {
> > > +				thc63lvd1024_in0: endpoint {
> > >  					remote-endpoint = <&lvds0_out>;
> > >  				};
> > >  			};
> > >
> > > +			port@1 {
> > > +				reg = <1>;
> > > +				thc63lvd1024_in1: endpoint {
> > > +					remote-endpoint = <&lvds1_out>;
> > > +				};
> > > +			};
> > > +
> > >  			port@2 {
> > >  				reg = <2>;
> > >  				thc63lvd1024_out: endpoint {
> > > @@ -482,24 +489,27 @@
> > >  	ports {
> > >  		port@1 {
> > >  			lvds0_out: endpoint {
> > > -				remote-endpoint = <&thc63lvd1024_in>;
> > > +				remote-endpoint = <&thc63lvd1024_in0>;
> > >  			};
> > >  		};
> > >  	};
> > >  };
> > >
> > >  &lvds1 {
> > > -	/*
> > > -	 * Even though the LVDS1 output is not connected, the encoder must be
> > > -	 * enabled to supply a pixel clock to the DU for the DPAD output when
> > > -	 * LVDS0 is in use.
> > > -	 */
> > >  	status = "okay";
> > >
> > >  	clocks = <&cpg CPG_MOD 727>,
> > >  		 <&x13_clk>,
> > >  		 <&extal_clk>;
> > >  	clock-names = "fck", "dclkin.0", "extal";
> > > +
> > > +	ports {
> > > +		port@1 {
> > > +			lvds1_out: endpoint {
> > > +				remote-endpoint = <&thc63lvd1024_in1>;
> > > +			};
> > > +		};
> > > +	};
> > >  };
> > >
> > >  &ohci0 {
> > > --
> > > Regards,
> > >
> > > Laurent Pinchart
> >
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index c72772589953..988d82609f41 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -93,11 +93,18 @@ 
 
 			port@0 {
 				reg = <0>;
-				thc63lvd1024_in: endpoint {
+				thc63lvd1024_in0: endpoint {
 					remote-endpoint = <&lvds0_out>;
 				};
 			};
 
+			port@1 {
+				reg = <1>;
+				thc63lvd1024_in1: endpoint {
+					remote-endpoint = <&lvds1_out>;
+				};
+			};
+
 			port@2 {
 				reg = <2>;
 				thc63lvd1024_out: endpoint {
@@ -482,24 +489,27 @@ 
 	ports {
 		port@1 {
 			lvds0_out: endpoint {
-				remote-endpoint = <&thc63lvd1024_in>;
+				remote-endpoint = <&thc63lvd1024_in0>;
 			};
 		};
 	};
 };
 
 &lvds1 {
-	/*
-	 * Even though the LVDS1 output is not connected, the encoder must be
-	 * enabled to supply a pixel clock to the DU for the DPAD output when
-	 * LVDS0 is in use.
-	 */
 	status = "okay";
 
 	clocks = <&cpg CPG_MOD 727>,
 		 <&x13_clk>,
 		 <&extal_clk>;
 	clock-names = "fck", "dclkin.0", "extal";
+
+	ports {
+		port@1 {
+			lvds1_out: endpoint {
+				remote-endpoint = <&thc63lvd1024_in1>;
+			};
+		};
+	};
 };
 
 &ohci0 {