linux-kernel - Re: [PATCH 08/14] drm/imx: dc: Use TCON operation mode

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: <a4a75e87-ffe4-4660-a1a9-19ab06521a6e@nxp.com>
Date: Mon, 22 Sep 2025 11:48:26 +0800
From: Liu Ying <victor.liu@....com>
To: Frank Li <Frank.li@....com>
Cc: Philipp Zabel <p.zabel@...gutronix.de>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
 Sascha Hauer <s.hauer@...gutronix.de>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, Dmitry Baryshkov <lumag@...nel.org>,
 dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/14] drm/imx: dc: Use TCON operation mode

On 09/19/2025, Frank Li wrote:
> On Fri, Jul 04, 2025 at 05:03:55PM +0800, Liu Ying wrote:
>> In TCON operation mode, sync signals from FrameGen are ignored, but
>> a much more customized output timing can be generated by the TCON
>> module.  By using TCON operaton mode, generate KACHUNK signal along
>> with HSYNC/VSYNC/data enable signals.  The KACHUNK signal is used as
>> a synchronization signal inside the prefetch engine(DPRC + PRG(s),
>> attached to FetchUnit(s)).  Carefully switch TCON bypass mode to TCON
>> operation mode when CRTC is being enabled so that the prefetch engine
>> may evade the first dumb frame generated by the display controller.
>>
>> Since TCON BYPASS bit is controlled by KMS driver when doing atomic
>> commits, drop the bit setting when initializing TCON.  This also
>> avoids accidentally initializing TCON BYPASS bit to 1 when driver
>> module removing and re-installing where an upcoming patch would
>> disable a CRTC at boot in TCON operation mode if needed.
>>
>> Signed-off-by: Liu Ying <victor.liu@....com>
>> ---
>>  drivers/gpu/drm/imx/dc/dc-crtc.c |  28 ++++++++++
>>  drivers/gpu/drm/imx/dc/dc-de.h   |   2 +
>>  drivers/gpu/drm/imx/dc/dc-kms.h  |   2 +
>>  drivers/gpu/drm/imx/dc/dc-tc.c   | 114 +++++++++++++++++++++++++++++++++++++--
>>  4 files changed, 142 insertions(+), 4 deletions(-)
>>
> ...
>> @@ -249,6 +260,7 @@ dc_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state)
>>  	enable_irq(dc_crtc->irq_ed_safe_shdload);
>>
>>  	dc_fg_cfg_videomode(dc_crtc->fg, adj);
>> +	dc_tc_cfg_videomode(dc_crtc->tc, adj);
>>
>>  	dc_cf_framedimensions(dc_crtc->cf_cont,
>>  			      adj->crtc_hdisplay, adj->crtc_vdisplay);
>> @@ -273,7 +285,22 @@ dc_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state *state)
>>  	dc_ed_pec_sync_trigger(dc_crtc->ed_cont);
>>  	dc_ed_pec_sync_trigger(dc_crtc->ed_safe);
>>  	dc_fg_shdtokgen(dc_crtc->fg);
>> +
>> +	/* Don't relinquish CPU until TCON is set to operation mode. */
>> +	local_irq_save(flags);
>> +	preempt_disable();
>> +
>>  	dc_fg_enable(dc_crtc->fg);
>> +	/*
>> +	 * Turn TCON into operation mode as soon as the first dumb
>> +	 * frame is generated by DC(we don't relinquish CPU to ensure
>> +	 * this).  This makes DPR/PRG be able to evade the frame.
>> +	 */
>> +	DC_CRTC_WAIT_FOR_FRAMEGEN_FRAME_INDEX_MOVING(dc_crtc->fg);
>> +	dc_tc_set_operation_mode(dc_crtc->tc);
>> +
>> +	local_irq_restore(flags);
>> +	preempt_enable();
> 
> Does it need reverised order?

I'm referring to __raw_spin_lock_irqsave() and __raw_spin_unlock_irqrestore()
to do this right, where local IRQ is saved/restored prior to preemption
disablement/enablement.  Am I missing anything?

> 
>>
>>  	DC_CRTC_WAIT_FOR_COMPLETION_TIMEOUT(ed_safe_shdload_done);
>>  	DC_CRTC_WAIT_FOR_COMPLETION_TIMEOUT(ed_cont_shdload_done);
>> @@ -561,6 +588,7 @@ int dc_crtc_init(struct dc_drm_device *dc_drm, int crtc_index)
>>  	dc_crtc->ed_cont = pe->ed_cont[crtc_index];
>>  	dc_crtc->ed_safe = pe->ed_safe[crtc_index];
>>  	dc_crtc->fg = de->fg;
>> +	dc_crtc->tc = de->tc;
>>
>>  	dc_crtc->irq_dec_framecomplete = de->irq_framecomplete;
>>  	dc_crtc->irq_dec_seqcomplete = de->irq_seqcomplete;
>> diff --git a/drivers/gpu/drm/imx/dc/dc-de.h b/drivers/gpu/drm/imx/dc/dc-de.h
>> index 211f3fcc1a9ad642617d3b22e35ea923f75e645b..c39f2ef5eea98c3eb6ae9b5392f9bf9f7e33e7c5 100644
>> --- a/drivers/gpu/drm/imx/dc/dc-de.h
>> +++ b/drivers/gpu/drm/imx/dc/dc-de.h
>> @@ -54,6 +54,8 @@ enum drm_mode_status dc_fg_check_clock(struct dc_fg *fg, int clk_khz);
>>  void dc_fg_init(struct dc_fg *fg);
>>
> ...
> 
>>
>> --
>> 2.34.1
>>


-- 
Regards,
Liu Ying