[PATCH v2 0/6] Allow drm_writeback_connector to accept pointer to drm_encoder

[Abhinav Kumar]

Hi Dmitry

On 3/16/2022 12:40 AM, Dmitry Baryshkov wrote:
> Hi Abhinav,
> 
> On 16/03/2022 02:11, Abhinav Kumar wrote:
>> There are some vendor drivers for which the writeback encoder shares
>> hardware resources such as clocks and interrupts with the rest of the
>> display pipeline. In addition, there can be use-cases where the
>> writeback encoder could be a shared encoder between the physical display
>> path and the writeback path.
>>
>> To accommodate for such cases, change the drm_writeback_connector to
>> accept a pointer to drm_encoder.
>>
>> For existing users of drm_writeback_connector there will not be any
>> change in functionality due to this change.
>>
>> This approach was first posted by Suraj Kandpal here [1] for both
>> encoder and connector. But after discussions [2], the consensus was
>> reached to split this change for the drm_encoder first and the
>> drm_connector part can be reworked in a subsequent change later.
>>
>> Validation of this change was done using igt_writeback tests on
>> MSM based RB5 board using the changes posted here [3].
>>
>> For all other chipsets, these changes were compile-tested.
>>
>> [1] 
>> https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kandpal@intel.com/ 
>>
>> [2] 
>> https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kandpal@intel.com/ 
>>
>> [3] https://patchwork.freedesktop.org/series/99724/
>>
>> changes in v2:
>>      - introduce a new API drm_writeback_connector_init_with_encoder()
>>      - allow passing possible_crtcs for existing users of
>>        drm_writeback_connector_init()
>>
>> Abhinav Kumar (6):
>>    drm: allow real encoder to be passed for drm_writeback_connector
>>    drm/komeda: pass possible_crtcs as parameter for
>>      drm_writeback_connector
>>    drm/vkms: pass possible_crtcs as parameter for drm_writeback_connector
>>    drm/vc4: change vc4 driver to use
>>      drm_writeback_connector_init_with_encoder()
>>    drm/rcar_du: pass possible_crtcs as parameter for
>>      drm_writeback_connector
>>    drm/malidp: pass possible_crtcs as parameter for
>>      drm_writeback_connector
> 
> I think we expect that at each commit point the kernel should be 
> compilable. Could you please squash patches accordingly?
> 
> I'd suggest the following patch sequence:
> 
> - Add possible_crtcs to the drm_writeback_connector_init() including all 
> the driver changes (all drivers must be compilable, including vc4)
> - Add drm_writeback_connector_init_with_encoder()
> - Modify vc4 to use new API
> 
> WDYT?

Yes I also thought if each commit point should be compilable.
The way this started out was that in the original series 
https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kandpal@intel.com/ 
every commit was separated vendor-wise even though it will not compile 
individually.

So I thought that, for ease of code-review perhaps it was alright to 
separate it that way so that individual vendors can review separately.

But if we need to make each of the commits compilable we will have to 
squash the way you have mentioned.

> 
>>
>>   .../drm/arm/display/komeda/komeda_wb_connector.c   |   3 +-
>>   drivers/gpu/drm/arm/malidp_mw.c                    |   5 +-
>>   drivers/gpu/drm/drm_writeback.c                    | 144 
>> +++++++++++++++------
>>   drivers/gpu/drm/rcar-du/rcar_du_writeback.c        |   5 +-
>>   drivers/gpu/drm/vc4/vc4_txp.c                      |  30 ++++-
>>   drivers/gpu/drm/vkms/vkms_writeback.c              |   3 +-
>>   include/drm/drm_writeback.h                        |  27 +++-
>>   7 files changed, 161 insertions(+), 56 deletions(-)
>>
> 
>