[PATCH v2 5/6] arm64: dts: renesas: r8a77990: ebisu: Enable LVDS1 encoder

[Simon Horman]

On Fri, Feb 15, 2019 at 01:44:43PM +0200, Laurent Pinchart wrote:
> 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 at 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 at 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 ?

Thanks, I've applied patches 5 and 6 of this series to my
renesas tree for inclusion in v5.2.