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

Dmitry Baryshkov dmitry.baryshkov at linaro.org
Fri Mar 4 10:39:56 UTC 2022


Hi,

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

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


-- 
With best wishes
Dmitry


More information about the dri-devel mailing list