ping?
On Fri, Jun 26, 2020 at 10:04 AM Alex Deucher wrote:
>
> When the GPU is in reset, accessing the hw is unreliable and could
> interfere with the reset. Return an error in those cases.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 ++
> 1 file
Ping on this series?
On Thu, Jun 25, 2020 at 6:05 PM Alex Deucher wrote:
>
> Renoir uses integrated_system_info table v12. The table
> has the same layout as v11 with respect to this data. Just
> reuse the existing code for v12 for stable.
>
> Fixes incorrectly reported vram info in the driver
commit 5fa689e66bf406ef3a1afe03d0139d90b0b13773
Author: Likun Gao
Commit: Alex Deucher
drm/amdgpu/powerplay: add smu block for sienna_cichlid
Add SMU block for sienna_cichlid with psp load type.
Signed-off-by: Likun Gao
Reviewed-by: Jack Xiao
Spot the missing
kfd_pasid.c isn't using the kfd2kgd interface any more. Remove redundant
code trying to look up a device for finding that interface.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_pasid.c | 31 +++---
1 file changed, 8 insertions(+), 23 deletions(-)
diff
Am 2020-06-30 um 7:44 p.m. schrieb Fenghua Yu:
> PASID is defined as a few different types in iommu including "int",
> "u32", and "unsigned int". To be consistent and to match with uapi
> definitions, define PASID and its variations (e.g. max PASID) as "u32".
> "u32" is also shorter and a little
Typical hardware devices require a driver stack to translate application
buffers to hardware addresses, and a kernel-user transition to notify the
hardware of new work. What if both the translation and transition overhead
could be eliminated? This is what Shared Virtual Address (SVA) and ENQCMD
A PASID is allocated for an "mm" the first time any thread attaches
to an SVM capable device. Later device attachments (whether to the same
device or another SVM device) will re-use the same PASID.
The PASID is freed when the process exits (so no need to keep
reference counts on how many SVM
Work submission instruction comes in two flavors. ENQCMD can be called
both in ring 3 and ring 0 and always uses the contents of PASID MSR when
shipping the command to the device. ENQCMDS allows a kernel driver to
submit commands on behalf of a user process. The driver supplies the
PASID value in
From: Peter Zijlstra
The flag is defined for the task to identify if the task has a valid
PASID. Its initial value is 0 when the task is forked/cloned. It will
be used shortly.
Signed-off-by: Peter Zijlstra
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
---
v2:
- Add this patch to
PASID is defined as a few different types in iommu including "int",
"u32", and "unsigned int". To be consistent and to match with uapi
definitions, define PASID and its variations (e.g. max PASID) as "u32".
"u32" is also shorter and a little more explicit than "unsigned int".
No PASID type change
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Add this patch to initialize PASID value for a new mm.
include/linux/mm_types.h | 2 ++
kernel/fork.c
From: Yu-cheng Yu
ENQCMD instruction reads PASID from IA32_PASID MSR. The MSR is stored
in the task's supervisor FPU PASID state and is context switched by
XSAVES/XRSTORS.
Signed-off-by: Yu-cheng Yu
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
-
"flags" passed to intel_svm_bind_mm() is a bit mask and should be
defined as "unsigned int" instead of "int".
Change its type to "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
Reviewed-by: Lu Baolu
---
v5:
- Reviewed by Lu Baolu
v2:
- Add this
From: Ashok Raj
ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
features are a complicated stack with lots of interconnected pieces.
This documentation provides a big picture overview for all of the
features.
Signed-off-by: Ashok Raj
Co-developed-by: Fenghua Yu
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Both ARM and X86 need to use the PASID in the
"mm".
Suggested-by: Christoph Hellwig
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v4:
- Change PASID type to u32 (Christoph)
v3:
-
The PASID state has to be cleared on forks, since the child has a
different address space. The PASID is also cleared for thread clone. While
it would be correct to inherit the PASID in this case, it is unknown
whether the new task will use ENQCMD. Giving it the PASID "just in case"
would have the
A #GP fault is generated when ENQCMD instruction is executed without
a valid PASID value programmed in the current thread's PASID MSR. The
#GP fault handler will initialize the MSR if a PASID has been allocated
for this process.
Decoding the user instruction is ugly and sets a bad architecture
The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier
(PASID), a 20-bit value. Bit 31 must be set to indicate the value
programmed in the MSR is valid. Hardware uses PASID to identify process
address space and direct responses to the right address space.
Signed-off-by: Fenghua
[AMD Public Use]
Reviewed-by: Roman Li
-Original Message-
From: amd-gfx On Behalf Of Nicholas
Kazlauskas
Sent: Monday, June 29, 2020 4:49 PM
To: amd-gfx@lists.freedesktop.org
Cc: Lakha, Bhawanpreet ; Siqueira, Rodrigo
; Wu, Hersen ; Kazlauskas,
Nicholas
Subject: [PATCH]
When I update the latest kernel, I see the following "ptrval" boot
messages. Use "%pK" instead of "%p" so that the cpu address can be printed
when the kptr_restrict sysctl is set to 1.
Both radeon_fence_driver_start_ring() and amdgpu_fence_driver_start_ring()
have this similar issue, fix
On 06/30/2020 04:05 PM, Christian König wrote:
Am 30.06.20 um 09:36 schrieb Tiezhu Yang:
When I update the latest kernel, I see the following "ptrval"
boot
messages. Use "%pK" instead of "%p" so that the cpu address can be
printed
when the kptr_restrict sysctl is set to 1.
Both
[AMD Public Use]
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Huang Rui
Sent: Tuesday, June 30, 2020 6:30 AM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray
Subject: [PATCH 2/2] drm/amdgpu: add TMR destory function for psp
TMR is
[AMD Public Use]
Response inline.
Thanks,
-Joe
-Original Message-
From: Russell, Kent
Sent: Tuesday, June 30, 2020 7:00 AM
To: Greathouse, Joseph ;
amd-gfx@lists.freedesktop.org
Cc: Greathouse, Joseph
Subject: RE: [PATCH] drm/amdkfd: Add Arcturus GWS support and fix VG10
[AMD
[AMD Public Use]
Thanks for answering my question offline. Patch is
Reviewed-by: Kent Russell
> -Original Message-
> From: amd-gfx On Behalf Of Russell,
> Kent
> Sent: Tuesday, June 30, 2020 8:00 AM
> To: Greathouse, Joseph ; amd-
> g...@lists.freedesktop.org
> Cc: Greathouse, Joseph
Am 30.06.20 um 14:14 schrieb Tiezhu Yang:
On 06/30/2020 04:05 PM, Christian König wrote:
Am 30.06.20 um 09:36 schrieb Tiezhu Yang:
When I update the latest kernel, I see the following
"ptrval" boot
messages. Use "%pK" instead of "%p" so that the cpu address can be
printed
when the
On Mon, Jun 29, 2020 at 11:54 PM Quan, Evan wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> That's because pr_warn/err/info are forbidden to use in power routines.
>
> /*
> * DO NOT use these for err/warn/info/debug messages.
> * Use dev_err, dev_warn, dev_info and dev_dbg
[AMD Public Use]
One inquiry inline
> -Original Message-
> From: amd-gfx On Behalf Of Joseph
> Greathouse
> Sent: Monday, June 29, 2020 9:55 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Greathouse, Joseph
> Subject: [PATCH] drm/amdkfd: Add Arcturus GWS support and fix VG10
>
> Add
Unload ASD function in suspend phase.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 9342a9e8cadf..e57a53d5ca96 100644
---
TMR is required to be destoried with GFX_CMD_ID_DESTROY_TMR while the
system goes to suspend. Otherwise, PSP may return the failure state
(0x007) on Gfx-2-PSP command GFX_CMD_ID_SETUP_TMR after do multiple
times suspend/resume.
Signed-off-by: Huang Rui
---
Am 30.06.20 um 10:55 schrieb Hawking Zhang:
This reverts commit e318290d4845026623924a42435eafd101f669ac.
Fallback to a stable base until we have a correct new one
Signed-off-by:Hawking Zhang
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 19 ++---
This reverts commit e318290d4845026623924a42435eafd101f669ac.
Fallback to a stable base until we have a correct new one
Signed-off-by:Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 19 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 45 +++---
Am 30.06.20 um 00:46 schrieb Luben Tuikov:
On 2020-06-26 1:04 p.m., Christian König wrote:
Am 26.06.20 um 18:12 schrieb Alex Jivin:
Adding a delay between writing to UVD control register and reading from it.
This is to allow the HW to process the write command.
Signed-off-by: Alex Jivin
32 matches
Mail list logo
