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@xxxxxxxxxxxxxxxx> > > >>> --- > > >>> 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@xxxxxxxxxxxx> > > > > > > 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.
