[PATCH v7 13/20] drm/mediatek: Add programming flow for unsupported subsys ID hardware

[Jason-JH Lin (林睿祥)]

Hi CK, Angelo,

Thanks for the review.

On Thu, 2025-10-09 at 13:54 +0200, AngeloGioacchino Del Regno wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> Il 27/08/25 13:37, Jason-JH Lin ha scritto:
> > To support hardware without subsys IDs on new SoCs, add a
> > programming
> > flow that checks whether the subsys ID is valid.
> > 
> > If the subsys ID is valid, the flow will call
> > cmdq_pkt_write_subsys()
> > instead of the original cmdq_pkt_write().
> > 
> > If the subsys ID is invalid, the flow will call
> > cmdq_pkt_write_mask_pa()
> > to achieve the same functionality.
> > 
> > Signed-off-by: Jason-JH Lin <jason-jh.lin at mediatek.com>
> 
> In mediatek-drm and in mtk-mdp3 the performance of mtk_ddp_write is
> important: in
> both, there are ways to know whether a platform is expected to always
> use the
> cmdq_pkt_write_mask_pa() or the subsys() one.
> 
> Please check what platform is this driver running on - based on the
> platform, you
> can assign a function pointer, so that you always call it like
> 
> priv->write_cmdq_pkt(cmdq_pkt, cmdq_reg, ofst, val, mask);
> 
> write_cmdq_pkt() could point to, either:
> 1. A function that checks if subsys != CMDQ_SUBSYS_INVALID, for
> platforms that
>     are expected to have mixed PA *and* SUBSYS (hopefully none!!!);
> or
> 2. The cmdq_pkt_write_mask_subsys() function; or
> 3. The cmdq_pkt_write_mask_pa() function.
> 

I'll also assign cmdq_pkt_write_subsys() and cmdq_pkt_write_pa() to
increase more flexibility for DRM drivers.

> This removes lots and lots of branches at every call.
> 
> I want to remind you that CMDQ packets are being generated in many
> cases in the
> mediatek-drm driver, one of which is upon VBLANK; Think of the case
> in which we
> are driving a high refresh rate display (>=120Hz): not just in DSI
> Video mode
> for which we manage just only vblanks and data pumping (which still
> needs quite
> a bit of GCE writes).. but something like DSI CMD mode would probably
> generate
> *a myriad* of GCE calls.... and that is only one of the cases, there
> are more
> that don't involve specifically DSI.
> 

Thanks! I agree with your insight suggestion.
I'll try to reduce this `if (subsys != CMDQ_SUBSYS_INVALID)` branch and
create a function hook for ddp_comp and assign the corresponding
function by platforms at the initialization phase.

> Of course, for mtk-mdp3 there's a different story - but I guess it's
> useless to
> add a specific example for that, I'm sure you got the point here.
> 

I'll check if I can apply this thought into mtk-mdp3. Thanks!

Regards,
Jason-JH Lin

> Cheers,
> Angelo