On Tue, Aug 26, 2025 at 05:48:18PM +0200, mrip...@kernel.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.du...@arm.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
