Hi Christian,
I'm not sure I get your point here.
As I understand it, the amdgpu_vm structure represents the user mode VM
context. It has the pointers to the root page directory and the rest of
the page table hierarchy. If there is no amdgpu_vm, there is no user
mode context that cares about the
On 2018-09-07 01:49 PM, David Francis wrote:
> [Why]
> DMCU (Display MicroController Unit) is an on-GPU microcontroller
> in AMD graphics cards that is used in features for
> embedded displays such as Panel Self-Refresh
>
> DMCU is part of the DM IP block
>
> [How]
> DMCU is added as an option in t
[+Eric, see my comment below about iolink atomic flags]
On 2018-09-07 05:37 PM, shaoyunl wrote:
> Change-Id: Ibb6a89ed878fffccb9a8bb4032b07a10ee298a99
> Signed-off-by: shaoyunl
See one comment inline. It's not directly related to this change so this
is Reviewed-by: Felix Kuehling
> ---
> driv
On Fri, Sep 7, 2018 at 5:55 AM, Bas Nieuwenhuizen
wrote:
> On Fri, Sep 7, 2018 at 6:51 AM Marek Olšák wrote:
>>
>> Hopefully this answers some questions.
>>
>> Other parameters that affect tiling layouts are GB_ADDR_CONFIG (all
>> chips) and MC_ARB_RAMCFG (GFX6-8 only), and those vary with each c
Hi Christian,
See comments inline
Thanks,
Oak
From: Koenig, Christian
Sent: Monday, September 10, 2018 7:44 AM
To: Zeng, Oak ; Oak Zeng ;
amd-gfx@lists.freedesktop.org; Yang, Philip
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm
>The VM doesn't know that information
Hi!
I want to use sriov functionality of S75150x2 with some debian-based
distro with pretty up-to-date kernel (4.15.3-1). Of course, this lead me
to some issues with gim and amdgpu.
Is it possible to use amdgpu with gim instead of amdgpu-pro? Are there
any plans to support gim for newer kern
Change-Id: Ibb6a89ed878fffccb9a8bb4032b07a10ee298a99
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 15 +--
drivers/gpu/drm/amd/amdkfd/kfd_crat.h | 3 ++-
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 +
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git
From: Shaoyun Liu
Add dummy function for xgmi function interface with psp
Change-Id: I01f35baf5a4b96e9654d448c9892be3cd72c05b7
Signed-off-by: Shaoyun Liu
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 29 +
1 file changed, 29 insertions(+)
From: Alex Deucher
On hives with xgmi enabled, the fb_location aperture is a size
which defines the total framebuffer size of all nodes in the
hive. Each GPU in the hive has the same view via the fb_location
aperture. GPU0 starts at offset (0 * segment size),
GPU1 starts at offset (1 * segment
[Why]
DMCU (Display MicroController Unit) is an on-GPU microcontroller
in AMD graphics cards that is used in features for
embedded displays such as Panel Self-Refresh
DMCU is part of the DM IP block
[How]
DMCU is added as an option in the enum AMDGPU_UCODE_ID
DMCU needs two pieces of firmware -
On 2018-09-07 01:49 PM, David Francis wrote:
> [Why]
> DMCU (Display MicroController Unit) is an on-GPU microcontroller
> in AMD graphics cards that is used in features for
> embedded displays such as Panel Self-Refresh
>
> DMCU is part of the DM IP block
>
> [How]
> DMCU is added as an option in
Ok in this case feel free to add my Acked-by.
Christian.
Am 07.09.2018 um 20:10 schrieb Felix Kuehling:
On 2018-09-07 05:05 AM, Christian König wrote:
Well, exactly that's my point. How certain are we that the PSP
firmware interface is not going to change?
The interface has been defined and a
On 2018-09-07 05:05 AM, Christian König wrote:
> Well, exactly that's my point. How certain are we that the PSP
> firmware interface is not going to change?
The interface has been defined and agreed on and is being implemented at
the moment. The placeholders here are based on that design. Of cours
Ignore this thread - new, fixed patch is up
From: Francis, David
Sent: September 7, 2018 10:26:59 AM
To: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd: Add DMCU firmware loading on raven
This will cause amdgpu startup to fail if the firmware does not
[Why]
DMCU (Display MicroController Unit) is an on-GPU microcontroller
in AMD graphics cards that is used in features for
embedded displays such as Panel Self-Refresh
DMCU is part of the DM IP block
[How]
DMCU is added as an option in the enum AMDGPU_UCODE_ID
DMCU needs two pieces of firmware -
Hi Iida-san,
On 2018-09-06 4:10 a.m., Masanari Iida wrote:
> This patch fixes following wornings.
>
> ./drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:3011:
> warning: Excess function parameter 'dev' description
> in 'amdgpu_vm_get_task_info'
>
> ./drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:3012:
> warnin
From: Michel Dänzer
No need to process any events in that case.
(Ported from amdgpu commit ca5eb9894fff153c0a1df7bdc4a4745713309e27)
Signed-off-by: Michel Dänzer
---
src/radeon_drm_queue.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/radeon_drm_queue.c b/src/radeo
The VM doesn't know that information either.
In other words when you request the address of a PT you get the address
where memory management has moved it, not the address where the hardware
is processing the fault from.
I see only a few possible solutions for that:
1. We use an extra structur
Without a VM, how can you get the physical address of the faulty virtual
address? Where this information should be hold?
Thanks,
Oak
From: Koenig, Christian
Sent: Monday, September 10, 2018 7:20 AM
To: Zeng, Oak ; Oak Zeng ;
amd-gfx@lists.freedesktop.org; Yang, Philip
Subject: Re: [PATCH 1/2]
Am I right that the handling of page fault need a valid VM?
No, exactly that view is incorrect.
The VM is meant to be a memory management structure of page tables and
is completely pointless fault processing because it represent the future
state of the page tables and not the current one.
Wh
Hi Christian,
What is the value of delay the destroy of hash to after vm is destroyed? Since
vm is destroyed, you basically don’t have enough information to paging in the
correct page to gpuvm. Am I right that the handling of page fault need a valid
VM? For example, you need the VM to get the c
This will cause amdgpu startup to fail if the firmware does not exist: this
should either wait until the firmware is available or not return an error value
if -ENOENT is returned from request_firmware
From: David Francis
Sent: September 7, 2018 10:16:56 AM
To: a
[Why]
DMCU (Display MicroController Unit) is an on-GPU microcontroller
in AMD graphics cards that is used in features for
embedded displays such as Panel Self-Refresh
DMCU is part of the DM IP block
[How]
DMCU is added as an option in the enum AMDGPU_UCODE_ID
DMCU needs two pieces of firmware -
Acked-by: Christian König
Am 07.09.2018 um 13:19 schrieb Zhang, Hawking:
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Tao Zhou
Sent: 2018年9月7日 18:48
To: Zhang, Hawking ; Koenig, Christian
; Zhang, Jerry ;
amd-gfx@lists.freedesktop.org
Cc: Li, Yukun1 ; Zhou1,
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Tao Zhou
Sent: 2018年9月7日 18:48
To: Zhang, Hawking ; Koenig, Christian
; Zhang, Jerry ;
amd-gfx@lists.freedesktop.org
Cc: Li, Yukun1 ; Zhou1, Tao
Subject: [PATCH v2] drm/amdgpu: Fix SDMA hang in prt mode v2
Fix SDMA
Am 07.09.2018 um 13:02 schrieb Huang, Ray:
Yes, that was one problem. Another was that the cutting code was buggy
and determined one of the positions to cut at the wrong time.
I went through again about the list cutting behavior and wrote down with the
attached picture.
After do the second
Fix SDMA hang in prt mode, clear XNACK_WATERMARK in reg SDMA0_UTCL1_WATERMK to
avoid the issue
Affected ASICs: VEGA10 VEGA12 RV1 RV2
v2: add reg clear for SDMA1
Change-Id: I2261b8e753600731d0d8ee8bbdfc08d01eeb428e
Signed-off-by: Tao Zhou
Tested-by: Yukun Li
---
drivers/gpu/drm/amd/amdgpu/sdm
On Fri, Sep 7, 2018 at 6:51 AM Marek Olšák wrote:
>
> Hopefully this answers some questions.
>
> Other parameters that affect tiling layouts are GB_ADDR_CONFIG (all
> chips) and MC_ARB_RAMCFG (GFX6-8 only), and those vary with each chip.
For GFX6-GFX8:
From GB_ADDR_CONFIG addrlib only uses the pi
On 09/07/2018 03:41 PM, Tao Zhou wrote:
Fix SDMA hang in prt mode, clear XNACK_WATERMARK in reg SDMA0_UTCL1_WATERMK to
avoid the issue
What test case for that? new case?
Previously we have passed Vulkan CTS for that.
IIRC, NACK is required to reply, what's that meaning to clear that? no reply
Well, exactly that's my point. How certain are we that the PSP firmware
interface is not going to change?
At bare minimum we should add big "/* TODOD: .. */" markers all around
explaining why those functions aren't implemented yet.
Thanks,
Christian.
Am 07.09.2018 um 08:03 schrieb Kuehling,
Am 07.09.2018 um 09:41 schrieb Tao Zhou:
Fix SDMA hang in prt mode, clear XNACK_WATERMARK in reg SDMA0_UTCL1_WATERMK to
avoid the issue
Affected ASIC: VEGA10 VEGA12 RV1 RV2
Change-Id: I2261b8e753600731d0d8ee8bbdfc08d01eeb428e
Signed-off-by: Tao Zhou
Tested-by: Yukun Li
Well, looks like a g
Hi Ray,
in the meantime can we disable the feature once more in the kernel until
we have hammered out all possible corner cases?
As Tom figured out commenting out setting "bulk_moveable" to true should
be enough.
Thanks,
Christian.
Am 07.09.2018 um 08:51 schrieb Huang, Ray:
Hi Tom,
Thank
Hi Oak,
yeah, but this is still a NAK. Making the hash per PASID was not a
suggestion but rather a must have.
The VM structures must be destroyed while the processing is still
ongoing, or otherwise we would not have a clean OOM handling.
The IDR for PASID lockup can be put into amdgpu_ids.c
Fix SDMA hang in prt mode, clear XNACK_WATERMARK in reg SDMA0_UTCL1_WATERMK to
avoid the issue
Affected ASIC: VEGA10 VEGA12 RV1 RV2
Change-Id: I2261b8e753600731d0d8ee8bbdfc08d01eeb428e
Signed-off-by: Tao Zhou
Tested-by: Yukun Li
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 +++-
1 file chan
On 2018/08/27 16:41, Christian König wrote:
> Am 26.08.2018 um 10:40 schrieb Tetsuo Handa:
>> I'm not following. Why don't we need to do like below (given that
>> nobody except amdgpu_mn_read_lock() holds ->read_lock) because e.g.
>> drm_sched_fence_create() from drm_sched_job_init() from amdgpu_cs
In stead of share one fault hash table per device, make it
per vm. This can avoid inter-process lock issue when fault
hash table is full.
Change-Id: I5d1281b7c41eddc8e26113e010516557588d3708
Signed-off-by: Oak Zeng
Suggested-by: Christian Konig
Suggested-by: Felix Kuehling
---
drivers/gpu/drm/
With the change of making fault hash per vm, this is not needed
anymore.
Change-Id: I9427ff1786deaf1f5b7d121a6f7f75f00acfc9b7
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 ---
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 9 -
37 matches
Mail list logo
