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 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 > > Tested-by: Jacopo Mondi > > 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 >