| Age | Commit message (Collapse) | Author | Files | Lines |
|
drm-misc-fixes for v6.19-rc6:
vmwgfx:
- Fix hw regression from refactoring cursor handling on v10 'hardware'
- Fix warnings in destructor by merging the 2 release functions
- kernel doc fix
- error handling in vmw_compat_shader_add()
rockchip:
- fix vop2 polling
- fix regression waiting for cfgdone without config change
- fix warning when enabling encoder
core:
- take gem lock when preallocating in gpuvm.
- add single byte read fallback to dp for broken usb-c adapters
- remove duplicate drm_sysfb declarations
gud:
- Fix oops on usb disconnect
Simple panel:
- Re-add fallback when connector is not set to fix regressions
- Set correct type in DataImage SCF0700C48GGU18
nouveau:
- locking fixes for cursor handling.
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patch.msgid.link/ce0acfe2-9c1a-42b7-8782-f1e7f34b8544@linux.intel.com
|
|
We need the drm-rust fixes from -rc5 in here for nova-core to build on
top of.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
amd-drm-fixes-6.19-2026-01-15:
amdgpu:
- GC 9 PTE mtype fix
- Non-DC display kernel panic helper fix
- Merge fix
- GART vram access fix
- Userq fixes
- PSR debugging fix
- HDMI fixes
- Backlight fix
- SMU 14 fix
- TLB flush fixes
amdkfd:
- KFD node cleanup for eGPU disconnect
- Memory leak fix
- MES evict process fix
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260115205405.1890089-1-alexander.deucher@amd.com
|
|
Currently Tyr's struct GpuInfo is manually copied and updated from
include/uapi/drm/panthor_drm.h. But an auto generated struct is
available, so use that instead to avoid copy/paste errors and to stay
up-to-date with the panthor uapi.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260115193843.34878-1-deborah.brouwer@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
|
|
DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized
property blobs backed by kernel memory.
Currently, the blob data allocation is not accounted to the allocating
process's memory cgroup, allowing unprivileged users to trigger unbounded
kernel memory consumption and potentially cause system-wide OOM.
Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory
is properly charged to the caller's memcg. This ensures existing cgroup
memory limits apply and prevents uncontrolled kernel memory growth without
introducing additional policy or per-file limits.
Signed-off-by: Xiao Kan <814091656@qq.com>
Signed-off-by: Xiao Kan <xiao.kan@samsung.com>
Link: https://patch.msgid.link/tencent_D12AA2DEDE6F359E1AF59405242FB7A5FD05@qq.com
Signed-off-by: Maxime Ripard <mripard@kernel.org>
|
|
Since commit 56de5e305d4b ("clk: renesas: r9a07g044: Add MSTOP for RZ/G2L")
we may get the following kernel panic, for some panels, when rebooting:
systemd-shutdown[1]: Rebooting.
Call trace:
...
do_serror+0x28/0x68
el1h_64_error_handler+0x34/0x50
el1h_64_error+0x6c/0x70
rzg2l_mipi_dsi_host_transfer+0x114/0x458 (P)
mipi_dsi_device_transfer+0x44/0x58
mipi_dsi_dcs_set_display_off_multi+0x9c/0xc4
ili9881c_unprepare+0x38/0x88
drm_panel_unprepare+0xbc/0x108
This happens for panels that need to send MIPI-DSI commands in their
unprepare() callback. Since the MIPI-DSI interface is stopped at that
point, rzg2l_mipi_dsi_host_transfer() triggers the kernel panic.
Fix by moving rzg2l_mipi_dsi_stop() to new callback function
rzg2l_mipi_dsi_atomic_post_disable().
With this change we now have the correct power-down/stop sequence:
systemd-shutdown[1]: Rebooting.
rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_disable(): entry
ili9881c-dsi 10850000.dsi.0: ili9881c_unprepare(): entry
rzg2l-mipi-dsi 10850000.dsi: rzg2l_mipi_dsi_atomic_post_disable(): entry
reboot: Restarting system
Suggested-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Tested-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20260112154333.655352-1-hugo@hugovil.com
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
|
|
With some panels informing support for Panel Replay we are observing
problems if having Panel Replay enable bit set on sink when forced to use
PSR instead of Panel Replay. Avoid these problems by not setting Panel
Replay enable bit in sink when Panel Replay is globally disabled during
link training. I.e. disabled by module parameter.
The enable bit is still set when disabling Panel Replay via debugfs
interface. Added note comment about this.
Fixes: 68f3a505b367 ("drm/i915/psr: Enable Panel Replay on sink always when it's supported")
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <stable@vger.kernel.org> # v6.15+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260115070039.368965-1-jouni.hogander@intel.com
|
|
UAPI Changes:
- Remove unused KEEP_ACTIVE flag in the new multi queue uAPI (Niranjana)
- Expose new temperature attributes in HWMON (Karthik)
Driver Changes:
- Force i2c into polling mode when in survivability (Raag)
- Validate preferred system memory placement in xe_svm_range_validate (Brost)
- Adjust page count tracepoints in shrinker (Brost)
- Fix a couple drm_pagemap issues with multi-GPU (Brost)
- Define GuC firmware for NVL-S (Roper)
- Handle GT resume failure (Raag)
- Improve wedged mode handling (Lukasz)
- Add missing newlines to drm_warn messages (Osama)
- Fix WQ_MEM_RECLAIM passed as max_active to alloc_workqueue (Marco)
- Page-reclaim fixes and PRL stats addition (Brian)
- Fix struct guc_lfd_file_header kernel-doc (Jani)
- Allow compressible surfaces to be 1-way coherent (Xin)
- Fix DRM scheduler layering violations in Xe (Brost)
- Minor improvements to MERT code (Michal)
- Privatize struct xe_ggtt_node (Maarten)
- Convert wait for lmem init into an assert (Bala)
- Enable GSC loading and PXP for PTL (Daniele)
- Replace use of system_wq with tlb_inval->timeout_wq (Marco)
- VRAM addr range bit expansion (Fei)
- Cleanup unused header includes (Roper)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/aWkSxRQK7VhTlP32@intel.com
|
|
Beyond Display:
- Make 'guc_hw_reg_state' static as it isn't exported (Ben)
- Fix doc build on mei related interface header (Jani)
Display related:
- Fix ggtt fb alignment on Xe display (Tvrtko)
- More display clean-up towards deduplication and full separation (Jani)
- Use the consolidated HDMI tables (Suraj)
- Account for DSC slice overhead (Ankit)
- Prepare GVT for display modularization (Ankit, Jani)
- Enable/Disable DC balance along with VRR DSB (Mitul, Ville)
- Protection against unsupported modes in LT PHY (Suraj)
- Display W/a addition and fixes (Gustavo)
- Fix many SPDX identifier comments (Ankit)
- Incorporate Xe3_LPD changes for CD2X divider (Gustavo)
- Clean up link BW/DSC slice config computation (Imre)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/aWkNThVRSkGAfUVv@intel.com
|
|
drm-misc-next for 6.20:
Core Changes:
- atomic: Introduce Gamma/Degamma LUT size check
- gem: Fix a leak in drm_gem_get_unmapped_area
- gpuvm: API sanitation for Rust bindings
- panic: Few corner-cases fixes
Driver Changes:
- Replace system workqueue with percpu equivalent
- amdxdna: Update message buffer allocation requirements, Update
firmware version check
- imagination: Add AM62P support
- ivpu: Implement warm boot flow
- rockchip: Get rid of atomic_check fixups, Add Rockchip RK3506 Support
- rocket: Cleanups
- bridge:
- dw-hdmi-qp: Add support for HPD-less setups
- panel:
- mantix: Various power management related improvements
- new panels: Innolux G150XGE-L05,
- dma-buf:
- cma: Call clear_page instead of memset
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@redhat.com>
Link: https://patch.msgid.link/20260115-lilac-dragon-of-opposition-ac0a30@houat
|
|
Some GPUs like A612 doesn't use a named register range resource. This
is because the reg-name property is discouraged when there is just a
single resource.
To address this, retrieve the 'gmu' register range by its index. It is
always guaranteed to be at index 0.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/696673/
Message-ID: <20251231-qcs615-spin-2-v6-1-da87debf6883@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
This should also be zero for gen8. This does change a7xx-gen1 to zero.
It was almost certainly incorrect before, but we have no such devices in
CI currently.
Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support")
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/697779/
Message-ID: <20260109153730.130462-3-robin.clark@oss.qualcomm.com>
|
|
We actually need to set b26, just claiming to do so is not enough :-)
Fixes: 01ff3bf27215 ("drm/msm/a8xx: Add support for Adreno X2-85 GPU")
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/697778/
Message-ID: <20260109153730.130462-2-robin.clark@oss.qualcomm.com>
|
|
The hw clock gating register sequence consists of register value pairs
that are written to the GPU during initialisation.
The a690 hwcg sequence has two GMU registers in it that used to amount
to random writes in the GPU mapping, but since commit 188db3d7fe66
("drm/msm/a6xx: Rebase GMU register offsets") they trigger a fault as
the updated offsets now lie outside the mapping. This in turn breaks
boot of machines like the Lenovo ThinkPad X13s.
Note that the updates of these GMU registers is already taken care of
properly since commit 40c297eb245b ("drm/msm/a6xx: Set GMU CGC
properties on a6xx too"), but for some reason these two entries were
left in the table.
Fixes: 5e7665b5e484 ("drm/msm/adreno: Add Adreno A690 support")
Cc: stable@vger.kernel.org # 6.5
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Konrad Dybcio <konradybcio@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Fixes: 188db3d7fe66 ("drm/msm/a6xx: Rebase GMU register offsets")
Patchwork: https://patchwork.freedesktop.org/patch/695778/
Message-ID: <20251221164552.19990-1-johan@kernel.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
There's no need to check a userspace-provided GT ID (which may come from
any tile) against the number of GTs that can be present on a single
tile. The xe_device_get_gt() lookup already checks that the GT ID passed
is valid for the current device.(Matt Roper)
Signed-off-by: Nakshtra Goyal <nakshtra.goyal@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260113091928.67446-1-nakshtra.goyal@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
Simplify things by computing the detailed slice configuration using
intel_dp_dsc_get_slice_config(), instead of open-coding the same.
While at it add a TODO comment to intel_dp_dsc_compute_config() to
explore if it's worth increasing the number of VDSC stream engines used,
in order to reduce the minimum CDCLK required.
v2: Add a TODO comment to intel_dp_dsc_compute_config() to explore if
it's worth increasing the number of slices in order to use a lower
CDCLK. (Jouni)
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-16-imre.deak@intel.com
|
|
Add intel_dp_dsc_get_slice_config() to compute the detailed slice
configuration and determine the slices-per-line value (returned by
intel_dp_dsc_get_slice_count()) using this function.
v2: Fix incorrectly returning false from intel_dp_dsc_min_slice_count()
due to rebase fail. (Jouni)
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-15-imre.deak@intel.com
|
|
Unify the DP and eDP slices-per-line computation. Atm eDP simply returns
the maximum slices-per-line value supported by the sink, but using the
same helper function for both cases still makes sense, since a follow-up
change will compute the detailed slice config for both cases.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-14-imre.deak@intel.com
|
|
Use intel_dsc_get_slice_config() for DSI to compute the slice
configuration based on the slices-per-line sink capability, instead of
open-coding the same.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-13-imre.deak@intel.com
|
|
Add intel_dsc_get_slice_config() and move the logic to select a given
slice configuration to that function from the configuration loop in
intel_dp_dsc_get_slice_count(). The same functionality can be used by
other outputs like DSI as well, done as a follow-up.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-12-imre.deak@intel.com
|
|
Simplify the slice config loop in intel_dp_dsc_get_slice_count(), using
the loop iterator as the slices-per-pipe value directly, instead of
looking up the same value from an array.
While at it move the code comment about the slice configuration closer
to where the configuration is determined and clarify it a bit.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-11-imre.deak@intel.com
|
|
Rename test_slice_count to slices_per_line for clarity.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-10-imre.deak@intel.com
|
|
There is no reason to use the more specific u8 type for slice count
variables, use the more generic int type instead.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-9-imre.deak@intel.com
|
|
Factor out intel_dp_dsc_min_slice_count() for making
intel_dp_dsc_get_slice_count() more readable and also to prepare for a
follow-up change unifying the eDP and DP slice count/config computation.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-8-imre.deak@intel.com
|
|
By now all the places are updated to track the DSC slice configuration
in intel_crtc_state::dsc.slice_config, so calculate the slices-per-line
value using that config, instead of using
intel_crtc_state::dsc.slice_count caching the same value and remove
the cached slice_count.
v2: Rebase on latest drm-tip, converting another user of dsc.slice_count
in intel_vdsc_min_cdclk().
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com> # v1
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-7-imre.deak@intel.com
|
|
Add tracking for the DP DSC pipes-per-line and slices-per-stream value
in the slice config state and compute the current slices-per-line
(slice_count) value using this slice config. The slices-per-line value
used atm will be removed by a follow-up change after converting all the
places using it to use the slice config instead.
For now the slices-per-stream value is calculated based on the
slices-per-line value (slice_count) calculated by the
drm_dp_dsc_sink_max_slice_count() / intel_dp_dsc_get_slice_count()
functions. In a follow-up change these functions will be converted to
calculate the slices-per-stream value directly, along with the detailed
slice configuration.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-6-imre.deak@intel.com
|
|
Add tracking for the DSI DSC pipes-per-line and slices-per-stream value
in the slice config state and compute the current slices-per-line value
using this slice config state. The slices-per-line value used atm will
be removed by a follow-up change after converting all the places using
it to use the detailed slice config instead.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-5-imre.deak@intel.com
|
|
Move the initialization of the DSI DSC streams-per-pipe value to
fill_dsc() next to where the corresponding (per-line) slice_count value
is initialized. This allows converting the initialization to use the
detailed slice configuration state in follow-up changes.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-4-imre.deak@intel.com
|
|
Move the tracking for the DSC stream count from
intel_crtc_state::dsc.num_streams to
intel_crtc_state::dsc.slice_config.streams_per_pipe.
While at it add a TODO comment to read out the full DSC configuration
from HW including the pipes-per-line and slices-per-stream values.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-3-imre.deak@intel.com
|
|
Add a way to track the detailed DSC pipes-per-line, streams-per-pipe,
slices-per-stream configuration instead of the current streams-per-pipe
and slices-per-line value. This way describes the slice configuration in
a clearer way, for instance providing a
2 pipes-per-line x 2 streams-per-pipe x 2 slices-per-stream = 8 slices-per-line
view, instead of the current, coarser
2 streams-per-pipe, 8 slices-per-line
view, the former better reflecting that each DSC stream engine has 2
slices. This also let's optimizing the configuration in a
simpler/clearer way, for instance using 1 stream x 2 slices, or 1 stream
x 4 slices instead of the current 2 stream x 1 slice, or 2 streams x 2
slices configuration (so that 1 DSC stream engine can be powered off in
each pipe).
Follow-up changes will convert the current slices-per-line computation
logic to compute instead the above detailed slice configuration.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260114162232.92731-2-imre.deak@intel.com
|
|
An LRC timestamp getting stuck is a somewhat normal occurrence. If a
single VF submits a job that does not get timesliced, the LRC timestamp
will not increment. Reduce the LRC timestamp stuck message on VFs to
notice (same log level as job timeout) to avoid false CI bugs in tests
where a VF submits a job that does not get timesliced.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7032
Fixes: bb63e7257e63 ("drm/xe: Avoid toggling schedule state to check LRC timestamp in TDR")
Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patch.msgid.link/20260114184905.4189026-1-matthew.brost@intel.com
|
|
clangd reports many "unused header" warnings throughout the Xe driver.
Start working to clean this up by removing unnecessary includes in our
.c files and/or replacing them with explicit includes of other headers
that were previously being included indirectly.
By far the most common offender here was unnecessary inclusion of
xe_gt.h. That likely originates from the early days of xe.ko when
xe_mmio did not exist and all register accesses, including those
unrelated to GTs, were done with GT functions.
There's still a lot of additional #include cleanup that can be done in
the headers themselves; that will come as a followup series.
v2:
- Squash the 79-patch series down to a single patch. (MattB)
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260115032803.4067824-2-matthew.d.roper@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
|
|
amd-drm-next-6.20-2026-01-09:
amdgpu:
- GPUVM updates
- Initial support for larger GPU address spaces
- Initial SMUIO 15.x support
- Documentation updates
- Initial PSP 15.x support
- Initial IH 7.1 support
- Initial IH 6.1.1 support
- SMU 13.0.12 updates
- RAS updates
- Initial MMHUB 3.4 support
- Initial MMHUB 4.2 support
- Initial GC 12.1 support
- Initial GC 11.5.4 support
- HDMI fixes
- Panel replay improvements
- DML updates
- DC FP fixes
- Initial SDMA 6.1.4 support
- Initial SDMA 7.1 support
- Userq updates
- DC HPD refactor
- SwSMU cleanups and refactoring
- TTM memory ops parallelization
- DCN 3.5 fixes
- DP audio fixes
- Clang fixes
- Misc spelling fixes and cleanups
- Initial SDMA 7.11.4 support
- Convert legacy DRM logging helpers to new drm logging helpers
- Initial JPEG 5.3 support
- Add support for changing UMA size via the driver
- DC analog fixes
- GC 9 gfx queue reset support
- Initial SMU 15.x support
amdkfd:
- Reserved SDMA rework
- Refactor SPM
- Initial GC 12.1 support
- Initial GC 11.5.4 support
- Initial SDMA 7.1 support
- Initial SDMA 6.1.4 support
- Increase the kfd process hash table
- Per context support
- Topology fixes
radeon:
- Convert legacy DRM logging helpers to new drm logging helpers
- Use devm for i2c adapters
- Variable sized array fix
- Misc cleanups
UAPI:
- KFD context support. Proposed userspace:
https://github.com/ROCm/rocm-systems/pull/1705
https://github.com/ROCm/rocm-systems/pull/1701
- Add userq metadata queries for more queue types. Proposed userspace:
https://gitlab.freedesktop.org/yogeshmohan/mesa/-/commits/userq_query
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260109154713.3242957-1-alexander.deucher@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
[Why&How]
Right now, the HDMI HPD filter is enabled by default at 1500ms.
We want to disable it by default, as most modern displays with HDMI do
not require it for DPMS mode.
The HPD can instead be enabled as a driver parameter with a custom delay
value in ms (up to 5000ms).
Fixes: c918e75e1ed9 ("drm/amd/display: Add an HPD filter for HDMI")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4859
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 6a681cd9034587fe3550868bacfbd639d1c6891f)
|
|
The user mode queue keeps a pointer to the most recent fence in
userq->last_fence. This pointer holds an extra dma_fence reference.
When the queue is destroyed, we free the fence driver and its xarray,
but we forgot to drop the last_fence reference.
Because of the missing dma_fence_put(), the last fence object can stay
alive when the driver unloads. This leaves an allocated object in the
amdgpu_userq_fence slab cache and triggers
This is visible during driver unload as:
BUG amdgpu_userq_fence: Objects remaining on __kmem_cache_shutdown()
kmem_cache_destroy amdgpu_userq_fence: Slab cache still has objects
Call Trace:
kmem_cache_destroy
amdgpu_userq_fence_slab_fini
amdgpu_exit
__do_sys_delete_module
Fix this by putting userq->last_fence and clearing the pointer during
amdgpu_userq_fence_driver_free().
This makes sure the fence reference is released and the slab cache is
empty when the module exits.
v2: Update to only release userq->last_fence with dma_fence_put()
(Christian)
Fixes: edc762a51c71 ("drm/amdgpu/userq: move some code around")
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 8e051e38a8d45caf6a866d4ff842105b577953bb)
|
|
Each queue of the process is individually removed and there is not need
to suspend whole mes. Suspending mes stops kernel mode queues also
causing unnecessary timeouts when running mixed work loads
Fixes: 079ae5118e1f ("drm/amdkfd: fix suspend/resume all calls in mes based eviction path")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4765
Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3fd20580b96a6e9da65b94ac3b58ee288239b731)
|
|
This reverts commit 820b3d376e8a102c6aeab737ec6edebbbb710e04.
It’s better to validate VM TLB flushes in the flush‑TLB backend
rather than in the generic VM layer.
Reverting this patch depends on
commit fa7c231fc2b0 ("drm/amdgpu: validate the flush_gpu_tlb_pasid()")
being present in the tree.
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 9163fe4d790fb4e16d6b0e23f55b43cddd3d4a65)
|
|
Validate flush_gpu_tlb_pasid() availability before flushing tlb.
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f4db9913e4d3dabe9ff3ea6178f2c1bc286012b8)
|
|
resolving the issue of incorrect type definitions potentially causing calculation errors.
Fixes: 54f7f3ca982a ("drm/amdgpu/swm14: Update power limit logic")
Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e3a03d0ae16d6b56e893cce8e52b44140e1ed985)
|
|
Internal backlight levels are initialised from ACPI but the values
are sometimes out of sync with the levels in effect until there has
been a read from hardware (eg triggered by reading from sysfs).
This means that the first drm_commit can cause the levels to be set
to a different value than the actual starting one, which results in
a sudden change in brightness.
This path shows the problem (when the values are out of sync):
amdgpu_dm_atomic_commit_tail()
-> amdgpu_dm_commit_streams()
-> amdgpu_dm_backlight_set_level(..., dm->brightness[n])
This patch calls the backlight ops get_brightness explicitly
at the end of backlight registration to make sure dm->brightness[n]
is in sync with the actual hardware levels.
Fixes: 2fe87f54abdc ("drm/amd/display: Set default brightness according to ACPI")
Signed-off-by: Vivek Das Mohapatra <vivek@collabora.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 318b1c36d82a0cd2b06a4bb43272fa6f1bc8adc1)
Cc: stable@vger.kernel.org
|
|
[Why]
DP-HDMI dongles can execeed bandwidth requirements on high resolution
monitors. This can lead to pruning the high resolution modes.
HDMI 1.3 bumped the clock to 340MHz, but display code never matched it.
[How]
Set default to (DVI) 165MHz. Once HDMI display is identified update
to 340MHz.
Reported-by: Dianne Skoll <dianne@skoll.ca>
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4780
Reviewed-by: Chris Park <chris.park@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ac1e65d8ade46c09fb184579b81acadf36dcb91e)
Cc: stable@vger.kernel.org
|
|
[Why]
The PSR message was moved in commit 4321742c394e ("drm/amd/display:
Move PSR support message into amdgpu_dm"). This message however shows
for every single link without showing which link is which. This can
send a confusing message to the user.
[How]
Add link name into the message.
Fixes: 4321742c394e ("drm/amd/display: Move PSR support message into amdgpu_dm")
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 99f77f6229c0766b980ae05affcf9f742d97de6a)
|
|
If dqm->ops.initialize() fails, add deallocate_hiq_sdma_mqd()
to release the memory allocated by allocate_hiq_sdma_mqd().
Move deallocate_hiq_sdma_mqd() up to ensure proper function
visibility at the point of use.
Fixes: 11614c36bc8f ("drm/amdkfd: Allocate MQD trunk for HIQ and SDMA")
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit b7cccc8286bb9919a0952c812872da1dcfe9d390)
Cc: stable@vger.kernel.org
|
|
These IOCTLs shouldn't be called when userqs are not
enabled. Make sure they are enabled before executing
the IOCTLs.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit d967509651601cddce7ff2a9f09479f3636f684d)
Cc: stable@vger.kernel.org
|
|
Use dst input parameter to setup gart page table entries instead of using fixed
location.
Fixes: 237d623ae659 ("drm/amdgpu/gart: Add helper to bind VRAM pages (v2)")
Signed-off-by: Xiaogang Chen <xiaogang.chen@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ca5d4db8db843be7ed35fc9334737490c2b58d32)
|
|
This reverts commit 22a36e660d014925114feb09a2680bb3c2d1e279 once,
which was merged twice due to an incorrect backmerge resolution.
Fixes: ce0478b02ed2 ("Merge tag 'v6.18-rc6' into drm-next")
Signed-off-by: Peter Colberg <pcolberg@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 38a0f4cf8c6147fd10baa206ab349f8ff724e391)
|
|
When an eGPU is unplugged the KFD topology should also be destroyed
for that GPU. This never happens because the fini_sw callbacks never
get to run. Run them manually before calling amdgpu_device_ip_fini_early()
when a device has already been disconnected.
This location is intentionally chosen to make sure that the kfd locking
refcount doesn't get incremented unintentionally.
Cc: kent.russell@amd.com
Closes: https://community.frame.work/t/amd-egpu-on-linux/8691/33
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 6a23e7b4332c10f8b56c33a9c5431b52ecff9aab)
Cc: stable@vger.kernel.org
|
|
When driver not support atomic, fb using plane->fb rather than
plane->state->fb.
Fixes: fe151ed7af54 ("drm/amdgpu: add generic display panic helper code")
Signed-off-by: Lu Yao <yaolu@kylinos.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 2f2a72de673513247cd6fae14e53f6c40c5841ef)
|
|
Fix copy&paste error, that should have been an assignment instead of an or,
otherwise MTYPE_UC 0x3 can not be updated to MTYPE_RW 0x1.
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit fc1366016abe4103c0f0fac882811aea961ef213)
Cc: stable@vger.kernel.org
|
|
[Why&How]
Right now, the HDMI HPD filter is enabled by default at 1500ms.
We want to disable it by default, as most modern displays with HDMI do
not require it for DPMS mode.
The HPD can instead be enabled as a driver parameter with a custom delay
value in ms (up to 5000ms).
Fixes: c918e75e1ed9 ("drm/amd/display: Add an HPD filter for HDMI")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4859
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|