Hi Kazlauskas,
I have modified the patch as your suggestion, could you please help to
review it again?
Best wishes
Emily Deng
>-Original Message-
>From: amd-gfx On Behalf Of Emily
>Deng
>Sent: Wednesday, May 29, 2019 11:12 AM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deng, Emily
looks good to me.
发件人: Alex Deucher
发送时间: 2019年5月30日 2:44
收件人: amd-gfx@lists.freedesktop.org
抄送: Deucher, Alexander; Pan, Xinhui
主题: [PATCH] drm/amdgpu: fix a race in GPU reset with IB test (v2)
Split late_init into two functions, one (do_late_init)
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Xiao, Jack
Sent: 2019年5月29日 14:32
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhang, Hawking ; Koenig,
Christian ; Kuehling, Felix
Cc: Xiao, Jack
Subject: [PATCH 3/3] drm/amdkfd: remove
This driver currently contains a repeated 500ms blocking delay call
which causes frequent major buffer underruns in PulseAudio. This patch
fixes this issue by replacing the blocking delay with a non-blocking
sleep call.
Signed-off-by: Yrjan Skrimstad
---
On 2019-05-28 3:08 p.m., Nicholas Kazlauskas wrote:
> This patch series enables HDR output metadata support in amdgpu using the
> DRM HDR interface merged in drm-misc-next. Enabled for DCE and DCN ASICs
> over DP and HDMI.
>
> It's limited to static HDR metadata support for now since that's all
Hi Dave, Daniel,
New stuff for 5.3:
- Add new thermal sensors for vega asics
- Various RAS fixes
- Add sysfs interface for memory interface utilization
- Use HMM rather than mmu notifier for user pages
- Expose xgmi topology via kfd
- SR-IOV fixes
- Fixes for manual driver reload
- Add unique
On 2019-05-29 2:32 a.m., Xiao, Jack wrote:
> Since amdgpu has always requested PCIE atomics, kfd don't
> need duplicated PCIE atomics enablement. Referring to amdgpu
> request result is enough.
>
> Signed-off-by: Jack Xiao
This patch is Reviewed-by: Felix Kuehling
> ---
>
On 2019-05-29 11:07 a.m., Colin King wrote:
> From: Colin Ian King
>
> The pointer dev is set to null yet it is being dereferenced when
> checking dev->dqm->sched_policy. Fix this by performing the check
> on dev->dqm->sched_policy after dev has been assigned and null
> checked. Also remove the
On Wed, May 29, 2019 at 08:45:44PM +, Kuehling, Felix wrote:
> Just to clarify, are you saying that we should upstream this change
> through Alex Deucher's amd-staging-drm-next and Dave Airlie's drm-next
> trees?
Yeah, sure, whichever tree is the most convenient.
Thanks.
--
tejun
Hi,
I have a RX 570 which fails to suspend properly under memory pressure and stays
black after waking up.
It looks like an allocation failure in the TTM VRAM eviction is to blame:
[635471.240411] kworker/u24:26: page allocation failure: order:0,
On 2019-05-28 3:02 p.m., Tejun Heo wrote:
> Hello,
>
> On Fri, May 17, 2019 at 08:12:17PM +, Kuehling, Felix wrote:
>> Patches 1,2,4 will be submitted through amd-staging-drm-next. Patch 3
>> goes through the cgroup tree. Patch 4 depends on patch 3. So submitting
>> patch 4 will need to wait
On Wed, May 29, 2019 at 04:43:45PM +, Grodzovsky, Andrey wrote:
> I don't, sorry.
Should we fix that? Seems like you do plenty of scheduler stuff, so would
make sense I guess ...
-Daniel
>
> Andrey
>
> On 5/29/19 12:42 PM, Alex Deucher wrote:
> > On Wed, May 29, 2019 at 10:29 AM Andrey
On Wed, May 29, 2019 at 10:29:40AM -0400, Andrey Grodzovsky wrote:
> Signed-off-by: Andrey Grodzovsky
Thanks for quick fixing!
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On 5/29/19 8:20 AM, Catalin Marinas wrote:
> Hi Khalid,
>
> On Tue, May 28, 2019 at 05:33:04PM -0600, Khalid Aziz wrote:
>> On Tue, 2019-05-28 at 16:40 +0100, Catalin Marinas wrote:
>>> I think another aspect is how we define the ABI. Is allowing tags to
>>> mlock() for example something specific
Split late_init into two functions, one (do_late_init) which
just does the hw init, and late_init which calls do_late_init
and schedules the IB test work. Call do_late_init in
the GPU reset code to run the init code, but not schedule
the IB test code. The IB test code is called directly
in the
Hi Dave, Daniel,
Fixes for 5.2:
- Respin the Raven DMCU patch with the ifdef fixed
- Fix for a clean display when loading the driver on Raven
The following changes since commit c074989171801171af6c5f53dd16b27f36b31deb:
Revert "drm/amd/display: Don't load DMCU for Raven 1" (2019-05-24 19:56:50
I don't, sorry.
Andrey
On 5/29/19 12:42 PM, Alex Deucher wrote:
> On Wed, May 29, 2019 at 10:29 AM Andrey Grodzovsky
> wrote:
>> Signed-off-by: Andrey Grodzovsky
> Reviewed-by: Alex Deucher
>
> I'll push it to drm-misc in a minute unless you have commit rights.
>
> Alex
>
>> ---
>>
On Wed, May 29, 2019 at 10:29 AM Andrey Grodzovsky
wrote:
>
> Signed-off-by: Andrey Grodzovsky
Reviewed-by: Alex Deucher
I'll push it to drm-misc in a minute unless you have commit rights.
Alex
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>
On 2019/05/29, Koenig, Christian wrote:
> Am 29.05.19 um 15:03 schrieb Emil Velikov:
> > On 2019/05/29, Dave Airlie wrote:
> >> On Wed, 29 May 2019 at 02:47, Emil Velikov
> >> wrote:
> >>> On 2019/05/28, Koenig, Christian wrote:
> Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > On
From: Colin Ian King
The pointer dev is set to null yet it is being dereferenced when
checking dev->dqm->sched_policy. Fix this by performing the check
on dev->dqm->sched_policy after dev has been assigned and null
checked. Also remove the redundant null assignment to dev.
Addresses-Coverity:
On Wed, May 29, 2019 at 02:23:42PM +0100, Catalin Marinas wrote:
> On Wed, May 29, 2019 at 01:42:25PM +0100, Dave P Martin wrote:
> > On Tue, May 28, 2019 at 05:34:00PM +0100, Catalin Marinas wrote:
> > > On Tue, May 28, 2019 at 04:56:45PM +0100, Dave P Martin wrote:
> > > > On Tue, May 28, 2019
add pmu counters to monitor amdgpu device performance.
each pmu registered recorded per pmu type per asic type.
Change-Id: I8449f4ea824c411ee24a5b783ac066189b9de08e
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |
On Mon, 2019-05-06 at 18:30 +0200, Andrey Konovalov wrote:
> To allow arm64 syscalls to accept tagged pointers from userspace, we
> must
> untag them when they are passed to the kernel. Since untagging is
> done in
> generic parts of the kernel, the untagged_addr macro needs to be
> defined
> for
Regards,
Oak
-Original Message-
From: Kuehling, Felix
Sent: Tuesday, May 28, 2019 5:08 PM
To: Zeng, Oak ; amd-gfx@lists.freedesktop.org
Cc: Zhao, Yong ; Liu, Alex ; Freehill,
Chris
Subject: Re: [PATCH] drm/amdkfd: Fix a potential circular lock
On 2019-05-28 2:28 p.m., Zeng, Oak
Hi Khalid,
On Tue, May 28, 2019 at 05:33:04PM -0600, Khalid Aziz wrote:
> On Tue, 2019-05-28 at 16:40 +0100, Catalin Marinas wrote:
> > I think another aspect is how we define the ABI. Is allowing tags to
> > mlock() for example something specific to arm64 or would sparc ADI
> > need the same? In
Hi Christian,
The series is:
Tested-by: Pierre-Eric Pelloux-Prayer
Pierre-Eric
On 29/05/2019 14:27, Christian König wrote:
> This avoids OOM situations when we have lots of threads
> submitting at the same time.
>
> v3: apply this to the whole driver, not just CS
>
> Signed-off-by:
On Wed, May 29, 2019 at 01:42:25PM +0100, Dave P Martin wrote:
> On Tue, May 28, 2019 at 05:34:00PM +0100, Catalin Marinas wrote:
> > On Tue, May 28, 2019 at 04:56:45PM +0100, Dave P Martin wrote:
> > > On Tue, May 28, 2019 at 04:40:58PM +0100, Catalin Marinas wrote:
> > >
> > > [...]
> > >
> >
Am 29.05.19 um 15:03 schrieb Emil Velikov:
> On 2019/05/29, Dave Airlie wrote:
>> On Wed, 29 May 2019 at 02:47, Emil Velikov wrote:
>>> On 2019/05/28, Koenig, Christian wrote:
Am 28.05.19 um 18:10 schrieb Emil Velikov:
> On 2019/05/28, Daniel Vetter wrote:
>> On Tue, May 28, 2019 at
Patch #1,#5,#6,#8,#9,#10 are Reviewed-by: Chunming Zhou
Patch #2,#3,#4 are Acked-by: Chunming Zhou
-David
> -Original Message-
> From: dri-devel On Behalf Of
> Christian K?nig
> Sent: Wednesday, May 29, 2019 8:27 PM
> To: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
On 2019/05/29, Dave Airlie wrote:
> On Wed, 29 May 2019 at 02:47, Emil Velikov wrote:
> >
> > On 2019/05/28, Koenig, Christian wrote:
> > > Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > > > On 2019/05/28, Daniel Vetter wrote:
> > > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> > > >>
On Tue, May 28, 2019 at 05:34:00PM +0100, Catalin Marinas wrote:
> On Tue, May 28, 2019 at 04:56:45PM +0100, Dave P Martin wrote:
> > On Tue, May 28, 2019 at 04:40:58PM +0100, Catalin Marinas wrote:
> >
> > [...]
> >
> > > My thoughts on allowing tags (quick look):
> > >
> > > brk - no
> >
> >
We tried this once before, but that turned out to be more
complicated than thought. With all the right prerequisites
it looks like we can do this now.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 127 ++-
1 file changed, 66 insertions(+), 61
The messages about amdgpu_cs_list_validate are duplicated because the
caller will complain into the logs as well and we can also get
interrupted by a signal here.
Also fix the the caller to not report -EAGAIN from validation.
Signed-off-by: Christian König
---
And only move them in on validation. This allows for better control
when multiple processes are fighting over those resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
When a signal arrives we should return immediately for
handling it and not try other placements first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
If drivers don't prefer a system memory placement
they should not but it into the placement list first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
From: Chunming Zhou
add ticket for display bo, so that it can preempt busy bo.
v2: fix stupid rebase error
Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21
Move BOs which are currently in a lower domain to the new
LRU before allocating backing space while validating.
This makes sure that we always have enough entries on the
LRU to allow for other processes to wait for an operation
to complete.
v2: generalize the test
v3: fix rebase error
This avoids OOM situations when we have lots of threads
submitting at the same time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
v2: drop BUG_ON from ttm_bo_add_to_lru
Signed-off-by: Christian König
---
On Tue, May 28, 2019 at 11:11:26PM -0700, Christoph Hellwig wrote:
> On Tue, May 28, 2019 at 04:14:45PM +0200, Andrey Konovalov wrote:
> > Thanks for a lot of valuable input! I've read through all the replies
> > and got somewhat lost. What are the changes I need to do to this
> > series?
> >
> >
On Thu, Dec 27, 2018 at 8:28 PM Andrey Grodzovsky
wrote:
>
> Decauple sched threads stop and start and ring mirror
> list handling from the policy of what to do about the
> guilty jobs.
> When stoppping the sched thread and detaching sched fences
> from non signaled HW fenes wait for all signaled
On Thu, Apr 18, 2019 at 5:00 PM Andrey Grodzovsky
wrote:
>
> From: Christian König
>
> We now destroy finished jobs from the worker thread to make sure that
> we never destroy a job currently in timeout processing.
> By this we avoid holding lock around ring mirror list in drm_sched_stop
> which
currently gpu reset will schedule late_init_work which will do one IB
test. That would race with the IB test in gpu reset itself.
add another do_ip_late_init() function which skips the late_init_work.
Signed-off-by: xinhui pan
Suggested-by: Alex Deucher
---
No problem. Thanks for your reviewing.
Best wishes
Emily Deng
From: Christian König
Sent: Wednesday, May 29, 2019 3:54 PM
To: Deng, Emily ; amd-gfx@lists.freedesktop.org; Koenig,
Christian ; Quan, Evan
Subject: Re: [PATCH] drm/amdgpu:Fix the unpin warning about csb buffer
Sorry for the delay,
Sorry for the delay, your patch simply got stuck in the daily wave of mails.
Reviewed-by: Christian König
Regards,
Christian.
Am 29.05.19 um 05:07 schrieb Deng, Emily:
Hi Christian,
I have reverted the before change as your suggestion, and sent this new
patch, could you help to review
Hi Louis,
please don't create tickets for this, that is just overkill.
Those are obvious and simple to fix bugs and should go upstream immediately.
Regards,
Christian.
Am 29.05.19 um 03:14 schrieb Li, Ching-shih (Louis):
Hi Christian,
Your explanation matches my code study and test results.
Am 28.05.19 um 21:29 schrieb Alex Deucher:
Split late_init into two functions, one (do_late_init) which
just does the hw init, and late_init which calls do_late_init
and schedules the IB test work. Call do_late_init in
the GPU reset code to run the init code, but not schedule
the IB test code.
otherwise client would wait for reply forever and desktop appears hang.
Signed-off-by: Flora Cui
---
src/amdgpu_dri2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/amdgpu_dri2.c b/src/amdgpu_dri2.c
index 44316ac..34353a7 100644
--- a/src/amdgpu_dri2.c
+++ b/src/amdgpu_dri2.c
@@
The new field in amdgpu device is used to record whether the
system has PCIE atomics support. The field can be exposed to
UMD or kfd whether PCIE atomics have supported.
Signed-off-by: Jack Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
1 file changed, 1 insertion(+)
diff --git
GPU atomics operation depends on PCIE atomics support.
Always enable PCIE atomics ops support in case that
it hasn't been enabled.
Signed-off-by: Jack Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +++
1 file changed, 11 insertions(+)
diff --git
Since amdgpu has always requested PCIE atomics, kfd don't
need duplicated PCIE atomics enablement. Referring to amdgpu
request result is enough.
Signed-off-by: Jack Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
GPU atomics operation depends on PCIE atomics support.
Always enable PCIE atomics ops support in case that
it hasn't been enabled.
Add field to amdgpu device, that can be exposed to UMD or
kfd indicating whether the system has PCIE atomics support.
Jack Xiao (3):
drm/amdgpu: add field
On Tue, May 28, 2019 at 04:14:45PM +0200, Andrey Konovalov wrote:
> Thanks for a lot of valuable input! I've read through all the replies
> and got somewhat lost. What are the changes I need to do to this
> series?
>
> 1. Should I move untagging for memory syscalls back to the generic
> code so
54 matches
Mail list logo
