linux-kernel - Re: [PATCH] drm/mediatek: Add wait_event

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPj87rNV_48pQF+gv3HEx+-n1WvKOoX2u_HRW5w8DrgEAigk9w@mail.gmail.com>
Date: Sat, 24 May 2025 13:47:13 +0100
From: Daniel Stone <daniel@...ishbar.org>
To: Jason-JH Lin <jason-jh.lin@...iatek.com>
Cc: Chun-Kuang Hu <chunkuang.hu@...nel.org>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, 
	Nancy Lin <nancy.lin@...iatek.com>, Singo Chang <singo.chang@...iatek.com>, 
	Paul-PL Chen <paul-pl.chen@...iatek.com>, Yongqiang Niu <yongqiang.niu@...iatek.com>, 
	Zhenxing Qin <zhenxing.qin@...iatek.com>, Sirius Wang <sirius.wang@...iatek.com>, 
	Xavier Chang <xavier.chang@...iatek.com>, Fei Shao <fshao@...omium.org>, 
	Chen-yu Tsai <wenst@...omium.org>, dri-devel@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org, 
	linux-arm-kernel@...ts.infradead.org, 
	Project_Global_Chrome_Upstream_Group@...iatek.com
Subject: Re: [PATCH] drm/mediatek: Add wait_event_timeout when disabling plane

Hi Jason,

On Thu, 22 May 2025 at 09:52, Jason-JH Lin <jason-jh.lin@...iatek.com> wrote:
> Our hardware registers are set through GCE, not by the CPU.
> DRM might assume the hardware is disabled immediately after calling
> atomic_disable() of drm_plane, but it is only truly disabled after the
> GCE IRQ is triggered.
>
> Additionally, the cursor plane in DRM uses async_commit, so DRM will
> not wait for vblank and will free the buffer immediately after calling
> atomic_disable().
>
> To prevent the framebuffer from being freed before the layer disable
> settings are configured into the hardware, which can cause an IOMMU
> fault error, a wait_event_timeout has been added to wait for the
> ddp_cmdq_cb() callback,indicating that the GCE IRQ has been triggered.

Waiting up to 500ms for each plane to be disabled is ... not ideal.
Especially as multiple planes can be disabled at once. This may happen
dynamically during runtime, e.g. when a video is playing and a user
moves their cursor over the plane to make the UI controls visible.

I think this should be handled through the atomic_commit() handler,
with asynchronous tracking of the state, instead of the hard block
here.

Cheers,
Daniel