Luca Ceresoli [Fri, 1 Aug 2025 17:05:26 +0000 (19:05 +0200)]
drm/omapdrm: use drm_bridge_chain_get_last_bridge()
Use drm_bridge_chain_get_last_bridge() instead of open coding a loop with
two invocations of drm_bridge_get_next_bridge() per iteration.
Besides being cleaner and more efficient, this change is necessary in
preparation for drm_bridge_get_next_bridge() to get a reference to the
returned bridge.
Luca Ceresoli [Fri, 1 Aug 2025 17:05:25 +0000 (19:05 +0200)]
drm/bridge: imx93-mipi-dsi: use drm_bridge_chain_get_last_bridge()
Use drm_bridge_chain_get_last_bridge() instead of open coding a loop with
two invocations of drm_bridge_get_next_bridge() per iteration.
Besides being cleaner and more efficient, this change is necessary in
preparation for drm_bridge_get_next_bridge() to get a reference to the
returned bridge.
drm/sched: Fix racy access to drm_sched_entity.dependency
The drm_sched_job_unschedulable trace point can access
entity->dependency after it was cleared by the callback
installed in drm_sched_entity_add_dependency_cb, causing:
To fix this we either need to keep a reference to the fence before
setting up the callbacks, or move the trace_drm_sched_job_unschedulable
calls into drm_sched_entity_add_dependency_cb where they can be
done earlier.
Liao Yuanhong [Wed, 20 Aug 2025 13:14:15 +0000 (21:14 +0800)]
drm/ssd130x: Remove the use of dev_err_probe()
Logging messages that show some type of "out of memory" error are generally
unnecessary as there is a generic message and a stack dump done by the
memory subsystem. These messages generally increase kernel size without
much added value[1].
The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore,
remove the useless call to dev_err_probe(), and just return the value
instead.
It uses drm_fb_xrgb8888_to_gray8() to convert the pixels to gray8 as an
intermediate step before converting to gray2.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250721-st7571-format-v2-5-159f4134098c@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Michal Wilczynski [Thu, 21 Aug 2025 22:20:18 +0000 (00:20 +0200)]
drm/imagination: Enable PowerVR driver for RISC-V
Several RISC-V boards feature Imagination GPUs that are compatible with
the PowerVR driver. An example is the IMG BXM-4-64 GPU on the Lichee Pi
4A board. This commit adjusts the driver's Kconfig dependencies to allow
the PowerVR driver to be compiled on the RISC-V architecture.
By enabling compilation on RISC-V, we expand support for these GPUs,
providing graphics acceleration capabilities and enhancing hardware
compatibility on RISC-V platforms.
The RISC-V support is restricted to 64-bit systems (RISCV && 64BIT) as
the driver currently has an implicit dependency on a 64-bit platform.
Add a dependency on MMU to fix a build warning on RISC-V configurations
without an MMU.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://lore.kernel.org/r/20250822-apr_14_for_sending-v13-4-af656f7cc6c3@samsung.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Michal Wilczynski [Thu, 21 Aug 2025 22:20:16 +0000 (00:20 +0200)]
dt-bindings: gpu: img,powervr-rogue: Add TH1520 GPU support
Rework the PowerVR Rogue GPU binding to use an explicit, per variant
style for defining power domain properties and add support for the
T-HEAD TH1520 SoC's GPU.
To improve clarity and precision, the binding is refactored so that
power domain items are listed explicitly for each variant [1]. The
previous method relied on an implicit, positional mapping between the
`power-domains` and `power-domain-names` properties. This change
replaces the generic rules with self contained if/then blocks for each
GPU variant, making the relationship between power domains and their
names explicit and unambiguous.
The generic if block for img,img-rogue, which previously required
power-domains and power-domain-names for all variants, is removed.
Instead, each specific GPU variant now defines its own power domain
requirements within a self-contained if/then block, making the schema
more explicit.
This new structure is then used to add support for the
`thead,th1520-gpu`. While its BXM-4-64 IP has two conceptual power
domains, the TH1520 SoC integrates them behind a single power gate. The
new binding models this with a specific rule that enforces a single
`power-domains` entry and disallows the `power-domain-names` property.
Michal Wilczynski [Thu, 21 Aug 2025 22:20:15 +0000 (00:20 +0200)]
drm/imagination: Use pwrseq for TH1520 GPU power management
Update the Imagination PVR DRM driver to leverage the pwrseq framework
for managing the complex power sequence of the GPU on the T-HEAD TH1520
SoC.
To cleanly separate platform-specific logic from the generic driver,
this patch introduces an `init` callback to the `pwr_power_sequence_ops`
struct. This allows for different power management strategies to be
selected at probe time based on the device's compatible string.
A `pvr_device_data` struct, associated with each compatible in the
of_device_id table, points to the appropriate ops table (manual or
pwrseq).
At probe time, the driver now calls the `->init()` op. For pwrseq-based
platforms, this callback calls `devm_pwrseq_get("gpu-power")`, deferring
probe if the sequencer is not yet available. For other platforms, it
falls back to the existing manual clock and reset handling. The runtime
PM callbacks continue to call the appropriate functions via the ops
table.
Lukas Bulwahn [Tue, 26 Aug 2025 06:32:48 +0000 (08:32 +0200)]
MAINTAINERS: adjust file entry in DRM ACCEL DRIVER FOR ROCKCHIP NPU
Commit a7352c849492 ("dt-bindings: npu: rockchip,rknn: Add bindings") adds
the device-tree binding rockchip,rk3588-rknn-core.yaml, whereas the commit ed98261b4168 ("accel/rocket: Add a new driver for Rockchip's NPU") adds the
section DRM ACCEL DRIVER FOR ROCKCHIP NPU in MAINTAINERS with a file entry
referring to rockchip,rknn-core.yaml. Note that the file entry is missing
the part rk3588, compared to the added file above, which it intends to
refer to.
Dan Carpenter [Thu, 21 Aug 2025 12:30:19 +0000 (15:30 +0300)]
accel/rocket: Fix some error checking in rocket_core_init()
The problem is that pm_runtime_get_sync() can return 1 on success so
checking for zero doesn't work. Use the pm_runtime_resume_and_get()
function instead. The pm_runtime_resume_and_get() function does
additional cleanup as well so that's a bonus as well.
Brigham Campbell [Wed, 13 Aug 2025 16:02:37 +0000 (10:02 -0600)]
accel/rocket: Fix usages of kfree() and sizeof()
Replace usages of kfree() with kvfree() for pointers which were
allocated using kvmalloc(), as required by the kernel memory management
API.
Use sizeof() on the type that a pointer references instead of the
pointer itself. In this case, scheds and *scheds both happen to be
pointers, so sizeof() will expand to the same value in either case, but
using *scheds is more technically correct since scheds is an array of
drm_gpu_scheduler *.
Marek Vasut [Wed, 13 Aug 2025 21:08:13 +0000 (23:08 +0200)]
drm/rcar-du: dsi: Fix 1/2/3 lane support
Remove fixed PPI lane count setup. The R-Car DSI host is capable
of operating in 1..4 DSI lane mode. Remove the hard-coded 4-lane
configuration from PPI register settings and instead configure
the PPI lane count according to lane count information already
obtained by this driver instance.
Configure TXSETR register to match PPI lane count. The R-Car V4H
Reference Manual R19UH0186EJ0121 Rev.1.21 section 67.2.2.3 Tx Set
Register (TXSETR), field LANECNT description indicates that the
TXSETR register LANECNT bitfield lane count must be configured
such, that it matches lane count configuration in PPISETR register
DLEN bitfield. Make sure the LANECNT and DLEN bitfields are
configured to match.
Fixes: 155358310f01 ("drm: rcar-du: Add R-Car DSI driver") Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250813210840.97621-1-marek.vasut+renesas@mailbox.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
drm/sitronix/st7571-i2c: Make st7571_panel_data variables static const
The kernel test robot reported that sparse gives the following warnings:
make C=2 M=drivers/gpu/drm/sitronix/
CC [M] st7571-i2c.o
CHECK st7571-i2c.c
st7571-i2c.c:1027:26: warning: symbol 'st7567_config' was not declared. Should it be static?
st7571-i2c.c:1039:26: warning: symbol 'st7571_config' was not declared. Should it be static?
MODPOST Module.symvers
LD [M] st7571-i2c.ko
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507180503.nfyD9uRv-lkp@intel.com Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250718152534.729770-1-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Maxime Ripard [Wed, 27 Aug 2025 15:12:44 +0000 (17:12 +0200)]
drm/tidss: dispc: Switch OVR_REG_FLD_MOD to using a mask
The OVR_REG_FLD_MOD function takes the start and end bits as parameter
and will generate a mask out of them.
This makes it difficult to share the masks between callers, since we now
need two arguments and to keep them consistent.
Let's change OVR_REG_FLD_MOD to take the mask as an argument instead,
and let the caller create the mask. Eventually, this mask will be moved
to a define.
Maxime Ripard [Wed, 27 Aug 2025 15:12:43 +0000 (17:12 +0200)]
drm/tidss: dispc: Switch VP_REG_FLD_MOD to using a mask
The VP_REG_FLD_MOD function takes the start and end bits as parameter
and will generate a mask out of them.
This makes it difficult to share the masks between callers, since we now
need two arguments and to keep them consistent.
Let's change VP_REG_FLD_MOD to take the mask as an argument instead, and
let the caller create the mask. Eventually, this mask will be moved to a
define.
Maxime Ripard [Wed, 27 Aug 2025 15:12:41 +0000 (17:12 +0200)]
drm/tidss: dispc: Switch VID_REG_FLD_MOD to using a mask
The VID_REG_FLD_MOD function takes the start and end bits as parameter
and will generate a mask out of them.
This makes it difficult to share the masks between callers, since we now
need two arguments and to keep them consistent.
Let's change VID_REG_FLD_MOD to take the mask as an argument instead,
and let the caller create the mask. Eventually, this mask will be moved
to a define.
Ruben Wauters [Mon, 18 Aug 2025 19:35:26 +0000 (20:35 +0100)]
drm/gud: Replace simple display pipe with DRM atomic helpers
The simple display pipe is obsolete and the atomic helpers allow for
more control over the rendering process. As such, this patch replaces
the old simple display pipe system with the newer atomic helpers.
As the code is mainly the same, merely replaced with the new atomic
system, there should be no change in functionality.
Pierre-Eric Pelloux-Prayer [Wed, 4 Jun 2025 12:28:23 +0000 (14:28 +0200)]
drm/amdgpu: give each kernel job a unique id
Userspace jobs have drm_file.client_id as a unique identifier
as job's owners. For kernel jobs, we can allocate arbitrary
values - the risk of overlap with userspace ids is small (given
that it's a u64 value).
In the unlikely case the overlap happens, it'll only impact
trace events.
Since this ID is traced in the gpu_scheduler trace events, this
allows to determine the source of each job sent to the hardware.
To make grepping easier, the IDs are defined as they will appear
in the trace output.
Qianfeng Rong [Thu, 28 Aug 2025 03:39:17 +0000 (11:39 +0800)]
accel/amdxdna: Use int instead of u32 to store error codes
Change the 'ret' variable from u32 to int to store -EINVAL. Storing the
negative error codes in unsigned type, doesn't cause an issue at runtime
but it's ugly as pants.
Additionally, assigning -EINVAL to u32 ret (i.e., u32 ret = -EINVAL) may
trigger a GCC warning when the -Wsign-conversion flag is enabled.
Danilo Krummrich [Fri, 29 Aug 2025 07:55:39 +0000 (09:55 +0200)]
drm/test: drm_exec: use kzalloc() to allocate GEM objects
Since commit e7fa80e2932c ("drm_gem: add mutex to drm_gem_object.gpuva")
it is possible for test_prepare_array() to exceed a stack frame size of
2048 bytes depending on the exact configuration of the kernel.
drivers/gpu/drm/tests/drm_exec_test.c: In function ‘test_prepare_array’:
drivers/gpu/drm/tests/drm_exec_test.c:171:1: error: the frame size of 2128 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
171 | }
| ^
cc1: all warnings being treated as errors
make[6]: *** [scripts/Makefile.build:287: drivers/gpu/drm/tests/drm_exec_test.o] Error 1
make[6]: *** Waiting for unfinished jobs....
In order to fix this, allocate the GEM objects in test_prepare_array()
with kzalloc(), rather than placing them on the stack.
Cc: Alice Ryhl <aliceryhl@google.com> Cc: Christian König <christian.koenig@amd.com> Fixes: e7fa80e2932c ("drm_gem: add mutex to drm_gem_object.gpuva") Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Nirmoy Das <nirmoyd@nvidia.com> Link: https://lore.kernel.org/r/20250829075633.2306-1-dakr@kernel.org
[ Use kunit_kzalloc() instead of kzalloc(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Maíra Canal [Tue, 26 Aug 2025 14:19:03 +0000 (11:19 -0300)]
drm/v3d: Protect per-fd reset counter against fd release
The per-fd reset counter tracks GPU resets caused by jobs submitted
through a specific file descriptor. However, there's a race condition
where the file descriptor can be closed while jobs are still running,
leading to potential access to freed memory when updating the reset
counter.
Ensure that the per-fd reset counter is only updated when the file
descriptor is still valid, preventing use-after-free scenarios during
GPU reset handling.
Maíra Canal [Tue, 26 Aug 2025 14:19:02 +0000 (11:19 -0300)]
drm/v3d: Synchronous operations can't timeout
CPU jobs and CACHE CLEAN jobs execute synchronously once the DRM
scheduler starts running them. Therefore, there is no fence to wait on,
neither are those jobs able to timeout.
Hence, remove the `timedout_job` hook from the CPU and CACHE CLEAN
scheduler ops.
Maíra Canal [Tue, 26 Aug 2025 14:19:01 +0000 (11:19 -0300)]
drm/v3d: Address race-condition between per-fd GPU stats and fd release
When the file descriptor is closed while a job is still running,
there's a race condition between the job completion callback and the
file descriptor cleanup. This can lead to accessing freed memory when
updating per-fd GPU stats, such as the following example:
Fix such an issue by protecting all accesses to `job->file_priv` with
the queue's lock. With that, we can clear `job->file_priv` before the
V3D per-fd structure is freed and assure that `job->file_priv` exists
during the per-fd GPU stats updates.
Maíra Canal [Tue, 26 Aug 2025 14:19:00 +0000 (11:19 -0300)]
drm/v3d: Replace a global spinlock with a per-queue spinlock
Each V3D queue works independently and all the dependencies between the
jobs are handled through the DRM scheduler. Therefore, there is no need
to use one single lock for all queues. Using it, creates unnecessary
contention between different queues that can operate independently.
Replace the global spinlock with per-queue locks to improve parallelism
and reduce contention between different V3D queues (BIN, RENDER, TFU,
CSD). This allows independent queues to operate concurrently while
maintaining proper synchronization within each queue.
Maíra Canal [Tue, 26 Aug 2025 14:18:59 +0000 (11:18 -0300)]
drm/v3d: Store the active job inside the queue's state
Instead of storing the queue's active job in four different variables,
store the active job inside the queue's state. This way, it's possible
to access all active jobs using an index based in `enum v3d_queue`.
Maíra Canal [Tue, 26 Aug 2025 14:18:58 +0000 (11:18 -0300)]
drm/v3d: Store a pointer to `struct v3d_file_priv` inside each job
Instead of storing a pointer to the DRM file data, store a pointer
directly to the private V3D file struct. No functional change, this
commit only avoids multiple levels of pointer indirection and makes
the code more straightforward.
Dmitry Baryshkov [Wed, 27 Aug 2025 13:29:04 +0000 (16:29 +0300)]
drm/bridge: adv7511: provide SPD and HDMI infoframes
ADV75xx hardware supports sending SPD InfoFrame over the HDMI link. Also
it provides support for two generic (Spare) InfoFrames. Use those
capabilities to be able to send SPD and HDMI Vendor-Specific Infoframes.
Yannick Fertre [Fri, 22 Aug 2025 14:34:17 +0000 (16:34 +0200)]
drm/stm: ltdc: handle lvds pixel clock
Handle LVDS pixel clock.
The LTDC operates with multiple clock domains for register access,
requiring all clocks to be provided during read/write operations. This
imposes a dependency between the LVDS and LTDC to access correctly all
LTDC registers. And because both IPs' pixel rates must be synchronized,
the LTDC has to handle the LVDS clock.
On STM32MP25 SoC, the syscfg peripheral provides a clock to the display
subsystem through a multiplexer. Since it only provides a single clock,
the cell value is 0.
Doing so allows the clock consumers to reach the peripheral and gate the
clock accordingly.
access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).
This property is added when the peripheral is under the STM32 firewall
controller. It allows an accurate representation of the hardware, where
the peripheral is connected to a firewall bus. The firewall can then
check the peripheral accesses before allowing its device to probe.
access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).
This property is added when the peripheral is under the STM32 firewall
controller. It allows an accurate representation of the hardware, where
the peripheral is connected to a firewall bus. The firewall can then check
the peripheral accesses before allowing its device to probe.
Raphael Gallais-Pou [Fri, 22 Aug 2025 14:34:10 +0000 (16:34 +0200)]
dt-bindings: display: st: add two new compatibles to LTDC device
The new STMicroelectronics SoC features a display controller similar to
the one used in previous SoCs. Because there is additional registers,
and different mandatory clocks it is incompatible with existing IPs. On
STM32MP251, the device only needs two clocks while on STM32MP255 it
needs four.
Add the new names to the list of compatible string and handle each
quirks accordingly.
Andy Yan [Fri, 22 Aug 2025 06:39:46 +0000 (14:39 +0800)]
drm/bridge: synopsys: Add DW DPTX Controller support library
The DW DP TX Controller is compliant with the DisplayPort Specification
Version 1.4 with the following features:
* DisplayPort 1.4a
* Main Link: 1/2/4 lanes
* Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbps and 8.1Gbps
* AUX channel 1Mbps
* Single Stream Transport(SST)
* Multistream Transport (MST)
* Type-C support (alternate mode)
* HDCP 2.2, HDCP 1.3
* Supports up to 8/10 bits per color component
* Supports RBG, YCbCr4:4:4, YCbCr4:2:2, YCbCr4:2:0
* Pixel clock up to 594MHz
* I2S, SPDIF audio interface
Add library with common helpers to make it can be shared with
other SoC.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250822063959.692098-3-andyshrk@163.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Andy Yan [Fri, 22 Aug 2025 06:39:45 +0000 (14:39 +0800)]
dt-bindings: display: rockchip: Add schema for RK3588 DPTX Controller
The Rockchip RK3588 SoC integrates the Synopsys DesignWare DPTX
controller. And this DPTX controller need share a USBDP PHY with
the USB 3.0 OTG controller during operation.
Steven Price [Fri, 15 Aug 2025 13:42:24 +0000 (14:42 +0100)]
drm/panthor: Simplify mmu_hw_do_operation_locked
The only callers to mmu_hw_do_operation_locked() pass an 'op' of either
AS_COMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. This means the code paths
after that are dead. Removing those paths means the
mmu_hw_do_flush_on_gpu_ctrl() function might has well be inlined.
Simplify everything by having a switch statement for the type of 'op'
(warning if we get an unexpected value) and removing the dead cases.
Alice Ryhl [Wed, 27 Aug 2025 13:38:39 +0000 (13:38 +0000)]
gpuvm: remove gem.gpuva.lock_dep_map
Since all users of gem.gpuva.lock_dep_map now rely on the mutex directly
in gpuva, we may remove it. Whether the mutex is used is now tracked by
a flag in gpuvm rather than by whether lock_dep_map is null.
Note that a GEM object may not be pushed to multiple gpuvms that
disagree on the value of this new flag. But that's okay because a single
driver should use the same locking scheme everywhere, and a GEM object
is driver specific (when a GEM is exported with prime, a new GEM object
instance is created from the backing dma-buf).
The flag is present even with CONFIG_LOCKDEP=n because the intent is
that the flag will also cause vm_bo cleanup to become deferred. However,
that will happen in a follow-up patch.
Alice Ryhl [Wed, 27 Aug 2025 13:38:38 +0000 (13:38 +0000)]
panthor: use drm_gem_object.gpuva.lock instead of gpuva_list_lock
Now that drm_gem_object has a dedicated mutex for the gpuva list that is
intended to be used in cases that must be fence signalling safe, use it
in Panthor.
Alice Ryhl [Wed, 27 Aug 2025 13:38:37 +0000 (13:38 +0000)]
drm_gem: add mutex to drm_gem_object.gpuva
There are two main ways that GPUVM might be used:
* staged mode, where VM_BIND ioctls update the GPUVM immediately so that
the GPUVM reflects the state of the VM *including* staged changes that
are not yet applied to the GPU's virtual address space.
* immediate mode, where the GPUVM state is updated during run_job(),
i.e., in the DMA fence signalling critical path, to ensure that the
GPUVM and the GPU's virtual address space has the same state at all
times.
Currently, only Panthor uses GPUVM in immediate mode, but the Rust
drivers Tyr and Nova will also use GPUVM in immediate mode, so it is
worth to support both staged and immediate mode well in GPUVM. To use
immediate mode, the GEMs gpuva list must be modified during the fence
signalling path, which means that it must be protected by a lock that is
fence signalling safe.
For this reason, a mutex is added to struct drm_gem_object that is
intended to achieve this purpose. Adding it directly in the GEM object
both makes it easier to use GPUVM in immediate mode, but also makes it
possible to take the gpuva lock from core drm code.
As a follow-up, another change that should probably be made to support
immediate mode is a mechanism to postpone cleanup of vm_bo objects, as
dropping a vm_bo object in the fence signalling path is problematic for
two reasons:
* When using DRM_GPUVM_RESV_PROTECTED, you cannot remove the vm_bo from
the extobj/evicted lists during the fence signalling path.
* Dropping a vm_bo could lead to the GEM object getting destroyed.
The requirement that GEM object cleanup is fence signalling safe is
dubious and likely to be violated in practice.
Panthor already has its own custom implementation of postponing vm_bo
cleanup.
Philipp Stanner [Wed, 13 Aug 2025 08:56:55 +0000 (10:56 +0200)]
drm/sched: Document race condition in drm_sched_fini()
In drm_sched_fini() all entities are marked as stopped - without taking
the appropriate lock, because that would deadlock. That means that
drm_sched_fini() and drm_sched_entity_push_job() can race against each
other.
This should most likely be fixed by establishing the rule that all
entities associated with a scheduler must be torn down first. Then,
however, the locking should be removed from drm_sched_fini() alltogether
with an appropriate comment.
Tvrtko Ursulin [Thu, 14 Aug 2025 13:36:27 +0000 (14:36 +0100)]
drm/sched: Remove mention of indirect buffers
Indirect buffers are an AMD term describing essentialy a job submitted to
the scheduler, just a lower level one. Since scheduler was promoted to be
generic long ago, lets replace those references with jobs.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250814133627.2550-1-tvrtko.ursulin@igalia.com
Dan Carpenter [Wed, 27 Aug 2025 12:57:31 +0000 (15:57 +0300)]
HID: i2c-hid: Fix test in i2c_hid_core_register_panel_follower()
Bitwise AND was intended instead of OR. With the current code the
condition is always true.
Fixes: cbdd16b818ee ("HID: i2c-hid: Make elan touch controllers power on after panel is enabled") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Pin-yen Lin <treapking@chromium.org> Acked-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/aK8Au3CgZSTvfEJ6@stanley.mountain
Thomas Zimmermann [Tue, 26 Aug 2025 14:50:25 +0000 (16:50 +0200)]
drm/sysfb: Do not deref unexisting CRTC state in atomic_disable
Do not access CRTC state in drm_sysfb_plane_helper_atomic_disable().
Use format from sysfb device for clearing scanout buffer. This is
the behavior from before commit 061963cd9e5b ("drm/sysfb: Blit to
CRTC destination format").
When being disabled, the plane has no associated CRTC. Trying to deref
the format pointer results in a segmentation fault. An example stack
track is shown below.
Lizhi Hou [Tue, 26 Aug 2025 17:19:51 +0000 (10:19 -0700)]
accel/amdxdna: Fix incorrect type used for a local variable
drivers/accel/amdxdna/aie2_pci.c:794:13: sparse: sparse: incorrect type in assignment (different address spaces)
Fixes: c8cea4371e5e ("accel/amdxdna: Add a function to walk hardware contexts") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202508230855.0b9efFl6-lkp@intel.com/ Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://lore.kernel.org/r/20250826171951.801585-1-lizhi.hou@amd.com
Thomas Zimmermann [Mon, 14 Jul 2025 15:13:09 +0000 (17:13 +0200)]
drm/vesadrm: Support DRM_FORMAT_C8
Add support for DRM_FORMAT_C8 to vesadrm. The new pixel-format
description PIXEL_FORMAT_C8 describes the layout. Vesadrm's helpers
vesadrm_fill_palette_lut() and vesadrm_load_palette_lut() set the
hardware palette according to the CRTC's output format.
The driver emulates XRGB8888 by converting the source buffer to
RGB332 and using the resulting 256 colors as index into the hardware
palette. The hardware palette converts back to RGB during scanout.
This has no overhead compared to other format conversion, but allows
common userspace, such as Wayland compositors, to operate on the
display.
Thomas Zimmermann [Mon, 14 Jul 2025 15:13:08 +0000 (17:13 +0200)]
drm/vesadrm: Prepare color management for palette-based framebuffers
Distiguish between component-based formats and 'the rest' in vesadrm's
color management. Scanout buffers with component-based format allow
for gamma correction. Palette-based formats (i.e., 'the rest') require
palette setup.
Thomas Zimmermann [Mon, 14 Jul 2025 15:13:07 +0000 (17:13 +0200)]
drm/vesadrm: Rename vesadrm_set_gamma_lut() to vesadrm_set_color_lut()
Rename vesadrm's gamma helpers in preparation of the upcoming support
for color palettes. Gamma correction and color palettes share the same
hardware features, but the driver's old naming only indicated support
for gamma LUTs.
Thomas Zimmermann [Mon, 14 Jul 2025 15:13:05 +0000 (17:13 +0200)]
drm/color-mgmt: Prepare for RGB332 palettes
Add helper drm_crtc_fill_palette_332(), which fills palettes with
RGB332 color data. Each color in RGB332 format serves as an index
into an 8-bit palette that stores the corresponding component-based
colors.
Vesadrm will use the new helper to emulate RGB formats on top of
framebuffers in C8 format.
Thomas Zimmermann [Mon, 14 Jul 2025 15:13:04 +0000 (17:13 +0200)]
drm/sysfb: Blit to CRTC destination format
Use the color format stored in struct drm_sysfb_crtc_state for
color-format conversion instead of the scanout-buffer format
announced by firmware. Currently, both values are identical.
This will allow drivers to modify the CRTC's input format to a
certain extend. Specifically, vesadrm will be able to display RGB
framebuffers when the scanout buffer is of C8 format. With color-
format conversion to RGB332 and correct setup of the C8 palette,
displaying XRGB8888-based buffers under C8 can be achieved.
Thomas Zimmermann [Mon, 14 Jul 2025 15:13:03 +0000 (17:13 +0200)]
drm/sysfb: Find screen_info format with helpers
Convert drm_sysfb_get_format_si() to lookup the screen_info color
format as struct pixel_format with screen_info_pixel_format(). Then
search the list of given formats for the screen_info format with
pixel_format_equal().
Replaces custom code with helpers. The pixel-compare helper
pixel_format_equal() also handles indexed color formats. Prepares
for sysfb drivers to support color palettes.
Thomas Zimmermann [Mon, 14 Jul 2025 15:13:02 +0000 (17:13 +0200)]
video: screen_info: Add pixel-format helper for linear framebuffers
Add screen_info_pixel_format(), which converts a screen_info's
information about the color format to struct pixel_format. The encoding
within the screen_info structure is complex and therefore prone to
errors. Later patches will convert callers to use the pixel format.
Pin-yen Lin [Mon, 18 Aug 2025 11:49:34 +0000 (19:49 +0800)]
HID: i2c-hid: Make elan touch controllers power on after panel is enabled
Introduce a new HID quirk to indicate that this device has to be enabled
after the panel's backlight is enabled, and update the driver data for
the elan devices to enable this quirk. This cannot be a I2C HID quirk
because the kernel needs to acknowledge this before powering up the
device and read the VID/PID. When this quirk is enabled, register
.panel_enabled()/.panel_disabling() instead for the panel follower.
Also rename the *panel_prepare* functions into *panel_follower* because
they could be called in other situations now.
Fixes: bd3cba00dcc63 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens") Fixes: d06651bebf99e ("HID: i2c-hid: elan: Add elan-ekth6a12nay timing") Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Pin-yen Lin <treapking@chromium.org> Acked-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250818115015.2909525-2-treapking@chromium.org
Pin-yen Lin [Mon, 18 Aug 2025 11:49:33 +0000 (19:49 +0800)]
drm/panel: Allow powering on panel follower after panel is enabled
Some touch controllers have to be powered on after the panel's backlight
is enabled. To support these controllers, introduce .panel_enabled() and
.panel_disabling() to panel_follower_funcs and use them to power on the
device after the panel and its backlight are enabled.
Dmitry Baryshkov [Sat, 23 Aug 2025 00:12:00 +0000 (03:12 +0300)]
drm/msm: fix msm_gem_vma_new() allocations for managed GPUVMs
Since commit 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") MSM
driver fails to init, failing with "[drm:msm_gpu_init] *ERROR* could not
allocate memptrs: -22" errors. The mentioned commit reworked the
function, but didn't take into account that op_map is initialized at the
top of the function, while ranges might change if GPUVM is managed by
the kernel.
Move op_mode initialization after finalizing all addresses and right
before the drm_gpuva_init_from_op() call.
Reported-by: Danct12 <danct12@disroot.org> Fixes: 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") Suggested-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Rob Clark <robin.clark@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250823-msm-fix-gpuvm-init-v1-1-e199cd5b1983@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Add the necessary specific bits to support the rk3576-variant of the
DW-DSI2 controller.
Signed-off-by: Guochun Huang <hero.huang@rock-chips.com>
[adapted from the vendor-kernel for mainline] Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250707164906.1445288-10-heiko@sntech.de
dt-bindings: vendor-prefixes: Add prefix for Shenzhen Bestar Electronic
Add the prefix for Bestar, named in full both on Panelook.com and their
display datasheets as
Shenzhen Bestar Electronic Technology Co., Ltd.
which produces at least DSI displays and maybe more.
drm/panel: ilitek-ili9881c: move display_on/_off dcs calls to (un-)prepare
At least for panel-bridges, the atomic_enable call is defined as being
called right after the preceding element in the display pipe is enabled.
It is also stated that "The bridge can assume that the display pipe (i.e.
clocks and timing signals) feeding it is running when this callback is
called"
This means the DSI controller driving this display would have already
switched over to video-mode from command mode and thus dcs functions
should not be called anymore at this point.
This caused a non-working display for me, when trying to enable
the rk3576 dsi controller using a display using this controller.
Therefore move the display_on/off calls the more appropriate
prepare/unprepare callbacks.
drm/panel: ilitek-ili9881c: turn off power-supply when init fails
The prepare function turns on the power-supply regulator first, when
preparing the display. But in an error case, just returns the error
code, but does not power off the regulator again, fix that.
Xaver Hugl [Fri, 22 Aug 2025 15:28:49 +0000 (17:28 +0200)]
drm: re-allow no-op changes on non-primary planes in async flips
Commit fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to
async flip") unintentionally disallowed no-op changes on non-primary
planes that the driver doesn't allow async flips on. This broke async
flips for compositors that disable the cursor plane in every async
atomic commit. To fix that, change drm_atomic_set_property to again
only run atomic_async_check if the plane would actually be changed by
the atomic commit.
Fixes: fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to async flip") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263 Signed-off-by: Xaver Hugl <xaver.hugl@kde.org> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://lore.kernel.org/r/20250822152849.87843-1-xaver.hugl@kde.org
[andrealmeid: fix checkpatch warning] Signed-off-by: André Almeida <andrealmeid@igalia.com>
projects / users / hch / misc.git / log