Am 06.10.21 um 21:32 schrieb Borislav Petkov:
On Wed, Oct 06, 2021 at 02:21:40PM -0400, Alex Deucher wrote:
And just another general comment, swiotlb + bounce buffers isn't
really useful on GPUs. You may have 10-100s of MBs of memory mapped
long term into the GPU's address space for random acce
Am 06.10.21 um 18:04 schrieb Nirmoy Das:
Unify BO evicting functionality for possible memory
types in amdgpu_ttm.c and remove corresponding function
from amdgpu_object.c.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 8 +++---
drivers/gpu/drm/amd/amdgpu/amdg
On 10/6/21 1:36 PM, Alex Deucher wrote:
On Wed, Oct 6, 2021 at 2:21 PM Borislav Petkov wrote:
On Wed, Oct 06, 2021 at 02:10:30PM -0400, Alex Deucher wrote:
From the x86 model and family info? I think Raven has different
families from other Zen based CPUs.
And even if we do, that's still
Am 2021-10-06 um 10:32 a.m. schrieb Philip Yang:
> migrate_vma_setup may return cpages 0, means 0 page can be migrated,
> treat this as error case to skip the rest of migration steps, and don't
> change prange actual loc, to avoid warning message "VRAM BO missing
> during validation".
>
> Signed-of
Am 2021-10-06 um 10:32 a.m. schrieb Philip Yang:
> No function change, use pr_debug_ratelimited to avoid per page debug
> message overflowing dmesg buf and console log.
>
> use dev_err to show error message from unexpected situation, to provide
> clue to help debug without enabling dynamic debug lo
Hi Dave, Daniel,
Fixes for 5.15.
The following changes since commit 9e1ff307c779ce1f0f810c7ecce3d95bbae40896:
Linux 5.15-rc4 (2021-10-03 14:08:47 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.15-2021-10-06
for you to fe
On 2021-10-06 2:23 p.m., Felix Kuehling
wrote:
Am 2021-10-06 um 2:09 p.m. schrieb philip yang:
On 2021-10-06 1:22 p.m., Felix Kuehling wrote:
Am 2021-10-06 um 10:32 a.m. schrieb Philip Yang:
For io
On Wed, Oct 06, 2021 at 02:21:40PM -0400, Alex Deucher wrote:
> And just another general comment, swiotlb + bounce buffers isn't
> really useful on GPUs. You may have 10-100s of MBs of memory mapped
> long term into the GPU's address space for random access. E.g., you
> may have buffers in system
On Wed, Oct 06, 2021 at 02:36:56PM -0400, Alex Deucher wrote:
> From the x86 model and family info? I think Raven has different
> families from other Zen based CPUs.
Yeah, I'd like to avoid a f/m/s mapping table, if possible. Those things
should be a last resort and they always need adjustment wh
On Wed, Oct 6, 2021 at 2:21 PM Borislav Petkov wrote:
>
> On Wed, Oct 06, 2021 at 02:10:30PM -0400, Alex Deucher wrote:
> > This is not limited to Raven.
>
> That's what the innocuous "a.o." wanted to state. :)
Whoops, my eyes passed right over that.
>
> > All GPUs (and quite a few other
> > dev
On Wed, Oct 06, 2021 at 02:10:30PM -0400, Alex Deucher wrote:
> This is not limited to Raven.
That's what the innocuous "a.o." wanted to state. :)
> All GPUs (and quite a few other
> devices) have a limited DMA mask. AMD GPUs have between 32 and 48
> bits of DMA depending on what generation the
Am 2021-10-06 um 2:09 p.m. schrieb philip yang:
>
>
> On 2021-10-06 1:22 p.m., Felix Kuehling wrote:
>> Am 2021-10-06 um 10:32 a.m. schrieb Philip Yang:
>>> For ioctl_alloc_memory_of_gpu to alloc userptr bo, check userptr address
>>> does not exist in svm->objects.
>>>
>>> For svm range allocation,
And just another general comment, swiotlb + bounce buffers isn't
really useful on GPUs. You may have 10-100s of MBs of memory mapped
long term into the GPU's address space for random access. E.g., you
may have buffers in system memory that the display hardware is
actively scanning out of. For GP
On Wed, Oct 6, 2021 at 1:48 PM Borislav Petkov wrote:
>
> Ok,
>
> so I sat down and wrote something and tried to capture all the stuff we
> so talked about that it is clear in the future why we did it.
>
> Thoughts?
>
> ---
> From: Borislav Petkov
> Date: Wed, 6 Oct 2021 19:34:55 +0200
> Subject:
On 2021-10-06 1:22 p.m., Felix Kuehling
wrote:
Am 2021-10-06 um 10:32 a.m. schrieb Philip Yang:
For ioctl_alloc_memory_of_gpu to alloc userptr bo, check userptr address
does not exist in svm->objects.
For svm range allocation, look for addres
Ok,
so I sat down and wrote something and tried to capture all the stuff we
so talked about that it is clear in the future why we did it.
Thoughts?
---
From: Borislav Petkov
Date: Wed, 6 Oct 2021 19:34:55 +0200
Subject: [PATCH] x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
autom
Am 2021-10-06 um 10:32 a.m. schrieb Philip Yang:
> For ioctl_alloc_memory_of_gpu to alloc userptr bo, check userptr address
> does not exist in svm->objects.
>
> For svm range allocation, look for address in the userptr range of
> interval tree VA nodes.
Why? The purpose of the check is to prevent
Unify BO evicting functionality for possible memory
types in amdgpu_ttm.c and remove corresponding function
from amdgpu_object.c.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 8 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +--
drivers/gpu/drm/amd/amdgp
On 10/6/2021 4:58 PM, Christian König wrote:
Am 06.10.21 um 16:45 schrieb Nirmoy Das:
Unify BO evicting functionality for VRAM and TT memory
types in amdgpu_object.c. Use amdgpu_bo_evict_gtt()
for evicting gtt memory similar to how we do that
for amdgpu_debugfs_evict_vram().
Signed-off-by: Ni
Am 06.10.21 um 16:45 schrieb Nirmoy Das:
Unify BO evicting functionality for VRAM and TT memory
types in amdgpu_object.c. Use amdgpu_bo_evict_gtt()
for evicting gtt memory similar to how we do that
for amdgpu_debugfs_evict_vram().
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgp
Unify BO evicting functionality for VRAM and TT memory
types in amdgpu_object.c. Use amdgpu_bo_evict_gtt()
for evicting gtt memory similar to how we do that
for amdgpu_debugfs_evict_vram().
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 +--
drivers/gpu/drm/amd/am
For ioctl_alloc_memory_of_gpu to alloc userptr bo, check userptr address
does not exist in svm->objects.
For svm range allocation, look for address in the userptr range of
interval tree VA nodes.
Change helper svm_range_check_vm to return amdgpu_bo, which will be used
to avoid creating new svm ra
When creating new svm range to recover retry fault, avoid svm range
to overlap with ranges or userptr ranges managed by TTM, otherwise
svm migration will trigger TTM or userptr eviction, to evict user queues
unexpectedly.
Add helper amdgpu_ttm_tt_get_userptr because amdgpu_ttm_tt structure is
not
No function change, use pr_debug_ratelimited to avoid per page debug
message overflowing dmesg buf and console log.
use dev_err to show error message from unexpected situation, to provide
clue to help debug without enabling dynamic debug log.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/a
migrate_vma_setup may return cpages 0, means 0 page can be migrated,
treat this as error case to skip the rest of migration steps, and don't
change prange actual loc, to avoid warning message "VRAM BO missing
during validation".
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_migra
> current->comm is "DrmThread" on my ChromeOS system.
Oops! I forgot that current->comm could be overwritten by user-space. Sent v4
which should address this by checking the executable name too.
Commit ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when
using overlay") changed the atomic validation code to forbid the
overlay plane from being used if it doesn't cover the whole CRTC. The
motivation is that ChromeOS uses the atomic API for everything except
the cursor plane (which
The current logic checks whether the cursor plane blending
properties match the primary plane's. However that's wrong,
because the cursor is painted on all planes underneath. If
the cursor is over the primary plane and the overlay plane,
it's painted on both pipes.
Iterate over the CRTC planes and
On 2021-10-06 06:14, Lin, Wayne wrote:
> [Public]
>
>> -Original Message-
>> From: Wentland, Harry
>> Sent: Wednesday, October 6, 2021 1:11 AM
>> To: Lin, Wayne ; amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander ; Kazlauskas, Nicholas
>> ; Siqueira, Rodrigo
>> ; Wang, Chao-kai
On 10/6/21 8:23 AM, Alex Deucher wrote:
On Wed, Oct 6, 2021 at 5:42 AM Borislav Petkov wrote:
On Tue, Oct 05, 2021 at 10:48:15AM -0400, Alex Deucher wrote:
It's not incompatible per se, but SEM requires the IOMMU be enabled
because the C bit used for encryption is beyond the dma_mask of most
On Wed, Oct 06, 2021 at 09:23:22AM -0400, Alex Deucher wrote:
> There could be some OEM systems that disable the IOMMU on the platform
> and don't provide a switch in the bios to enable it. The GPU driver
> will still work in that case, it will just not be able to enable KFD
> support for ROCm com
On 10/6/2021 1:55 PM, Lazar, Lijo wrote:
On 10/6/2021 3:21 PM, Nirmoy Das wrote:
Check first if debugfs is initialized before creating
amdgpu debugfs files.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/1686
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_de
On Tue, Oct 05, 2021 at 10:48:15AM -0400, Alex Deucher wrote:
> It's not incompatible per se, but SEM requires the IOMMU be enabled
> because the C bit used for encryption is beyond the dma_mask of most
> devices. If the C bit is not set, the en/decryption for DMA doesn't
> occur. So you need IOM
On Wed, Oct 6, 2021 at 5:42 AM Borislav Petkov wrote:
>
> On Tue, Oct 05, 2021 at 10:48:15AM -0400, Alex Deucher wrote:
> > It's not incompatible per se, but SEM requires the IOMMU be enabled
> > because the C bit used for encryption is beyond the dma_mask of most
> > devices. If the C bit is not
Am 06.10.21 um 13:55 schrieb Lazar, Lijo:
On 10/6/2021 3:21 PM, Nirmoy Das wrote:
Check first if debugfs is initialized before creating
amdgpu debugfs files.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/1686
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_deb
On 10/6/2021 3:21 PM, Nirmoy Das wrote:
Check first if debugfs is initialized before creating
amdgpu debugfs files.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/1686
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
1 file changed, 3 inserti
[Public]
> -Original Message-
> From: Wentland, Harry
> Sent: Wednesday, October 6, 2021 1:14 AM
> To: Lin, Wayne ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Kazlauskas, Nicholas
> ; Siqueira, Rodrigo
> ; Wang, Chao-kai (Stylon) ;
> Shih, Jude ; Kizito, Jimmy
> ; Somasund
[Public]
> -Original Message-
> From: Wentland, Harry
> Sent: Wednesday, October 6, 2021 1:11 AM
> To: Lin, Wayne ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Kazlauskas, Nicholas
> ; Siqueira, Rodrigo
> ; Wang, Chao-kai (Stylon) ;
> Shih, Jude ; Kizito, Jimmy
> ; Somasund
[Why & How]
As part of the FPU isolation work documented in
https://patchwork.freedesktop.org/series/93042/, isolate
code that uses FPU in DCN301 to DML, where all FPU code
should locate.
Cc: Christian König
Cc: Harry Wentland
Cc: Rodrigo Siqueira
Tested-by: Zhan Liu
Signed-off-by: Qingqing Zh
Check first if debugfs is initialized before creating
amdgpu debugfs files.
References: https://gitlab.freedesktop.org/drm/amd/-/issues/1686
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu
On 10/6/2021 8:59 AM, Christian König wrote:
Am 06.10.21 um 08:55 schrieb Lazar, Lijo:
On 10/6/2021 12:05 PM, Christian König wrote:
Am 06.10.21 um 08:32 schrieb Lazar, Lijo:
On 10/6/2021 11:49 AM, Christian König wrote:
Am 06.10.21 um 06:51 schrieb Lazar, Lijo:
On 10/5/2021 10:15 PM
41 matches
Mail list logo
