Hi, On Fri, 4 Mar 2022 at 12:56, Kandpal, Suraj <suraj.kand...@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