linux-toradex.git/drivers/gpu/drm/tidss, branch master

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using

    git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook

drm/tidss: Fix enable/disable order

2026-01-03T19:08:24+00:00

TI's OLDI and DSI encoders need to be set up before the crtc is enabled,
but the DRM helpers will enable the crtc first. This causes various
issues on TI platforms, like visual artifacts or crtc sync lost
warnings.

Thus drm_atomic_helper_commit_modeset_enables() and
drm_atomic_helper_commit_modeset_disables() cannot be used, as they
enable the crtc before bridges' pre-enable, and disable the crtc after
bridges' post-disable.

Open code the drm_atomic_helper_commit_modeset_enables() and
drm_atomic_helper_commit_modeset_disables(), and first call the bridges'
pre-enables, then crtc enable, then bridges' post-enable (and vice versa
for disable).

Signed-off-by: Tomi Valkeinen 
Cc: stable@vger.kernel.org # v6.17+
Fixes: c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")
Reviewed-by: Aradhya Bhatia 
Reviewed-by: Maxime Ripard 
Reviewed-by: Linus Walleij 
Tested-by: Linus Walleij 
Signed-off-by: Linus Walleij 
Link: https://patch.msgid.link/20251205-drm-seq-fix-v1-4-fda68fa1b3de@ideasonboard.com

drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook

2025-11-12T09:54:39+00:00

After integrating OLDI support[0], it is necessary to identify which VP
instances use OLDI, since the OLDI driver owns the video port clock
(as a serial clock). Clock operations on these VPs must be delegated to
the OLDI driver, not handled by the TIDSS driver. This issue also
emerged in upstream discussions when DSI-related clock management was
attempted in the TIDSS driver[1].

To address this, add an 'is_ext_vp_clk' array to the 'tidss_device'
structure, marking a VP as 'true' during 'tidss_oldi_init()' and as
'false' during 'tidss_oldi_deinit()'. TIDSS then uses 'is_ext_vp_clk'
to skip clock validation checks in 'dispc_vp_mode_valid()' for VPs
under OLDI control.

Since OLDI uses the DSS VP clock directly as a serial interface and
manages its own rate, mode validation should be implemented in the OLDI
bridge's 'mode_valid' hook. This patch adds that logic, ensuring proper
delegation and avoiding spurious clock handling in the TIDSS driver.

[0]: https://lore.kernel.org/all/20250528122544.817829-1-aradhya.bhatia@linux.dev/
[1]: https://lore.kernel.org/all/DA6TT575Z82D.3MPK8HG5GRL8U@kernel.org/

Fixes: 7246e0929945 ("drm/tidss: Add OLDI bridge support")
Tested-by: Michael Walle 
Reviewed-by: Devarsh Thakkar 
Reviewed-by: Tomi Valkeinen 
Signed-off-by: Jayesh Choudhary 
Signed-off-by: Swamil Jain 
Link: https://patch.msgid.link/20251104151422.307162-3-s-jain1@ti.com
Signed-off-by: Tomi Valkeinen 
Link: https://patch.msgid.link/ffd5ebe03391b3c01e616c0c844a4b8ddecede36.1762513240.git.jani.nikula@intel.com

drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display features

2025-11-12T09:52:40+00:00

The TIDSS hardware does not have independent maximum or minimum pixel
clock limits for each video port. Instead, these limits are determined
by the SoC's clock architecture. Previously, this constraint was
modeled using the 'max_pclk_khz' and 'min_pclk_khz' fields in
'dispc_features', but this approach is static and does not account for
the dynamic behavior of PLLs.

This patch removes the 'max_pclk_khz' and 'min_pclk_khz' fields from
'dispc_features'. The correct way to check if a requested mode's pixel
clock is supported is by using 'clk_round_rate()' in the 'mode_valid()'
hook. If the best frequency match for the mode clock falls within the
supported tolerance, it is approved. TIDSS supports a 5% pixel clock
tolerance, which is now reflected in the validation logic.

This change allows existing DSS-compatible drivers to be reused across
SoCs that only differ in their pixel clock characteristics. The
validation uses 'clk_round_rate()' for each mode, which may introduce
additional delay (about 3.5 ms for 30 modes), but this is generally
negligible. Users desiring faster validation may bypass these calls
selectively, for example, checking only the highest resolution mode,
as shown here[1].

[1]: https://lore.kernel.org/all/20250704094851.182131-3-j-choudhary@ti.com/

Tested-by: Michael Walle 
Reviewed-by: Devarsh Thakkar 
Reviewed-by: Tomi Valkeinen 
Signed-off-by: Jayesh Choudhary 
Signed-off-by: Swamil Jain 
Link: https://patch.msgid.link/20251104151422.307162-2-s-jain1@ti.com
[Tomi: dropped 'inline' from check_pixel_clock]
Signed-off-by: Tomi Valkeinen

drm/tidss: use drm_crtc_vblank_crtc()

2025-11-10T11:23:49+00:00

