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@xxxxxxxxx/
[2]
https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kandpal@xxxxxxxxx/
[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@xxxxxxxxx/
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(-)
