Re: [PATCH v6 11/11] drm/mediatek: Add Write DMA (WDMA) Engine for Writeback support

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

On 8/27/26 07:33, CK Hu (胡俊光) wrote:
> On Wed, 2026-07-15 at 15:57 +0200, AngeloGioacchino Del Regno wrote:
>> Add a basic driver for the Write DMA Engine and initial compatible
>> for the MediaTek MT8173 and MediaTek Dimensity 1200 MT6893, and
>> hook it up to the mtk_ddp_comp and mtk_drm_drv in order for it to
>> probe.
>>
>> This display controller component is used to enable the writeback
>> engine that can be used for faster display image capturing in the
>> userspace (for example, screenshots and screen recording).
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> ---
>>   
>> +static const struct mtk_ddp_comp_funcs ddp_wdma = {
>> +	.clk_enable = mtk_wdma_clk_enable,
>> +	.clk_disable = mtk_wdma_clk_disable,
>> +	.config = mtk_wdma_config,
>> +	.start = mtk_wdma_start,
>> +	.stop = mtk_wdma_stop,
>> +	.register_vblank_cb = mtk_wdma_register_vblank_cb,
>> +	.unregister_vblank_cb = mtk_wdma_unregister_vblank_cb,
>> +	.enable_vblank = mtk_wdma_enable_vblank,
>> +	.disable_vblank = mtk_wdma_disable_vblank,
>> +	.layer_nr = mtk_wdma_layer_nr,
>> +	.layer_config = mtk_wdma_layer_config,
>> +	.get_formats = mtk_wdma_get_formats,
>> +	.get_num_formats = mtk_wdma_get_num_formats,
> 
> I does not see you modify mtk crtc.
> mtk crtc would use some interface only on 'first' ddp component of a pipeline.
> WDMA would not be the first component,
> so register_vblank_cb, unregister_vblank_cb, enable_vblank, disable_vblank, layer_nr, layer_config, get_formats, and get_num_formats are useless.

It's true in this specific case, but this was done while performing the big
mediatek-drm restructuring.

I decided to split the full changes in two separate series, because the one
restructuring mediatek-drm is literally huge... and this series is adding
only things that can be applied before the full restructuring takes place.

That was done in order to speed up the upstreaming and nothing else - so you
can safely ignore the fact that there is extra functionality in this driver,
because those extras will be used once the other big series is merged.

It's a lot of code, please-please-please don't make me split things up even
more, because then the commit log becomes messy :-)

As for the comments on 8189/8196 (link rate and qos), you're right in that it
makes sense to split the algo additions from the soc addition: I've done that
already and will come in v7.

Cheers,
Angelo