On 5/1/20 11:20 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Presumably the intent here was that hmm_range_fault() could put the data
into some HW specific format and thus avoid some work. However, nothing
actually does that, and it isn't clear how anything actually could do that
as hmm_r
[AMD Official Use Only - Internal Distribution Only]
-Original Message-
From: Zuo, Jerry
Sent: May 1, 2020 8:23 PM
To: Wentland, Harry ; amd-gfx@lists.freedesktop.org;
Wu, Hersen ; S, Shirish
Cc: Deucher, Alexander ; Siqueira, Rodrigo
Subject: RE: [PATCH] drm/amd/display: Add dm suppor
[AMD Official Use Only - Internal Distribution Only]
The error handling for edid read right now is categorized as:
1. If base block is fetched with checksum mismatch, drm will set
connector->edid_corrupt and return with Null edid buffer. This case will be
handled as compliance test case 4.2.2.6,
container_of is never null, so the null check on pdd is unnecessary.
If the null check is removed, function kfd_procfs_show()
will always return before reaching "return 0", hence
such return is logically dead. So, remove it, as well.
Addresses-Coverity-ID: 1492793 ("Logically dead code")
Fixes: d
From: Jason Gunthorpe
hmm_vma_walk->last is supposed to be updated after every write to the
pfns, so that it can be returned by hmm_range_fault(). However, this is
not done consistently. Fortunately nothing checks the return code of
hmm_range_fault() for anything other than error.
More important
From: Jason Gunthorpe
This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
because of a special page vs any other error case.
Acked-by: Felix Kuehling
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
drivers
From: Jason Gunthorpe
Presumably the intent here was that hmm_range_fault() could put the data
into some HW specific format and thus avoid some work. However, nothing
actually does that, and it isn't clear how anything actually could do that
as hmm_range_fault() provides CPU addresses which must
From: Jason Gunthorpe
The API is a bit complicated for the uses we actually have, and
disucssions for simplifying have come up a number of times.
This small series removes the customizable pfn format and simplifies the
return code of hmm_range_fault()
All the drivers are adjusted to process in
From: Jason Gunthorpe
There is no reason for a user to select this or not directly - it should
be selected by drivers that are going to use the feature, similar to how
CONFIG_HMM_MIRROR works.
Currently all drivers provide a feature kconfig that will disable use of
DEVICE_PRIVATE in that driver,
From: Jason Gunthorpe
Since amdgpu does not use the snapshot mode of hmm_range_fault() a
successful return already proves that all entries in the pfns are
HMM_PFN_VALID, there is no need to check the return result of
hmm_device_entry_to_page().
Acked-by: Felix Kuehling
Signed-off-by: Jason Gunt
Am 01.05.20 um 18:37 schrieb Alex Deucher:
The frame emit counts were not updated.
Fixes: 0dd3baafb62c38 ("drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to compute
IBs too")
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 3 ++-
dr
- Guest side change
- Refactor and implement VF2PF information
- Share checksum function between guest and host
- Refactor code in amdgpu_virt.c since some of them are useless
Change-Id: I881989d8fb6b6af88209badf4c4070c281f65b6a
Signed-off-by: Bokun Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu
The frame emit counts were not updated.
Fixes: 0dd3baafb62c38 ("drm/amdgpu: apply AMDGPU_IB_FLAG_EMIT_MEM_SYNC to
compute IBs too")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/gfx_v7_0
The gfx ring already has this.
Marek
On Tue, Apr 28, 2020 at 5:50 AM Liu, Monk wrote:
> Hi Marek
>
>
>
> I’m not very familiar with the background of your patch, but I have a
> question: why you only apply this change on SDMA and compute ring, but
> ignore GFX ring ?
>
>
>
> Thanks
>
>
>
>
I'll answer two questions asked:
1) SDMA doesn't need GCR at the end of IBs. It's because SDMA writes bypass
GL2 and at the same time they invalidate all cache lines they touch.
2)
> If we always insert a GL2C invalidate at every EOP of every IB from every
engine, why we need a GL2C invalidate be
[dropping my gmail address]
We saw this backtrace showing the call chain while investigating a
kernel oops caused by this issue on the DKMS branch with the KFD IPC
API. It happens after a dma-buf file is released with fput:
[ 1255.049330] BUG: kernel NULL pointer dereference, address: 000
Am 01.05.20 um 16:21 schrieb Felix Kuehling:
From: Felix Kuehling
That reference gets dropped when the the dma-buf is freed. Not incrementing
the refcount can lead to use-after-free errors.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 9 -
1 file
From: Felix Kuehling
That reference gets dropped when the the dma-buf is freed. Not incrementing
the refcount can lead to use-after-free errors.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --g
On 2020-04-29 1:58 p.m., Jerry (Fangzhi) Zuo wrote:
> It works together with drm framework
> "drm: Add support for DP 1.4 Compliance edid corruption test"
>
> Signed-off-by: Jerry (Fangzhi) Zuo
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 40 ++-
> 1 file changed, 1
19 matches
Mail list logo
