RE: [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

From: "Kandpal, Suraj" <suraj.kandpal@intel.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Carsten Haitzler <carsten.haitzler@arm.com>,
	"Nikula, Jani" <jani.nikula@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Abhinav Kumar <quic_abhinavk@quicinc.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	David Airlie <airlied@linux.ie>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	"Murthy, Arun R" <arun.r.murthy@intel.com>
Subject: RE: [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
Date: Fri, 4 Mar 2022 10:47:37 +0000	[thread overview]
Message-ID: <MWHPR11MB1741708DEFD56E02C1BBC7A3E3059@MWHPR11MB1741.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAA8EJppTVN1EnytD5mCmr4ZTi4M8u9ENOmJuweNyDRkB3LEHnw@mail.gmail.com>

Hi,
> > Hi Abhinav,
> > > Hi Laurent
> > >
> > > Ok sure, I can take this up but I need to understand the proposal a
> > > little bit more before proceeding on this. So we will discuss this
> > > in another email where we specifically talk about the connector changes.
> > >
> > > Also, I am willing to take this up once the encoder part is done and
> > > merged so that atleast we keep moving on that as MSM WB
> > > implementation can proceed with that first.
> > >
> > > Hi Jani and Suraj
> > >
> > > Any concerns with splitting up the series into encoder and connector
> > > OR re- arranging them?
> > >
> > > Let me know if you can do this OR I can also split this up keeping
> > > Suraj's name in the Co-developed by tag.
> > I was actually thinking of floating a new patch series with both
> > encoder and connector pointer changes but with a change in
> > initialization functions wherein we allocate a connector and encoder
> > incase the driver doesn’t have its own this should minimize the effect
> > on other drivers already using current drm writeback framework and also
> allow i915 to create its own connector.
> 
> I thought that Laurent was quite strict about the connector. So I'd suggest
> targeting drm_writeback_connector with an optionally created encoder and
> the builtin connector
In that case even if we target that i915 will not be able to move forward with its
implementation of writeback as builtin connector does not work for us right now
as explained earlier, optionally creating encoder and connector will help everyone
move forward and once done we can actually sit and work on how to side step this 
issue using Laurent's suggestion
> 
> > We can work on Laurent's suggestion but that would first require the
> > initial RFC patches and then a rework from both of our drivers side to
> > see if they gel well with our current code which will take a
> > considerable amount of time. We can for now however float the patch
> > series up which minimally affects the current drivers and also allows
> > i915 and msm to move forward with its writeback implementation off
> > course with a proper documentation stating new drivers shouldn't try to
> make their own connectors and encoders and that drm_writeback will do
> that for them.
> > Once that's done and merged we can work with Laurent on his proposal
> > to improve the drm writeback framework so that this issue can be side
> stepped entirely in future.
> > For now I would like to keep the encoder and connector pointer changes
> together.

Best Regards,
Suraj Kandpal