Message-ID: <76cmo6pqa534cdnckfgsnspczenzt7kiwkpgg4olxysjn2can7@g5dxteqi5jjs>
Date: Tue, 26 Aug 2025 19:08:17 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: "mripard@...nel.org" <mripard@...nel.org>
Cc: "Kandpal, Suraj" <suraj.kandpal@...el.com>,
        "liviu.dudau@....com" <liviu.dudau@....com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        "kernel-list@...pberrypi.com" <kernel-list@...pberrypi.com>,
        "amd-gfx@...ts.freedesktop.org" <amd-gfx@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "freedreno@...ts.freedesktop.org" <freedreno@...ts.freedesktop.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "intel-xe@...ts.freedesktop.org" <intel-xe@...ts.freedesktop.org>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "Nautiyal, Ankit K" <ankit.k.nautiyal@...el.com>,
        "Murthy, Arun R" <arun.r.murthy@...el.com>,
        "Shankar, Uma" <uma.shankar@...el.com>,
        "Nikula, Jani" <jani.nikula@...el.com>,
        "harry.wentland@....com" <harry.wentland@....com>,
        "siqueira@...lia.com" <siqueira@...lia.com>,
        "alexander.deucher@....com" <alexander.deucher@....com>,
        "christian.koenig@....com" <christian.koenig@....com>,
        "airlied@...il.com" <airlied@...il.com>,
        "simona@...ll.ch" <simona@...ll.ch>,
        "maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
        "robin.clark@....qualcomm.com" <robin.clark@....qualcomm.com>,
        "abhinav.kumar@...ux.dev" <abhinav.kumar@...ux.dev>,
        "tzimmermann@...e.de" <tzimmermann@...e.de>,
        "jessica.zhang@....qualcomm.com" <jessica.zhang@....qualcomm.com>,
        "sean@...rly.run" <sean@...rly.run>,
        "marijn.suijten@...ainline.org" <marijn.suijten@...ainline.org>,
        "mcanal@...lia.com" <mcanal@...lia.com>,
        "dave.stevenson@...pberrypi.com" <dave.stevenson@...pberrypi.com>,
        "tomi.valkeinen+renesas@...asonboard.com" <tomi.valkeinen+renesas@...asonboard.com>,
        "kieran.bingham+renesas@...asonboard.com" <kieran.bingham+renesas@...asonboard.com>,
        "louis.chauvet@...tlin.com" <louis.chauvet@...tlin.com>
Subject: Re: [RFC PATCH 1/8] drm: writeback: Refactor drm_writeback_connector
 structure

On Tue, Aug 26, 2025 at 05:48:18PM +0200, mripard@...nel.org wrote:
> On Mon, Aug 25, 2025 at 06:26:48AM +0000, Kandpal, Suraj wrote:
> > > Subject: Re: [RFC PATCH 1/8] drm: writeback: Refactor
> > > drm_writeback_connector structure
> > > 
> > > Hi,
> > > 
> > > On Sat, Aug 16, 2025 at 01:20:53AM +0300, Dmitry Baryshkov wrote:
> > > > On Thu, Aug 14, 2025 at 05:13:54PM +0100, liviu.dudau@....com wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, Aug 13, 2025 at 10:04:22AM +0000, Kandpal, Suraj wrote:
> > > > > > > > > };
> > > > > > > >
> > > > > > > > I still don't like that. This really doesn't belong here. If
> > > > > > > > anything, the drm_connector for writeback belongs to drm_crtc.
> > > > > > >
> > > > > > > Why? We already have generic HDMI field inside drm_connector. I
> > > > > > > am really hoping to be able to land DP parts next to it. In
> > > > > > > theory we can have a DVI- specific entry there (e.g. with the
> > > subconnector type).
> > > > > > > The idea is not to limit how the drivers subclass those structures.
> > > > > > >
> > > > > > > I don't see a good case why WB should deviate from that design.
> > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > Having a pointer requires additional ops in order to get
> > > > > > > drm_connector from WB code and vice versa. Having
> > > > > > > drm_connector_wb inside drm_connector saves us from those ops
> > > (which don't manifest for any other kind of structure).
> > > > > > > Nor will it take any more space since union will reuse space
> > > > > > > already taken up by HDMI part.
> > > > > > >
> > > > > > > >
> > > > > >
> > > > > > Seems like this thread has died. We need to get a conclusion on the
> > > design.
> > > > > > Laurent do you have any issue with the design given Dmitry's
> > > > > > explanation as to why this Design is good for drm_writeback_connector.
> > > > >
> > > > > I'm with Laurent here. The idea for drm_connector (and a lot of drm
> > > > > structures) are to be used as base "classes" for extended
> > > > > structures. I don't know why HDMI connector ended up inside
> > > > > drm_connector as not all connectors have HDMI functionality, but that's a
> > > cleanup for another day.
> > > >
> > > > Maybe Maxime can better comment on it, but I think it was made exactly
> > > > for the purpose of not limiting the driver's design. For example, a
> > > > lot of drivers subclass drm_connector via drm_bridge_connector. If
> > > > struct drm_connector_hdmi was a wrapper around struct drm_connector,
> > > > then it would have been impossible to use HDMI helpers for bridge
> > > > drivers, while current design freely allows any driver to utilize
> > > > corresponding library code.
> > > 
> > > That's exactly why we ended up like this. With that design, we wouldn't have
> > > been able to "inherit" two connector "classes": bridge_connector is one,
> > > intel_connector another one.
> > > 
> > > See here for the rationale:
> > > https://lore.kernel.org/dri-devel/ZOTDKHxn2bOg+Xmg@phenom.ffwll.local/
> > > 
> > > I don't think the "but we'll bloat drm_connector" makes sense either.
> > > There's already a *lot* of things that aren't useful to every connector (fwnode,
> > > display_info, edid in general, scaling, vrr, etc.)
> > > 
> > > And it's not like we allocate more than a handful of them during a system's life.
> > 
> > So Are we okay with the approach mentioned here with the changes that have been proposed here like
> > Having drm_writeback_connector in union with drm_hdmi_connector
> 
> I don't think we need a union here. It artificially creates the same
> issue: we can't have two types for a connector if we do so.

Well... What kind of connector would be both HDMI and WriteBack? I think
they are mutually exclusive already.

> > Also one more thing I would like to clarify here is how everyone would
> > like the patches patches where each patch changes both the drm core
> > and all related drivers (ensures buildability but then review is tough
> > for each driver). Or patches where we have initial drm core changes
> > and then each patch does the all changes in a driver in its own
> > respective patch.
> 
> The latter should be preferred, but if you can't maintain bisectability
> that way, then it's the most important and you should fall back to the
> former.

I'd say, we should be trying our best in providing bisectability. It
really a PITA if one can not use `git bisect run`.

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists