I have been working on converting Jerome's hmm_dummy driver and self
tests into a stand-alone set of tests to be included in
tools/testing/selftests/vm and came across these two bug fixes in the
process. The tests aren't quite ready to be posted as a patch.
I'm posting the fixes now since I
Although hmm_range_fault() calls find_vma() to make sure that a vma exists
before calling walk_page_range(), hmm_vma_walk_hole() can still be called
with walk->vma == NULL if the start and end address are not contained
within the vma range.
hmm_range_fault() /* calls find_vma() but no range
Normally, callers to handle_mm_fault() are supposed to check the
vma->vm_flags first. hmm_range_fault() checks for VM_READ but doesn't
check for VM_WRITE if the caller requests a page to be faulted in
with write permission (via the hmm_range.pfns[] value).
If the vma is write protected, this can
The same BO can be mapped with different PTE flags by different GPUs.
Therefore determine the PTE flags separately for each mapping instead
of storing them in the buffer object.
Add a helper function to determine the PTE flags with special logic
for Arcturus that takes advantages of the new
From: Oak Zeng
Add definition of all supported mtypes. The RW mtype
is recently introduced for arcturus. Also add definition
of a flag to probe and possibly invalidate remote GPU
cache, which will be used later in this series.
Change-Id: I96fc9bb4b6b1e62bdc10b600d8aaa6a802128d6d
Signed-off-by:
From: Oak Zeng
Arcturus repurposed mtype WC to RW. Modify gmc functions
to support the new mtype
Change-Id: Idc338e5386a57020f45262025e2664ab4ba9f291
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 +++
drivers/gpu/drm/amd/include/vega10_enum.h | 1 +
2 files
This is a simplified version of Oak's patch series, addressing some of
the concerns raised during code review. Patches 1-3 are taken directly
from Oak's series. Patch 4 is a simplified version of Oak's patches
3 and 5 that keeps all the KFD memory type abstractions out of the GMC
From: Oak Zeng
Set snooped PTE flag according to mapping flag. Write request to a
page with snooped bit set, will send out invalidate probe request
to TCC of the remote GPU where the vram page resides.
Change-Id: I799f68ec7a5a1abf32075f5ef31051641a0b3736
Signed-off-by: Oak Zeng
---
Hi Dave, Daniel,
A few new bits for 5.4, mostly ongoing new asic support. This is pretty much it
for 5.4. We have a few patches for display enablement of renoir which should be
out next week (just wrapping up IP review).
The following changes since commit
This reverts commit 4f8bc72fbf10f2dc8bca74d5da08b3a981b2e5cd.
Change-Id: I577ba236e0571d11400a51f9d95840234aef678a
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
Hi Harry,
Thanks for your feedback, I'll prepare a V2.
On 08/23, Wentland, Harry wrote:
> On 2019-08-22 6:46 p.m., Siqueira, Rodrigo wrote:
> > DP 1.4 specification defines Link Training Tunable PHY Repeater (LTTPR)
> > which is required to add support for systems with Thunderbolt or other
> >
On Thu, Aug 22, 2019 at 05:50:02PM -0400, Wayne Lin wrote:
> For HDMI2.0 CTS item - HF1-35, it verifies if the source generates
> video timing "64:27" video format correctly.
>
> eg: (vic-76) 1920x1080p@60Hz,24bpp
>
> This patch add on "64:27" and "256:135" to drm_aspect_ratio_enum_list.
>
On 2019-08-22 5:50 p.m., Wayne Lin wrote:
> For HDMI2.0 CTS item - HF1-35, it verifies if the source generates
> video timing "64:27" video format correctly.
>
> eg: (vic-76) 1920x1080p@60Hz,24bpp
>
> This patch add on "64:27" and "256:135" to drm_aspect_ratio_enum_list.
> Thereafter, one can
On Thu, Aug 15, 2019 at 08:52:56PM +, Yang, Philip wrote:
> hmm_range_fault may return NULL pages because some of pfns are equal to
> HMM_PFN_NONE. This happens randomly under memory pressure. The reason is
> for swapped out page pte path, hmm_vma_handle_pte doesn't update fault
> variable
Hi
On 23/08/2019 18:16, Andrey Konovalov wrote:
> On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi
> wrote:
>>
>> Hi Andrey
>>
>> On 24/06/2019 15:33, Andrey Konovalov wrote:
>>> This patch is a part of a series that extends kernel ABI to allow to pass
>>> tagged user pointers (with the top
On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi
wrote:
>
> Hi Andrey
>
> On 24/06/2019 15:33, Andrey Konovalov wrote:
> > This patch is a part of a series that extends kernel ABI to allow to pass
> > tagged user pointers (with the top byte set to something else other than
> > 0x00) as syscall
Hi Andrey
On 24/06/2019 15:33, Andrey Konovalov wrote:
> This patch is a part of a series that extends kernel ABI to allow to pass
> tagged user pointers (with the top byte set to something else other than
> 0x00) as syscall arguments.
>
> This patch adds a simple test, that calls the uname
On 2019-08-22 6:46 p.m., Siqueira, Rodrigo wrote:
> DP 1.4 specification defines Link Training Tunable PHY Repeater (LTTPR)
> which is required to add support for systems with Thunderbolt or other
> repeater devices.
>
> Cc: Abdoulaye Berthe
> Cc: Harry Wentland
> Cc: Leo Li
> Signed-off-by:
Reviewed-by: Xiaojie Yuan
BR,
Xiaojie
> On Aug 23, 2019, at 10:45 PM, Alex Deucher wrote:
>
> So that we properly handle them on older asics.
>
> Fixes: 3ff985485b29 ("drm/amdgpu: Export function to flush TLB of specific vm
> hub")
> Signed-off-by: Alex Deucher
> ---
>
So that we properly handle them on older asics.
Fixes: 3ff985485b29 ("drm/amdgpu: Export function to flush TLB of specific vm
hub")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
Thanks Alex
That sounds correct to me, mode1 rest once do clear the vram data on vega10
_
Monk Liu|GPU Virtualization Team |AMD
[sig-cloud-gpu]
From: Deucher, Alexander
Sent: Friday, August 23, 2019 10:34 PM
To: Koenig, Christian ; Liu, Monk ;
>> Please no, that thing certainly proved to be useful. Maybe we could
>> investigate why it failed to auto detect the lost VRAM.
The reason is with BACO reset I found VRAM lost in high address e.g. 15~16 G
(for 16 G vega10), amdgpu_device_check_vram_lost only checks the very ahead
visible
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Russell,
Kent
Sent: Friday, August 23, 2019 9:37 AM
To: amd-gfx@lists.freedesktop.org
Cc: Russell, Kent
Subject: [PATCH] drm/powerplay: Fix Vega20 power reading again
For the 40.46 SMU release, they
for mode1 and BACO, I think we can assume vram is lost because the UMC gets
reset in that case. Some of the data may still look valid, but it's not
necessarily reliable. For mode2, vram should be fine because the UMC doesn't
get reset.
Alex
From: amd-gfx on
For the 40.46 SMU release, they changed CurrSocketPower to
AverageSocketPower, but this was changed back in 40.47 so just check if
it's 40.46 and make the appropriate change
Tested with 40.45, 40.46 and 40.47 successfully
Change-Id: Icbbe6fd3381b8ad6298c2d0852a726ffac98f93a
Signed-off-by: Kent
Am 23.08.19 um 10:57 schrieb Liu, Monk:
>>> vram_lost = amdgpu_device_check_vram_lost(tmp_adev);
>>> if (vram_lost) {
>>> DRM_INFO("VRAM is lost due to
>>> GPU reset!\n");
>>>
>> vram_lost = amdgpu_device_check_vram_lost(tmp_adev);
>> if (vram_lost) {
>> DRM_INFO("VRAM is lost due to GPU
>> reset!\n");
>>
>> atomic_inc(_adev->vram_lost_counter);
Above is the
I thought in the BACO reset function.
The top level reset function doesn't do much more than increment the
vram_lost_counter either.
Christian.
Am 23.08.19 um 10:32 schrieb Liu, Monk:
>>> On the other hand wouldn't it be simpler to just increment
>>> vram_lost_counter?
> In where ? if you
>> On the other hand wouldn't it be simpler to just increment vram_lost_counter?
In where ? if you mean in amdgpu_device_recover routine I won't do that since
the reset() can do any kind of reset like:
1) PF FLR
2) mode1/2 reset
3) magic reset through config space
4) BACO reset
PF FLR won't
Am 23.08.19 um 05:34 schrieb Monk Liu:
for SOC15/vega10 the BACO reset would introduce vram lost in
the high end address range and current kmd's vram lost
checking cannot catch it since it only check visible frame buffer
TODO:
to confirm if mode1/2 reset would introduce vram lost
Looks good
30 matches
Mail list logo
