On Wed, Feb 06, 2019 at 05:46:51PM +0100, Noralf Trønnes wrote:
>
>
> Den 06.02.2019 16.26, skrev Daniel Vetter:
> > On Tue, Feb 05, 2019 at 06:57:50PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 05.02.2019 17.31, skrev Daniel Vetter:
> >>> On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf
I see. I will drop this. How about the other two patches?
Regards,
Yong
From: Christian K?nig
Sent: Wednesday, February 6, 2019 1:20 PM
To: Alex Deucher; Zhao, Yong
Cc: Kuehling, Felix; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/amdgpu: Fix a typo
Hey Oak,
Interesting you should ask since this has been discussed a lot here recently.
So I didn't know until recently that the nbif routes doorbells only using 11:2.
So in each 4k page there is an area for the various doorbell recipients
including cp gfx and compute.
The doorbell
Am 06.02.19 um 18:23 schrieb Ard Biesheuvel:
On Fri, 25 Jan 2019 at 11:35, Ard Biesheuvel wrote:
On Fri, 25 Jan 2019 at 12:30, Christian König
wrote:
Am 25.01.19 um 09:43 schrieb Ard Biesheuvel:
On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote:
On Thu, Jan 24, 2019 at 9:00 AM Ard
Am 06.02.19 um 19:17 schrieb Alex Deucher:
On Wed, Feb 6, 2019 at 12:01 PM Zhao, Yong wrote:
Not too sure about this, but it looks strange in the code when all other
similar code uses 64-bit.
It's worth double checking, but Felix is right. A number of IPs still
used 32 bit doorbells on
On Wed, Feb 6, 2019 at 12:01 PM Zhao, Yong wrote:
>
> Not too sure about this, but it looks strange in the code when all other
> similar code uses 64-bit.
It's worth double checking, but Felix is right. A number of IPs still
used 32 bit doorbells on vega10. E.g., multi-media for example.
On Fri, 25 Jan 2019 at 11:35, Ard Biesheuvel wrote:
>
> On Fri, 25 Jan 2019 at 12:30, Christian König
> wrote:
> >
> > Am 25.01.19 um 09:43 schrieb Ard Biesheuvel:
> > > On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote:
> > >> On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuvel
> > >> wrote:
> >
Daniel Vetter writes:
>
> Zooming out more looking at the big picture I'd say all your work in the
> past few years has enormously simplified drm for simple drivers already.
> If we can't resolve this one here right now that just means you "only"
> made drm 98% simpler instead of maybe 99%. It's
Hi,
I use HP EliteBook 745 G5 with Ryzen 5 PRO 2500U. With kernels 4.20
and 5.0.0-rc3 I see a display corruption during resume from RAM. It's
a short time corruption of black screen only, after less than second
an expected image appears, so nothing critical.
It's a regression though so I somehow
Not too sure about this, but it looks strange in the code when all other
similar code uses 64-bit.
"Maybe it makes more sense to think of 64-bit doorbells as using 2 doorbell
indexes". You mean the alternative is to multiply all the current 64 doorbell
index constants with 2, right? That might
Den 06.02.2019 16.26, skrev Daniel Vetter:
> On Tue, Feb 05, 2019 at 06:57:50PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 05.02.2019 17.31, skrev Daniel Vetter:
>>> On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
Den 05.02.2019 10.11, skrev Daniel Vetter:
> On
There is circular lock between gfx and kfd path with HMM change:
lock(dqm) -> bo::reserve -> amdgpu_mn_lock
To avoid this, move init/unint_mqd() out of lock(dqm), to remove nested
locking between mmap_sem and bo::reserve. The locking order
is: bo::reserve -> amdgpu_mn_lock(p->mn)
Change-Id:
Replace our MMU notifier with hmm_mirror_ops.sync_cpu_device_pagetables
callback. Enable CONFIG_HMM and CONFIG_HMM_MIRROR as a dependency in
DRM_AMDGPU_USERPTR Kconfig.
It supports both KFD userptr and gfx userptr paths.
Change-Id: Ie62c3c5e3c5b8521ab3b438d1eff2aa2a003835e
Signed-off-by: Philip
Hi Christian,
Resend patch 1/3, 2/3, added Reviewed-by in comments.
Change in patch 3/3, amdgpu_cs_submit, amdgpu_cs_ioctl return -EAGAIN
to user space to retry cs_ioctl.
Regards,
Philip
Philip Yang (3):
drm/amdgpu: use HMM mirror callback to replace mmu notifier v7
drm/amdkfd: avoid HMM
Are you sure about this? Typically 64-bit doorbells don't wrap around. But this
one does. If the IH doorbell wraps around, there is no reason why it needs to
be 64-bit, so I suspect it may still be a 32-bit doorbell.
AFAIK, not all doorbells on Vega10 are 64-bit. It depends on the IP block.
Use HMM helper function hmm_vma_fault() to get physical pages backing
userptr and start CPU page table update track of those pages. Then use
hmm_vma_range_done() to check if those pages are updated before
amdgpu_cs_submit for gfx or before user queues are resumed for kfd.
If userptr pages are
Reviewed-by: Eric Huang
On 2019-02-05 4:37 p.m., Kasiviswanathan, Harish wrote:
> v2: Fix SMU message format
> Send override message after SMU enable features
>
> Change-Id: Ib880c83bc7aa12be370cf6619acfe66e12664c9c
> Signed-off-by: Harish Kasiviswanathan
> ---
>
Am 06.02.19 um 16:53 schrieb Yang, Philip:
> >> +/* If userptr are updated after amdgpu_cs_parser_bos(), restart
> >> cs */
> >> amdgpu_bo_list_for_each_userptr_entry(e, p->bo_list) {
> >> struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
> >> -if
Hi Alex,
I only add the corresponding changes for IH, but not for GFX as GFX does not
use the similar range functions.
Regards,
Yong
From: Zhao, Yong
Sent: Wednesday, February 6, 2019 10:49 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhao, Yong
Subject: [PATCH 1/3]
>> +/* If userptr are updated after amdgpu_cs_parser_bos(), restart
>> cs */
>> amdgpu_bo_list_for_each_userptr_entry(e, p->bo_list) {
>> struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
>> -if (amdgpu_ttm_tt_userptr_needs_pages(bo->tbo.ttm)) {
>> -r
When doorbells are 8-byte on SOC15, doorbell_index in rings no longer
reflects its true usage. So we should indicate its dword attribute as
a generic way to accommodate different doorbell sizes.
Change-Id: I053c69498af5d68df1783a7eb03106dd68f5e8cc
Signed-off-by: Yong Zhao
---
Indicate that the doorbell offset and range is in dwords.
Change-Id: Ib0f2564ffa7b1940ffb8725cdc03f662184f5436
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
Clearly, it should be a 64-bit doorbell operation.
Change-Id: I644a2ebcb18c2ede24ee15692a6189efad10a35c
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
On Tue, Feb 05, 2019 at 06:57:50PM +0100, Noralf Trønnes wrote:
>
>
> Den 05.02.2019 17.31, skrev Daniel Vetter:
> > On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 05.02.2019 10.11, skrev Daniel Vetter:
> >>> On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf
+ Clint/Alice
Hi Clint,
We think CP_MEC_DOORBELL_RANGE_LOWER/UPPER registers are used by MEC to check
whether a doorbell routed to MEC belongs to MEC, is this understanding correct?
From the register spec, those registers are 27 bits. Does this mean MEC use all
27 bits to determine? For
Good morning,
on my Lenovo G50-45 a6310 APU with R4 Mullins commit
e261568f94d6c37ebb94d3c4b3f8a3085375dd9d is causing kernel Oops (unable to
handle NULL pointer).
Cross-checked by reverting troublesome commit and machine without it is
working fine.
Here is a part of the Oops message from
Am 06.02.19 um 02:13 schrieb Alex Deucher:
On Tue, Feb 5, 2019 at 4:38 PM Kasiviswanathan, Harish
wrote:
The new Vega series GPU cards have in-built bridges. To get the pcie
speed and width supported by the platform walk the hierarchy and get the
slowest link.
Change-Id:
Am 05.02.19 um 23:00 schrieb Yang, Philip:
Use HMM helper function hmm_vma_fault() to get physical pages backing
userptr and start CPU page table update track of those pages. Then use
hmm_vma_range_done() to check if those pages are updated before
amdgpu_cs_submit for gfx or before user queues
Am 06.02.19 um 00:51 schrieb Kuehling, Felix:
> On 2019-02-05 11:00 a.m., Koenig, Christian wrote:
>> Ah! The initial clear of the PDs is syncing to everything!
> Right. Using amdgpu_sync_resv(... AMDGPU_FENCE_OWNER_VM ...) in
> amdgpu_vm_clear_bo seems to help. But if I also change the
>
Am 05.02.19 um 22:56 schrieb Yang, Philip:
Hi Christian,
I will submit new patch for review, my comments embedded inline below.
Thanks,
Philip
On 2019-02-05 1:09 p.m., Koenig, Christian wrote:
Am 05.02.19 um 18:25 schrieb Yang, Philip:
[SNIP]+
+ if (r == -ERESTARTSYS) {
+ if
30 matches
Mail list logo
