linux-kernel - Re: [PATCH] drm/tidss: Set crtc modesetting parameters with adjusted 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] [day] [month] [year] [list]

Message-ID: <d6ac1fe1-eeac-430c-ada6-d19386781b53@ideasonboard.com>
Date: Tue, 24 Jun 2025 14:47:02 +0300
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Jayesh Choudhary <j-choudhary@...com>, jyri.sarha@....fi,
 dri-devel@...ts.freedesktop.org, devarsht@...com
Cc: maarten.lankhorst@...ux.intel.com, mripard@...nel.org,
 tzimmermann@...e.de, airlied@...il.com, simona@...ll.ch,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/tidss: Set crtc modesetting parameters with adjusted
 mode

Hi,

On 24/06/2025 11:04, Jayesh Choudhary wrote:
> TIDSS uses crtc_* fields to propagate its registers and set the
> clock rates. So set the CRTC modesetting timing parameters with
> the adjusted mode when needed, to set correct values.
> 
> Cc: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
> Signed-off-by: Jayesh Choudhary <j-choudhary@...com>
> ---
> 
> Hello All,
> 
> After the DSI fixes[0], TIDSS is using crtc_* timings while programming
> hardware[1]. But while testing on TI's J784S4-EVM platform, I noticed
> that crtc_timings are not propagated properly.
> 
> The display pipeline there looks like:
> TIDSS -> CDNS-DSI -> SN65DSI86 bridge -> DisplayPort
> 
> Consider the case of 1920x1080 resolution where the EDID mode has clock
> of 148500kHz. After adjustment, the clock changes to 148800kHz. While
> this change is reflected in mode->clock, its not propagated to
> mode->crtc_clock.

Hmm, so CDNS-DSI changes the adjusted_mode->clock, but in the end tidss
doesn't actually use the adjusted clock at all? I'm pretty sure I tested
that... I need to try it (and this) again.

 Tomi

> 
> [0] provides the **essential** fixes to get DSI working and its
> patches are Reviewed and Tested.
> The series improves the condition of DSI. I have observed that
> 800x600 and 1280x1024 modes are working now after [0].
> 
> This patch helps to enables other modes. So taking this up as a
> delta patch so as to avoid respining v5 of [0].
> I hope this approach is okay!
> 
> [0]: https://lore.kernel.org/all/20250618-cdns-dsi-impro-v4-0-862c841dbe02@ideasonboard.com/
> [1]: https://patchwork.kernel.org/project/dri-devel/patch/20250618-cdns-dsi-impro-v4-3-862c841dbe02@ideasonboard.com/ 
> 
>  drivers/gpu/drm/tidss/tidss_crtc.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c
> index 17efd77ce7f2..da89fd01c337 100644
> --- a/drivers/gpu/drm/tidss/tidss_crtc.c
> +++ b/drivers/gpu/drm/tidss/tidss_crtc.c
> @@ -91,7 +91,7 @@ static int tidss_crtc_atomic_check(struct drm_crtc *crtc,
>  	struct dispc_device *dispc = tidss->dispc;
>  	struct tidss_crtc *tcrtc = to_tidss_crtc(crtc);
>  	u32 hw_videoport = tcrtc->hw_videoport;
> -	const struct drm_display_mode *mode;
> +	struct drm_display_mode *mode;
>  	enum drm_mode_status ok;
>  
>  	dev_dbg(ddev->dev, "%s\n", __func__);
> @@ -108,6 +108,9 @@ static int tidss_crtc_atomic_check(struct drm_crtc *crtc,
>  		return -EINVAL;
>  	}
>  
> +	if (drm_atomic_crtc_needs_modeset(crtc_state))
> +		drm_mode_set_crtcinfo(mode, 0);
> +
>  	return dispc_vp_bus_check(dispc, hw_videoport, crtc_state);
>  }
>