Harry Wentland [Sat, 15 Nov 2025 00:01:29 +0000 (17:01 -0700)]
drm/colorop: Introduce new drm_colorop mode object
This patches introduces a new drm_colorop mode object. This
object represents color transformations and can be used to
define color pipelines.
We also introduce the drm_colorop_state here, as well as
various helpers and state tracking bits.
Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-5-alex.hung@amd.com
Harry Wentland [Sat, 15 Nov 2025 00:01:28 +0000 (17:01 -0700)]
drm/doc/rfc: Describe why prescriptive color pipeline is needed
Add documentation for color pipeline API.
Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-4-alex.hung@amd.com
Harry Wentland [Sat, 15 Nov 2025 00:01:27 +0000 (17:01 -0700)]
drm/vkms: Add kunit tests for VKMS LUT handling
Debugging LUT math is much easier when we can unit test
it. Add kunit functionality to VKMS and add tests for
- get_lut_index
- lerp_u16
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Cc: Arthur Grillo <arthurgrillo@riseup.net> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-3-alex.hung@amd.com
Harry Wentland [Sat, 15 Nov 2025 00:01:26 +0000 (17:01 -0700)]
drm: Add helper for conversion from signed-magnitude
CTM values are defined as signed-magnitude values. Add
a helper that converts from CTM signed-magnitude fixed
point value to the twos-complement value used by
drm_fixed.
Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-2-alex.hung@amd.com
Until now ttm stored a single pipelined eviction fence which means
drivers had to use a single entity for these evictions.
To lift this requirement, this commit allows up to 8 entities to
be used.
Ideally a dma_resv object would have been used as a container of
the eviction fences, but the locking rules makes it complex.
dma_resv all have the same ww_class, which means "Attempting to
lock more mutexes after ww_acquire_done." is an error.
One alternative considered was to introduced a 2nd ww_class for
specific resv to hold a single "transient" lock (= the resv lock
would only be held for a short period, without taking any other
locks).
The other option, is to statically reserve a fence array, and
extend the existing code to deal with N fences, instead of 1.
The driver is still responsible to reserve the correct number
of fence slots.
Ashley Smith [Thu, 13 Nov 2025 10:57:34 +0000 (11:57 +0100)]
drm/panthor: Reset queue slots if termination fails
Make sure the queue slot is reset even if we failed termination so
we don't have garbage in the CS input interface after a reset. In
practice that's not a problem because we zero out all RW sections when
a hangs occurs, but it's safer to reset things manually, in case we
decide to not conditionally reload RW sections based on the type of
hang.
v4:
- Split the changes in two separate patches
v5:
- No changes
v6:
- Adjust the explanation in the commit message
- Drop the Fixes tag
- Put after the timeout changes and make the two patches independent
so one can be backported, and the other not
v7:
- Use the local group variable instead of dereferencing csg_slot->group
- Add Steve's R-b
Ashley Smith [Thu, 13 Nov 2025 10:57:33 +0000 (11:57 +0100)]
drm/panthor: Make the timeout per-queue instead of per-job
The timeout logic provided by drm_sched leads to races when we try
to suspend it while the drm_sched workqueue queues more jobs. Let's
overhaul the timeout handling in panthor to have our own delayed work
that's resumed/suspended when a group is resumed/suspended. When an
actual timeout occurs, we call drm_sched_fault() to report it
through drm_sched, still. But otherwise, the drm_sched timeout is
disabled (set to MAX_SCHEDULE_TIMEOUT), which leaves us in control of
how we protect modifications on the timer.
One issue seems to be when we call drm_sched_suspend_timeout() from
both queue_run_job() and tick_work() which could lead to races due to
drm_sched_suspend_timeout() not having a lock. Another issue seems to
be in queue_run_job() if the group is not scheduled, we suspend the
timeout again which undoes what drm_sched_job_begin() did when calling
drm_sched_start_timeout(). So the timeout does not reset when a job
is finished.
v2:
- Fix syntax error
v3:
- Split the changes in two commits
v4:
- No changes
v5:
- No changes
v6:
- Fix a NULL deref in group_can_run(), and narrow the group variable
scope to avoid such mistakes in the future
- Add an queue_timeout_is_suspended() helper to clarify things
v7:
- No changes
v8:
- Don't touch drm_gpu_scheduler::timeout in queue_timedout_job()
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Signed-off-by: Ashley Smith <ashley.smith@collabora.com> Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251113105734.1520338-2-boris.brezillon@collabora.com
Steven Price [Mon, 24 Nov 2025 11:20:38 +0000 (11:20 +0000)]
drm/gem: Correct error condition in drm_gem_objects_lookup
When vmemdup_array_user() fails, 'handles' is set to a negative error
code and no memory is allocated. So the call to kvfree() should not
happen. Instead just return early with the error code.
Log the number of pages and their sizes actually mapped/unmapped by
the IOMMU page table driver. Since a map/unmap op is often split in
several ops depending on the underlying scatter/gather table, add the
start address and the total size to the debugging logs in order to
help understand which batch an op is part of.
Karunika Choo [Tue, 25 Nov 2025 12:55:48 +0000 (12:55 +0000)]
drm/panthor: Add support for Mali-G1 GPUs
Add support for Mali-G1 GPUs (CSF architecture v14), introducing a new
panthor_hw_arch_v14 entry with reset and L2 power management operations
via the PWR_CONTROL block.
Mali-G1 introduces a dedicated PWR_CONTROL block for managing resets and
power domains. panthor_gpu_info_init() is updated to use this block for
L2, tiler, and shader domain present register reads.
Karunika Choo [Tue, 25 Nov 2025 12:55:47 +0000 (12:55 +0000)]
drm/panthor: Support 64-bit endpoint_req register for Mali-G1
Add support for the 64-bit endpoint_req register introduced in CSF v4.0+
GPUs. Unlike a simple register widening, the 64-bit variant occupies the
next 64 bits after the original 32-bit field, requiring
version-dependent access.
This change introduces helper functions to read, write, and update the
endpoint_req register, ensuring correct handling on both pre-v4.0 and
v4.0+ firmwares.
Karunika Choo [Tue, 25 Nov 2025 12:55:46 +0000 (12:55 +0000)]
drm/panthor: Support GLB_REQ.STATE field for Mali-G1 GPUs
Add support for the GLB_REQ.STATE field introduced in CSF v4.1+, which
replaces the HALT bit to provide finer control over the MCU state. This
change implements basic handling for transitioning the MCU between
ACTIVE and HALT states on Mali-G1 GPUs.
The update introduces new helpers to issue the state change requests,
poll for MCU halt completion, and restore the MCU to an active state
after halting.
Karunika Choo [Tue, 25 Nov 2025 12:55:45 +0000 (12:55 +0000)]
drm/panthor: Implement soft reset via PWR_CONTROL
Add helpers to issue reset commands through the PWR_CONTROL interface
and wait for reset completion using IRQ signaling. This enables support
for RESET_SOFT operations with timeout handling and status verification.
Karunika Choo [Tue, 25 Nov 2025 12:55:44 +0000 (12:55 +0000)]
drm/panthor: Implement L2 power on/off via PWR_CONTROL
This patch adds common helpers to issue power commands, poll
transitions, and validate domain state, then wires them into the L2
on/off paths.
The L2 power-on sequence now delegates control of the SHADER and TILER
domains to the MCU when allowed, while the L2 itself is never delegated.
On power-off, dependent domains beneath the L2 are checked, and if
necessary, retracted and powered down to maintain proper domain
ordering.
Karunika Choo [Tue, 25 Nov 2025 12:55:43 +0000 (12:55 +0000)]
drm/panthor: Introduce panthor_pwr API and power control framework
Add the new panthor_pwr module, which provides basic power control
management for Mali-G1 GPUs. The initial implementation includes
infrastructure for initializing the PWR_CONTROL block, requesting and
handling its IRQ, and checking for PWR_CONTROL support based on GPU
architecture.
The patch also integrates panthor_pwr with the device lifecycle (init,
suspend, resume, and unplug) through the new API functions. It also
registers the IRQ handler under the 'gpu' IRQ as the PWR_CONTROL block
is located within the GPU_CONTROL block.
Karunika Choo [Tue, 25 Nov 2025 12:55:42 +0000 (12:55 +0000)]
drm/panthor: Add architecture-specific function operations
Introduce architecture-specific function pointers to support
architecture-dependent behaviours. This patch adds the following
function pointers and updates their usage accordingly:
Karunika Choo [Tue, 25 Nov 2025 12:55:41 +0000 (12:55 +0000)]
drm/panthor: Add arch-specific panthor_hw binding
This patch adds the framework for binding to a specific panthor_hw
structure based on the architecture major value parsed from the GPU_ID
register. This is in preparation of enabling architecture-specific
behaviours based on GPU_ID. As such, it also splits the GPU_ID register
read operation into its own helper function.
This framework allows a single panthor_hw structure to be shared across
multiple architectures should there be minimal changes between them via
the arch_min and arch_max field of the panthor_hw_entry structure,
instead of duplicating the structure across multiple architectures.
Akash Goel [Thu, 20 Nov 2025 17:21:18 +0000 (17:21 +0000)]
drm/panthor: Avoid adding of kernel BOs to extobj list
The kernel BOs unnecessarily got added to the external objects list
of drm_gpuvm, when mapping to GPU, which would have resulted in few
extra CPU cycles being spent at the time of job submission as
drm_exec_until_all_locked() loop iterates over all external objects.
Kernel BOs are private to a VM and so they share the dma_resv object of
the dummy GEM object created for a VM. Use of DRM_EXEC_IGNORE_DUPLICATES
flag ensured the recursive locking of the dummy GEM object was ignored.
Also no extra space got allocated to add fences to the dma_resv object
of dummy GEM object. So no other impact apart from few extra CPU cycles.
This commit sets the pointer to dma_resv object of GEM object of
kernel BOs before they are mapped to GPU, to prevent them from
being added to external objects list.
v2: Add R-bs and fixes tags
Fixes: 8a1cc07578bf ("drm/panthor: Add GEM logical block") Signed-off-by: Akash Goel <akash.goel@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251120172118.2741724-1-akash.goel@arm.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
drm/fb-helper: Allocate and release fb_info in single place
Move the calls to drm_fb_helper_alloc_info() from drivers into a
single place in fbdev helpers. Allocates struct fb_info for a new
framebuffer device. Then call drm_fb_helper_single_fb_probe() to
create an fbdev screen buffer. Also release the instance on errors
by calling drm_fb_helper_release_info().
Simplifies the code and fixes the error cleanup for some of the
drivers.
Regular release of the struct fb_info instance still happens in
drm_fb_helper_fini() as before.
v2:
- remove error rollback in driver implementations (kernel test robot)
- initialize info in TTM implementation (kernel test robot)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Christian König <christian.koenig@amd.com> # radeon Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # msm Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20251027081245.80262-1-tzimmermann@suse.de
Restore the log client's output when the DRM core invokes the restore
callback. Follow the existing behavior of fbdev emulation wrt. the
value of the force parameter.
If force is false, acquire the DRM master lock and reprogram the
display. This is the case when the user-space compositor exits and
the DRM core transfers the display back to the in-kernel client. This
also enables drm_log output during reboot and shutdown.
If force is true, reprogram without considering the master lock. This
overrides the current compositor and prints the log to the screen. In
case of system malfunction, users can enter SysRq+v to invoke the
emergency error reporting. See Documentation/admin-guide/sysrq.rst for
more information.
v2:
- s/exists/exits/ in second paragraph of commit description
- fix grammar in commit description
drm/client: Support emergency restore via sysrq for all clients
Move the sysrq functionality from DRM fbdev helpers to the DRM device
and in-kernel clients, so that it becomes available on all clients.
DRM fbdev helpers support emergency restoration of the console output
via a special key combination. Press SysRq+v to replace the current
compositor with the kernel's output on the framebuffer console. This
allows users to see the log messages during system emergencies.
By moving the functionality from fbdev helpers to the DRM device, any
in-kernel client can serve as emergency output. This can be used to
bring up drm_log, for example.
Each DRM device registers itself to the list of possible sysrq handlers.
On receiving SysRq+v, the DRM core goes over all registered devices and
restores an in-kernel DRM client for each of them.
See Documentation/admin-guide/sysrq.rst on how to invoke SysRq. Switch
VTs to bring back the user-space compositor.
v2:
- declare placeholders as 'static inline' (kernel test robot)
- fix grammar in commit description
drm/client: Pass force parameter to client restore
Add force parameter to client restore and pass value through the
layers. The only currently used value is false.
If force is true, the client should restore its display even if it
does not hold the DRM master lock. This is be required for emergency
output, such as sysrq.
While at it, inline drm_fb_helper_lastclose(), which is a trivial
wrapper around drm_fb_helper_restore_fbdev_mode_unlocked().
Daniel Thompson [Fri, 21 Nov 2025 17:23:54 +0000 (17:23 +0000)]
drm/edp-panel: Add touchscreen panel used by Lenovo X13s
After (checks watch) a little over two years I finally investigated the
boot warning on my Thinkpad X13s and it was caused by the conservative
timings warning in panel-edp.c . The X13s was sold with a variety of
different panel versions; I have the 300 nit multi-touch variant.
I have been unable to secure panel documentation so the I copied the
timings from NV133WUM-N63.
Ettore Chimenti [Fri, 21 Nov 2025 14:26:14 +0000 (15:26 +0100)]
dt-bindings: display: bridge: simple: document the ASL CS5263 DP-to-HDMI bridge
The ASL CS5263 is a high-performance DP1.4 to HDMI2.0b converter,
designed to connect a DP1.4 source to an HDMI2.0b sink. The CS5263AN
integrates a DP1.4 compliant receiver, and a HDMI2.0b compliant
transmitter.
Signed-off-by: Ettore Chimenti <ettore.chimenti@linaro.org> Signed-off-by: Georg Gottleuber <ggo@tuxedocomputers.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251121142623.251118-3-ggo@tuxedocomputers.com
Nishanth Menon [Wed, 29 Oct 2025 15:06:36 +0000 (10:06 -0500)]
drm/bridge: it66121: Add minimal it66122 support
The IT66122 is a pin compatible replacement for the IT66122. Based on
empirical testing, the new device looks to be compatible with IT66121.
However due to a lack of public data sheet at this time beyond overall
feature list[1] (which seems to add additional features vs ITT66121),
it is hard to determine that additional register operations required
to enable additional features.
So, introduce the device as a new compatible that we will detect based
on vid/pid match, with explicit id that can be used to extend the
driver capability as information becomes available later on.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251029150636.3118628-6-nm@ti.com
Nishanth Menon [Wed, 29 Oct 2025 15:06:35 +0000 (10:06 -0500)]
drm/bridge: it66121: Use vid/pid to detect the type of chip
The driver knows exactly which version of the chip is present since
the vid/pid is used to enforce a compatibility. Given that some
devices like IT66121 has potentially been replaced with IT66122 mid
production for many platforms, it makes no sense to use the vid/pid
as an enforcement for compatibility. Instead, detect the ID of the
actual chip in use by matching the corresponding vid/pid and drop the
compatible specific lookup table.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251029150636.3118628-5-nm@ti.com
Nishanth Menon [Wed, 29 Oct 2025 15:06:32 +0000 (10:06 -0500)]
dt-bindings: display: bridge: it66121: Add compatible string for IT66122
Add a new ite,it66122 compatible string to the IT66121 binding
documentation, since the two chips are practically same except for id
register difference.
Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251029150636.3118628-2-nm@ti.com
Barry Song [Tue, 21 Oct 2025 04:20:22 +0000 (17:20 +1300)]
dma-buf: system_heap: use larger contiguous mappings instead of per-page mmap
We can allocate high-order pages, but mapping them one by
one is inefficient. This patch changes the code to map
as large a chunk as possible. The code looks somewhat
complicated mainly because supporting mmap with a
non-zero offset is a bit tricky.
Using the micro-benchmark below, we see that mmap becomes
35X faster:
for (int i = 0; i < PAGES; i++) p[i*STRIDE] = i;
for (int i = 0; i < PAGES; i++)
if (p[i*STRIDE] != i) {
fprintf(stderr, "mismatch at page %d\n", i);
exit(1);
}
long ns = (t1.tv_sec-t0.tv_sec)*1000000000L +
(t1.tv_nsec-t0.tv_nsec);
printf("mmap 512MB took %.3f us, verify OK\n", ns/1000.0);
return 0;
}
W/ patch:
~ # ./a.out
mmap 512MB took 200266.000 us, verify OK
~ # ./a.out
mmap 512MB took 198151.000 us, verify OK
~ # ./a.out
mmap 512MB took 197069.000 us, verify OK
~ # ./a.out
mmap 512MB took 196781.000 us, verify OK
~ # ./a.out
mmap 512MB took 198102.000 us, verify OK
~ # ./a.out
mmap 512MB took 195552.000 us, verify OK
W/o patch:
~ # ./a.out
mmap 512MB took 6987470.000 us, verify OK
~ # ./a.out
mmap 512MB took 6970739.000 us, verify OK
~ # ./a.out
mmap 512MB took 6984383.000 us, verify OK
~ # ./a.out
mmap 512MB took 6971311.000 us, verify OK
~ # ./a.out
mmap 512MB took 6991680.000 us, verify OK
Signed-off-by: Barry Song <v-songbaohua@oppo.com> Acked-by: John Stultz <jstultz@google.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: correct from 3.5x to 35x] Link: https://patch.msgid.link/20251021042022.47919-1-21cnbao@gmail.com
David Heidelberg [Wed, 19 Nov 2025 14:21:34 +0000 (15:21 +0100)]
drm/panel: sofef00: Introduce compatible which includes the panel name
Compatible should correspond to the panel used and the driver currently
supports only AMS628NW01 panel. Adapt the internal driver structures to
reflect the name.
Original, not very descriptive, compatible is kept to ensure compatibility
with older device-trees.
David Heidelberg [Wed, 19 Nov 2025 14:21:30 +0000 (15:21 +0100)]
drm/panel: sofef00: Split sending commands to the enable/disable functions
It's not possible to send DSI panel commands in the .unprepare. Move it
to .disable and do similar for prepare, where we move the display on to
the .enable.
David Heidelberg [Wed, 19 Nov 2025 14:21:26 +0000 (15:21 +0100)]
dt-bindings: panel: Convert Samsung SOFEF00 DDIC into standalone yaml
Reason for moving from simple panel is this DDIC has three supplies,
while panel-simple-dsi is limited to one.
Previous compatible only described the DDIC, but didn't include panel
connected to it. Let's fix it, and offer bindings authors two
compatibles to distinguish the connected panel.
Basic description for SOFEF00 DDIC with attached panels
- Samsung AMS601NT22 6.01 inch, 1080x2160 pixels, 18:9 ratio
- Samsung AMS628NW01 6.28 inch, 1080x2280 pixels, 19:9 ratio
There is only one user which uses samsung,sofef00 and it's updated to
comply within this patch series.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20251119-sofef00-rebuild-v3-1-6cd55471e84e@ixit.cz
Abhishek Rajput [Mon, 17 Nov 2025 06:47:02 +0000 (12:17 +0530)]
drm/panel: jadard-jd9365da-h3: Use dev_err_probe() instead of DRM_DEV_ERROR() during probing
The DRM_DEV_ERROR() has been deprecated, and use dev_err_probe()
can be better. The other reason is that dev_err_probe() help avoid
unexpected repeated err logs during defered probing.
Svyatoslav Ryhel [Mon, 10 Nov 2025 09:14:32 +0000 (11:14 +0200)]
gpu/drm: panel: add support for LG LD070WX3-SL01 MIPI DSI panel
The LD070WX3 is a Color Active Matrix Liquid Crystal Display with an
integral Light Emitting Diode (LED) backlight system. The matrix employs
a-Si Thin Film Transistor as the active element. It is a transmissive type
display operating in the normally Black mode. This TFT-LCD has 7.0 inches
diagonally measured active display area with WXGA resolution (800 by 1280
pixel array).
LG LD070WX3-SL01 MIPI DSI panel was treated as simple DSI panel when it is
actually not and requires proper setup for correct work. Simple panel work
relied on preliminary configuration done by bootloader.
Svyatoslav Ryhel [Mon, 10 Nov 2025 09:14:31 +0000 (11:14 +0200)]
dt-bindings: display: panel: properly document LG LD070WX3 panel
LG LD070WX3-SL01 was mistakenly documented as a simple DSI panel, which it
clearly is not. Address this by adding the proper schema for this panel.
There is only one user of this panel binding in the mainline Linux kernel,
which is the Nvidia tablet Tegra Note 7. Its panel is broken anyway since
it cannot initialize properly if the bootloader does not leave a
pre-initialized panel. It also cannot suspend or re-initialize properly,
since no DSI configuration is set and it has a loose regulator which
relies on an always-on property rather than being hooked to the panel
where it belongs.
Tegra Note 7 device tree is adjusted as a part of this series.
Andy Yan [Wed, 12 Nov 2025 08:50:23 +0000 (16:50 +0800)]
drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use win_mask calculate used layers
When there are multiple Video Ports, and only one of them is working
(for example, VP1 is working while VP0 is not), in this case, the
win_mask of VP0 is 0. However, we have already set the port mux for VP0
according to vp0->nlayers, and at the same time, in the OVL_LAYER_SEL
register, there are windows will also be assigned to layers which will
map to the inactive VPs. In this situation, vp0->win_mask is zero as it
now working, it is more reliable to calculate the used layers based on
the configuration of the OVL_LAYER_SEL register.
Note: as the configuration of OVL_LAYER_SEL is take effect when the
vsync is come, so we use the value backup in vop2->old_layer_sel instead
of read OVL_LAYER_SEL directly.
Fixes: 3e89a8c68354 ("drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568") Cc: stable@vger.kernel.org Reported-by: Diederik de Haas <diederik@cknow-tech.com> Closes: https://bugs.kde.org/show_bug.cgi?id=511274 Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Tested-by: Dang Huynh <dang.huynh@mainlining.org> Tested-by: Diederik de Haas <diederik@cknow-tech.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20251112085024.2480111-1-andyshrk@163.com
Dmitry Osipenko [Wed, 22 Oct 2025 16:19:48 +0000 (19:19 +0300)]
drm/rockchip: Set VOP for the DRM DMA device
Use VOP for DMA operations performed by DRM core. Rockchip DRM driver
is backed by a virtual device that isn't IOMMU-capable, while VOP is the
actual display controller device backed by IOMMU. Fixes "swiotlb buffer
is full" warning messages originated from GEM prime code paths.
Note, that backporting is non-trivial as this depends on
commit 143ec8d3f9396 ("drm/prime: Support dedicated DMA device for dma-buf
imports"), which landed in v6.16 and commit 421be3ee36a4 ("drm/rockchip:
Refactor IOMMU initialisation"), which landed in v5.19.
drm/rockchip: dw_hdmi_qp: Add high color depth support
Since both RK3576 and RK3588 SoCs are capable of handling 10 bpc color
depth, introduce a pair of new helpers to program the necessary
registers, as well as passing bpc at PHY configuration level.
Note max_bpc is unconditionally set to 10 before initializing the QP
bridge library, as there is no need to adjust it dynamically, i.e. per
SoC variant, for now.
While setting up .enc_init() callbacks of rockchip_hdmi_qp_ctrl_ops,
also replace the unnecessary whitespace chars before .irq_callback()
assignments.
drm/rockchip: dw_hdmi_qp: Use bit macros for RK3576 regs
For consistency and improved readability, redefine a few RK3576 specific
register configurations by relying on GENMASK() and unshifted values for
color depth and output format. Those are not used at the moment, but
will be needed soon to support the related features.
While at it, drop a few other defines which are unlikely to be ever
required.
drm/rockchip: dw_hdmi_qp: Switch to phy_configure()
Stop relying on phy_set_bus_width() based workaround to setup the TMDS
character rate and, instead, use the recently introduced HDMI PHY
configuration API. This is also a prerequisite to enable high color
depth and FRL support.
Additionally, move the logic to ->atomic_check() callback where the
current mode rate is already provided by the connector state. As a
matter of fact this is actually necessary to ensure the link rate is
configured before VOP2 attempts to use the PHY PLL as a DCLK source in
vop2_crtc_atomic_enable(). The rationale is to restrict any changes of
the PHY rate via CCF and, instead, prefer the PHY configuration API for
this purpose.
drm/bridge: dw-hdmi-qp: Handle platform supported formats and color depth
Extend struct dw_hdmi_qp_plat_data to include the supported display
output formats and maximum bits per color channel. When provided by the
platform driver, use them to setup the HDMI bridge accordingly.
Additionally, improve debug logging in dw_hdmi_qp_bridge_atomic_enable()
to also show the current HDMI output format and bpc.
drm/rockchip: vop2: Check bpc before switching DCLK source
When making use of the HDMI PHY PLL as a VOP2 DCLK source, it's output
rate does normally match the mode clock. But this is only applicable
for default color depth of 8 bpc. For higher depths, the output clock
is further divided by the hardware according to the formula:
output rate = PHY PLL rate * 8 / bpc
Hence there is no need for VOP2 to compensate for bpc when adjusting
DCLK, but it is required to do so when computing its maximum operating
frequency.
Take color depth into consideration before deciding to switch DCLK
source.
Damon Ding [Mon, 10 Nov 2025 07:58:17 +0000 (15:58 +0800)]
drm/rockchip: analogix_dp: Use dev_err_probe() instead of DRM_DEV_ERROR() during probing
The DRM_DEV_ERROR() has been deprecated, and use dev_err_probe()
can be better. The other reason is that dev_err_probe() help avoid
unexpected repeated err logs during defered probing.
drm/rockchip: dw_hdmi_qp: Fixup usage of enable_gpio member in main struct
The name of the enable_gpio member in struct rockchip_hdmi_qp is too
generic, as initially "borrowed" from downstream BSP code. Moreover,
this hasn't been really in use so far, since there is neither a DT
providing an "enable-gpios" property to any of the "hdmi" nodes, nor a
binding documenting it.
The actual purpose of this GPIO line is to control the voltage bias for
the HDMI TX data lines when switching between TMDS and FRL operating
modes.
A previous patch introduced the "frl-enable-gpios" property of the
RK3588 HDMI TX Controller binding, hence pass the updated string to
devm_gpiod_get_optional(), rename the struct member accordingly and set
it to a low level.
Add an optional property to RK3588 HDMI TX Controller binding describing
a GPIO line to be asserted when operating in HDMI 2.1 FRL mode and
deasserted for HDMI 1.4/2.0 TMDS.
This is used to control an external voltage bias for HDMI data lines.
Optimize performance of syncpoint interrupt handling by reading
the status register in 64-bit chunks when possible, and skipping
processing when the read value is zero.
Lizhi Hou [Fri, 7 Nov 2025 18:10:50 +0000 (10:10 -0800)]
accel/amdxdna: Fix deadlock between context destroy and job timeout
Hardware context destroy function holds dev_lock while waiting for all jobs
to complete. The timeout job also needs to acquire dev_lock, this leads to
a deadlock.
Fix the issue by temporarily releasing dev_lock before waiting for all
jobs to finish, and reacquiring it afterward.
Lizhi Hou [Fri, 7 Nov 2025 18:11:15 +0000 (10:11 -0800)]
accel/amdxdna: Clear mailbox interrupt register during channel creation
The mailbox interrupt register is not always cleared when a mailbox channel
is created. This can leave stale interrupt states from previous operations.
Fix this by explicitly clearing the interrupt register in the mailbox
channel creation function.
drm/imx/ipuv3: Fix dumb-buffer allocation for non-RGB formats
Align pitch to multiples of 8 pixels for bpp values that do not map
to RGB formats. The call to drm_driver_color_mode_format() fails with
DRM_INVALID_FORMAT in these cases. Fall back to manually computing
the pitch alignment from which drm_mode_size_dumb() can compute the
correct pitch.
Fixes userspace that allocates dumb buffers for YUV formats, where
bpp equals 12. A common example is the IGT kms_getfb test.
v2:
- ignore width in calculation
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: b1d0e470f881 ("drm/imx/ipuv3: Compute dumb-buffer sizes with drm_mode_size_dumb()") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: imx@lists.linux.dev Cc: linux-arm-kernel@lists.infradead.org Tested-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patch.msgid.link/20251104153832.189666-1-tzimmermann@suse.de
Timur Tabi [Fri, 10 Oct 2025 22:39:57 +0000 (17:39 -0500)]
drm/nouveau: fully define nvfw_hs_load_header_v2
Add the missing fields of the nvfw_hs_load_header_v2 struct, so that the
struct matches the actual contents of the firmware images.
nvfw_hs_load_header_v2 is a struct that defines a header for some firmware
images used by Nouveau. The current structure definition is incomplete;
it omits the last two fields because they are unused.
To maintain consistency between Nouveau, OpenRM, and Nova, and to
make it easier to support possible future images, we should fully define
the struct. Also add a __counted_by tag for the flex array.
Mohamed Ahmed [Mon, 10 Nov 2025 15:33:00 +0000 (16:33 +0100)]
drm/nouveau/drm: Bump the driver version to 1.4.1 to report new features
The HW can only do compression on large and huge pages, and enabling it on
4K pages leads to a MMU fault. Compression also needs kernel support for
handling the compressed kinds and managing the compression tags.
This increments the nouveau version number which allows NVK to enable it
only when the kernel actually supports both features and avoid breaking
the system if a newer mesa version is paired with an older kernel version.
For the associated userspace MR, please see !36450:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36450
Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-5-83b05475f57c@mary.zone
Ben Skeggs [Mon, 10 Nov 2025 15:32:59 +0000 (16:32 +0100)]
drm/nouveau/mmu/tu102: Add support for compressed kinds
Allow compressed PTE kinds to be written into PTEs when GSP-RM is
present, rather than reverting to their non-compressed versions.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-4-83b05475f57c@mary.zone
Ben Skeggs [Mon, 10 Nov 2025 15:32:58 +0000 (16:32 +0100)]
drm/nouveau/mmu/gp100: Remove unused/broken support for compression
From GP100 onwards it's not possible to initialise comptag RAM without
PMU firmware, which nouveau has no support for.
As such, this code is essentially a no-op and will always revert to the
equivalent non-compressed kind due to comptag allocation failure. It's
also broken for the needs of VM_BIND/Vulkan.
Remove the code entirely to make way for supporting compression on GPUs
that support GSM-RM.
Signed-off-by: Ben Skeggs <bskeggs@nvidia.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mary Guillemard <mary@mary.zone> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-3-83b05475f57c@mary.zone
Mary Guillemard [Mon, 10 Nov 2025 15:32:57 +0000 (16:32 +0100)]
drm/nouveau/uvmm: Allow larger pages
Now that everything in UVMM knows about the variable page shift, we can
select larger values.
The proposed approach relies on nouveau_bo::page unless if it would cause
alignment issues (in which case we fall back to searching for an
appropriate shift)
Signed-off-by: Mary Guillemard <mary@mary.zone> Co-developed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-2-83b05475f57c@mary.zone
Mary Guillemard [Mon, 10 Nov 2025 15:32:56 +0000 (16:32 +0100)]
drm/nouveau/uvmm: Prepare for larger pages
Currently memory allocated by VM_BIND uAPI can only have a granuality
matching PAGE_SIZE (4KiB in common case)
To have a better memory management and to allow big (64KiB) and huge
(2MiB) pages later in the series, we are now passing the page shift all
around the internals of UVMM.
Signed-off-by: Mary Guillemard <mary@mary.zone> Co-developed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: James Jones <jajones@nvidia.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patch.msgid.link/20251110-nouveau-compv6-v6-1-83b05475f57c@mary.zone
drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook
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.
drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display features
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].
Jernej Skrabec [Tue, 4 Nov 2025 18:09:39 +0000 (19:09 +0100)]
drm/sun4i: mixer: split out layer config
Later special plane only driver for DE33 will provide separate
configuration. This change will also help layer driver migrate away from
mixer structure.
Jernej Skrabec [Tue, 4 Nov 2025 18:09:38 +0000 (19:09 +0100)]
drm/sun4i: mixer: Add quirk for number of VI scalers
On DE2 and DE3, UI scalers are located right after VI scalers. So in
order to calculate proper UI scaler base address, number of VI scalers
must be known. In practice, it is same as number of VI channels, but it
doesn't need to be.
Let's make a quirk for this number. Code for configuring channels and
associated functions won't have access to vi_num quirk anymore after
rework for independent planes.
Jernej Skrabec [Tue, 4 Nov 2025 18:09:37 +0000 (19:09 +0100)]
drm/sun4i: ui_scaler: drop sanity checks
They can't be triggered if mixer configuration is properly specified in
quirks. Additionally, number of VI channels won't be available in future
due to rework for DE33 support.
Jernej Skrabec [Tue, 4 Nov 2025 18:09:36 +0000 (19:09 +0100)]
drm/sun4i: mixer: Convert heuristics to quirk
Determination if FCC unit can be used for VI layer alpha depends on
number of VI channels. This info won't be available anymore in future
to VI layer driver because of DE33 way of allocating planes from same
pool to different mixers.
While order is slightly changed, it doesn't affect anything due to
double buffering of registers. New order keeps related registers
together and quirk separate.
Jernej Skrabec [Tue, 4 Nov 2025 18:09:35 +0000 (19:09 +0100)]
drm/sun4i: vi_scaler: Update DE33 base calculation
Now that channel base calculation is straightforward, let's update VI
scaler base calculation to be simpler. At the same time, also introduce
macro to avoid magic numbers.
Note, reason why current magic value and new macro value isn't the same
is because sun8i_channel_base() already introduces offset to channel
registers. Previous value is just the difference to VI scaler registers.
However, new code calculates scaler base from channel base. This is also
easier to understand when looking into BSP driver. Macro value can be
easily found whereas old diff value was not.
gentwo / linux / .git / log