Hi Dmitry, Thanks for your comments
Could you please clarify, why do you want to use intel_connector for the writeback connector? I can see a usecase for sharing an encoder between the display and writback pipelines (and if I'm not mistaken, this is the case for Abhinav's case). However, sharing the hardware-backed connector and writeback connector sounds like a sign of a loose abstraction for me.
Please correct me if I'm wrong and Intel driver would really benefit from reusing intel_connector as a base for drm_writeback_connector.
The thing is drm_writeback_connector contains drm_connector and drm_encoder fields which get initialized when we call drm_writeback_connector_init adding the connector to the list of connectors for the drm_device. Now if I decide not to wrap drm_writeback_connector with intel_connector the issue is I'll have to add a lot of checks all over the driver to see if the drm_connector is actually present inside intel_connector or not. I don’t see the point of not having drm_writeback_ connector as even though it’s a faux connector we still treat is as a connector and it would be better for us to use intel_connector for writeback_connector. Also the current drm_writeback_connector structure kind of restricts drivers consequently dictating how they implement their writeback functionality, as a midlayer I don't feel that would be the right approach as drivers should have the freedom to develop their own flow to implement the functionality and use the midlayer as a helper to get that done.
Best Regards, Suraj Kandpal