From: Abhinav Kumar <quic_abhinavk@quicinc.com> To: "Kandpal, Suraj" <suraj.kandpal@intel.com>, 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>, 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: Tue, 8 Mar 2022 11:44:07 -0800 [thread overview] Message-ID: <4daece94-c438-29dd-ef9d-e4c4c06187c4@quicinc.com> (raw) In-Reply-To: <MWHPR11MB1741B36C4BA59CDF84D9F52EE3099@MWHPR11MB1741.namprd11.prod.outlook.com> Hi Suraj On 3/8/2022 6:30 AM, Kandpal, Suraj wrote: > Hi Abhinav, >>> Hi, >>>>> 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 was proposing to split up the encoder and connector because the >> comments from Laurent meant we were in agreement about the encoder >> but not about the connector. >> >> I am afraid another attempt with the similar idea is only going to stall the >> series again and hence i gave this option. > > Seems like this patch series currently won't be able to move forward with the > connector pointer change so I guess you can split the series to encoder pointer > change where we optionally create encoder if required ,keeping my name in > co-developed tag so that msm can move forward with its implementation and > then we can work to see how the connector issue can be bypassed. > > Best Regards, > Suraj Kandpal Thanks, let me re-spin this and will keep your name as co-developer. Should be able to get it on the list in a week. Thanks Abhinav >> Eventually its upto Laurent and the other maintainers to guide us forward on >> this as this series has been stalled for weeks now. >> >>>>>> 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. >>> Bringing in the change where we don’t treat each drm_connector as an >>> intel_connector or even adding a branch which checks if drm_connector >>> is DRM_CONNECTOR_VIRTUAL and conditionally cast it to intel_connector >>> is quite a lot of work for i915. >>> That's why I was suggesting if for now we could move forward with >>> optionally creating both encoder and connector minimizing affects on >>> other drivers as well as allowing us to move forward. >>> What do you think, Launrent? >>> >>>> >>>>>> >>>>>>> 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. >>>>> >>>>
WARNING: multiple messages have this Message-ID (diff)
From: Abhinav Kumar <quic_abhinavk@quicinc.com> To: "Kandpal, Suraj" <suraj.kandpal@intel.com>, 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>, dri-devel <dri-devel@lists.freedesktop.org>, David Airlie <airlied@linux.ie>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Subject: Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes Date: Tue, 8 Mar 2022 11:44:07 -0800 [thread overview] Message-ID: <4daece94-c438-29dd-ef9d-e4c4c06187c4@quicinc.com> (raw) In-Reply-To: <MWHPR11MB1741B36C4BA59CDF84D9F52EE3099@MWHPR11MB1741.namprd11.prod.outlook.com> Hi Suraj On 3/8/2022 6:30 AM, Kandpal, Suraj wrote: > Hi Abhinav, >>> Hi, >>>>> 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 was proposing to split up the encoder and connector because the >> comments from Laurent meant we were in agreement about the encoder >> but not about the connector. >> >> I am afraid another attempt with the similar idea is only going to stall the >> series again and hence i gave this option. > > Seems like this patch series currently won't be able to move forward with the > connector pointer change so I guess you can split the series to encoder pointer > change where we optionally create encoder if required ,keeping my name in > co-developed tag so that msm can move forward with its implementation and > then we can work to see how the connector issue can be bypassed. > > Best Regards, > Suraj Kandpal Thanks, let me re-spin this and will keep your name as co-developer. Should be able to get it on the list in a week. Thanks Abhinav >> Eventually its upto Laurent and the other maintainers to guide us forward on >> this as this series has been stalled for weeks now. >> >>>>>> 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. >>> Bringing in the change where we don’t treat each drm_connector as an >>> intel_connector or even adding a branch which checks if drm_connector >>> is DRM_CONNECTOR_VIRTUAL and conditionally cast it to intel_connector >>> is quite a lot of work for i915. >>> That's why I was suggesting if for now we could move forward with >>> optionally creating both encoder and connector minimizing affects on >>> other drivers as well as allowing us to move forward. >>> What do you think, Launrent? >>> >>>> >>>>>> >>>>>>> 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. >>>>> >>>>
next prev parent reply other threads:[~2022-03-08 19:44 UTC|newest] Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-02 8:54 [PATCH 0/6] drm writeback connector changes Kandpal Suraj 2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj 2022-02-02 8:54 ` [PATCH 1/6] drm: add writeback pointers to drm_connector Kandpal Suraj 2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj 2022-02-02 10:28 ` Dmitry Baryshkov 2022-02-02 10:28 ` [Intel-gfx] " Dmitry Baryshkov 2022-02-03 8:46 ` Kandpal, Suraj 2022-02-03 8:46 ` [Intel-gfx] " Kandpal, Suraj 2022-02-02 11:17 ` kernel test robot 2022-02-02 11:17 ` kernel test robot 2022-02-02 20:07 ` kernel test robot 2022-02-02 20:07 ` kernel test robot 2022-02-02 20:07 ` kernel test robot 2022-02-02 8:54 ` [PATCH 2/6] drm/arm/komeda : change driver to use drm_writeback_connector.base pointer Kandpal Suraj 2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj 2022-02-02 8:54 ` [PATCH 3/6] drm/vkms: change vkms " Kandpal Suraj 2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj 2022-02-02 8:54 ` [PATCH 4/6] drm/vc4: vc4 driver changes to accommodate changes done in drm_writeback_connector structure Kandpal Suraj 2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj 2022-02-02 8:54 ` [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes Kandpal Suraj 2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj 2022-02-02 12:42 ` Laurent Pinchart 2022-02-02 12:42 ` [Intel-gfx] " Laurent Pinchart 2022-02-02 13:15 ` Jani Nikula 2022-02-02 13:15 ` [Intel-gfx] " Jani Nikula 2022-02-02 13:26 ` Laurent Pinchart 2022-02-02 13:26 ` [Intel-gfx] " Laurent Pinchart 2022-02-02 15:38 ` Jani Nikula 2022-02-02 15:38 ` [Intel-gfx] " Jani Nikula 2022-02-26 18:27 ` Rob Clark 2022-02-26 18:27 ` [Intel-gfx] " Rob Clark 2022-02-28 8:03 ` Laurent Pinchart 2022-02-28 8:03 ` [Intel-gfx] " Laurent Pinchart 2022-02-28 12:09 ` Jani Nikula 2022-02-28 12:09 ` [Intel-gfx] " Jani Nikula 2022-02-28 12:28 ` Laurent Pinchart 2022-02-28 12:28 ` [Intel-gfx] " Laurent Pinchart 2022-02-28 13:42 ` Laurent Pinchart 2022-02-28 13:42 ` [Intel-gfx] " Laurent Pinchart 2022-03-02 18:28 ` Abhinav Kumar 2022-03-02 18:28 ` [Intel-gfx] " Abhinav Kumar 2022-03-02 18:31 ` Laurent Pinchart 2022-03-02 18:31 ` [Intel-gfx] " Laurent Pinchart 2022-03-03 17:32 ` Abhinav Kumar 2022-03-03 17:32 ` [Intel-gfx] " Abhinav Kumar 2022-03-04 9:56 ` Kandpal, Suraj 2022-03-04 9:56 ` [Intel-gfx] " Kandpal, Suraj 2022-03-04 10:39 ` Dmitry Baryshkov 2022-03-04 10:39 ` [Intel-gfx] " Dmitry Baryshkov 2022-03-04 10:47 ` Kandpal, Suraj 2022-03-04 10:47 ` [Intel-gfx] " Kandpal, Suraj 2022-03-04 11:25 ` Dmitry Baryshkov 2022-03-04 11:25 ` [Intel-gfx] " Dmitry Baryshkov 2022-03-04 14:16 ` Kandpal, Suraj 2022-03-04 14:16 ` [Intel-gfx] " Kandpal, Suraj 2022-03-04 20:47 ` Abhinav Kumar 2022-03-04 20:47 ` [Intel-gfx] " Abhinav Kumar 2022-03-08 14:30 ` Kandpal, Suraj 2022-03-08 14:30 ` [Intel-gfx] " Kandpal, Suraj 2022-03-08 19:44 ` Abhinav Kumar [this message] 2022-03-08 19:44 ` Abhinav Kumar 2022-02-06 23:32 ` Dmitry Baryshkov 2022-02-06 23:32 ` [Intel-gfx] " Dmitry Baryshkov 2022-02-07 7:20 ` Abhinav Kumar 2022-02-07 7:20 ` [Intel-gfx] " Abhinav Kumar 2022-02-10 1:40 ` Abhinav Kumar 2022-02-10 1:40 ` [Intel-gfx] " Abhinav Kumar 2022-02-10 4:58 ` Laurent Pinchart 2022-02-10 4:58 ` [Intel-gfx] " Laurent Pinchart 2022-02-22 3:32 ` Dmitry Baryshkov 2022-02-22 3:32 ` [Intel-gfx] " Dmitry Baryshkov 2022-02-22 7:34 ` Laurent Pinchart 2022-02-22 7:34 ` [Intel-gfx] " Laurent Pinchart 2022-02-24 0:27 ` Abhinav Kumar 2022-02-24 0:27 ` [Intel-gfx] " Abhinav Kumar 2022-02-02 13:34 ` Ville Syrjälä 2022-02-02 13:34 ` [Intel-gfx] " Ville Syrjälä 2022-02-02 13:40 ` Dmitry Baryshkov 2022-02-02 13:40 ` [Intel-gfx] " Dmitry Baryshkov 2022-02-02 15:57 ` Jani Nikula 2022-02-02 15:57 ` [Intel-gfx] " Jani Nikula 2022-02-23 6:17 ` Kandpal, Suraj 2022-02-23 6:17 ` [Intel-gfx] " Kandpal, Suraj 2022-02-25 23:26 ` Abhinav Kumar 2022-02-25 23:26 ` [Intel-gfx] " Abhinav Kumar 2022-02-26 5:10 ` Kandpal, Suraj 2022-02-26 5:10 ` [Intel-gfx] " Kandpal, Suraj 2022-02-28 8:00 ` Laurent Pinchart 2022-02-28 8:00 ` [Intel-gfx] " Laurent Pinchart 2022-02-28 8:07 ` Dmitry Baryshkov 2022-02-28 8:07 ` [Intel-gfx] " Dmitry Baryshkov 2022-02-28 8:28 ` Laurent Pinchart 2022-02-28 8:28 ` [Intel-gfx] " Laurent Pinchart 2022-02-02 8:54 ` [PATCH 6/6] drm/arm: changes to malidp " Kandpal Suraj 2022-02-02 8:54 ` [Intel-gfx] " Kandpal Suraj 2022-02-02 10:01 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm writeback connector changes Patchwork 2022-02-02 10:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-02-02 12:22 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4daece94-c438-29dd-ef9d-e4c4c06187c4@quicinc.com \ --to=quic_abhinavk@quicinc.com \ --cc=Laurent.pinchart@ideasonboard.com \ --cc=airlied@linux.ie \ --cc=arun.r.murthy@intel.com \ --cc=carsten.haitzler@arm.com \ --cc=daniel.vetter@ffwll.ch \ --cc=dmitry.baryshkov@linaro.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jani.nikula@intel.com \ --cc=suraj.kandpal@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.