drm/sched: Allow drivers to skip the reset and keep on running
When the DRM scheduler times out, it's possible that the GPU isn't hung;
instead, a job just took unusually long (longer than the timeout) but is
still running, and there is, thus, no reason to reset the hardware. This
can occur in two scenarios:
1. The job is taking longer than the timeout, but the driver determined
through a GPU-specific mechanism that the hardware is still making
progress. Hence, the driver would like the scheduler to skip the
timeout and treat the job as still pending from then onward. This
happens in v3d, Etnaviv, and Xe.
2. Timeout has fired before the free-job worker. Consequently, the
scheduler calls `sched->ops->timedout_job()` for a job that isn't
timed out.
These two scenarios are problematic because the job was removed from the
`sched->pending_list` before calling `sched->ops->timedout_job()`, which
means that when the job finishes, it won't be freed by the scheduler
though `sched->ops->free_job()` - leading to a memory leak.
To solve these problems, create a new `drm_gpu_sched_stat`, called
DRM_GPU_SCHED_STAT_NO_HANG, which allows a driver to skip the reset. The
new status will indicate that the job must be reinserted into
`sched->pending_list`, and the hardware / driver will still complete that
job.
drm/sched: Rename DRM_GPU_SCHED_STAT_NOMINAL to DRM_GPU_SCHED_STAT_RESET
Among the scheduler's statuses, the only one that indicates an error is
DRM_GPU_SCHED_STAT_ENODEV. Any status other than DRM_GPU_SCHED_STAT_ENODEV
signifies that the operation succeeded and the GPU is in a nominal state.
However, to provide more information about the GPU's status, it is needed
to convey more information than just "OK".
Therefore, rename DRM_GPU_SCHED_STAT_NOMINAL to
DRM_GPU_SCHED_STAT_RESET, which better communicates the meaning of this
status. The status DRM_GPU_SCHED_STAT_RESET indicates that the GPU has
hung, but it has been successfully reset and is now in a nominal state
again.
dt-bindings: display: rockchip,dw-mipi-dsi: Drop address/size cells
The "rockchip,dw-mipi-dsi" binding has allOf "snps,dw-mipi-dsi.yaml"
which has allOf "dsi-controller.yaml", which already has #address-cells
and #size-cells defined as '1' and '0' respectively.
So drop this re-definition.
Val Packett [Sun, 6 Jul 2025 20:50:27 +0000 (17:50 -0300)]
drm/panel-edp: Add BOE NE14QDM panel for Dell Latitude 7455
Cannot confirm which variant exactly it is, as the EDID alphanumeric data
contains '0RGNR' <0x80> 'NE14QDM' and ends there; but it's 60 Hz and with
touch.
I do not have access to datasheets for these panels, so the timing is
a guess that was tested to work fine on this laptop.
Commit ec62d37d2c0d("drm/panthor: Fix the fast-reset logic") did away
with the only reference to panthor_vm_flush_all(), so let's get rid
of the orphaned definition.
Andy Yan [Thu, 3 Jul 2025 12:49:53 +0000 (20:49 +0800)]
drm/bridge: Pass down connector to drm bridge detect hook
In some application scenarios, we hope to get the corresponding
connector when the bridge's detect hook is invoked.
In most cases, we can get the connector by drm_atomic_get_connector_for_encoder
if the encoder attached to the bridge is enabled, however there will
still be some scenarios where the detect hook of the bridge is called
but the corresponding encoder has not been enabled yet. For instance,
this occurs when the device is hot plug in for the first time.
Since the call to bridge's detect is initiated by the connector, passing
down the corresponding connector directly will make things simpler.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250703125027.311109-3-andyshrk@163.com
[DB: added the chunk to the cdn-dp driver] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Andy Yan [Thu, 3 Jul 2025 12:49:52 +0000 (20:49 +0800)]
drm/bridge: Make dp/hdmi_audio_* callback keep the same paramter order with get_modes
Make the dp/hdmi_audio_* callback maintain the same parameter order as
get_modes and edid_read: first the bridge, then the connector.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250703125027.311109-2-andyshrk@163.com
[DB: added the chunk to the cdn-dp driver] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
PM: hibernate: Add stub for pm_hibernate_is_recovering()
Randy reports that amdgpu fails to compile with the following error:
ERROR: modpost: "pm_hibernate_is_recovering" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
This happens because pm_hibernate_is_recovering() is only compiled when
CONFIG_PM_SLEEP is set. Add a stub for it so that drivers don't need
to depend upon CONFIG_PM.
Cc: Samuel Zhang <guoqing.zhang@amd.com> Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/dri-devel/CAJZ5v0h1CX+aTu7dFy6vB-9LM6t5J4rt7Su3qVnq1xx-BFAm=Q@mail.gmail.com/T/#m2b9fe212b35fde11d58fcbc4e0727bc02ebba7b0 Fixes: c2aaddbd2dede ("PM: hibernate: add new api pm_hibernate_is_recovering()") Acked-by: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20250712233715.821424-1-superm1@kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Alice Ryhl [Fri, 11 Jul 2025 08:04:38 +0000 (08:04 +0000)]
drm: rust: rename as_ref() to from_raw() for drm constructors
The prefix as_* should not be used for a constructor. Constructors
usually use the prefix from_* instead.
Some prior art in the stdlib: Box::from_raw, CString::from_raw,
Rc::from_raw, Arc::from_raw, Waker::from_raw, File::from_raw_fd.
There is also prior art in the kernel crate: cpufreq::Policy::from_raw,
fs::File::from_raw_file, Kuid::from_raw, ARef::from_raw,
SeqFile::from_raw, VmaNew::from_raw, Io::from_raw.
André Almeida [Fri, 4 Jul 2025 03:06:29 +0000 (00:06 -0300)]
drm/amdgpu: Fix lifetime of struct amdgpu_task_info after ring reset
When a ring reset happens, amdgpu calls drm_dev_wedged_event() using
struct amdgpu_task_info *ti as one of the arguments. After using *ti, a
call to amdgpu_vm_put_task_info(ti) is required to correctly track its
lifetime.
However, it's called from a place that the ring reset path never reaches
due to a goto after drm_dev_wedged_event() is called. Move
amdgpu_vm_put_task_info() bellow the exit label to make sure that it's
called regardless of the code path.
amdgpu_vm_put_task_info() can only accept a valid address or NULL as
argument, so initialise *ti to make sure we can call this function if
*ti isn't used.
Fixes: a72002cb181f ("drm/amdgpu: Make use of drm_wedge_task_info") Reported-by: Dave Airlie <airlied@gmail.com> Closes: https://lore.kernel.org/dri-devel/CAPM=9tz0rQP8VZWKWyuF8kUMqRScxqoa6aVdwWw9=5yYxyYQ2Q@mail.gmail.com/ Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250704030629.1064397-1-andrealmeid@igalia.com Signed-off-by: André Almeida <andrealmeid@igalia.com>
include/drm/drm_device.h:40: warning: Function parameter or struct member 'pid' not described in 'drm_wedge_task_info'
include/drm/drm_device.h:40: warning: Function parameter or struct member 'comm' not described in 'drm_wedge_task_info'
Fixes: 183bccafa176 ("drm: Create a task info option for wedge events") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/lkml/20250618151307.4a1a5e17@canb.auug.org.au/ Reviewed-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20250704190724.1159416-2-andrealmeid@igalia.com Signed-off-by: André Almeida <andrealmeid@igalia.com>
Samuel Zhang [Thu, 10 Jul 2025 06:23:13 +0000 (14:23 +0800)]
drm/amdgpu: do not resume device in thaw for normal hibernation
For normal hibernation, GPU do not need to be resumed in thaw since it is
not involved in writing the hibernation image. Skip resume in this case
can reduce the hibernation time.
On VM with 8 * 192GB VRAM dGPUs, 98% VRAM usage and 1.7TB system memory,
this can save 50 minutes.
Signed-off-by: Samuel Zhang <guoqing.zhang@amd.com> Tested-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Link: https://lore.kernel.org/r/20250710062313.3226149-6-guoqing.zhang@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Samuel Zhang [Thu, 10 Jul 2025 06:23:12 +0000 (14:23 +0800)]
PM: hibernate: add new api pm_hibernate_is_recovering()
dev_pm_ops.thaw() is called in following cases:
* normal case: after hibernation image has been created.
* error case 1: creation of a hibernation image has failed.
* error case 2: restoration from a hibernation image has failed.
For normal case, it is called mainly for resume storage devices for
saving the hibernation image. Other devices that are not involved
in the image saving do not need to resume the device. But since there's
no api to know which case thaw() is called, device drivers can't
conditionally resume device in thaw().
The new pm_hibernate_is_recovering() is such a api to query if thaw() is
called in normal case.
Samuel Zhang [Thu, 10 Jul 2025 06:23:11 +0000 (14:23 +0800)]
PM: hibernate: shrink shmem pages after dev_pm_ops.prepare()
When hibernate with data center dGPUs, huge number of VRAM data will be
moved to shmem during dev_pm_ops.prepare(). These shmem pages take a lot
of system memory so that there's no enough free memory for creating the
hibernation image. This will cause hibernation fail and abort.
After dev_pm_ops.prepare(), call shrink_all_memory() to force move shmem
pages to swap disk and reclaim the pages, so that there's enough system
memory for hibernation image and less pages needed to copy to the image.
This patch can only flush and free about half shmem pages. It will be
better to flush and free more pages, even all of shmem pages, so that
there're less pages to be copied to the hibernation image and the overall
hibernation time can be reduced.
Samuel Zhang [Thu, 10 Jul 2025 06:23:10 +0000 (14:23 +0800)]
drm/amdgpu: move GTT to shmem after eviction for hibernation
When hibernate with data center dGPUs, huge number of VRAM BOs evicted
to GTT and takes too much system memory. This will cause hibernation
fail due to insufficient memory for creating the hibernation image.
Move GTT BOs to shmem in KMD, then shmem to swap disk in kernel
hibernation code to make room for hibernation image.
Samuel Zhang [Thu, 10 Jul 2025 06:23:09 +0000 (14:23 +0800)]
drm/ttm: add new api ttm_device_prepare_hibernation()
This new api is used for hibernation to move GTT BOs to shmem after
VRAM eviction. shmem will be flushed to swap disk later to reduce
the system memory usage for hibernation.
Philipp Stanner [Thu, 10 Jul 2025 12:54:12 +0000 (14:54 +0200)]
drm/nouveau: Remove waitque for sched teardown
struct nouveau_sched contains a waitque needed to prevent
drm_sched_fini() from being called while there are still jobs pending.
Doing so so far would have caused memory leaks.
With the new memleak-free mode of operation switched on in
drm_sched_fini() by providing the callback nouveau_sched_cancel_job()
the waitque is not necessary anymore.
Philipp Stanner [Thu, 10 Jul 2025 12:54:10 +0000 (14:54 +0200)]
drm/nouveau: Make fence container helper usable driver-wide
In order to implement a new DRM GPU scheduler callback in Nouveau, a
helper for obtaining a nouveau_fence from a dma_fence is necessary. Such
a helper exists already inside nouveau_fence.c, called from_fence().
Make that helper available to other C files with a more precise name.
Philipp Stanner [Thu, 10 Jul 2025 12:54:08 +0000 (14:54 +0200)]
drm/sched/tests: Add unit test for cancel_job()
The scheduler unit tests now provide a new callback, cancel_job(). This
callback gets used by drm_sched_fini() for all still pending jobs to
cancel them.
Philipp Stanner [Thu, 10 Jul 2025 12:54:07 +0000 (14:54 +0200)]
drm/sched/tests: Implement cancel_job() callback
The GPU Scheduler now supports a new callback, cancel_job(), which lets
the scheduler cancel all jobs which might not yet be freed when
drm_sched_fini() runs. Using this callback allows for significantly
simplifying the mock scheduler teardown code.
Implement the cancel_job() callback and adjust the code where necessary.
Philipp Stanner [Thu, 10 Jul 2025 12:54:06 +0000 (14:54 +0200)]
drm/sched: Avoid memory leaks with cancel_job() callback
Since its inception, the GPU scheduler can leak memory if the driver
calls drm_sched_fini() while there are still jobs in flight.
The simplest way to solve this in a backwards compatible manner is by
adding a new callback, drm_sched_backend_ops.cancel_job(), which
instructs the driver to signal the hardware fence associated with the
job. Afterwards, the scheduler can safely use the established free_job()
callback for freeing the job.
Implement the new backend_ops callback cancel_job().
drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs code
The object is potentially already gone after the drm_gem_object_put().
In general the object should be fully constructed before calling
drm_gem_handle_create(), except the debugfs tracking uses a separate
lock and list and separate flag to denotate whether the object is
actually initialized.
Since I'm touching this all anyway simplify this by only adding the
object to the debugfs when it's ready for that, which allows us to
delete that separate flag. panthor_gem_debugfs_bo_rm() already checks
whether we've actually been added to the list or this is some error
path cleanup.
v2: Fix build issues for !CONFIG_DEBUGFS (Adrián)
v3: Add linebreak and remove outdated comment (Liviu)
Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS") Cc: Adrián Larumbe <adrian.larumbe@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Simona Vetter <simona.vetter@intel.com> Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250709135220.1428931-1-simona.vetter@ffwll.ch
Set VGACRB6[5], which disables asynchronous sequencer resets via
VGASR0[1]. This was most likely an oversight when adding support
for Gen7. Aligns Gen7 with the earlier Gen4+.
drm/ast: Split ast_set_def_ext_reg() by chip generation
Duplicate ast_set_def_ext_reg() for individual chip generations
and move call it into per-chip source files. Remove the original
code. AST2100 and AST2500 reuse the function from earlier chips.
AST2600 appears to be incorrect as it uses an older function. Keep
this behavior for now.
drm/ast: Move Gen2+ and Gen1 POST code to separate source files
Move POST code for Gen2+ and Gen1 to separate source files and
hide it in ast_2100_post() ans ast_2000_post(). With P2A
configuration, the POST logic for these chip generations has
been mingled in ast_init_dram_reg(). Hence, handle all generations
in a single change. The split simplifies both cases. Also move
the DRAM init tables for each Gen into the respective source
file. No changes to the overall logic.
drm/ast: Move Gen4+ POST code to separate source file
Move POST code for Gen4+ to separate source file and hide it in
ast_2300_post(). With P2A configuration, it performs a full board
POST and enables the transmitter chip; otherwise it only enables the
transmitter chip.
Also fix coding style in several places. No changes to the overall
logic.
drm/ast: Move Gen6+ POST code to separate source file
Move POST code for Gen6+ to separate source file and hide it in
ast_2500_post(). With P2A configuration, it performs a full board
POST; otherwise it enables the transmitter chip. No changes to the
overall logic.
drm/ast: Move Gen7+ POST code to separate source file
Move POST code for Gen7+ to separate source file and hide it in
ast_2600_post(). There's not much going on here except for enabling
the DP transmitter chip.
Jared Kangas [Tue, 10 Jun 2025 13:12:31 +0000 (06:12 -0700)]
dma-buf: heaps: Give default CMA heap a fixed name
The CMA heap's name in devtmpfs can vary depending on how the heap is
defined. Its name defaults to "reserved", but if a CMA area is defined
in the devicetree, the heap takes on the devicetree node's name, such as
"default-pool" or "linux,cma". To simplify naming, unconditionally name
it "default_cma_region", but keep a legacy node in place backed by the
same underlying allocator for backwards compatibility.
Jared Kangas [Tue, 10 Jun 2025 13:12:29 +0000 (06:12 -0700)]
Documentation: dma-buf: heaps: Fix code markup
Code snippets should be wrapped in double backticks to follow
reStructuredText semantics; the use of single backticks uses the
:title-reference: role by default, which isn't quite what we want.
Add double backticks to code snippets to fix this.
T.J. Mercier [Thu, 17 Apr 2025 18:09:41 +0000 (18:09 +0000)]
dma-buf: system_heap: No separate allocation for attachment sg_tables
struct dma_heap_attachment is a separate allocation from the struct
sg_table it contains, but there is no reason for this. Let's use the
slab allocator just once instead of twice for dma_heap_attachment.
drm/sti: hda: convert to devm_drm_bridge_alloc() API
devm_drm_bridge_alloc() is the new API to be used for allocating (and
partially initializing) a private driver struct embedding a struct
drm_bridge.
This driver was missed during the automated conversion in commit 9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to
devm_drm_bridge_alloc() API") and following commits.
The lack of conversion for this driver is a bug since commit a7748dd127ea
("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()")
which is the first commmit having added a drm_bridge_get/put() pair and
thus exposing the incorrect initial refcount issue.
Fix this by switching the driver to the new API.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/ce9c6aa3-5372-468f-a4bf-5a261259e459@samsung.com/ Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250708-drm-bridge-convert-to-alloc-api-leftovers-v1-2-6285de8c3759@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
drm/sti: hdmi: convert to devm_drm_bridge_alloc() API
devm_drm_bridge_alloc() is the new API to be used for allocating (and
partially initializing) a private driver struct embedding a struct
drm_bridge.
This driver was missed during the automated conversion in commit 9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to
devm_drm_bridge_alloc() API") and following commits.
The lack of conversion for this driver is a bug since commit a7748dd127ea
("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()")
which is the first commmit having added a drm_bridge_get/put() pair and
thus exposing the incorrect initial refcount issue.
Fix this by switching the driver to the new API.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/ce9c6aa3-5372-468f-a4bf-5a261259e459@samsung.com/ Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250708-drm-bridge-convert-to-alloc-api-leftovers-v1-1-6285de8c3759@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
drm/amdgpu: fix the logic to validate fpriv and root bo
Fix the smatch warning,
smatch warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:2146 amdgpu_pt_info_read()
error: we previously assumed 'fpriv' could be null (see line 2146)
"if (!fpriv && !fpriv->vm.root.bo)", It has to be an OR condition
rather than an AND which makes an NULL dereference in case fpriv is NULL.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507090525.9rDWGhz3-lkp@intel.com/ Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Link: https://lore.kernel.org/r/20250709071618.591866-1-sunil.khatri@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
Andy Yan [Mon, 21 Apr 2025 10:21:54 +0000 (18:21 +0800)]
drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there are multi display output on rk3588/rk3568
The all video ports of rk3568/rk3588 share the same OVL_LAYER_SEL
and OVL_PORT_SEL registers, and the configuration of these two registers
can be set to take effect when the vsync signal arrives at a certain Video
Port.
If two threads for two display output choose to update these two registers
simultaneously to meet their own plane adjustment requirements(change plane
zpos or switch plane from one crtc to another), then no matter which Video
Port'svsync signal we choose to follow for these two registers, the display
output of the other Video Port will be abnormal.
This is because the configuration of this Video Port does not take
effect at the right time (its configuration should take effect when its
VSYNC signal arrives).
In order to solve this problem, when performing plane migration or
change the zpos of planes, there are two things to be observed and
followed:
1. When a plane is migrated from one VP to another, the configuration of
the layer can only take effect after the Port mux configuration is
enabled.
2. When change the zpos of planes, we must ensure that the change for
the previous VP takes effect before we proceed to change the next VP.
Otherwise, the new configuration might overwrite the previous one for
the previous VP, or it could lead to the configuration of the previous
VP being take effect along with the VSYNC of the new VP.
This issue only occurs in scenarios where multi-display output is enabled.
Fixes: c5996e4ab109 ("drm/rockchip: vop2: Make overlay layer select register configuration take effect by vsync") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250421102156.424480-1-andyshrk@163.com
Andy Yan [Mon, 12 May 2025 12:46:05 +0000 (20:46 +0800)]
drm/rockchip: inno_hdmi: Rename function inno_hdmi_reset to inno_hdmi_init_hw
This function not only configure hardware reset register, but also
do some other configurations. Therefore, it is more appropriate to
name it inno_hdmi_init_hw, which will also facilitate the addition
of other functions to this function in the following patch.
Yumeng Fang [Thu, 15 May 2025 12:35:54 +0000 (20:35 +0800)]
drm/rockchip: dw_hdmi: Use dev_err_probe() to simplify code
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later through debugfs.
Chaoyi Chen [Thu, 29 May 2025 07:13:34 +0000 (15:13 +0800)]
drm/rockchip: cdn-dp: Convert to drm bridge
Convert it to drm bridge driver, it will be convenient for us to
migrate the connector part to the display driver later.
Considering that some code depend on the connector, the following
changes have been made:
- Only process edid in &drm_bridge_funcs.edid_read(), so no need to
store additional edid info.
- Now cdn_dp_get_sink_capability() only focused on reading DPCD_REV.
- Update bpc info in cdn_dp_bridge_atomic_enable() instead of
cdn_dp_encoder_mode_set(). Actually, the bpc data will be used in
cdn_dp_bridge_atomic_enable().
- Switch to use DRM_BRIDGE_OP_DP_AUDIO helpers.
This patch also convert to use devm_drm_bridge_alloc() API.
Heiko Stuebner [Tue, 10 Jun 2025 21:27:48 +0000 (23:27 +0200)]
drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port
Each window of a vop2 is usable by a specific set of video ports, so while
binding the vop2, we look through the list of available windows trying to
find one designated as primary-plane and usable by that specific port.
The code later wants to use drm_crtc_init_with_planes with that found
primary plane, but nothing has checked so far if a primary plane was
actually found.
For whatever reason, the rk3576 vp2 does not have a usable primary window
(if vp0 is also in use) which brought the issue to light and ended in a
null-pointer dereference further down.
As we expect a primary-plane to exist for a video-port, add a check at
the end of the window-iteration and fail probing if none was found.
Merge tag 'drm-msm-next-2025-07-05' of https://gitlab.freedesktop.org/drm/msm into drm-next
Updates for v6.17
CI:
- uprev mesa and ci-templates
- use shallow clone to speed up build jobs
- remove sdm845/cheza jobs. These runners are no more (RIP
dear chezas)
- fix runner tag for i915 cml runners
- uprev igt to pull in msm test fixes
Core:
- VM_BIND support!
- single source of truth for UBWC configuration. Adds a global soc
driver for UBWC config which is used from display and GPU. (And
later vidc/camera/etc)
- Decouple ties between GPU and KMS, adding a `separate_gpu_kms`
modparam to allow the GPU and KMS to bind to separate DRM devices.
This should better deal with more exotic SoC configurations where
the number of GPUs is different from number of DPUs. The default
behavior is to still come up as a single unified DRM device to
avoid surprising userspace.
DP:
- major rework of the I/O accessors
DPU:
- use version checks instead of feature bits
- SM8750 support
- set min_prefill_lines for SC8180X
Merge tag 'drm-intel-next-2025-07-04' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
drm/i915 feature pull #2 for v6.17:
Features and functionality:
- Add drm_panic support for both i915 and xe drivers (Jocelyn Falempe)
- Add initial flip queue implementation, disabled by default, for LNL and PTL
(Ville)
- Add support for Wildcat Lake (WCL) display, version 30.02 (Matt Roper, Matt
Atwood, Dnyaneshwar)
- Extend drm_panel and follower support to DDI eDP (Arun)
Refactoring and cleanups:
- Make all global state objects opaque (Jani)
- Move display works to display specific unordered workqueue (Luca)
- Add and use struct drm_device based pcode interface (Jani, Lucas)
- Use clamp() instead of max()+min() combo (Ankit)
- Simplify wait for power well disable (Jani)
- Various stylistics cleanups and renames (Jani)
Fixes:
- Deal with loss of pipe DMC state (Ville)
- Fix PTL HDCP2 stream status check (Suraj)
- Add workaround for ADL-P DKL PHY DP and HDMI (Nemesa)
- Fix skl_print_wm_changes() stack usage with KMSAN (Arnd Bergmann)
- Fix PCON capability reads on non-branch devices (Chaitanya)
- Fix which platforms have ultra joiner (Ankit)
DRM core changes:
- Add ttm_bo_kmap_try_from_panic() for xe drm_panic support (Jocelyn Falempe)
- Add private pointer to struct drm_scanout buffer for xe/i915 drm_panic support
(Jocelyn Falempe)
Merges:
- Backmerge drm-next for drm_panel and xe changes (Jani)
Avoid dereferencing struct drm_gem_object.import_attach for the
imported dma-buf. The dma_buf field in the GEM object instance refers
to the same buffer. Prepares to make import_attach an implementation
detail of PRIME.
The vgem driver does not need to create a platform device, as there is
no real platform resources associated it, it only did so because it was
simple to do that in order to get a device to use for resource
management of drm resources. Change the driver to use the faux device
instead as this is NOT a real platform device.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/2025070114-iron-shiny-b92e@gregkh
The vkms driver does not need to create a platform device, as there is
no real platform resources associated it, it only did so because it was
simple to do that in order to get a device to use for resource
management of drm resources. Change the driver to use the faux device
instead as this is NOT a real platform device.
Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: Melissa Wen <melissa.srw@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/2025070147-antics-pleat-edd2@gregkh
The vast majority of drivers that use GEM-SHMEM helpers do not use
an s/g table for imported buffers; specifically all drivers that use
DRM_GEM_SHMEM_DRIVER_OPS. Therefore convert the initializer macro
to DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT and remove the latter. This
helps to avoid swiotbl errors, such as seen with some Aspeed systems
ast 0000:07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768 (slots), used 0 (slots)
The error is caused by the system's limited DMA capabilities and can
happen with any GEM-SHMEM-based driver. It results in a performance
penalty.
In the case of vgem and vkms, the devices do not support DMA at all,
which can result in failure to map the buffer object into the kernel's
address space. [1][2] Avoiding the s/g table fixes this problem.
The other drivers based on GEM-SHMEM, imagination, lima, panfrost,
panthor, v3d and virtio, use the s/g table of imported buffers. Neither
driver uses the default initializer, so they won't be affected by
this change.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Zenghui Yu <zenghui.yu@linux.dev> Closes: https://lore.kernel.org/dri-devel/6d22bce3-4533-4cfa-96ba-64352b715741@linux.dev/ # [1] Reported-by: José Expósito <jose.exposito89@gmail.com> Closes: https://lore.kernel.org/dri-devel/20250311172054.2903-1-jose.exposito89@gmail.com/ # [2] Tested-by: Zenghui Yu <zenghui.yu@linux.dev> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://lore.kernel.org/r/20250630143537.309052-1-tzimmermann@suse.de
Commit a59a27176914 ("drm/bridge: tc358767: convert to
devm_drm_bridge_alloc() API") split tc_probe_bridge_endpoint() in two
functions, thus duplicating the loop over the endpoints in each of those
functions. However it missed duplicating the of_graph_parse_endpoint() call
which initializes the struct of_endpoint, resulting in an uninitialized
read.
Fixes: a59a27176914 ("drm/bridge: tc358767: convert to devm_drm_bridge_alloc() API") Cc: stable@vger.kernel.org Reported-by: Colin King (gmail) <colin.i.king@gmail.com> Closes: https://lore.kernel.org/all/056b34c3-c1ea-4b8c-9672-c98903ffd012@gmail.com/ Reviewed-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250704-drm-bridge-alloc-fix-tc358767-regression-v2-1-ec0e511bedd0@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Marek Szyprowski [Fri, 27 Jun 2025 16:56:52 +0000 (18:56 +0200)]
drm/bridge: analogix_dp: Use devm_drm_bridge_alloc() API
devm_drm_bridge_alloc() is the new API to be used for allocating
(and partially initializing) a private driver struct embedding
a struct drm_bridge.
Analogix DP driver somehow missed the automated conversion in commit 9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to
devm_drm_bridge_alloc() API"), what causes the following warning:
------------[ cut here ]------------
WARNING: lib/refcount.c:25 at drm_bridge_attach+0x2c/0x248, CPU#1: kworker/u8:1/34
refcount_t: addition on 0; use-after-free.
Modules linked in:
CPU: 1 UID: 0 PID: 34 Comm: kworker/u8:1 Not tainted 6.16.0-rc3-next-20250627-dirty #15839 PREEMPT
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x68/0x88
dump_stack_lvl from __warn+0x94/0x1f0
__warn from warn_slowpath_fmt+0x124/0x1bc
warn_slowpath_fmt from drm_bridge_attach+0x2c/0x248
drm_bridge_attach from analogix_dp_bind+0x70/0xc8
analogix_dp_bind from exynos_dp_bind+0x58/0xc4
exynos_dp_bind from component_bind_all+0x11c/0x27c
component_bind_all from exynos_drm_bind+0xe8/0x198
exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8
try_to_bring_up_aggregate_device from __component_add+0xb0/0x170
__component_add from exynos_dp_probe+0xc0/0x164
exynos_dp_probe from platform_probe+0x5c/0xb8
platform_probe from really_probe+0xe0/0x3d8
really_probe from __driver_probe_device+0x9c/0x1e0
__driver_probe_device from driver_probe_device+0x30/0xc0
driver_probe_device from __device_attach_driver+0xa8/0x120
__device_attach_driver from bus_for_each_drv+0x84/0xdc
bus_for_each_drv from __device_attach+0xb0/0x20c
__device_attach from bus_probe_device+0x8c/0x90
bus_probe_device from deferred_probe_work_func+0x98/0xe0
deferred_probe_work_func from process_one_work+0x24c/0x70c
process_one_work from worker_thread+0x1b8/0x3bc
worker_thread from kthread+0x13c/0x264
kthread from ret_from_fork+0x14/0x28
...
---[ end trace 0000000000000000 ]---
Fix this by switching the driver to the new API.
Note the above warning only appears starting with commit a7748dd127ea
("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()")
which is the first commmit having added a drm_bridge_get/put() pair and
thus exposing the incorrect initial refcount issue.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250627165652.580798-1-m.szyprowski@samsung.com
[Luca: add Fixes tag and mention the reason in commit message] Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Thierry Reding [Fri, 13 Jun 2025 12:28:38 +0000 (14:28 +0200)]
drm/fbdev-client: Skip DRM clients if modesetting is absent
Recent generations of Tegra have moved the display components outside of
host1x, leading to a device that has no CRTCs attached and hence doesn't
support any of the modesetting functionality. When this is detected, the
driver clears the DRIVER_MODESET and DRIVER_ATOMIC flags for the device.
Unfortunately, this causes the following errors during boot:
[ 15.418958] ERR KERN drm drm: [drm] *ERROR* Failed to register client: -95
[ 15.425311] WARNING KERN drm drm: [drm] Failed to set up DRM client; error -95
These originate from the fbdev client checking for the presence of the
DRIVER_MODESET flag and returning -EOPNOTSUPP. However, if a driver does
not support DRIVER_MODESET this is entirely expected and the error isn't
helpful.
Prevent this misleading error message by setting up the DRM clients only
if modesetting is enabled.
Changes in v2:
- use DRIVER_MODESET check to avoid registering any clients
Reported-by: Jonathan Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250613122838.2082334-1-thierry.reding@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
When driver is built with either CONFIG_DRM_I2C_ADV7511_AUDIO or
CONFIG_DRM_I2C_ADV7511_CEC disabled, drm_bridge_connector_init() is
expected to fail with -EINVAL. That is because all required audio (or
CEC) related callbacks in adv7511_bridge_funcs ended up being NULL.
Set DRM_BRIDGE_OP_HDMI_AUDIO and DRM_BRIDGE_OP_HDMI_CEC_ADAPTER bridge
ops only when the aforementioned kernel config options have been
enabled.
drm/bridge: Fix kdoc comment for DRM_BRIDGE_OP_HDMI_CEC_ADAPTER
Correct the kernel-doc comment for DRM_BRIDGE_OP_HDMI_CEC_ADAPTER member
of enum drm_bridge_ops. This seems to be just a copy-paste artifact
from DRM_BRIDGE_OP_HDMI_CEC_NOTIFIER above.
Rob Clark [Sat, 5 Jul 2025 16:57:05 +0000 (09:57 -0700)]
drm/msm: Small function param doc fix
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507032334.9SCwc952-lkp@intel.com/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Rob Clark [Sat, 5 Jul 2025 14:52:41 +0000 (07:52 -0700)]
drm/msm: Take the ioctls away from the KMS-only driver
KMS-only drivers should only allocate dumb buffers. The driver custom
ioctls are only meant for the usermode gpu driver (mesa), and not for
general consumption, so they don't make sense for standalone KMS
drivers.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662598/
Rob Clark [Sat, 5 Jul 2025 14:52:40 +0000 (07:52 -0700)]
drm/msm: Clean up split driver features
Avoid the possibility of missing features between the split and unified
drm driver cases by defining DRIVER_FEATURES_GPU / KMS and using those
in the drm_driver initializations.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662595/
drm/msm: enable separate binding of GPU and display devices
There are cases when we want to have separate DRM devices for GPU and
display pipelines.
One example is development, when it is beneficial to be able to bind the
GPU driver separately, without the display pipeline (and without the
hacks adding "amd,imageon" to the compatible string).
Another example is some of Qualcomm platforms, which have two MDSS
units, but only one GPU. With current approach it is next to impossible
to support this usecase properly, while separate binding allows users to
have three DRM devices: two for MDSS units and a single headless GPU.
Add kernel param msm.separate_gpu_kms, which if set to true forces
creation of separate display and GPU DRM devices. Mesa supports this
setup by using the kmsro wrapper.
The param is disabled by default, in order to be able to test userspace
for the compatibility issues. Simple clients are able to handle this
setup automatically.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662590/
[Rob: renamed the modparam to separate_gpu_kms, and add missing
DRIVER_GEM_GPUVA] Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Currently the msm driver creates an extra interim platform device for
Imageon GPUs. This is not ideal, as the device doesn't have
corresponding OF node. If the headless mode is used for newer GPUs, then
the msm_use_mmu() function can not detect corresponding IOMMU devices.
Also the DRM device (although it's headless) is created with modesetting
flags being set.
To solve all these issues, rework the way the Imageon devices are bound.
Remove the interim device, don't register a component and instead use a
cut-down version of the normal functions to probe or remove the driver.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662584/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Move symbol selection to be more fine grained: select DP helpers only if
DP driver is also enabled, move KMS and display helpers to the newly
introduced DRM_MSM_KMS.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662589/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
drm/msm: bail out late_init_minor() if it is not a GPU device
Both perf and hangrd make sense only for GPU devices. Bail out if we are
registering a KMS-only device.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662583/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
drm/msm: make it possible to disable KMS-related code.
If the Adreno device is used in a headless mode, there is no need to
build all KMS components. Build corresponding parts conditionally, only
selecting them if modeset support is actually required.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662581/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Data for HDMI, DSI and DP blocks only makes sense for the KMS parts of
the driver. Move corresponding data pointers from struct msm_drm_private
to struct msm_kms.
Suggested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662580/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Drop superfluous msm_drm_private::num_crtcs in favour of using
drm_mode_config::num_crtc or MAX_CRCS as appropriate.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662578/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
There is no reason to store CRTC id, it's a part of the drm_crtc. Drop
this member and use drm_crtc.name for the warning message.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662576/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
The global workqueue is only used for vblanks inside KMS code. Move
allocation / flushing / deallcation of it to msm_kms.c
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/662573/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Attempting to reload a kernel module of an HDMI driver making use of the
new CEC helpers revealed a resource deallocation issue, i.e. the entries
in /dev/cec* keep growing.
Moreover, after a couple of tries the kernel crashes and the whole
system freezes:
Konrad Dybcio [Thu, 26 Jun 2025 09:02:41 +0000 (11:02 +0200)]
drm/msm/adreno: Switch to the common UBWC config struct
Now that Adreno specifics are out of the way, use the common config
(but leave the HBB hardcoding in place until that is wired up on the
other side).
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660985/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:40 +0000 (11:02 +0200)]
soc: qcom: ubwc: Fill in UBWC swizzle cfg for platforms that lack one
The UBWC 1.0 case is easy - it must be all 3 enabled.
UBWC2.0 and 3.x require that level1 is removed, follow suit.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660983/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:39 +0000 (11:02 +0200)]
soc: qcom: ubwc: Add #defines for UBWC swizzle bits
Make the values a bit more meaningful.
This commit is intentionally cross-subsystem to ease review, as the
patchset is intended to be merged together, with a maintainer
consensus.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660981/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:38 +0000 (11:02 +0200)]
soc: qcom: ubwc: Fix SM6125's ubwc_swizzle value
The value of 7 (a.k.a. GENMASK(2, 0), a.k.a. disabling levels 1-3 of
swizzling) is what we want on this platform (and others with a UBWC
1.0 encoder).
Fix it to make mesa happy (the hardware doesn't care about the 2 higher
bits, as they weren't consumed on this platform).
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660980/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:37 +0000 (11:02 +0200)]
drm/msm/a6xx: Simplify min_acc_len calculation
It's only necessary for some lower end parts.
Also rename it to min_acc_len_64b to denote that if set, the minimum
access length is 64 bits, 32b otherwise.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660977/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:36 +0000 (11:02 +0200)]
drm/msm/a6xx: Resolve the meaning of rgb565_predicator
It's supposed to be on when the UBWC encoder version is >= 4.0.
Drop the per-GPU assignments.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660975/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:35 +0000 (11:02 +0200)]
drm/msm/a6xx: Replace '2' with BIT(1) in level2_swizzling_dis calc
ubwc_swizzle is a bitmask. Check for a bit to make it more obvious.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660973/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:34 +0000 (11:02 +0200)]
drm/msm/a6xx: Resolve the meaning of UBWC_MODE
This bit is set iff the UBWC version is 1.0. That notably does not
include QCM2290's "no UBWC".
This commit is intentionally cross-subsystem to ease review, as the
patchset is intended to be merged together, with a maintainer
consensus.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660971/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:33 +0000 (11:02 +0200)]
drm/msm/a6xx: Simplify uavflagprd_inv detection
Instead of setting it on a gpu-per-gpu basis, converge it to the
intended "is A650 family or A7xx".
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660969/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:32 +0000 (11:02 +0200)]
drm/msm/a6xx: Resolve the meaning of AMSBC
The bit must be set to 1 if the UBWC encoder version is >= 3.0, drop it
as a separate field.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660967/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Konrad Dybcio [Thu, 26 Jun 2025 09:02:31 +0000 (11:02 +0200)]
drm/msm/a6xx: Get a handle to the common UBWC config
Start the great despaghettification by getting a pointer to the common
UBWC configuration, which houses e.g. UBWC versions that we need to
make decisions.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/660965/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
projects / thirdparty / linux.git / log
