linux-kernel - Re: [PATCH v8 14/16] drm/mediatek: Support CRC in display driver

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]

Date: Fri, 21 Jun 2024 07:27:24 +0000
From: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>
To: CK Hu (胡俊光) <ck.hu@...iatek.com>,
	Shawn Sung (宋孝謙) <Shawn.Sung@...iatek.com>,
	"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	Bibby Hsieh (謝濟遠) <Bibby.Hsieh@...iatek.com>,
	"jason-ch.chen@...iatek.corp-partner.google.com"
	<jason-ch.chen@...iatek.corp-partner.google.com>,
	Nancy Lin (林欣螢) <Nancy.Lin@...iatek.com>,
	"daniel@...ll.ch" <daniel@...ll.ch>, "p.zabel@...gutronix.de"
	<p.zabel@...gutronix.de>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "airlied@...il.com" <airlied@...il.com>,
	"sean@...rly.run" <sean@...rly.run>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>, "fshao@...omium.org" <fshao@...omium.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
	"angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH v8 14/16] drm/mediatek: Support CRC in display driver

Hi CK,

On Wed, 2024-06-12 at 01:22 +0000, CK Hu (胡俊光) wrote:
> Hi, Shawn:
> 
> On Thu, 2024-06-06 at 17:26 +0800, Shawn Sung wrote:
> > From: Hsiao Chien Sung <shawn.sung@...iatek.com>
> > 
> > Register CRC related function pointers to support
> > CRC retrieval.
> > 
> > Signed-off-by: Hsiao Chien Sung <shawn.sung@...iatek.com>
> > ---
> 
> [snip]
> 
> > 
> > +static void mtk_crtc_crc_work(struct kthread_work *base)
> > +{
> > +	struct drm_vblank_work *work = to_drm_vblank_work(base);
> > +	struct mtk_crtc *mtk_crtc =
> > +		container_of(work, typeof(*mtk_crtc), crc_work);
> > +	struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
> > +
> > +	if (!comp) {
> > +		DRM_WARN("%s(crtc-%d): no crc provider\n",
> > +			 __func__, drm_crtc_index(&mtk_crtc->base));
> > +		return;
> > +	}
> > +
> > +	if (mtk_crtc->base.crc.opened) {
> > +		u64 vblank = drm_crtc_vblank_count(&mtk_crtc->base);
> > +
> > +		comp->funcs->crc_read(comp->dev);
> > +
> > +		/* could take more than 50ms to finish */
> > +		drm_crtc_add_crc_entry(&mtk_crtc->base, true, vblank,
> > +				       comp->funcs->crc_entry(comp-
> > >dev));
> 
> It seems that you could regenerate cmdq packet for crc here. So crtc
> atomic flush and crc could use the same mailbox channel.
> 
> Regards,
> CK
> 
It seems that it's possible to call mtk_ddp_update_config() here and
add a new pending_read_crc flag to insert the read crc related
instructions into the same cmdq_pkt and use the same mailbox channel as
atomic flush.

I'll try this, but I'll need some time to modify this and test it to 
make sure no other issues arise.

Regards,
Jason-Jh Lin

> > +
> > +		drm_vblank_work_schedule(&mtk_crtc->crc_work, vblank +
> > 1, true);
> > +	} else {
> > +		comp->funcs->crc_stop(comp->dev);
> > +	}
> > +}
> > +