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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <41434fa60f587291cf5b98f7e385dc3a9360e6e3.camel@mediatek.com>
Date: Mon, 13 Oct 2025 11:29:50 +0000
From: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>
To: "robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, AngeloGioacchino Del Regno
	<angelogioacchino.delregno@...labora.com>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "mchehab@...nel.org" <mchehab@...nel.org>,
	"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
	"jassisinghbrar@...il.com" <jassisinghbrar@...il.com>
CC: "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	Sirius Wang (王皓昱) <Sirius.Wang@...iatek.com>,
	Moudy Ho (何宗原) <Moudy.Ho@...iatek.com>,
	Nancy Lin (林欣螢) <Nancy.Lin@...iatek.com>,
	Xiandong Wang (王先冬)
	<Xiandong.Wang@...iatek.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "nicolas@...fresne.ca"
	<nicolas@...fresne.ca>, Paul-pl Chen (陳柏霖)
	<Paul-pl.Chen@...iatek.com>, "linux-mediatek@...ts.infradead.org"
	<linux-mediatek@...ts.infradead.org>, Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@...iatek.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"fshao@...omium.org" <fshao@...omium.org>,
	Singo Chang (張興國) <Singo.Chang@...iatek.com>,
	"wenst@...omium.org" <wenst@...omium.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>
Subject: Re: [PATCH v7 13/20] drm/mediatek: Add programming flow for
 unsupported subsys ID hardware

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@...iatek.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