From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>,
kernel-list@raspberrypi.com, amd-gfx@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, ankit.k.nautiyal@intel.com,
arun.r.murthy@intel.com, uma.shankar@intel.com,
jani.nikula@intel.com, harry.wentland@amd.com,
siqueira@igalia.com, alexander.deucher@amd.com,
christian.koenig@amd.com, airlied@gmail.com, simona@ffwll.ch,
liviu.dudau@arm.com, maarten.lankhorst@linux.intel.com,
mripard@kernel.org, robin.clark@oss.qualcomm.com,
abhinav.kumar@linux.dev, tzimmermann@suse.de,
jessica.zhang@oss.qualcomm.com, sean@poorly.run,
marijn.suijten@somainline.org, mcanal@igalia.com,
dave.stevenson@raspberrypi.com,
tomi.valkeinen+renesas@ideasonboard.com,
kieran.bingham+renesas@ideasonboard.com,
louis.chauvet@bootlin.com
Subject: Re: [RFC PATCH 1/8] drm: writeback: Refactor drm_writeback_connector structure
Date: Mon, 11 Aug 2025 14:15:46 +0300 [thread overview]
Message-ID: <20250811111546.GA30760@pendragon.ideasonboard.com> (raw)
In-Reply-To: <awtqznhquyn7etojonmjn7karznefsb7fdudawcjsj5g2bok3u@2iqcdviuiz2s>
On Mon, Aug 11, 2025 at 01:22:30PM +0300, Dmitry Baryshkov wrote:
> On Mon, Aug 11, 2025 at 12:44:29PM +0300, Laurent Pinchart wrote:
> > On Mon, Aug 11, 2025 at 02:57:00PM +0530, Suraj Kandpal wrote:
> > > Some drivers cannot work with the current design where the connector
> > > is embedded within the drm_writeback_connector such as intel and
> > > some drivers that can get it working end up adding a lot of checks
> > > all around the code to check if it's a writeback conenctor or not.
> > > To solve this we move the drm_writeback_connector within the
> > > drm_connector and remove the drm_connector base which was in
> > > drm_writeback_connector. We do all other required
> > > modifications that come with these changes along with addition
> > > of new function which returns the drm_connector when
> > > drm_writeback_connector is present.
> > > All drivers will be expected to allocate the drm_connector.
> > >
> > > Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
> > > ---
> > > drivers/gpu/drm/drm_writeback.c | 33 ++++++++++------
> > > include/drm/drm_connector.h | 60 +++++++++++++++++++++++++++++
> > > include/drm/drm_writeback.h | 68 ++++-----------------------------
> > > 3 files changed, 89 insertions(+), 72 deletions(-)
> > >
> > > @@ -2305,6 +2360,11 @@ struct drm_connector {
> > > * @cec: CEC-related data.
> > > */
> > > struct drm_connector_cec cec;
> > > +
> > > + /**
> > > + * @writeback: Writeback related valriables.
> > > + */
> > > + struct drm_writeback_connector writeback;
> >
> > No, sorry, that's a bad idea. Most connectors have nothing to do with
> > writeback, you shouldn't introduce writeback-specific fields here.
> > drm_writeback_connector happens to be a drm_connector because of
> > historical reasons (it was decided to reuse the connector API exposed to
> > userspace instead of exposing a completely separate API in order to
> > simplify the implementation), but that does not mean that every
> > connector is related to writeback.
> >
> > I don't know what issues the Intel driver(s) have with
> > drm_writeback_connector, but you shouldn't make things worse for
> > everybody due to a driver problem.
>
> Suraj is trying to solve a problem that in Intel code every drm_connector
> must be an intel_connector too. His previous attempt resulted in a loose
> abstraction where drm_writeback_connector.base wasn't initialized in
> some cases (which is a bad idea IMO).
>
> I know the historical reasons for drm_writeback_connector, but I think
> we can do better now.
>
> So, I think, a proper approach would be:
>
> struct drm_connector {
> // other fields
>
> union {
> struct drm_connector_hdmi hdmi; // we already have it
> struct drm_connector_wb wb; // this is new
> };
>
> // rest of the fields.
> };
I still don't like that. This really doesn't belong here. If anything,
the drm_connector for writeback belongs to drm_crtc.
If the issue is that some drivers need a custom drm_connector subclass,
then I'd rather turn the connector field of drm_writeback_connector into
a pointer.
> I plan to add drm_connector_dp in a similar way, covering DP needs
> (currently WIP).
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2025-08-11 11:16 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 9:26 [RFC PATCH 0/8] Refactor drm_writeback_connector structure Suraj Kandpal
2025-08-11 9:27 ` [RFC PATCH 1/8] drm: writeback: " Suraj Kandpal
2025-08-11 9:44 ` Laurent Pinchart
2025-08-11 10:22 ` Dmitry Baryshkov
2025-08-11 11:15 ` Laurent Pinchart [this message]
2025-08-11 11:19 ` Kandpal, Suraj
2025-08-11 13:26 ` Dmitry Baryshkov
2025-08-13 10:04 ` Kandpal, Suraj
2025-08-13 12:00 ` Laurent Pinchart
2025-08-14 16:13 ` liviu.dudau
2025-08-15 22:20 ` Dmitry Baryshkov
2025-08-19 9:03 ` mripard
2025-08-25 6:26 ` Kandpal, Suraj
2025-08-25 9:26 ` Dmitry Baryshkov
2025-08-26 15:48 ` mripard
2025-08-26 16:08 ` Dmitry Baryshkov
2025-08-27 6:34 ` mripard
2025-08-11 11:16 ` Kandpal, Suraj
2025-08-11 10:13 ` Dmitry Baryshkov
2025-08-11 11:12 ` Kandpal, Suraj
2025-08-11 10:28 ` Dmitry Baryshkov
2025-08-11 11:14 ` Kandpal, Suraj
2025-08-11 9:27 ` [RFC PATCH 2/8] drm/amd/display: Adapt amd writeback to new drm_writeback_connector Suraj Kandpal
2025-08-11 9:27 ` [RFC PATCH 3/8] drm/arm/komeda: Adapt komeda " Suraj Kandpal
2025-08-11 9:27 ` [RFC PATCH 4/8] drm/arm/mali: Adapt mali " Suraj Kandpal
2025-08-11 9:27 ` [RFC PATCH 5/8] drm/vc4: Adapt vc4 " Suraj Kandpal
2025-08-11 9:27 ` [RFC PATCH 6/8] drm/vkms: Adapt vkms " Suraj Kandpal
2025-08-11 9:51 ` Louis Chauvet
2025-08-11 11:23 ` Kandpal, Suraj
2025-08-11 14:33 ` Louis Chauvet
2025-08-11 9:27 ` [RFC PATCH 7/8] drm/rcar_du: " Suraj Kandpal
2025-08-11 9:40 ` Laurent Pinchart
2025-08-11 9:47 ` Kandpal, Suraj
2025-08-11 9:46 ` Louis Chauvet
2025-08-11 9:27 ` [RFC PATCH 8/8] drm/msm/dpu: Adapt dpu " Suraj Kandpal
2025-08-11 10:26 ` Dmitry Baryshkov
2025-08-11 11:15 ` Kandpal, Suraj
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=20250811111546.GA30760@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ankit.k.nautiyal@intel.com \
--cc=arun.r.murthy@intel.com \
--cc=christian.koenig@amd.com \
--cc=dave.stevenson@raspberrypi.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=jessica.zhang@oss.qualcomm.com \
--cc=kernel-list@raspberrypi.com \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=louis.chauvet@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=mcanal@igalia.com \
--cc=mripard@kernel.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=suraj.kandpal@intel.com \
--cc=tomi.valkeinen+renesas@ideasonboard.com \
--cc=tzimmermann@suse.de \
--cc=uma.shankar@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).