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.

drm_writeback_connector uses the 'base' drm_connector only for a few things, 
mostly in
__drm_writeback_connector_init() and prepare_job()/cleanup_job(). In _init() we 
just setup
the properties and the encoder after we disable interlacing. 
prepare_job()/cleanup_job()
is another workaround to be to some custom ops some drivers might want for 
signalling. So
we should be able to convert the 'base' drm_connector to a pointer relatively 
easy. We shouldn't
need to get to the drm_connector from a drm_writeback_connector() outside 
drm_writeback.c.

Then it looks like what we need is a 
__drm_writeback_connector_init_with_connector() where we
can pass a base pointer and remember it. Maybe an extra parameter to existing 
init functions,
or a new one that skips the encoder initialisation entirely.

Best regards,
Liviu


> 
> Regards,
> Suraj Kandpal
> 
> > > > I plan to add drm_connector_dp in a similar way, covering DP needs
> > > > (currently WIP).
> > 
> > --
> > With best wishes
> > Dmitry

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Reply via email to