Sriov guest side doesn't init ras feature hence the poison irq shouldn't
be put during hw fini
Signed-off-by: Mangesh Gadre
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/vcn_v5_0_1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v
Sriov guest side doesn't init ras feature hence the poison irq shouldn't
be put during hw fini
Signed-off-by: Mangesh Gadre
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/jpeg_v5_0_1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg
1. Unified amdgpu ip block name print with format
{ip_type}_v{major}_{minor}_{rev}
2. Avoid IP block name conflicts for SMU/PSP ip block
Signed-off-by: Yang Wang
Reviewed-by: Asad Kamal
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 35 --
1 file changed, 33 insertions
the PPSMC_MSG_GetPptLimit msg is not valid for gfx 11.0.3 on vf mode,
so skiped to create power1_cap* hwmon sysfs node.
Signed-off-by: Yang Wang
Reviewed-by: Asad Kamal
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a
This patch modifies the user queue management to use preempt/restore
operations instead of full map/unmap for queue eviction scenarios where
applicable. The changes include:
1. Introduces new helper functions:
- amdgpu_userqueue_preempt_helper()
- amdgpu_userqueue_restore_helper()
2. Update
From: Alex Deucher
This patch adds robust reset handling for user queues (userq) to improve
recovery from queue failures. The key components include:
1. Queue detection and reset logic:
- amdgpu_userq_detect_and_reset_queues() identifies failed queues
- Per-IP detect_and_reset callbacks fo
From: Alex Deucher
Add a detect and reset callback and add the implementation
for mes. The callback will detect all hung queues of a
particular ip type (e.g., GFX or compute or SDMA) and
reset them.
v2: increase reset counter and set fence force completion
v3: Removed userq_mutex in mes_userq_d
From: Alex Deucher
Add support for forcing completion of userq fences.
This is needed for userq resets and asic resets so that we
can set the error on the fence and force completion.
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 4
From: Alex Deucher
Implement support for the hung queue detect and reset
functionality.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
b/drivers/gpu/d
From: Alex Deucher
Track resets from user queues.
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
Reviewed-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/
From: Alex Deucher
Implement support for the hung queue detect and reset
functionality.
v2: Always use AMDGPU_MES_SCHED_PIPE
Signed-off-by: Alex Deucher
Signed-off-by: Jesse Zhang
---
drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 31 ++
1 file changed, 31 insertions(+)
di
From: Alex Deucher
Helper function to detect and reset hung queues. MES will
return an array of doorbell indices of which queues are hung
and were optionally reset.
v2: Clear the doorbell array before detection
Signed-off-by: Alex Deucher
Signed-off-by: Jesse Zhang
---
drivers/gpu/drm/amd/
This commit implements the actual MES (Micro Engine Scheduler) suspend
and resume gang operations for version 12 hardware. Previously these
functions were just stubs returning success.
v2: Always use AMDGPU_MES_SCHED_PIPE
Signed-off-by: Alex Deucher
Signed-off-by: Jesse Zhang
---
drivers/gpu/d
Use the suspend and resume API rather than remove queue
and add queue API. The former just preempts the queue
while the latter remove it from the scheduler completely.
There is no need to do that, we only need preemption
in this case.
V2: replace queue_active with queue state
v3: set the suspend_
From: Alex Deucher
Add two new function pointers to struct amdgpu_userq_funcs:
- preempt: To handle preemption of user mode queues
- restore: To restore preempted user mode queues
These callbacks will allow the driver to properly manage queue
preemption and restoration when needed, such as durin
Change the legacy (non-DC) display code to respect the maximum
pixel clock for HDMI and DVI-D. Reject modes that would require
a higher pixel clock than can be supported.
Also update the maximum supported HDMI clock value depending on
the ASIC type.
For reference, see the DC code:
check max_hdmi_
This code isn't needed anymore as we collect the same information
into pm_display_cfg instead.
Signed-off-by: Timur Kristóf
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 1 -
drivers/gpu/drm/amd/pm/amdgpu_dpm_internal.c | 74 -
This commit is necessary for DC to function well with chips
that use the legacy power management code, ie. SI and KV.
Communicate display information from DC to the legacy PM code.
Currently DC uses pm_display_cfg to communicate power management
requirements from the display code to the DPM code.
This commit adds the pixel_clock field to the display config
struct so that power management (DPM) can use it.
We currently don't have a proper bandwidth calculation on old
GPUs with DCE 6-10 because dce_calcs only supports DCE 11+.
So the power management (DPM) on these GPUs may need to make
ad-h
Hook up DC to legacy DPM. Now SI and KV DPM are aware of power
management related requirements that come from DC, which is
necessary for DC to function correctly on these chips when DPM
is enabled.
Based on the "SI power management fixes (v2)" series.
Background:
The power management code (DPM) n
DCE 6 was not advertised as being able to support VRR,
so let's mark it as unsupported for now.
The VRR implementation in amdgpu_dm depends on the VUPDATE
interrupt which is not registered for DCE 6.
Signed-off-by: Timur Kristóf
Reviewed-by: Rodrigo Siqueira
Reviewed-by: Alex Hung
---
drivers
The VUPDATE interrupt isn't registered on DCE 6, so don't try
to use that.
This fixes a page flip timeout after sleep/resume on DCE 6.
v2:
Fix rebase conflict with latest amd-staging-drm-next.
Signed-off-by: Timur Kristóf
Reviewed-by: Rodrigo Siqueira
Reviewed-by: Alex Hung
---
.../gpu/drm/a
It already didn't work on DCE 8,
so there is no reason to assume it would on DCE 6.
Signed-off-by: Timur Kristóf
Reviewed-by: Rodrigo Siqueira
Reviewed-by: Alex Hung
---
drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
DC can turn off the display clock when no displays are connected
or when all displays are off, for reference see:
- dce*_validate_bandwidth
DC also assumes that the DP clock is always on and never powers
it down, for reference see:
- dce110_clock_source_power_down
In case of DCE 6.0 and 6.4, PLL0
Compared to the previous version of this series, v2 fixes
the rebase conflicts on amd-staging-drm-next and includes
an additional patch to address page flip timeouts when the
displays are blanked.
Currently when using DC on DCE 6, it produces pageflip timeouts:
1. When displays are blanked
This i
We define "high pixelclock" for SI as higher than necessary
for 4K 30Hz. For example, 4K 60Hz and 1080p 144Hz fall into
this category.
When a high pixel clock display is connected, always disable
memory clock switching to solve some flickering that can be
observed on 4K 60Hz displays. (It's very s
These fields were only used by si_dpm and are not necessary
anymore. They also may have been incorrect because:
- wm_high was set to the LOW_WATERMARK field of watermark A.
- wm_low was not set on DCE 6 and was always zero.
Signed-off-by: Timur Kristóf
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.
According to pp_pm_compute_clocks the non-DC display code
has "issues with mclk switching with refresh rates over 120 hz".
The workaround is to disable MCLK switching in this case.
Do the same for legacy DPM.
Fixes: 6ddbd37f1074 ("drm/amd/pm: optimize the amdgpu_pm_compute_clocks()
implementatio
The si_upload_smc_data function uses si_write_smc_soft_register
to set some register values in the SMC, and expects the result
to be PPSMC_Result_OK which is 1.
The PPSMC_Result_OK / PPSMC_Result_Failed values are used for
checking the result of a command sent to the SMC.
However, the si_write_smc
Some parts of the code base expect that MCLK switching is turned
off when the vblank time is set to zero.
According to pp_pm_compute_clocks the non-DC code has issues
with MCLK switching with refresh rates over 120 Hz.
Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
Signed-off-by: Tim
Based on some comments in dm_pp_display_configuration
above the crtc_index and line_time fields, these values
are programmed to the SMC to work around an SMC hang
when it switches MCLK.
According to Alex, the Windows driver programs them to:
mclk_change_block_cp_min = 200 / line_time
mclk_change_b
This commit fixes some instability on Tahiti.
Sometimes UVD initialization would fail when using DC.
I suspect this is because DC doesn't immediately turn on the
display clock, so it changes how DPM behaves.
Fixes: 841686df9f7d ("drm/amdgpu: add SI DPM support (v4)")
Signed-off-by: Timur Kristóf
Unlike later versions, UVD 3 has firmware validation.
For this to work, the UVD should be powered up correctly.
When DPM is enabled and the display clock is off,
the SMU may choose a power state which doesn't power
the UVD, which can result in failure to initialize UVD.
v2:
Add code comments to e
This series fixes some power management issues on SI,
addressing the feedback I got for the first version,
as well as additionally dealing with the issue of higher
refresh rate displays with the non-DC display code.
I recommend backporting these commits to the stable kernel
because they fix some i
When the EDID has the HDMI bit, we should simply select
the HDMI signal type even on DVI ports.
For reference see, the legacy amdgpu display code:
amdgpu_atombios_encoder_get_encoder_mode
which selects ATOM_ENCODER_MODE_HDMI for the same case.
This commit fixes DVI connectors to work with DVI-D/H
On 8/25/2025 4:17 PM, Antheas Kapenekakis wrote:
On Mon, 25 Aug 2025 at 20:02, Mario Limonciello
wrote:
On 8/24/2025 3:02 PM, Antheas Kapenekakis wrote:
Certain OLED devices malfunction on specific brightness levels.
Specifically, when DP_SOURCE_BACKLIGHT_LEVEL is written to with
the first by
On Mon, 2025-08-25 at 13:06 -0400, Alex Deucher wrote:
> On Mon, Aug 25, 2025 at 12:39 PM Timur Kristóf
> wrote:
> >
> > On Mon, 2025-08-25 at 12:31 -0400, Alex Deucher wrote:
> > > On Mon, Aug 25, 2025 at 12:19 PM Timur Kristóf
> > > wrote:
> > > >
> > > > On Mon, 2025-08-25 at 11:38 -0400, Al
On 8/25/2025 4:02 PM, Antheas Kapenekakis wrote:
On Mon, 25 Aug 2025 at 18:47, Mario Limonciello
wrote:
On 8/24/2025 3:02 PM, Antheas Kapenekakis wrote:
On the SteamOS kernel, Valve universally makes minimum brightness 0
for all devices. SteamOS is (was?) meant for the Steam Deck, so
enabling
For multiple VCN instances case we get multiple lines of the same
message like below:
amdgpu :43:00.0: amdgpu: Found VCN firmware Version ENC: 1.24 DEC: 9 VEP:
0 Revision: 11
amdgpu :43:00.0: amdgpu: Found VCN firmware Version ENC: 1.24 DEC: 9 VEP:
0 Revision: 11
By adding instance
1 Remove unused code in vcn_v1_0.c and vcn_v4_0.c - found by Coverity scan
2 improve log message by adding instance number. It's more useful for
multiple VCN instances case.
David (Ming Qiang) Wu (3):
drm/amdgpu/vcn: remove unused code in vcn_v1_0.c
drm/amdgpu/vcn: remove unused code in vcn
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index 1785786a72f8e..d0d27790b73b1 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
++
Signed-off-by: David (Ming Qiang) Wu
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index c74947705d778..1e89ba153d9d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
The kfd CRIU checkpoint ioctl would return an error if trying
to checkpoint a process with no kfd buffer objects.
This is a normal case and should not be an error.
Reviewed-by: Felix Kuehling
Signed-off-by: David Francis
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 ++--
1 file changed, 2
Add new GEM_OP_IOCTL option GET_MAPPING_INFO, which
returns a list of mappings associated with a given bo, along with
their positions and offsets.
Signed-off-by: David Francis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 84 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 5
Add new ioctl DRM_IOCTL_AMDGPU_GEM_LIST_HANDLES.
This ioctl returns a list of bos with their handles, sizes,
and flags and domains.
This ioctl is meant to be used during CRIU checkpoint and
provide information needed to reconstruct the bos
in CRIU restore.
Signed-off-by: David Francis
Reviewed-
AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE is a flag that
specifies that gem memory contains sensitive information and
should be cleared to prevent snooping.
The COHERENT and UNCACHED gem create flags enable memory
features related to sharing memory across devices.
For CRIU we need to re-create KFD B
This patch series adds support for CRIU checkpointing of processes that
share memory with the amdgpu dmabuf interface.
This v16 reworks the op ioctl mapping
On 21.08.25 12:05, Lorenzo Stoakes wrote:
> On Thu, Aug 21, 2025 at 11:30:43AM +0200, David Hildenbrand wrote:
>>> I will add this xen/apply_to_page_range() thing to my TODOs, which atm
>>> would invovle changing these drivers to use vmf_insert_pfn_prot() instead.
>>>
>>
>> Busy today (want to repl
On 8/24/2025 3:02 PM, Antheas Kapenekakis wrote:
Certain OLED devices malfunction on specific brightness levels.
Specifically, when DP_SOURCE_BACKLIGHT_LEVEL is written to with
the first byte being 0x00 and sometimes 0x01, the panel forcibly
turns off until the device sleeps again.
Below are som
On 8/24/2025 3:01 PM, Antheas Kapenekakis wrote:
Currently, the brightness quirk is limited to minimum brightness only.
Refactor it to a structure, so that more quirks can be added in the
future. Reserve 0 value for "no quirk", and use u16 to allow minimum
brightness up to 255.
Signed-off-by: An
On Sat, Aug 23, 2025 at 6:11 AM Alex Tran wrote:
>
> Removed kfd_queue_buffer_put to call amdgpu_bo_unref directly.
>
> Signed-off-by: Alex Tran
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 1 -
> .../drm/amd/amdkfd/kfd_process_queue_manager.c | 2 +-
> drivers/gpu/drm/amd/amdk
On Mon, Aug 25, 2025 at 12:39 PM Timur Kristóf wrote:
>
> On Mon, 2025-08-25 at 12:31 -0400, Alex Deucher wrote:
> > On Mon, Aug 25, 2025 at 12:19 PM Timur Kristóf
> > wrote:
> > >
> > > On Mon, 2025-08-25 at 11:38 -0400, Alex Deucher wrote:
> > > > On Sun, Aug 24, 2025 at 7:43 PM Rodrigo Siqueir
On 8/24/2025 3:02 PM, Antheas Kapenekakis wrote:
On the SteamOS kernel, Valve universally makes minimum brightness 0
for all devices. SteamOS is (was?) meant for the Steam Deck, so
enabling it universally is reasonable. However, it causes issues in
certain devices. Therefore, introduce it just fo
On 8/24/2025 3:01 PM, Antheas Kapenekakis wrote:
This is an alternative to [1], since Phil found out there are still invalid
values. I made this series before the one I sent today, and I have to say
I tested it much less. Because I did not think it was very viable to
upstream.
I'll look throug
On 8/25/2025 9:01 AM, Antheas Kapenekakis wrote:
On Mon, 25 Aug 2025 at 15:33, Antheas Kapenekakis wrote:
On Mon, 25 Aug 2025 at 15:20, Alex Deucher wrote:
On Mon, Aug 25, 2025 at 3:13 AM Antheas Kapenekakis wrote:
On the Asus Z13 2025, which uses a Strix Halo platform, around 8% of the
On Mon, 2025-08-25 at 12:31 -0400, Alex Deucher wrote:
> On Mon, Aug 25, 2025 at 12:19 PM Timur Kristóf
> wrote:
> >
> > On Mon, 2025-08-25 at 11:38 -0400, Alex Deucher wrote:
> > > On Sun, Aug 24, 2025 at 7:43 PM Rodrigo Siqueira
> > > wrote:
> > >
> > >
> > > > +
> > > > +First of all, note
On Mon, Aug 25, 2025 at 12:19 PM Timur Kristóf wrote:
>
> On Mon, 2025-08-25 at 11:38 -0400, Alex Deucher wrote:
> > On Sun, Aug 24, 2025 at 7:43 PM Rodrigo Siqueira
> > wrote:
> >
> >
> > > +
> > > +First of all, note that the GC can have multiple SEs, depending on
> > > the specific
> > > +GPU/
On Mon, 2025-08-25 at 11:38 -0400, Alex Deucher wrote:
> On Sun, Aug 24, 2025 at 7:43 PM Rodrigo Siqueira
> wrote:
>
>
> > +
> > +First of all, note that the GC can have multiple SEs, depending on
> > the specific
> > +GPU/APU, and each SE has multiple Compute Units (CU). From the
> > diagram, y
Hi,
On Mon, 2025-08-25 at 17:19 +0200, Christian König wrote:
> On 25.08.25 01:29, Rodrigo Siqueira wrote:
> > Expand the kernel-doc about amdgpu_ring and add some tiny
> > improvements.
> >
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: Timur Kristóf
> > Signed-off-by: Rodrigo Siqueira
On Sun, Aug 24, 2025 at 7:43 PM Rodrigo Siqueira wrote:
>
> This commit introduces a diagram and a set of information that details
> the different sets of schedulers available in the SE.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Timur Kristóf
> Signed-off-by: Rodrigo Siqueira
> ---
> D
On 25.08.25 01:29, Rodrigo Siqueira wrote:
> Expand the kernel-doc about amdgpu_ring and add some tiny improvements.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Timur Kristóf
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 14 +++---
> drivers
On Sat, Aug 23, 2025 at 5:48 AM Srinivasan Shanmugam
wrote:
>
> Enable userspace to obtain a handle to the kernel-owned MMIO_REMAP
> singleton when AMDGPU_GEM_DOMAIN_MMIO_REMAP is requested via
> amdgpu_gem_create_ioctl().
>
> Validate the fixed 4K constraint: if PAGE_SIZE > AMDGPU_GPU_PAGE_SIZE
>
On Sat, Aug 23, 2025 at 3:20 AM Srinivasan Shanmugam
wrote:
>
> Add amdgpu_ttm_mmio_remap_bo_init()/fini() to manage the kernel-owned
> one-page(4K) MMIO_REMAP BO. The allocator runs during TTM init when the
> hardware exposes a remap base (adev->rmmio_base) and the host
> PAGE_SIZE is <= AMDGPU_G
On 20.08.25 13:32, Srinivasan Shanmugam wrote:
> This series introduces a kernel-managed singleton BO representing the
> MMIO-remap (HDP flush) page and exposes it to userspace through a new
> GEM domain.
>
> Design --
> - A tiny (1-page) TTM bucket is introduced for AMDGPU_PL_MMIO_REMAP
> (
On 20.08.25 13:32, Srinivasan Shanmugam wrote:
> When userspace requests a GEM in AMDGPU_GEM_DOMAIN_MMIO_REMAP, return a
> handle to the kernel-owned singleton BO instead of allocating a new one.
>
> Validate inputs (exact PAGE_SIZE, alignment PAGE_SIZE, no extra flags)
> and zero the ioctl out-st
On Mon, Aug 25, 2025 at 10:52 AM Alex Deucher wrote:
>
> On Sat, Aug 23, 2025 at 3:28 AM Srinivasan Shanmugam
> wrote:
> >
> > Implement TTM-level behavior for AMDGPU_PL_MMIO_REMAP so it behaves as a
> > CPU-visible IO page:
> >
> > * amdgpu_evict_flags(): mark as unmovable
> > * amdgpu_res_cpu_v
On Sat, Aug 23, 2025 at 3:28 AM Srinivasan Shanmugam
wrote:
>
> Implement TTM-level behavior for AMDGPU_PL_MMIO_REMAP so it behaves as a
> CPU-visible IO page:
>
> * amdgpu_evict_flags(): mark as unmovable
> * amdgpu_res_cpu_visible(): consider CPU-visible
> * amdgpu_bo_move(): use null move when
On 20.08.25 13:32, Srinivasan Shanmugam wrote:
> Create the single-page MMIO_REMAP BO and initialize a tiny on-chip
> range manager for the new placement:
>
> * add amdgpu_mmio_remap_bo_init()/fini()
> * in amdgpu_ttm_init(): initialize AMDGPU_PL_MMIO_REMAP heap and create
> the PAGE_SIZE BO
On 20.08.25 13:32, Srinivasan Shanmugam wrote:
> Implement TTM-level behavior for AMDGPU_PL_MMIO_REMAP so it behaves
> as a CPU-visible IO page:
>
> * amdgpu_evict_flags(): mark as unmovable
> * amdgpu_res_cpu_visible(): consider CPU-visible
> * amdgpu_bo_move(): use null move when src/dst is M
On 20.08.25 13:32, Srinivasan Shanmugam wrote:
> Add bookkeeping for the remap page to struct amdgpu_device:
>
> * mmio_remap_bo (singleton BO)
> * mmio_remap_base, mmio_remap_barsz (register BAR base/size)
> * mmio_remap_offset (BAR-relative offset of the remap page)
> * mmio_remap_size (PAGE_SIZ
On 20.08.25 13:32, Srinivasan Shanmugam wrote:
> Introduce a kernel-internal TTM placement type AMDGPU_PL_MMIO_REMAP
> for the HDP flush MMIO remap page
>
> Plumbing added:
> - amdgpu_res_cursor.{first,next}: treat MMIO_REMAP like DOORBELL
> - amdgpu_ttm_io_mem_reserve(): return BAR bus address +
When creating p2p links, KFD needs to check XGMI link
with two conditions, hive_id and is_sharing_enabled,
but it is missing to check is_sharing_enabled, so add
it to fix the error.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 3 ++-
1 file changed, 2 insertions(+),
On 22.08.25 21:47, David Francis wrote:
> Add new GEM_OP_IOCTL option GET_MAPPING_INFO, which
> returns a list of mappings associated with a given bo, along with
> their positions and offsets.
>
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 98 +
We need to cancel any outstanding work at both suspend
and driver teardown. Move the cancel to hw_fini which
gets called in both cases.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/dr
On Mon, Aug 25, 2025 at 3:13 AM Antheas Kapenekakis wrote:
>
> On the Asus Z13 2025, which uses a Strix Halo platform, around 8% of the
> suspend resumes result in a soft lock around 1 second after the screen
> turns on (it freezes). This happens due to power gating VPE when it is
> not used, whic
[Public]
Hi all,
This week this patchset was tested on 4 systems, two dGPU and two APU based,
and tested across multiple display and connection types.
APU
* Single Display eDP -> 1080p 60hz, 1920x1200 165hz, 3840x2400 60hz
* Single Display DP (SST DSC) -> 4k144hz, 4k240hz
On Sun, 2025-08-24 at 21:33 +0200, Antheas Kapenekakis wrote:
> Well Phil managed to fall into the value 332800, which has a 0 minor
> bit. Unfortunate. In hindsight, every 256 hundreds there would be a
> zero anyway.
>
> Before I made this patch I made a partial refactor of panel-quirks
> where a
dml21_map_dc_state_into_dml_display_cfg calls (the call is usually
inlined by the compiler) populate_dml21_surface_config_from_plane_state
and populate_dml21_plane_config_from_plane_state which may use FPU. In
a x86-64 build:
$ objdump --disassemble=dml21_map_dc_state_into_dml_display_cfg \
On 8/22/2025 5:58 PM, Matthew Auld wrote:
On 22/08/2025 09:37, Matthew Auld wrote:
On 21/08/2025 16:06, Arunpravin Paneer Selvam wrote:
Replace the freelist (O(n)) used for free block management with a
red-black tree, providing more efficient O(log n) search, insert,
and delete operations. Th
On 8/22/2025 5:32 PM, Matthew Auld wrote:
On 21/08/2025 16:06, Arunpravin Paneer Selvam wrote:
Maintain two separate RB trees per order - one for clear (zeroed) blocks
and another for dirty (uncleared) blocks. This separation improves
code clarity and makes it more obvious which tree is being
On 22.08.25 21:47, David Francis wrote:
> Add new ioctl DRM_IOCTL_AMDGPU_GEM_LIST_HANDLES.
>
> This ioctl returns a list of bos with their handles, sizes,
> and flags and domains.
>
> This ioctl is meant to be used during CRIU checkpoint and
> provide information needed to reconstruct the bos
> i
On Mon, Aug 25, 2025 at 06:26:48AM +, Kandpal, Suraj wrote:
> > Subject: Re: [RFC PATCH 1/8] drm: writeback: Refactor
> > drm_writeback_connector structure
> >
> > Hi,
> >
> > On Sat, Aug 16, 2025 at 01:20:53AM +0300, Dmitry Baryshkov wrote:
> > > On Thu, Aug 14, 2025 at 05:13:54PM +0100, liv
[Public]
(For the updated patch)
You may use BIT_ULL. That aside,
Reviewed-by: Lijo Lazar
Thanks,
Lijo
-Original Message-
From: amd-gfx On Behalf Of Jesse.Zhang
Sent: Monday, August 25, 2025 6:51 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
[Public]
You may use BIT_ULL. That aside,
Reviewed-by: Lijo Lazar
Thanks,
Lijo
-Original Message-
From: amd-gfx On Behalf Of Jesse.Zhang
Sent: Monday, August 25, 2025 6:46 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Zhang, Jesse(Jie)
Sub
On the Asus Z13 2025, which uses a Strix Halo platform, around 8% of the
suspend resumes result in a soft lock around 1 second after the screen
turns on (it freezes). This happens due to power gating VPE when it is
not used, which happens 1 second after inactivity.
Specifically, the VPE gating aft
On Sun, 24 Aug 2025 at 22:16, Mario Limonciello wrote:
>
>
>
> On 8/24/25 3:53 AM, Antheas Kapenekakis wrote:
> > On the Asus Z13 2025, which uses a Strix Halo platform, around 8% of the
> > suspend resumes result in a soft lock around 1 second after the screen
> > turns on (it freezes). This happ
Certain OLED devices malfunction on specific brightness levels.
Specifically, when DP_SOURCE_BACKLIGHT_LEVEL is written to with
the first byte being 0x00 and sometimes 0x01, the panel forcibly
turns off until the device sleeps again.
Below are some examples. This was found by iterating over brighn
On the SteamOS kernel, Valve universally makes minimum brightness 0
for all devices. SteamOS is (was?) meant for the Steam Deck, so
enabling it universally is reasonable. However, it causes issues in
certain devices. Therefore, introduce it just for the Steam Deck here.
SteamOS kernel does not hav
On Sun, 24 Aug 2025 at 10:54, Antheas Kapenekakis wrote:
>
> Certain OLED devices malfunction on specific brightness levels.
> Specifically, when DP_SOURCE_BACKLIGHT_LEVEL is written to with
> the minor byte being 0x00 and sometimes 0x01, the panel forcibly
> turns off until the device sleeps agai
This is an alternative to [1], since Phil found out there are still invalid
values. I made this series before the one I sent today, and I have to say
I tested it much less. Because I did not think it was very viable to
upstream. I was also not aware of [2] and [3] since they are not in a
public bug
This patch corrects several typographical errors in atomfirmware.h.
The fixes improve readability and maintain consistency in the codebase.
No functional changes are introduced.
Corrected terms include:
- aligment→ alignment
- Offest → Offset
- defintion → definition
- swithing→ swi
Currently, having a valid panel_id match is required to use the quirk
system. For certain devices, we know that all SKUs need a certain quirk.
Therefore, allow not specifying ident by only checking for a match
if panel_id is non-zero.
Signed-off-by: Antheas Kapenekakis
---
drivers/gpu/drm/drm_pa
Replace the previous O(N^2) implementation of remove_duplicates() in
with a O(N) version using a fast/slow pointer approach. The new version
keeps only the first occurrence of each element and compacts the array
in place, improving efficiency without changing functionality.
Signed-off-by: Kuan-Wei
Certain OLED devices malfunction on specific brightness levels.
Specifically, when DP_SOURCE_BACKLIGHT_LEVEL is written to with
the minor byte being 0x00 and sometimes 0x01, the panel forcibly
turns off until the device sleeps again. This is an issue on
multiple handhelds, including OneXPlayer F1 P
Optimize the handling of reserved time candidates by replacing the
custom bubble sort with the kernel's standard sort() and rewriting
duplicate removal with a linear-time fast/slow pointer method. The
changes improve sorting from O(N^2) to O(N log N) and duplicate removal
from O(N^2) to O(N), reduc
Currently, the brightness quirk is limited to minimum brightness only.
Refactor it to a structure, so that more quirks can be added in the
future. Reserve 0 value for "no quirk", and use u16 to allow minimum
brightness up to 255.
Signed-off-by: Antheas Kapenekakis
---
.../gpu/drm/amd/display/amd
Using a single DMI match only allows matching per manufacturer.
Introduce a second optional match to allow matching make/model.
In addition, make DMI optional to allow matching only by EDID.
Signed-off-by: Antheas Kapenekakis
---
drivers/gpu/drm/drm_panel_backlight_quirks.c | 19 ++--
Replace the custom bubble sort used for sorting reserved time
candidates in with the kernel's standard sort() helper. The previous
code had O(N^2) time complexity, while the generic kernel sort runs in
O(N log N). This improves efficiency and removes the need for a local
sorting implementation, whi
This is a note to let you know that I've just added the patch titled
drm/amdgpu: handle the case of pci_channel_io_frozen only in
amdgpu_pci_resume
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filen
99 matches
Mail list logo
