To acquire the voltage and current info from gpu_metrics interface,
but gpu_metrics_v2_3 doesn't contain them, and to be backward compatible,
add new gpu_metrics_v2_4 structure.
Reviewed-by: Mario Limonciello
Acked-by: Evan Quan
Signed-off-by: Wenyou Yang
---
.../gpu/drm/amd/include/kgd_pp_int
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 3 +
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 3 +
.../gpu/d
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 28 ---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 7 +
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/dr
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).
To make WBRF feature functional, the kernel n
To support AMD's WBRF interference mitigation mechanism, Wifi adapters
utilized in the system must register the frequencies in use(or unregister
those frequencies no longer used) via the dedicated APCI calls. So that,
other drivers responding to the frequencies can take proper actions to
mitigate p
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +-
.../amd/pm/swsmu/inc/pmfw
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
---
include/net/cfg80211.h | 8
net/wireless/chan.c| 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index
From: Mario Limonciello
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced an
Due to electrical and mechanical constraints in certain platform designs there
may
be likely interference of relatively high-powered harmonics of the (G-)DDR
memory
clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate
possible RFI interference producers can advertise th
[AMD Official Use Only - General]
Could you add the expected units of voltage/current in 2.4 metrics structure?
Is it mV/mA or mV/A?
Thanks,
Lijo
-Original Message-
From: amd-gfx On Behalf Of Wenyou Yang
Sent: Thursday, June 1, 2023 7:08 AM
To: Deucher, Alexander ; Limonciello, Mario
On Tue, Jun 20, 2023 at 7:18 AM Christian König
wrote:
>
> Since adding gang submit we need to take the gang size into account
> while reserving fences.
>
> Signed-off-by: Christian König
> Fixes: 4624459c84d7 ("drm/amdgpu: add gang submit frontend v6")
Reviewed-by: Alex Deucher
> ---
> drive
[AMD Official Use Only - General]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Zhou1, Tao
Sent: Wednesday, June 21, 2023 10:55
To: amd-gfx@lists.freedesktop.org; Yang, Stanley ; Zhang,
Hawking ; Li, Candice ; Chai, Thomas
Cc: Zhou1, Tao
Subject: [PATCH] drm/a
No RAS irq is allowed.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg
Conform to Linux kernel coding style.
Reported by checkpatch:
WARNING: else is not generally useful after a break or return
Expressions under 'else' branch in function 'dm_crtc_get_scanoutpos' are
executed whenever the expression in 'if' is False. Otherwise, return
from function occurs. Therefor
Conform to Linux kernel coding style.
Reported by checkpatch:
WARNING: else is not generally useful after a break or return
Expressions under 'else' branch in function 'dm_crtc_get_scanoutpos' are
executed whenever the expression in 'if' is False. Otherwise, return
from function occurs. Therefor
Call KFD api to get Dmabuf instead of calling GEM Prime API
Signed-off-by: Ramesh Errabolu
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
Need to unpause dpg first, or it will hit follow error during stop dpg:
"[drm] Register(1) [regUVD_POWER_STATUS] failed to reach value 0x0001 !=
0xn"
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu
[AMD Official Use Only - General]
Hi Leo,
Sorry, need to correct the commit message, it is unpasue, during unloading
driver, I haven't seen any place call un-pause dpg for vcn4.0 for hw fini. And
it will report "[drm] Register(1) [regUVD_POWER_STATUS] failed to reach value
>0x0001 != 0x
[AMD Official Use Only - General]
> -Original Message-
> From: Limonciello, Mario
> Sent: Monday, June 19, 2023 10:04 AM
> To: Quan, Evan
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@
[AMD Official Use Only - General]
> -Original Message-
> From: Limonciello, Mario
> Sent: Monday, June 19, 2023 10:17 AM
> To: Quan, Evan
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@
[AMD Official Use Only - General]
> -Original Message-
> From: Johannes Berg
> Sent: Monday, June 19, 2023 4:24 PM
> To: Limonciello, Mario ; Quan, Evan
>
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; l
Implement get_reset ioctl for i915.
Signed-off-by: André Almeida
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 18 ++
drivers/gpu/drm/i915/gem/i915_gem_context.h| 2 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 ++
drivers/gpu/drm/i915/i915_driver.c
Implement get_reset ioctl for amdgpu
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 35 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 5
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
drive
Create a new DRM ioctl operation to get the numbers of resets for a
given context. The numbers reflect just the resets that happened after
the context was created, and not since the machine was booted.
Create a debugfs interface to make easier to test the API without real
resets.
Signed-off-by: A
Create a section that specifies how to deal with DRM device resets for
kernel and userspace drivers.
Signed-off-by: André Almeida
---
Documentation/gpu/drm-uapi.rst | 65 ++
1 file changed, 65 insertions(+)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentat
Hi,
This is a new version of the documentation for DRM device resets. As I dived
more in the subject, I started to believe that part of the problem was the lack
of a DRM API to get reset information from the driver. With an API, we can
better standardize reset queries, increase common code from bo
[AMD Official Use Only - General]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of
> Kenneth Feng
> Sent: Tuesday, June 20, 2023 11:46 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Feng, Kenneth
> Subject: [PATCH] drm/amd/pm: add abnormal fan detection for smu 13
Hi Su,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.4-rc7 next-20230620]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
[AMD Official Use Only - General]
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, June 19, 2023 10:55 PM
> To: Quan, Evan ; raf...@kernel.org; l...@kernel.org;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@
On 2023-06-19 13:38, Mukul Joshi wrote:
Update the invalid PTE flag setting with TF enabled.
This is to ensure, in addition to transitioning the
retry fault to a no-retry fault, it also causes the
wavefront to enter the trap handler. With the current
setting, the fault only transitions to a no-re
[Public]
You've got an A-b from Evan already on this. It looks fine to me too.
Reviewed-by: Mario Limonciello
> -Original Message-
> From: Yang, WenYou
> Sent: Sunday, June 11, 2023 12:53 AM
> To: Yang, WenYou ; Deucher, Alexander
> ; Limonciello, Mario
> ; Koenig, Christian
> ; Pan,
Hi Su,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.4-rc7 next-20230620]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
MES allocates process level doorbells, but there is no userspace
client to consume it. It was only being used for the MES ring
tests (in kernel), and was written by kernel doorbell write.
The previous patch of this series has changed the MES ring test code to
use kernel level MES doorbells. This p
This patch:
- Removes the existing doorbell management code, and its variables
from the doorbell_init function, it will be done in doorbell
manager now.
- uses the doorbell page created for MES kernel level needs (doorbells
for MES self tests)
- current MES code was allocating MES doorbells i
This patch removes some variables and functions from KFD
doorbell handling code, which are no more required since
doorbell manager is handling doorbell calculations.
Cc: Alex Deucher
Cc: Christian Koenig
Cc: Felix Kuehling
Reviewed-by: Felix Kuehling
Signed-off-by: Shashank Sharma
---
driver
This patch:
- adds a doorbell object in kfd pdd structure.
- allocates doorbells for a process while creating its queue.
- frees the doorbells with pdd destroy.
- moves doorbell bitmap init function to kfd_doorbell.c
PS: This patch ensures that we don't break the existing KFD
functionality, bu
Doorbells in AMDGPU drivers are currently managed by different clients
in a scattered way, across may places. The existing clients are:
- AMDGPU graphics driver for kernel level doorbell writes.
- AMDGPU MES module for kernel level doorbell write (MES ring test and
aggregated doorbells).
- AMDGPU
From: Alex Deucher
This patch adds changes:
- to accommodate the new GEM domain DOORBELL
- to accommodate the new TTM PL DOORBELL
in order to manage doorbell pages as GEM object.
V2: Addressed reviwe comments from Christian
- drop the doorbell changes for pinning/unpinning
- drop the do
This patch:
- creates a doorbell page for graphics driver usages.
- adds a few new varlables in adev->doorbell structure to
keep track of kernel's doorbell-bo.
- removes the adev->doorbell.ptr variable, replaces it with
kernel-doorbell-bo's cpu address.
V2: - Create doorbell BO directly, no wr
This patch adds a helper function which converts a doorbell's
relative index in a BO to an absolute doorbell offset in the
doorbell BAR.
V2: No space between the variable name doc (Luben)
Cc: Alex Deucher
Cc: Christian Koenig
Acked-by: Christian König
Signed-off-by: Shashank Sharma
---
drive
This patch:
- adds a doorbell bo in kfd device structure.
- creates doorbell page for kfd kernel usages.
- updates the get_kernel_doorbell and free_kernel_doorbell functions
accordingly
V2: Do not use wrapper API, use direct amdgpu_create_kernel(Alex)
V3:
- Move single variable declaration belo
From: Alex Deucher
This patch adds flags for a new gem domain AMDGPU_GEM_DOMAIN_DOORBELL
in the UAPI layer.
V2: Drop 'memory' from description (Christian)
Cc: Alex Deucher
Cc: Christian Koenig
Reviewed-by: Christian Koenig
Signed-off-by: Alex Deucher
Signed-off-by: Shashank Sharma
---
inc
This patch initialzes the ttm resource manager for doorbells.
V2: Do not round up doorbell size (Alex)
Cc: Alex Deucher
Cc: Christian Koenig
Reviewed-by: Christian Koenig
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++
1 file changed, 7 insertions(+)
This patch:
- creates a new file for doorbell management.
- moves doorbell code from amdgpu_device.c to this file.
V2:
- remove doc from function declaration (Christian)
- remove 'device' from function names to make it consistent (Alex)
- add SPDX license identifier (Luben)
V3:
- change licen
This patch removes the check and change in num_kernel_doorbells
for MES, which is not being used anywhere by MES code.
Cc: Alex Deucher
Cc: Christian Koenig
Reviewed-by: Christian Koenig
Acked-by: Alex Deucher
Signed-off-by: Shashank Sharma
---
.../gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c |
[AMD Official Use Only - General]
Acked-by: Victor Skvortsov
-Original Message-
From: Lazar, Lijo
Sent: Monday, June 19, 2023 3:30 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Kuehling, Felix ;
Skvortsov, Victor
Subject: [PATCH v2] drm/amdgpu: Modify
[Why]
VCN will use some framebuffer space as its cache. It needs to
be reset when reset happens, such as FLR. Otherwise some error
may be kept after the reset.
Signed-off-by: Horace Chen
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/
Since adding gang submit we need to take the gang size into account
while reserving fences.
Signed-off-by: Christian König
Fixes: 4624459c84d7 ("drm/amdgpu: add gang submit frontend v6")
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
On Tue, 20 Jun 2023 11:14:51 +0200
Christian König wrote:
> Am 20.06.23 um 11:09 schrieb Boris Brezillon:
> > On Tue, 20 Jun 2023 10:44:26 +0200
> > Christian König wrote:
> >
> >> Am 20.06.23 um 10:28 schrieb Boris Brezillon:
> >>> On Tue, 20 Jun 2023 10:12:13 +0200
> >>> Christian König w
Am 20.06.23 um 11:13 schrieb Thomas Zimmermann:
Hi
Am 04.05.23 um 13:51 schrieb Christian König:
Just a straightforward conversion without any optimization.
Only compile tested for now.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/qxl/qxl_dr
Am 20.06.23 um 11:09 schrieb Boris Brezillon:
On Tue, 20 Jun 2023 10:44:26 +0200
Christian König wrote:
Am 20.06.23 um 10:28 schrieb Boris Brezillon:
On Tue, 20 Jun 2023 10:12:13 +0200
Christian König wrote:
I think Boris's suggestion of having this through a common
DRM_EXEC_FLAG_ALLOW_D
Hi
Am 04.05.23 um 13:51 schrieb Christian König:
Just a straightforward conversion without any optimization.
Only compile tested for now.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/qxl/qxl_drv.h | 7 ++--
drivers/gpu/drm/qxl/qxl_relea
On Tue, 20 Jun 2023 10:44:26 +0200
Christian König wrote:
> Am 20.06.23 um 10:28 schrieb Boris Brezillon:
> > On Tue, 20 Jun 2023 10:12:13 +0200
> > Christian König wrote:
> >
> >>> I think Boris's suggestion of having this through a common
> >>> DRM_EXEC_FLAG_ALLOW_DUPLICATES flag fits well.
On 6/20/23 17:16, Tatsuyuki Ishi wrote:
On 6/20/23 17:12, Christian König wrote:
Am 20.06.23 um 06:07 schrieb Tatsuyuki Ishi:
@@ -928,18 +874,56 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser
*p,
e->user_invalidated = userpage_invalidated;
}
- r = ttm_eu_reserv
Am 20.06.23 um 10:28 schrieb Boris Brezillon:
On Tue, 20 Jun 2023 10:12:13 +0200
Christian König wrote:
I think Boris's suggestion of having this through a common
DRM_EXEC_FLAG_ALLOW_DUPLICATES flag fits well.
No, again. The only driver which should accept duplicates is radeon, for
all other
On Tue, 20 Jun 2023 10:12:13 +0200
Christian König wrote:
> > I think Boris's suggestion of having this through a common
> > DRM_EXEC_FLAG_ALLOW_DUPLICATES flag fits well.
>
> No, again. The only driver which should accept duplicates is radeon, for
> all other drivers especially new ones dup
On 6/20/23 17:12, Christian König wrote:
Am 20.06.23 um 06:07 schrieb Tatsuyuki Ishi:
+Boris and +Matthew in case you want to take over this patch set.
Here are some review / testing comments, including those I posted before to
ease tracking.
On 5/4/23 20:51, Christian König wrote:
Use the n
Am 20.06.23 um 06:14 schrieb Tatsuyuki Ishi:
On 6/20/23 13:07, Tatsuyuki Ishi wrote:
@@ -1296,9 +1271,8 @@ static int amdgpu_cs_submit(struct
amdgpu_cs_parser *p,
*/
r = 0;
amdgpu_bo_list_for_each_userptr_entry(e, p->bo_list) {
- struct amdgpu_bo *bo = ttm_to_amdgpu_bo
Am 20.06.23 um 06:07 schrieb Tatsuyuki Ishi:
+Boris and +Matthew in case you want to take over this patch set.
Here are some review / testing comments, including those I posted
before to ease tracking.
On 5/4/23 20:51, Christian König wrote:
Use the new component here as well and remove the
[AMD Official Use Only - General]
> -Original Message-
> From: Stanley.Yang
> Sent: Monday, June 19, 2023 9:50 PM
> To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ;
> Zhou1, Tao ; Chai, Thomas
> Cc: Yang, Stanley
> Subject: [PATCH Review V2 1/1] drm/amdgpu: Remove redundant poison
>
Am 20.06.23 um 08:47 schrieb Boris Brezillon:
On Mon, 19 Jun 2023 14:29:23 +0200
Boris Brezillon wrote:
On Mon, 19 Jun 2023 12:44:06 +0200
Christian König wrote:
Am 19.06.23 um 12:12 schrieb Boris Brezillon:
[SNIP]
Note that the drm_exec_until_all_locked() helper I introduced is taking
an
Smatch error:
gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:316:49: error:
static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB"
static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
Fixes: 1721bc1b2afa ("drm/amdgpu: Update VF2PF interface")
Signed-off-by: Su Hui
---
driv
On Fri, 16 Jun 2023 08:53:20 -0400
Alex Deucher wrote:
> On Fri, Jun 16, 2023 at 8:11 AM Juerg Haefliger
> wrote:
> >
> > Add the missing MODULE_FIRMWARE macro for "amdgpu/fiji_smc.bin".
> >
> > Signed-off-by: Juerg Haefliger
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
> > 1
On 2023-06-19 16:05, Alex Deucher wrote:
> On Mon, Jun 19, 2023 at 9:05 AM Christian Kastner wrote:
>> On a Debian 12 ("bookworm") system, I observed a new warning when I
>> upgraded from kernel 6.1.25 to 6.1.27. This is on a system with an RX
>> 6800 XT GPU and 3500X processor.
>
> The warnings
65 matches
Mail list logo
