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

Message-ID: <20250624080402.302526-1-j-choudhary@ti.com>
Date: Tue, 24 Jun 2025 13:34:02 +0530
From: Jayesh Choudhary <j-choudhary@...com>
To: <jyri.sarha@....fi>, <dri-devel@...ts.freedesktop.org>, <devarsht@...com>,
        <tomi.valkeinen@...asonboard.com>
CC: <maarten.lankhorst@...ux.intel.com>, <mripard@...nel.org>,
        <tzimmermann@...e.de>, <airlied@...il.com>, <simona@...ll.ch>,
        <linux-kernel@...r.kernel.org>, <j-choudhary@...com>
Subject: [PATCH] drm/tidss: Set crtc modesetting parameters with adjusted mode

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.

[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);
 }

-- 
2.34.1