On 13.10.25 16:54, Philipp Stanner wrote:
> On Mon, 2025-10-13 at 15:48 +0200, Christian König wrote:
>> Hi everyone,
>>
>> dma_fences have ever lived under the tyranny dictated by the module
>> lifetime of their issuer, leading to crashes should anybody still holding
>> a reference to a dma_fence
On 13/10/2025 14:48, Christian König wrote:
The driver and timeline name are meaningless for signaled fences.
Drop them and also print the context number.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff
On 10/13/2025 10:00 PM, Ilya Zlobintsev wrote:
Calling `smu_cmn_get_sysfs_buf` aligns the
offset used by `sysfs_emit_at` to the current page boundary, which was
previously directly returned from the various `print_clk_levels`
implementations to be added to the buffer position.
Instead, only th
nd exiting the
> scheduler's runnable queue often.
>
> Relevant scenario here is what happens when an entity re-joins the
> runnable queue with other entities already present. One cornerstone of the
> virtual runtime algorithm is to let it re-join at the head and rely on the
&g
Hi Maxime,
On Tue Oct 14, 2025 at 9:44 AM CEST, Maxime Ripard wrote:
>> --- a/include/drm/drm_atomic.h
>> +++ b/include/drm/drm_atomic.h
>> @@ -672,7 +672,8 @@ void drm_atomic_private_obj_init(struct drm_device *dev,
>> struct drm_private_obj *obj,
>>
On 01/10/2025 16:37, Thomas Zimmermann wrote:
No caller of the client resume/suspend helpers holds the console
lock. The last such cases were removed from radeon in the patch
series at [1]. Now remove the related parameter and the TODO items.
v2:
- update placeholders for CONFIG_DRM_CLIENT=n
Si
v5 2/4] drm/amd: Remove second call to set_power_limit()
>
>The min/max limits only make sense for default PPT. Restructure
>smu_set_power_limit() to only use them in that case.
>
>Signed-off-by: Mario Limonciello
Reviewed-by: Lijo Lazar
Thanks,
Lijo
>---
>v5:
> * Re-o
[Public]
>-Original Message-
>From: amd-gfx On Behalf Of Ilya
>Zlobintsev
>Sent: Saturday, October 11, 2025 7:17 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Ilya Zlobintsev
>Subject: [PATCH 0/2] drm/amd/pm: Avoid writing nulls into
>`pp_od_clk_voltage`
>
>Previously, reading from the `pp_
On Thu, Oct 9, 2025 at 2:50 PM Jonathan Kim wrote:
>
> By design the MES will return an array result that is twice the number
> of hung doorbells it can report.
>
> i.e. if up k reported doorbells are supported, then the
> second half of the array, also of length k, holds the HQD information
> (ty
[AMD Official Use Only - AMD Internal Distribution Only]
Thanks,
Lijo
>-Original Message-
>From: amd-gfx On Behalf Of Ellen
>Pan
>Sent: Thursday, October 9, 2025 9:00 AM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deucher, Alexander ; Koenig, Christian
>; Gande, Shravan kumar
>; Pan, Ellen
>
On 08/10/2025 15:39, Thomas Hellström wrote:
On Wed, 2025-10-08 at 16:02 +0200, Christian König wrote:
On 08.10.25 15:50, Tvrtko Ursulin wrote:
On 08/10/2025 13:35, Christian König wrote:
On 08.10.25 13:53, Tvrtko Ursulin wrote:
Disclaimer:
Please note that as this series includes a patch
On Fri, Oct 10, 2025 at 12:43 AM Ellen Pan wrote:
>
> - This change prepares the later patches to intro _v2 suffix to SRIOV
> critical regions
>
> Signed-off-by: Ellen Pan
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c| 20
> drivers/gpu/drm/amd/amd
On 13.10.25 10:00, Jesse.Zhang wrote:
> Previously, APU platforms (and other scenarios with uninitialized VRAM
> managers)
> triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The
> root
> cause is not that the `struct ttm_resource_manager *man` pointer itself is
> NULL,
On Wed, 2025-10-08 at 09:53 +0100, Tvrtko Ursulin wrote:
> Move the code dealing with entities entering and exiting run queues to
> helpers to logically separate it from jobs entering and exiting entities.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matt
Subject: Re: [PATCH v3] drm/amd: Check that VPE has reached DPM0 in idle
handler
On 10/12/25 11:54 PM, Lazar, Lijo wrote:
[Public]
Doesn't this translate to just a higher idle timeout (VPE_IDLE_TIMEOUT ) for
the particular VPE version?
Thanks,
Lijo
Yes if the VPE microcode adjusts D
On Mon, Oct 13, 2025 at 8:27 PM Mario Limonciello wrote:
>
> On 10/13/25 12:58 PM, Rafael J. Wysocki wrote:
> > On Mon, Oct 13, 2025 at 7:48 PM Mario Limonciello (AMD)
> > wrote:
> >>
> >> From: Mario Limonciello
> >>
> >> After the hibernation snapshot is created all devices will have
> >> thei
On Mon, Oct 13, 2025 at 7:48 PM Mario Limonciello (AMD)
wrote:
>
> From: Mario Limonciello
>
> After the hibernation snapshot is created all devices will have
> their thaw() callback called before the next stage. For the most
> common scenarios of hibernation this is not necessary because the
>
Applied. Thanks!
Alex
On Mon, Oct 13, 2025 at 3:35 AM Aditya Gollamudi wrote:
>
> From: Adi Gollamudi
>
> Fix a typo in a comment, change "enviroment" to "environment" in
> drivers/gpu/drm/amd/display/dc/dml2/display_mode_core_structs.h
>
> Signed-off-by: Aditya Gollamudi
> ---
> drivers/gpu
[Public]
Regards,
Prike
> -Original Message-
> From: Alex Deucher
> Sent: Monday, October 13, 2025 9:43 PM
> To: Liang, Prike
> Cc: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 2/7] drm/amdgpu/userq: fix SDMA and compute valid
On Mon, Oct 13, 2025 at 10:21 AM Liang, Prike wrote:
>
> [Public]
>
> Regards,
> Prike
>
> > -Original Message-
> > From: Alex Deucher
> > Sent: Monday, October 13, 2025 9:44 PM
> > To: Liang, Prike
> > Cc: Deucher, Alexander ; amd
[AMD Official Use Only - AMD Internal Distribution Only]
>-Original Message-
>From: Mario Limonciello
>Sent: Monday, October 13, 2025 7:21 PM
>To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org
>Cc: Limonciello, Mario ; Lee, Peyton
>; Sultan Alsawaf
>Subject: Re: [PAT
On 10/12/25 11:54 PM, Lazar, Lijo wrote:
[Public]
Doesn't this translate to just a higher idle timeout (VPE_IDLE_TIMEOUT ) for
the particular VPE version?
Thanks,
Lijo
Yes if the VPE microcode adjusts DPM at runtime this makes sure that it
has settled when workload is complete.
I expect t
On Mon, Oct 13, 2025 at 4:54 AM Liang, Prike wrote:
>
> [Public]
>
> We may need to update the userspace EOP buffer request; otherwise, the EOP
> buffer validation may fail.
Existing userspace should be ok. It currently uses PAGE_SIZE which is
larger than 2048.
> Per this kernel change: Review
On 13.10.25 10:58, Jesse.Zhang wrote:
> The `ttm_resource_manager_usage()` function currently assumes `man->bdev` is
> non-NULL when accessing `man->bdev->lru_lock`.
> However, in scenarios where the resource manager is not fully initialized
> (e.g., APU platforms that lack dedicated VRAM, or inc
[Public]
Reviewed-by: Prike Liang
Regards,
Prike
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Saturday, October 11, 2025 5:15 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 6/7] drm/amdgpu: Update AMDGPU_INFO_UQ_FW_A
[Public]
Reviewed-by: Prike Liang
Regards,
Prike
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Saturday, October 11, 2025 5:15 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 5/7] drm/amdgpu: Update AMDGPU_INFO_UQ_FW_A
On Wed, Oct 08, 2025 at 09:53:55AM +0100, Tvrtko Ursulin wrote:
> Remove member no longer used by the scheduler core.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Boris Brezillon
> Cc: Steven Price
> Cc: Liviu Dudau
> Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Liviu Dudau
Best regards,
Liv
[AMD Official Use Only - AMD Internal Distribution Only]
>-Original Message-
>From: amd-gfx On Behalf Of Victor Zhao
>Sent: Friday, October 10, 2025 1:03 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Chang, HaiJun ; Zhao, Victor
>
>Subject: [PATCH v2 2/2] drm/amdgpu: use GPU_HDP_FLUSH for sr
On Wed, 08 Oct 2025 15:11:42 +0200, Maxime Ripard wrote:
> The state pointer found in the struct drm_atomic_state internals for
> most object is a bit ambiguous, and confusing when those internals also
> have old state and new state.
>
> After the recent cleanups, the state pointer only use is to
On 10.10.25 16:07, Sunil Khatri wrote:
> At times we need a bo reference for hmm and for that add
> a new struct amdgpu_hmm_range which will hold an optional
> bo member and hmm_range.
>
> Use amdgpu_hmm_range instead of hmm_range and let the bo
> as an optional argument for the caller if they wan
[Public]
>-Original Message-
>From: Pan, Ellen
>Sent: Saturday, October 11, 2025 12:19 AM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deucher, Alexander ; Koenig, Christian
>; Lazar, Lijo ; Chan, Hing
>Pong ; Pan, Ellen
>Subject: [PATCH v3 3/6] drm/amdgpu: Introduce SRIOV critical regions v2
Subject: [PATCH] drm/amdgpu: re-enable power1_cap* hwmon nodes for gfx 11.0.3
vf mode
get power limitation information from pptable instead of sending
PPSMC_MSG_GetPptLimit to pmfw on gfx 11.0.3 vf mode.
Fixes: 21129c51c616 ("drm/amd/amdgpu: disable hwmon power1_cap* for gfx 11.0.3
on vf
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Yang, Philip
> Sent: Monday, October 13, 2025 7:55 AM
> To: Zhang, Jesse(Jie) ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
>
> Subject: Re: [PATCH]
On 10/10/2025 13:22, Philipp Stanner wrote:
On Wed, 2025-10-08 at 09:53 +0100, Tvrtko Ursulin wrote:
To implement fair scheduling we need a view into the GPU time consumed by
entities. Problem we have is that jobs and entities objects have decoupled
lifetimes, where at the point we have a view
Hi Tvrtko,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-i915/for-linux-next drm-i915/for-linux-next-fixes
drm-xe/drm-xe-next drm-exynos/exynos-drm-next drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-misc
On Fri, Oct 10, 2025 at 11:06 AM Lijo Lazar wrote:
>
> For legacy SOCs, discovery binary is sideloaded. Instead of checking for
> binary blob, use a flag to determine if discovery region needs to be
> reserved.
>
> Signed-off-by: Lijo Lazar
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/am
On Fri, Oct 10, 2025 at 11:11 AM Lijo Lazar wrote:
>
> Add amdgpu_discovery_info structure to keep all discovery related
> information.
>
> Signed-off-by: Lijo Lazar
> ---
>
> v2: Remove superfluous discovery_ prefix for members (Alex)
>
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 10 +-
>
On Fri, Oct 10, 2025 at 1:01 AM Ellen Pan wrote:
>
> 1. Added VF logic to init data exchange region using the offsets from
> dynamic(v2) critical regions;
>
> Signed-off-by: Ellen Pan
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 88
> drivers/gpu/drm/amd/amdgpu/am
On 10. 10. 25 14:28, Christian König wrote:
David any objections that I take this patch and make the necessary
modifications?
Sure, please go ahead.
Thanks,
David
People are pinging me about the problem.
Regards,
Christian.
On 09.10.25 17:04, Christian König wrote:
FYI
On 09.10.25 09
On Wed, 2025-10-08 at 09:53 +0100, Tvrtko Ursulin wrote:
> This time round we explore the rate of submitted job queue processing
> with multiple identical parallel clients.
>
> Example test output:
>
> 3 clients:
> t cycle: min avg max : ...
> + 0ms
[AMD Official Use Only - AMD Internal Distribution Only]
>-Original Message-
>From: Pan, Ellen
>Sent: Friday, October 10, 2025 10:13 AM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deucher, Alexander ; Koenig, Christian
>; Lazar, Lijo ; Chan, Hing
>Pong ; Pan, Ellen
>Subject: [PATCH 4/6] drm/
On 10/8/25 05:15, Mario Limonciello wrote:
On 10/7/2025 5:45 PM, Eslam Khafagy wrote:
Initialize the return variable "r" to 0 in dm_cache_state() to fix
a potential use of uninitialized variable warning.
The return value for this function might not be a PTR_ERR, in casse if
condition fails.
On 2025-10-09 12:19, Christian König wrote:
> On 09.10.25 17:06, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel
>>
>> Test the existing CPP macro _LINUX_FPU_COMPILATION_UNIT, which is set
>> when building source files that are permitted to use floating point,
>> in the implementation of DC_FP_ST
On Thu, Oct 9, 2025 at 2:50 PM Jonathan Kim wrote:
>
> Initialized doorbells should be set to invalid rather than 0 to prevent
> driver from over counting hung doorbells since it checks against the
> invalid value to begin with.
>
> Signed-off-by: Jonathan Kim
Reviewed-by: Alex Deucher
> ---
>
On Wed, Oct 8, 2025 at 11:46 PM Ellen Pan wrote:
>
> - During guest driver init, asa VFs receive PF msg to
> init dynamic critical region(v2), VFs reuse fw_vram_usage_*
> from ttm to store critical region tables in a 5MB chunk.
>
> Signed-off-by: Ellen Pan
> ---
> drivers/gpu/dr
On Wed, Oct 8, 2025 at 10:48 PM Victor Zhao wrote:
>
> Add kiq hdp flush callbacks for gfx ips to support gpu hdp flush when no
> ring presents
>
> Signed-off-by: Victor Zhao
This patch is:
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
> drivers/gpu/drm/amd/amd
On Thu, Oct 09, 2025 at 11:23:01AM +0200, Matthew Schwartz wrote:
> This fix regressed the original issue that commit d83c747a1225
> ("drm/amd/display: Fix brightness level not retained over reboot") solved,
> so revert it until a different approach to solve the regression that
> it caused with AMD
Hi Alex,
With this change the expectation from userspace will be to provide
offset starting the doorbell range received over INFO_IOCTL.
Change looks good to me, we will have INFO_IOCTL to share doorbell info
userspace
Reviewed-by: Saleemkhan Jamadar
Regards,
Saleem
On 09/10/25 00:4
On 2025-09-26 14:01, Timur Kristóf wrote:
> This series adds support for analog connectors to DC for DCE6-10.
> There are two reasons to add this support:
>
> 1. GPUs that already use DC by default and have analog connectors.
> Some Tonga and Hawaii graphics cards in fact have DVI-I connectors,
>
On Wed, Oct 8, 2025 at 4:12 PM Kim, Jonathan wrote:
>
> [Public]
>
> > -Original Message-
> > From: Alex Deucher
> > Sent: Wednesday, October 8, 2025 1:46 PM
> > To: Kim, Jonathan
> > Cc: amd-gfx@lists.freedesktop.org; Liu, Shaoyun
> > S
On 08/10/2025 09:53, Tvrtko Ursulin wrote:
> Remove member no longer used by the scheduler core.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Boris Brezillon
> Cc: Rob Herring
> Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_job.c | 1 -
>
On Tue, 07 Oct 2025 20:40:43 +0100 Mario Limonciello
wrote ---
> On 10/7/25 2:31 PM, Bob Beckett wrote:
> > --- quoted message ---
> >> From: Robert Beckett
> >>> Lijo pointed out to me that
> >>> commit ed4efe426a49 ("drm/amd: Restore cached power limit during resume")
> >>> com
[Public]
> -Original Message-
> From: Alex Deucher
> Sent: Wednesday, October 8, 2025 1:12 PM
> To: Kim, Jonathan
> Cc: amd-gfx@lists.freedesktop.org; Liu, Shaoyun
> Subject: Re: [PATCH] drm/amdgpu: fix gfx12 mes packet submission status check
>
> On Wed,
On 10/2/25 12:42 PM, Mario Limonciello wrote:
The shutdown() callback doesn't use the same code as suspend()
callbacks. This series unifies them and then also improves error
handling for all suspend flows.
Mario Limonciello (7):
drm/amd: Unify shutdown() callback behavior
drm/amd: Stop exp
Am 08.10.25 um 15:11 schrieb Maxime Ripard:
The state pointer found in the struct drm_atomic_state internals for
most object is a bit ambiguous, and confusing when those internals also
have old state and new state.
After the recent cleanups, the state pointer only use is to point to the
state
On Mon, 6 Oct 2025 at 12:59, Ard Biesheuvel wrote:
>
> On Mon, 6 Oct 2025 at 19:42, Christian König wrote:
> >
> > On 02.10.25 23:00, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel
> > >
> > > The point of isolating code that uses kernel mode FPU in separate
> > > compilation units is to ensur
On Tue, 7 Oct 2025 16:44:59 +0200
Danilo Krummrich wrote:
> On 9/30/25 1:57 PM, Boris Brezillon wrote:
> > Can you remind me what the problem is? I thought the lifetime issue was
> > coming from the fact the drm_sched ownership model was lax enough that
> > the job could be owned by both drm_gpu_
[Public]
The change here in smu_restore_dpm_user_profile will need a revision of patch 3
also 😊
Thanks,
Lijo
-Original Message-
From: amd-gfx On Behalf Of Mario
Limonciello
Sent: Monday, October 6, 2025 10:11 PM
To: open list:RADEON and AMDGPU DRM DRIVERS
Subject: Re: [PATCH v2 2/5
[Public]
Reviewed-by: Lijo Lazar
Thanks,
Lijo
-Original Message-
From: Jesse.Zhang
Sent: Sunday, October 5, 2025 7:04 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Lazar, Lijo ; Zhang, Jesse(Jie)
; Zhang, Jesse(Jie)
Subject: [PATCH] drm/amd/pm: Dis
On 02.10.25 23:00, Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> The point of isolating code that uses kernel mode FPU in separate
> compilation units is to ensure that even implicit uses of, e.g., SIMD
> registers for spilling occur only in a context where this is permitted,
> i.e., from insi
On Wed, Aug 6, 2025 at 8:19 PM Ellen Pan wrote:
>
> 1. Updated previous layout offsets and sizes to _V1.
> 2. Added v2 layout offset enums for dynamic pf-vf critical region handling.
> 3. Added crit_region version in VF's msg[2] during REQ_INIT_DATA.
> 4. Added support to init critical region v2 d
On 10/6/2025 11:31 AM, Mario Limonciello wrote:
When passed around internally the upper 8 bits of power limit include the limit
type.
This is non-obvious without digging into the nuances of each function.
Instead pass the limit type as an argument to all applicable layers.
Signed-off-by: Mar
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Asad Kamal
Thanks & Regards
Asad
-Original Message-
From: Lazar, Lijo
Sent: Monday, October 6, 2025 10:49 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kamal, Asad
Subject: [PATCH]
der)
+ return 0;
+ }
Do we need all these changes in __force_merge? Can't we just always
pick the dirty tree and keep everything else the same? If something is
non-merged there must be a dirty block preventing that, and when force
merging everything unmerged
On 2025-10-03 17:46, Felix Kuehling wrote:
On 2025-10-03 17:18, Philip Yang wrote:
On 2025-10-03 17:05, Felix Kuehling wrote:
On 2025-09-26 17:03, Philip Yang wrote:
zone_device_page_init uses set_page_count to set vram page refcount to
1, there is race if step 2 happens between step 1 and
On 2025-10-03 17:18, Philip Yang wrote:
On 2025-10-03 17:05, Felix Kuehling wrote:
On 2025-09-26 17:03, Philip Yang wrote:
zone_device_page_init uses set_page_count to set vram page refcount to
1, there is race if step 2 happens between step 1 and 3.
1. CPU page fault handler get vram page,
[+Linux MM and HMM maintainers]
Please see below my question about the safety of using
zone_device_page_init.
On 2025-10-03 18:02, Philip Yang wrote:
On 2025-10-03 17:46, Felix Kuehling wrote:
On 2025-10-03 17:18, Philip Yang wrote:
On 2025-10-03 17:05, Felix Kuehling wrote:
On 2025-09-
On 2025-10-02 18:04, Chen, Xiaogang wrote:
On 10/2/2025 12:43 PM, Philip Yang wrote:
svm_range_unmap_from_gpus uses page aligned start, end address, the end
address is inclusive.
Fixes: 38c55f6719f7 ("drm/amdkfd: Handle lack of READ permissions in
SVM mapping")
Signed-off-by: Philip Yang
On 2025-10-03 17:05, Felix Kuehling wrote:
On 2025-09-26 17:03, Philip Yang wrote:
zone_device_page_init uses set_page_count to set vram page refcount to
1, there is race if step 2 happens between step 1 and 3.
1. CPU page fault handler get vram page, migrate the vram page to
system page
2. G
On 2025-09-26 17:03, Philip Yang wrote:
zone_device_page_init uses set_page_count to set vram page refcount to
1, there is race if step 2 happens between step 1 and 3.
1. CPU page fault handler get vram page, migrate the vram page to
system page
2. GPU page fault migrate to the vram page, set pa
On 2025-10-03 14:34, Chen, Xiaogang wrote:
On 10/3/2025 1:27 PM, Philip Yang wrote:
On 2025-10-03 14:22, Chen, Xiaogang wrote:
[AMD Official Use Only - AMD Internal Distribution Only]
The MADV_FREE is handled at
madvise_free_single_vma(madvise_dontneed_free) from
madvise_vma_behavior at mm
On 9/26/2025 5:53 AM, Khatri, Sunil wrote:
On 9/24/2025 10:27 PM, Kuehling, Felix wrote:
On 2025-09-24 06:01, Sunil Khatri wrote:
update the amdgpu_ttm_tt_get_user_pages and all dependent function
along with it callers to use a user allocated hmm_range buffer instead
hmm layer allocates the
Ping?
On Fri, Sep 26, 2025 at 7:44 PM Alex Deucher wrote:
>
> Chips which use the IP discovery firmware loaded by the driver
> reported incorrect harvesting information in the ip discovery
> table in sysfs because the driver only uses the ip discovery
> firmware for populating sysfs and not for d
On Fri, Oct 3, 2025 at 4:09 PM Felix Kuehling wrote:
>
> Queue read and write pointers are "to KFD", not "from KFD".
>
> Suggested-by: Robert Liu
> Signed-off-by: Felix Kuehling
Reviewed-by: Alex Deucher
> ---
> include/uapi/linux/kfd_ioctl.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 de
On 10/3/2025 10:12 AM, Philip Yang wrote:
On 2025-10-02 17:48, Chen, Xiaogang wrote:
On 10/2/2025 12:43 PM, Philip Yang wrote:
Add hmm_range kzalloc return NULL error check. In case the get_pages
return failed, free and set hmm_range to NULL, to avoid double free in
get_pages_done.
Fixes:
On Wed, Sep 24, 2025 at 08:23:08PM +, Eliav Farber wrote:
> From: Linus Torvalds
>
> [ Upstream commit 1a251f52cfdc417c84411a056bc142cbd77baef4 ]
As this didn't go into 6.6.y yet, I'll stop here on this series for now.
Please fix up for newer kernels first and then resend these.
The fix fo
在 2025/9/26 2:22, Harry Wentland 写道:
On 2025-09-25 04:11, Pekka Paalanen wrote:
On Tue, 23 Sep 2025 11:41:24 -0600
Alex Hung wrote:
On 9/23/25 10:16, Alex Hung wrote:
On 9/23/25 01:59, Pekka Paalanen wrote:
On Mon, 22 Sep 2025 21:16:45 -0600
Alex Hung wrote:
On 9/18/25 02:40, Pekka
[Public]
Patches 1 and 3 are
Reviewed-by: Lijo Lazar
For this one, suggest splitting to two patches - one to pass the limit type and
the other to save/restore fast ppt limit. Could add LIMIT_TYPE_COUNT to enum
smu_ppt_limit_type and keep an array in smu_user_dpm_profile. However, this
[Public]
This is because currently only Vangogh has Fast PPT limit. The limit for that
is not the same as default one. It will be higher than the max_power_limit.
Since this is Vangogh-only, it's left to the implementation to handle that
check.
Thanks,
Lijo
-Original Message-
From: Lim
> On Mon, Sep 29, 2025 at 02:39:26PM +, Farber, Eliav wrote:
> > > On Wed, Sep 24, 2025 at 08:23:08PM +, Eliav Farber wrote:
> > > > From: Linus Torvalds
> > > >
> > > > [ Upstream commit 1a251f52cfdc417c84411a056bc142cbd77baef4 ]
> > >
> > >
> > >
> > > As this didn't go into 6.6.y yet,
On Mon, Sep 29, 2025 at 02:39:26PM +, Farber, Eliav wrote:
> > On Wed, Sep 24, 2025 at 08:23:08PM +, Eliav Farber wrote:
> > > From: Linus Torvalds
> > >
> > > [ Upstream commit 1a251f52cfdc417c84411a056bc142cbd77baef4 ]
> >
> >
> >
> > As this didn't go into 6.6.y yet, I'll stop here on
> On Wed, Sep 24, 2025 at 08:23:08PM +, Eliav Farber wrote:
> > From: Linus Torvalds
> >
> > [ Upstream commit 1a251f52cfdc417c84411a056bc142cbd77baef4 ]
>
>
>
> As this didn't go into 6.6.y yet, I'll stop here on this series for now.
> Please fix up for newer kernels first and then resend th
+Cc Sima, Dave
On Mon, 2025-09-29 at 16:07 +0200, Danilo Krummrich wrote:
> On Wed Sep 3, 2025 at 5:23 PM CEST, Tvrtko Ursulin wrote:
> > This is another respin of this old work^1 which since v7 is a total rewrite
> > and
> > completely changes how the control is done.
>
> I only got some of the
On 9/26/2025 4:30 PM, Matthew Auld wrote:
On 23/09/2025 10:02, Arunpravin Paneer Selvam wrote:
Add KUnit test cases that create severe memory fragmentation and
measure allocation/free performance.
The tests simulate two scenarios -
1. Allocation under severe fragmentation
- Allocate the
Hi Bhanu,
kernel test robot noticed the following build warnings:
[auto build test WARNING on amd-pstate/linux-next]
[also build test WARNING on amd-pstate/bleeding-edge v6.17]
[cannot apply to linus/master next-20251002]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And
[Public]
Hi Alex,
Apologies for overlooking your earlier review comments. I just see patches 1-4
have already been reviewed. Can we proceed to land the series (patches 1-6) in
drm-next?
Regards,
Prike
> -Original Message-
> From: Liang, Prike
> Sent: Monday, September 29, 2025
On 10/2/2025 12:43 PM, Philip Yang wrote:
svm_range_unmap_from_gpus uses page aligned start, end address, the end
address is inclusive.
Fixes: 38c55f6719f7 ("drm/amdkfd: Handle lack of READ permissions in SVM
mapping")
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 4
On 10/2/2025 12:43 PM, Philip Yang wrote:
Add hmm_range kzalloc return NULL error check. In case the get_pages
return failed, free and set hmm_range to NULL, to avoid double free in
get_pages_done.
Fixes: 29e6f5716115 ("drm/amdgpu: use user provided hmm_range buffer in
amdgpu_ttm_tt_get_user_
On 2025-09-26 15:52, Chen, Xiaogang wrote:
On 9/24/2025 10:29 AM, Yifan Zhang wrote:
current switch partition only check if kfd_processes_table is empty.
kfd_prcesses_table entry is deleted in kfd_process_notifier_release, but
kfd_process tear down is in kfd_process_wq_release.
consider two
On Wed, Oct 01, 2025 at 04:37:03PM +0200, Thomas Zimmermann wrote:
> No caller of the client resume/suspend helpers holds the console
> lock. The last such cases were removed from radeon in the patch
> series at [1]. Now remove the related parameter and the TODO items.
>
> v2:
> - update placehold
On 01.10.25 16:39, Thomas Zimmermann wrote:
Hi
Am 01.10.25 um 14:46 schrieb Nirmoy Das:
On 01.10.25 14:15, Thomas Zimmermann wrote:
No caller of the client resume/suspend helpers holds the console
lock. The last such cases were removed from radeon in the patch
series at [1]. Now remove the
Hi
Am 01.10.25 um 14:46 schrieb Nirmoy Das:
On 01.10.25 14:15, Thomas Zimmermann wrote:
No caller of the client resume/suspend helpers holds the console
lock. The last such cases were removed from radeon in the patch
series at [1]. Now remove the related parameter and the TODO items.
Signed-o
On 01.10.25 14:15, Thomas Zimmermann wrote:
No caller of the client resume/suspend helpers holds the console
lock. The last such cases were removed from radeon in the patch
series at [1]. Now remove the related parameter and the TODO items.
Signed-off-by: Thomas Zimmermann
Link: https://patch
On 2025-09-26 06:53, Khatri, Sunil wrote:
On 9/24/2025 10:27 PM, Kuehling, Felix wrote:
On 2025-09-24 06:01, Sunil Khatri wrote:
update the amdgpu_ttm_tt_get_user_pages and all dependent function
along with it callers to use a user allocated hmm_range buffer instead
hmm layer allocates the buf
On Tue, Sep 30, 2025 at 4:27 AM YiPeng Chai wrote:
>
> Add amdgpu drm ras ioctl for ras module.
Please describe the IOCTL and how it is used and what functionality it
provides. Additionally please provide a link to the proposed open
source userspace tools that will use it. We can't merge the ke
On 2025-09-25 22:49, Zhu, Lingshan wrote:
On 9/25/2025 5:50 AM, Kuehling, Felix wrote:
On 2025-09-23 03:26, Zhu Lingshan wrote:
The user space program pass down a pid to kfd
through set_debug_trap ioctl, which can help
find the corresponding user space program and
its mm struct.
However, these
On 2025-09-30 03:07, Pekka Paalanen wrote:
On Thu, 14 Aug 2025 21:50:06 -0600
Alex Hung wrote:
From: Harry Wentland
Certain operations require us to preserve values below 0.0 and
above 1.0 (0x0 and 0x respectively in 16 bpc unorm). One
such operation is a BT709 encoding operation foll
On Tue Sep 30, 2025 at 11:00 AM CEST, Philipp Stanner wrote:
> +Cc Sima, Dave
>
> On Mon, 2025-09-29 at 16:07 +0200, Danilo Krummrich wrote:
>> On Wed Sep 3, 2025 at 5:23 PM CEST, Tvrtko Ursulin wrote:
>> > This is another respin of this old work^1 which since v7 is a total
>> > rewrite and
>> > c
Original Message-
> From: amd-gfx On Behalf Of Liang,
> Prike
> Sent: Tuesday, September 30, 2025 4:20 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
>
> Subject: RE: [PATCH v5 4/8] drm/amdgpu: keeping waiting userq fence infini
On Sun, 2025-09-28 at 16:14 +0200, Christian König wrote:
>
>
> On 26.09.25 20:26, Timur Kristóf wrote:
> > Set stricter dividers to stabilize the PLL's feedback loop.
> > In practice, the actual output isn't exactly the target
> > clock, but slowly oscillates around it. This makes it
> > more st
1 - 100 of 4776 matches
Mail list logo
