Hi James,
Evan seems to have understood how this all works together.
See while any begin/end use critical section is active the work should not be
active.
When you handle only one ring you can just call cancel in begin use and
schedule in end use. But when you have more than one ring you need
These registers have different address from other SMU V11 ASICs.
Change-Id: Iaeb0438331eed9b0313933da25622f8e4c048fab
Signed-off-by: Evan Quan
---
v1->v2:
- cover the ASIC specific details in arcturus_ppt.c (Lijo)
---
.../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 138 +-
1
Currently, the readout of fan speed pwm is transited into percent-based
and then pwm-based. However, the transition into percent-based is totally
unnecessary and make the final output less accurate.
Change-Id: Ib99e088cda1875b4e2601f7077a178af6fe8a6cb
Signed-off-by: Evan Quan
---
v1->v2:
-
The relationship "PWM = RPM / smu->fan_max_rpm" between fan speed
PWM and RPM is not true for SMU11 ASICs. So, we need a new way to
retrieving the fan speed RPM.
Change-Id: Ife4298c8b7ec93ef023a7da27d59654e0444e044
Signed-off-by: Evan Quan
--
v1->v2
- drop unneeded intermediate varaible
As the fan control was guarded under manual mode before fan speed
RPM/PWM setting. Thus the extra check is totally redundant.
Change-Id: Ia9d776141ec4aa39255accbf00d7e7ed81c8424d
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 12 +---
1 file changed, 1
The relationship "PWM = RPM / smu->fan_max_rpm" between fan speed
PWM and RPM is not true for SMU11 ASICs. So, we need a new way to
retrieving the fan speed PWM.
Change-Id: Idfe0276d7113b9c921b88fa08085a33fd971d621
Signed-off-by: Evan Quan
---
.../include/asic_reg/thm/thm_11_0_2_offset.h | 3
As the relationship "PWM = RPM / smu->fan_max_rpm" between fan speed
PWM and RPM is not true for SMU11 ASICs. So, both the RPM and PWM
settings need to be saved.
Change-Id: I318c134d442273d518b805339cdf383e151b935d
Signed-off-by: Evan Quan
--
v1->v2:
- coding style and logging prints
The relationship "PWM = RPM / smu->fan_max_rpm" between fan speed
PWM and RPM is not true for SMU11 ASICs. So, we need a new way to
perform the fan speed RPM setting.
Change-Id: I1afe8102f02ead9a8a07c7105f689ac60a85b0d8
Signed-off-by: Evan Quan
--
v1->v2:
- hardcode crystal_clock_freq as 25Mhz
[AMD Official Use Only]
please ignore this patch, there some errors in here.
Best Regards,
Kevin
From: Wang, Kevin(Yang)
Sent: Thursday, August 12, 2021 11:36 AM
To: amd-gfx@lists.freedesktop.org
Cc: Lazar, Lijo ; Feng, Kenneth ;
Min, Frank ; Zhang, Hawking ;
v1:
1. skip to load smu firmware in sriov mode for aldebaran chip
2. using vbios pptable if in sriov mode.
v2:
clean up smu driver code in sriov code path
Signed-off-by: Kevin Wang
---
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 41 +++
1 file changed, 25 insertions(+), 16
v1:
1. change return value to avoid smu driver probe fails when FEATURE_PPT is
not enabled.
2. if FEATURE_PPT is not enabled, set power limit value to 0.
v2:
instead dev_err with dev_warn
Signed-off-by: Kevin Wang
---
.../gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c| 15 +--
1
[AMD Official Use Only]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of
> Michel Dänzer
> Sent: Thursday, August 12, 2021 12:52 AM
> To: Deucher, Alexander ; Koenig, Christian
>
> Cc: Liu, Leo ; Zhu, James ; amd-
> g...@lists.freedesktop.org;
[AMD Official Use Only]
Different from the 1st patch(for amdgpu_gfx_off_ctrl) of the series,
"cancel_delayed_work_sync(>uvd.idle_work)" will be called on like
amdgpu_uvd_ring_begin_use(). Under this case, does it make any difference from
previous implementation "schedule_delayed_work"?
Hi Dave, Daniel,
Fixes for 5.14.
The following changes since commit d186f9c28008810d8f984d6bdd1c07757048ed63:
Merge tag 'amd-drm-fixes-5.14-2021-08-05' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-08-06 11:22:09
+1000)
are available in the Git repository at:
I will investigate it further. I am using DKMS-5.11 branch. The codebase I am
using to build has the right definition i.e. allow P2PDMA for Zen CPU's.
Regards,
Ramesh
-Original Message-
From: Alex Deucher
Sent: Wednesday, August 11, 2021 4:07 PM
To: Kuehling, Felix
Cc: Errabolu,
[AMD Official Use Only]
I shouldn't say reduce one delay work call , For this case, Michael's proposal
is closer to idle work design's purpose.
Thanks & Best Regards!
James Zhu
From: amd-gfx on behalf of Zhu, James
Sent: Wednesday, August 11, 2021 6:12
[AMD Official Use Only]
Hi Christian,
Since we have strict check on queue status, I don't think original design can
cause issue here.
But this change should help improve below case:
1. both enc thread and dec thread try to start begin_use.
2. dec thread gets the chance to finish
NAK to at least this patch.
Since activating power management while submitting work is problematic
cancel_delayed_work() must have been called during begin use or otherwise we
have a serious coding problem in the first place.
So this change shouldn't make a difference and I suggest to really
On Wed, Aug 11, 2021 at 4:50 PM Felix Kuehling wrote:
>
>
> Am 2021-08-11 um 3:29 p.m. schrieb Alex Deucher:
> > On Wed, Aug 11, 2021 at 3:11 PM Ramesh Errabolu
> > wrote:
> >> Current implementation will disallow P2P DMA if the participating
> >> devices belong to different root complexes.
[AMD Official Use Only]
This patch is Reviewed-by: James Zhu
Thanks & Best Regards!
James Zhu
From: Alex Deucher
Sent: Wednesday, August 11, 2021 4:34 PM
To: Michel Dänzer
Cc: Deucher, Alexander ; Koenig, Christian
; Liu, Leo ; Zhu, James
; amd-gfx list
Am 2021-08-11 um 3:29 p.m. schrieb Alex Deucher:
> On Wed, Aug 11, 2021 at 3:11 PM Ramesh Errabolu
> wrote:
>> Current implementation will disallow P2P DMA if the participating
>> devices belong to different root complexes. Implementation allows
>> this default behavior to be overridden for
On Wed, Aug 11, 2021 at 12:52 PM Michel Dänzer wrote:
>
> From: Michel Dänzer
>
> In contrast to schedule_delayed_work, this pushes back the work if it
> was already scheduled before. Specific behaviour change:
>
> Before:
>
> The scheduled work ran ~1 second after the first time ring_end_use
Applied. Thanks!
Alex
On Wed, Aug 11, 2021 at 9:46 AM Tuo Li wrote:
>
> The variable dc->clk_mgr is checked in:
> if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock)
>
> This indicates dc->clk_mgr can be NULL.
> However, it is dereferenced in:
> if (!dc->clk_mgr->funcs->get_clock)
>
> To
Applied. Thanks!
Alex
On Wed, Aug 11, 2021 at 7:35 AM Tuo Li wrote:
>
> The variable val is declared without initialization, and its address is
> passed to amdgpu_i2c_get_byte(). In this function, the value of val is
> accessed in:
> DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
>
On Wed, Aug 11, 2021 at 3:11 PM Ramesh Errabolu wrote:
>
> Current implementation will disallow P2P DMA if the participating
> devices belong to different root complexes. Implementation allows
> this default behavior to be overridden for whitelisted devices. The
> patch adds an AMD host bridge to
Current implementation will disallow P2P DMA if the participating
devices belong to different root complexes. Implementation allows
this default behavior to be overridden for whitelisted devices. The
patch adds an AMD host bridge to be whitelisted
Signed-off-by: Ramesh Errabolu
---
From: Michel Dänzer
In contrast to schedule_delayed_work, this pushes back the work if it
was already scheduled before. Specific behaviour change:
Before:
amdgpu_device_delay_enable_gfx_off ran ~100 ms after the first time
GFXOFF was disabled and re-enabled, even if GFXOFF was disabled and
From: Michel Dänzer
In contrast to schedule_delayed_work, this pushes back the work if it
was already scheduled before. Specific behaviour change:
Before:
The scheduled work ran ~1 second after the first time ring_end_use was
called, even if the ring was used again during that second.
After:
[AMD Official Use Only]
-Original Message-
From: Joshi, Mukul
Sent: Wednesday, August 11, 2021 10:57 AM
To: Kasiviswanathan, Harish ;
amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix ; Cornwall, Jay
Subject: RE: [PATCH] drm/amdkfd: CWSR with software scheduler
[AMD Official Use
Am 2021-08-11 um 10:35 a.m. schrieb Philip Yang:
> For xnack on, if range ACCESS or ACCESS_IN_PLACE (AIP) by single GPU, or
> range is ACCESS_IN_PLACE by mGPUs and all mGPUs connection on XGMI same
> hive, the best prefetch location is prefetch_loc GPU. Otherwise, the best
> prefetch location is
On 8/11/21 7:19 AM, Kirill A. Shutemov wrote:
> On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
>> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
>>>
>>>
>>> On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
On 8/11/21 9:53 AM, Kuppuswamy, Sathyanarayanan wrote:
> On 7/27/21 3:26 PM, Tom Lendacky wrote:
>> diff --git a/include/linux/protected_guest.h
>> b/include/linux/protected_guest.h
>> new file mode 100644
>> index ..f8ed7b72967b
>> --- /dev/null
>> +++
[AMD Official Use Only]
> -Original Message-
> From: Kasiviswanathan, Harish
> Sent: Tuesday, August 10, 2021 9:15 PM
> To: Joshi, Mukul ; amd-gfx@lists.freedesktop.org
> Cc: Kuehling, Felix ; Cornwall, Jay
> ; Joshi, Mukul
> Subject: RE: [PATCH] drm/amdkfd: CWSR with software
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/include/linux/protected_guest.h b/include/linux/protected_guest.h
new file mode 100644
index ..f8ed7b72967b
--- /dev/null
+++ b/include/linux/protected_guest.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+
For xnack on, if range ACCESS or ACCESS_IN_PLACE (AIP) by single GPU, or
range is ACCESS_IN_PLACE by mGPUs and all mGPUs connection on XGMI same
hive, the best prefetch location is prefetch_loc GPU. Otherwise, the best
prefetch location is always CPU because GPU does not have coherent
mapping VRAM
[AMD Official Use Only]
yes, it is a coding error, I will correct it.
thanks.
Best Regards,
Kevin
From: Lazar, Lijo
Sent: Wednesday, August 11, 2021 5:45 PM
To: Wang, Kevin(Yang) ; amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth ; Min, Frank ;
Zhang, Hawking
On Tue, Aug 10, 2021 at 9:14 PM Koba Ko wrote:
>
> On Tue, Aug 10, 2021 at 11:09 PM Alex Deucher wrote:
> >
> > On Tue, Aug 10, 2021 at 12:57 AM Koba Ko wrote:
> > >
> > > On Tue, Aug 10, 2021 at 12:45 PM Mario Limonciello
> > > wrote:
> > > >
> > > >
> > > >
> > > > On Mon, Aug 9, 2021 at
The variable val is declared without initialization, and its address is
passed to amdgpu_i2c_get_byte(). In this function, the value of val is
accessed in:
DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n",
addr, *val);
Also, when amdgpu_i2c_get_byte() returns, val may remain uninitialized,
The variable dc->clk_mgr is checked in:
if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock)
This indicates dc->clk_mgr can be NULL.
However, it is dereferenced in:
if (!dc->clk_mgr->funcs->get_clock)
To fix this null-pointer dereference, check dc->clk_mgr and the function
pointer
On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
> >
> >
> > On 7/27/21 3:26 PM, Tom Lendacky wrote:
> >> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> >> index de01903c3735..cafed6456d45 100644
> >> ---
[AMD Official Use Only]
Reviewed by: Monk Liu
Thanks
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: Jingwen Chen
Sent: Wednesday, August 11, 2021 9:02 PM
To: amd-gfx@lists.freedesktop.org
Hi Guchun
Sorry to cause this fail. already submit a v5 patch to fix this.
On Wed Aug 11, 2021 at 05:26:52PM +0800, Chen, Guchun wrote:
> [Public]
>
> Attach the error log.
>
> [ 99.534964] kfd kfd: amdgpu: Allocated 3969056 bytes on gart
> [ 99.535531] amdgpu: SRAT table not found
> [
From: Jack Zhang
Why: Previously hw fence is alloced separately with job.
It caused historical lifetime issues and corner cases.
The ideal situation is to take fence to manage both job
and fence's lifetime, and simplify the design of gpu-scheduler.
How:
We propose to embed hw_fence into
Reviewed-by: Lijo Lazar
On 8/11/2021 2:03 PM, Kevin Wang wrote:
the following clock is only support voltage DPM, change attribute to RO:
1. pp_dpm_sclk
2. pp_dpm_mclk
3. pp_dpm_fclk
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 9 +++--
1 file changed, 7
Reviewed-by: Lijo Lazar
On 8/11/2021 2:03 PM, Kevin Wang wrote:
the following message is allowed in sriov mode:
1. GetEnabledSmuFeaturesLow
2. GetEnabledSmuFeaturesHigh
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 4 ++--
1 file changed, 2
Reviewed-by: Lijo Lazar
On 8/11/2021 2:03 PM, Kevin Wang wrote:
the following feature is wrong, it will cause sysnode of pp_features show error:
1. DPM_XGMI
2. VCN_DPM
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/pm/inc/smu_types.h | 1 -
On 8/11/2021 2:03 PM, Kevin Wang wrote:
1. change return value to avoid smu driver probe fails when FEATURE_PPT is
not enabled.
2. if FEATURE_PPT is not enabled, set power limit value to 0.
Signed-off-by: Kevin Wang
---
.../gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c| 15
On 8/11/2021 2:03 PM, Kevin Wang wrote:
1. skip to load smu firmware in sriov mode for aldebaran chip
2. using vbios pptable if in sriov mode.
Signed-off-by: Kevin Wang
---
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 66 ++-
1 file changed, 36 insertions(+), 30
[Public]
Attach the error log.
[ 99.534964] kfd kfd: amdgpu: Allocated 3969056 bytes on gart
[ 99.535531] amdgpu: SRAT table not found
[ 99.535532] amdgpu: Virtual CRAT table created for GPU
[ 99.536695] amdgpu: Topology: Add dGPU node [0x73a3:0x1002]
[ 99.536697] kfd kfd: amdgpu:
[Public]
Hi Jingwen,
Your patch has caused amdgpu driver load failure on all ASICs. Please revert it
first and come up with a proper fix.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Andrey
Grodzovsky
Sent: Wednesday, August 11, 2021 12:41 AM
To: Chen, JingWen ;
1. change return value to avoid smu driver probe fails when FEATURE_PPT is
not enabled.
2. if FEATURE_PPT is not enabled, set power limit value to 0.
Signed-off-by: Kevin Wang
---
.../gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c| 15 +--
1 file changed, 13 insertions(+), 2
the following clock is only support voltage DPM, change attribute to RO:
1. pp_dpm_sclk
2. pp_dpm_mclk
3. pp_dpm_fclk
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
the following message is allowed in sriov mode:
1. GetEnabledSmuFeaturesLow
2. GetEnabledSmuFeaturesHigh
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
1. skip to load smu firmware in sriov mode for aldebaran chip
2. using vbios pptable if in sriov mode.
Signed-off-by: Kevin Wang
---
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 66 ++-
1 file changed, 36 insertions(+), 30 deletions(-)
diff --git
the following feature is wrong, it will cause sysnode of pp_features show error:
1. DPM_XGMI
2. VCN_DPM
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/pm/inc/smu_types.h | 1 -
.../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c| 16
[Public]
> -Original Message-
> From: Chen, Guchun
> Sent: Wednesday, July 7, 2021 12:48 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
>
> Subject: RE: [PATCH 1/7] drm/amd/pm: correct the fan speed RPM setting
>
> [Public]
>
> tach_period
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Wednesday, July 7, 2021 4:50 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 1/7] drm/amd/pm: correct the fan speed RPM setting
>
>
>
> On 7/7/2021 7:26 AM,
57 matches
Mail list logo
