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 (!--t
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
> amdgpu_jo
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 ar
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: I3196d158b0c614cbb5d7a
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 psto
+ 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 examp
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 Trø
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
b/drivers/gpu/dr
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
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
---
drivers/gpu/drm/amd
>> +/* 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
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]
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 (amdgpu_ttm_
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
> ---
> drivers/gpu/drm/amd/power
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 upda
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.
The
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 ch
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 Y
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: I2ec0
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 M
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
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
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 s
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:
> > >>>
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.
Alex
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 vega1
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 Biesheuve
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 upper/lo
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
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 Trø
30 matches
Mail list logo