We have drm_crtc_vblank_crtc() to get the struct drm_vblank_crtc pointer
for a crtc. Use it instead of poking at dev->vblank[] directly.

Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Acked-by: Jyri Sarha 
Link: https://patch.msgid.link/ffd5ebe03391b3c01e616c0c844a4b8ddecede36.1762513240.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula

drm/tidss: Set vblank (event) time at crtc_atomic_enable

2025-10-31T14:56:54+00:00

It was reported that Weston stops at an assert, which checks that the
page flip event timestamp is the same or newer than the previous
timestamp:

weston_output_finish_frame: Assertion `timespec_sub_to_nsec(stamp, &output->frame_time) >= 0' failed.

With manual tests, I can see that when I enable the CRTC, I get a page
flip event with a timestamp of 0. Tracking this down led to
drm_reset_vblank_timestamp() which does "t_vblank = 0" if
"high-precision query" is not available.

TI DSS does not have any hardware timestamping, and thus the default
ktime_get() is used in the DRM framework to get the vblank timestamp,
and ktime_get() is not "high precision" here.

It is not quite clear why the framework behaves this way, but I assume
the idea is that drm_crtc_vblank_on(), which calls
drm_reset_vblank_timestamp(), can be called at any time, and thus
ktime_get() wouldn't give a good timestamp. And, the idea is that the
driver would wait until next vblank after the CRTC enable, and then we
could get a good timestamp. This is hinted in the comment: "reinitialize
delayed at next vblank interrupt and assign 0 for now".

I think that makes sense. However, when we enable the CRTC in TI DSS,
i.e. we write the enable bit to the hardware, that's the exact moment
when the "vblank cycle" starts. It is the zero point in the cycle, and
thus ktime_get() would give a good timestamp.

I am not sure if this is applicable to other hardware, and if so, how
should it be solved in the framework. So, let's fix this in the tidss
driver at least for now.

This patch updates the vblank->time manually to ktime_get() just before
sending the vblank event, and we enable the crtc just before calling
ktime_get(). To get even more exact timing, the dispc_vp_enable() is
moved inside the event_lock spinlock.

With this, we get a proper timestamp for the page flip event from
enabling the CRTC, and Weston is happy.

Reviewed-by: Devarsh Thakkar
Link: https://patch.msgid.link/20250905-tidss-fix-timestamp-v1-2-c2aedf31e2c9@ideasonboard.com
Signed-off-by: Tomi Valkeinen
Closes: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1553964/processor-sdk-am62x-weston-fails-to-wake-from-idle-time-sleep-restarts-after-sigterm
Closes: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1416342/am625-am625-doesn-t-wake-up-from-standy-when-idle-time-is-configured-in-weston-ini

drm/tidss: Restructure dispc_vp_prepare() and dispc_vp_enable()

2025-10-31T14:56:05+00:00

tidss_crtc.c calls dispc_vp_prepare() and dispc_vp_enable() in that
order, next to each other. dispc_vp_prepare() does preparations for
enabling the crtc, by writing some registers, and dispc_vp_enable() does
more preparations. As the last thing, dispc_vp_enable() enables the CRTC
by writing the enable bit.

There might have been a reason at some point in the history for this
split, but I can't find any point to it. They also do a bit of
overlapping work: both call dispc_vp_find_bus_fmt(). They could as well
be a single function.

But instead of combining them, this patch moves everything from
dispc_vp_enable() to dispc_vp_prepare(), except the actual CRTC enable
bit write. The reason for this is that unlike all the preparatory
register writes, CRTC enable has an immediate effect, starting the
timing generator and the CRTC as a whole. Thus it may be important to
time the enable just right (as we do in the next patch).

No functional changes.

Reviewed-by: Devarsh Thakkar 
Link: https://patch.msgid.link/20250905-tidss-fix-timestamp-v1-1-c2aedf31e2c9@ideasonboard.com
Signed-off-by: Tomi Valkeinen

drm: include drm_print.h where needed

2025-10-31T08:34:52+00:00

There are a gazillion files that depend on drm_print.h being indirectly
included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In
preparation for removing those includes, explicitly include drm_print.h
where needed.

Cc: Thomas Zimmermann 
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Jani Nikula 
Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com

drm/tidss: crtc: Cleanup reset implementation

2025-09-30T09:57:12+00:00

The tidss_crtc_reset() function will (rightfully) destroy any
pre-existing state.

However, the tidss CRTC driver has its own CRTC state structure that
subclasses drm_crtc_state, and yet will destroy the previous state
by calling __drm_atomic_helper_crtc_destroy_state() and kfree() on its
drm_crtc_state pointer.

It works only because the drm_crtc_state is the first field in the
structure, and thus its offset is 0. It's incredibly fragile however, so
let's call our destroy implementation in such a case to deal with it
properly.

Reviewed-by: Thomas Zimmermann 
Link: https://lore.kernel.org/r/20250902-drm-state-readout-v1-22-14ad5315da3f@kernel.org
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20250902-drm-state-readout-v1-22-14ad5315da3f@kernel.org