On 8/12/2021 1:34 AM, Christoph Hellwig wrote:
Do you have a pointer to a git branch with this series and all dependencies
to ease testing?
Hi Christoph,
Yes, actually tomorrow we're planning to send a new version with
detailed instructions
on how to setup and run each of the tests. This
Hello Brian,
(+Uma in cc)
Thanks for your comments, Let me try to fill-in for Harry to keep the
design discussion going. Please find my comments inline.
On 8/2/2021 10:00 PM, Brian Starkey wrote:
Hi,
Thanks for having a stab at this, it's a massive complex topic to
solve.
Do you have the
On 8/12/2021 10:24 PM, Michel Dänzer wrote:
On 2021-08-12 1:33 p.m., Lazar, Lijo wrote:
On 8/12/2021 1:41 PM, Michel Dänzer wrote:
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
Hi James,
Evan seems to have understood how this all works together.
See while any begin/end use critical
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, August 12, 2021 5:49 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: nils.wallmen...@gmail.com; Chen, Guchun
> Subject: Re: [PATCH V3 2/7] drm/amd/pm: record the RPM and PWM based
> fan speed
Am 2021-08-12 um 11:49 a.m. schrieb Zhang, Yifan:
> [AMD Official Use Only]
>
> Yes, it is a sync issue b/w SVMRange unmap deferred list and get-attribute
> call. There is time slot when Process vma has been unmapped from CPU side,
> but prange is not removed in deferred list. If get-attribute
On 2021-08-12 1:33 p.m., Lazar, Lijo wrote:
> On 8/12/2021 1:41 PM, Michel Dänzer wrote:
>> On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
>>> Hi James,
>>>
>>> Evan seems to have understood how this all works together.
>>>
>>> See while any begin/end use critical section is active the work
[AMD Official Use Only]
Yes, it is a sync issue b/w SVMRange unmap deferred list and get-attribute
call. There is time slot when Process vma has been unmapped from CPU side, but
prange is not removed in deferred list. If get-attribute is called in this
time slot, then there will be a problem.
MMSCH doesn't have major/minor version, only verison.
Signed-off-by: Zhigang Luo
---
drivers/gpu/drm/amd/amdgpu/mmsch_v1_0.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mmsch_v1_0.h
b/drivers/gpu/drm/amd/amdgpu/mmsch_v1_0.h
index
On Wed, Aug 11, 2021 at 10:52:55AM -0500, Tom Lendacky wrote:
> 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:
>
On 8/12/2021 1:41 PM, Michel Dänzer wrote:
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
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
On 8/12/2021 3:03 PM, 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:
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
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
--
v1->v2:
- switch auto fan control off for AMD_FAN_CTRL_NONE mode (Lijo)
---
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
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
On 8/12/2021 2:19 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Thursday, August 12, 2021 3:53 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
On 8/12/2021 1:49 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Thursday, August 12, 2021 3:38 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
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, August 12, 2021 3:53 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
Reviewed-by: Emily.Deng
>-Original Message-
>From: amd-gfx On Behalf Of Zhou,
>Peng Ju
>Sent: Thursday, August 12, 2021 4:28 PM
>To: Zhou, Peng Ju ; amd-gfx@lists.freedesktop.org
>Cc: Zhao, Jiange
>Subject: RE: [PATCH] drm/amdgpu: Add MB_REQ_MSG_READY_TO_RESET
>response when VF get FLR
[AMD Official Use Only]
ping
> -Original Message-
> From: Peng Ju Zhou
> Sent: Monday, August 9, 2021 5:37 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhao, Jiange ; Zhou, Peng Ju
>
> Subject: [PATCH] drm/amdgpu: Add MB_REQ_MSG_READY_TO_RESET
> response when VF get FLR notification.
>
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, August 12, 2021 3:38 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
>
>
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
> 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
On 8/12/2021 12:21 PM, Quan, Evan wrote:
[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
On 8/12/2021 12:16 PM, Quan, Evan wrote:
[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
Do you have a pointer to a git branch with this series and all dependencies
to ease testing?
On Thu, Aug 12, 2021 at 01:30:47AM -0500, Alex Sierra wrote:
> v1:
> AMD is building a system architecture for the Frontier supercomputer with a
> coherent interconnect between CPUs and GPUs. This
[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
[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 =
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
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
---
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
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
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
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
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
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.
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
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
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
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
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
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
---
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:
50 matches
Mail list logo
