[v2,5/6] arm64: dts: renesas: r8a77990: ebisu: Enable LVDS1 encoder
diff mbox series

Message ID 20190122225405.7815-6-laurent.pinchart+renesas@ideasonboard.com
State Under Review
Delegated to: Simon Horman
Headers show
Series
  • R-Car DU DPAD support for D3 and E3
Related show

Commit Message

Laurent Pinchart Jan. 22, 2019, 10:54 p.m. UTC
The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
output when the LVDS0 encoder is used. Enable it despite its output not
being connected.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
Changes since v1:

- Add a comment in the DT to explain why the LVDS1 encoder needs to be
  enabled.
---
 arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Simon Horman Jan. 23, 2019, 8:56 a.m. UTC | #1
On Wed, Jan 23, 2019 at 12:54:04AM +0200, Laurent Pinchart wrote:
> The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
> output when the LVDS0 encoder is used. Enable it despite its output not
> being connected.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Changes since v1:
> 
> - Add a comment in the DT to explain why the LVDS1 encoder needs to be
>   enabled.

Thanks,

This looks fine to me but I will wait to see if there are other reviews
before applying.

Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Laurent Pinchart Jan. 23, 2019, 9:55 a.m. UTC | #2
Hi Simon,

On Wed, Jan 23, 2019 at 09:56:57AM +0100, Simon Horman wrote:
> On Wed, Jan 23, 2019 at 12:54:04AM +0200, Laurent Pinchart wrote:
> > The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
> > output when the LVDS0 encoder is used. Enable it despite its output not
> > being connected.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > Changes since v1:
> > 
> > - Add a comment in the DT to explain why the LVDS1 encoder needs to be
> >   enabled.
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
> 
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>

Please note that this will likely cause probe failures if applied
without the driver patches from this series. Would it be OK to merge the
DT changes through the DRM tree ?
Simon Horman Jan. 23, 2019, 10:03 a.m. UTC | #3
Hi Laurent,

On Wed, Jan 23, 2019 at 11:55:52AM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Wed, Jan 23, 2019 at 09:56:57AM +0100, Simon Horman wrote:
> > On Wed, Jan 23, 2019 at 12:54:04AM +0200, Laurent Pinchart wrote:
> > > The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
> > > output when the LVDS0 encoder is used. Enable it despite its output not
> > > being connected.
> > > 
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > ---
> > > Changes since v1:
> > > 
> > > - Add a comment in the DT to explain why the LVDS1 encoder needs to be
> > >   enabled.
> > 
> > Thanks,
> > 
> > This looks fine to me but I will wait to see if there are other reviews
> > before applying.
> > 
> > Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> 
> Please note that this will likely cause probe failures if applied
> without the driver patches from this series. Would it be OK to merge the
> DT changes through the DRM tree ?

I'm not sure that the probe failures are a problem unless they move
something that was in a working state to a non-working state. Nonetheless
they are at the very least not very nice.

I generally shy away from having DT patches merged in other trees
to avoid the chance of merge conflicts (that need to be resolved by Linus).
What is your feeling on the risk of such a conflict?
Laurent Pinchart Feb. 15, 2019, 11:44 a.m. UTC | #4
Hi Simon,

On Wed, Jan 23, 2019 at 11:03:04AM +0100, Simon Horman wrote:
> On Wed, Jan 23, 2019 at 11:55:52AM +0200, Laurent Pinchart wrote:
> > On Wed, Jan 23, 2019 at 09:56:57AM +0100, Simon Horman wrote:
> >> On Wed, Jan 23, 2019 at 12:54:04AM +0200, Laurent Pinchart wrote:
> >>> The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
> >>> output when the LVDS0 encoder is used. Enable it despite its output not
> >>> being connected.
> >>> 
> >>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >>> ---
> >>> Changes since v1:
> >>> 
> >>> - Add a comment in the DT to explain why the LVDS1 encoder needs to be
> >>>   enabled.
> >> 
> >> Thanks,
> >> 
> >> This looks fine to me but I will wait to see if there are other reviews
> >> before applying.
> >> 
> >> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> > 
> > Please note that this will likely cause probe failures if applied
> > without the driver patches from this series. Would it be OK to merge the
> > DT changes through the DRM tree ?
> 
> I'm not sure that the probe failures are a problem unless they move
> something that was in a working state to a non-working state. Nonetheless
> they are at the very least not very nice.
> 
> I generally shy away from having DT patches merged in other trees
> to avoid the chance of merge conflicts (that need to be resolved by Linus).
> What is your feeling on the risk of such a conflict?

I would have said low, but given that it's too late to get the DT
changes in v5.1 anyway, it's no big deal. The driver patches have been
merged for v5.1, so could you queue the DT changes for v5.2 ?

Patch
diff mbox series

diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 62bdddcbbae7..800a537bbbe0 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -443,6 +443,13 @@ 
 };
 
 &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>;