[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, August 12, 2021 2:05 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: nils.wallmen...@gmail.com; Chen, Guchun
> Subject: Re: [PATCH V2 2/7] drm/amd/pm: record the RPM and PWM based
> fan speed s
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, August 12, 2021 2:16 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: nils.wallmen...@gmail.com; Chen, Guchun
> Subject: Re: [PATCH V2 6/7] drm/amd/pm: drop unnecessary manual mode
> check
>
>
In order to configure device generic in test_hmm, two
module parameters should be passed, which correspon to the
SP start address of each device (2) spm_addr_dev0 &
spm_addr_dev1. If no parameters are passed, private device
type is configured.
v5:
Remove devmem->pagemap.type = MEMORY_DEVICE_PRIVAT
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device generic type.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c | 15 ++-
lib/test_hmm_uapi.h | 7 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/lib/test_hmm
Generic device type memory on VRAM to RAM migration,
has similar access as System RAM from the CPU. This flag sets
the source from the sender. Which in Generic type case,
should be set as SYSTEM.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
Test cases such as migrate_fault and migrate_multiple,
were modified to explicit migrate from device to sys memory
without the need of page faults, when using device generic
type.
Snapshot test case updated to read memory device type
first and based on that, get the proper returned results
migrate
Add MEMORY_DEVICE_GENERIC case to free_zone_device_page callback.
Device generic type memory case is now able to free its pages properly.
Signed-off-by: Alex Sierra
---
mm/memremap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/memremap.c b/mm/memremap.c
index 614b
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration, etc.). Clean up the code so the reference
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as generic.
Signed-off-by: Alex Sierra
---
tools/testing/selftests/vm/test_hmm.sh | 20
Device generic type case added for migrate_vma_pages and
migrate_vma_check_page helpers.
Both, generic and private device types have the same
conditions to decide to migrate pages from/to device
memory.
Signed-off-by: Alex Sierra
---
mm/migrate.c | 20 +---
1 file changed, 9 inse
Device Generic type uses device memory that is coherently
accesible by the CPU. Usually, this is shown as SP
(special purpose) memory range at the BIOS-e820 memory
enumeration. If no SP memory is supported in system,
this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only s
Two helpers added. One checks if zone device page is generic
type. The other if page is either private or generic type.
Signed-off-by: Alex Sierra
---
include/linux/mm.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c0fcb47d7641..8853ac
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_GENERIC to create the device
page map region.
Sign
The AMD architecture for the Frontier supercomputer will
have device memory which can be coherently accessed by
the CPU. The system BIOS advertises this memory as SPM
(special purpose memory) in the UEFI system address map.
The AMDGPU driver needs to be able to lookup this resource
in order to cla
From: Ralph Campbell
There are several places where ZONE_DEVICE struct pages assume a reference
count == 1 means the page is idle and free. Instead of open coding this,
add a helper function to hide this detail.
v3:
[AS]: rename dax_layout_is_idle_page func to dax_page_unused
v4:
[AS]: This ref
v1:
AMD is building a system architecture for the Frontier supercomputer with a
coherent interconnect between CPUs and GPUs. This hardware architecture allows
the CPUs to coherently access GPU device memory. We have hardware in our labs
and we are working with our partner HPE on the BIOS, firmware
[AMD Official Use Only]
From: Lazar, Lijo
Sent: Thursday, August 12, 2021 2:27 PM
To: Wang, Kevin(Yang) ; amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth ; Min, Frank ;
Zhang, Hawking
Subject: Re: [PATCH v2 1/2] drm/amd/pm: skip to load smu microcode on srio
On 8/12/2021 11:46 AM, Kevin Wang wrote:
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| 102 +++
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 fil
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| 102 --
1 file changed, 70 insertions(+), 32 d
On 8/12/2021 9:31 AM, Evan Quan wrote:
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_
On 8/12/2021 9:31 AM, Evan Quan wrote:
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:
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 fi
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:
- rena
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 (Guchun
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 inse
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 optimizati
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 ; W
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 d
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 fil
[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; dri-de...@lists.fr
[AMD Official Use Only]
Different from the 1st patch(for amdgpu_gfx_off_ctrl) of the series,
"cancel_delayed_work_sync(&adev->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"?
S
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:
https:/
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, Rames
[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 PM
[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 begin_use
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 st
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. Impl
[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 whi
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 was
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 fi
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",
>addr,
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
---
drivers/pci/p
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
re-e
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 On
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 al
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
inde
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
>> +++ b/include/linux/protected_guest.h
[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 schedule
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 9:3
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 dc->clk_mgr-
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
> >> --- a/
[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
> [ 99
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 amdgpu_j
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 insertions
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 insertions(+
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 -
.../gpu/drm/amd/pm/swsmu/smu11/arct
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 deletio
[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: added
[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 ; amd-
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 deletion
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 a/drivers/gpu/drm/amd/pm/swsmu/smu13/ald
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 a/drivers/gpu/drm/amd/pm/swsm
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
.../gpu/drm/amd/pm/swsmu/smu13/al
[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, Ev
79 matches
Mail list logo