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

[Dmitry Baryshkov]

On Fri, 4 Mar 2022 at 13:47, Kandpal, Suraj <suraj.kandpal at intel.com> wrote:
>
> 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

This is up to Laurent & other DRM maintainers to decide whether this
approach would be accepted or not.
So far unfortunately I have mostly seen the pushback and a strong
suggestion to stop treating each drm_connector as i915_connector.
I haven't checked the exact details, but IMO adding a branch if the
connector's type is DRM_CONNECTOR_VIRTUAL should be doable.

> >
> > > 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



-- 
With best wishes
Dmitry