VKexample test hang during Occlusion/SDMA/Varia runs.
Clear XNACK_WATERMK in reg SDMA0_UTCL1_WATERMK to fix this issue.
Signed-off-by: chen gong
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
b/drivers/gpu/dr
The UPSTREAM tag in the commit message needs to be removed.
On 10/21/2019 1:24 PM, Louis Li wrote:
> [Why]
> External monitor cannot be displayed consistently, if connecting
> via this Apple dongle (A1621, USB Type-C to HDMI).
> By experiments, it is confirmed that the dongle needs 200ms at least
On Tue, Oct 22, 2019 at 12:09 PM Michel Dänzer wrote:
>
> On 2019-10-20 11:21 p.m., Meelis Roos wrote:
> > I tried 5.2, 5.3 and 5.4-rc4 on my old Fujitsu RX220 with integrated
> > Radeon RV100. Dmesg tells that GPU acceleration is disabled. I do not
> > know if it has been enabled in the past - no
> -Original Message-
> From: amd-gfx On Behalf Of
> Marek Olšák
> Sent: Tuesday, October 22, 2019 5:23 PM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu: Allow reading more status registers on si/cik
>
> From: Marek Olšák
>
> Allow userspace to read the same status re
> -Original Message-
> From: Grodzovsky, Andrey
> Sent: Wednesday, October 23, 2019 3:10 AM
> To: Chen, Guchun ; amd-
> g...@lists.freedesktop.org
> Cc: Zhou1, Tao ; Deucher, Alexander
> ; noreply-conflue...@amd.com; Quan,
> Evan
> Subject: Re: [PATCH 2/4] drm/amd/powerplay: Add EEPROM
> -Original Message-
> From: amd-gfx On Behalf Of Zhu,
> James
> Sent: Tuesday, October 22, 2019 10:49 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, James
> Subject: [PATCH] drm/amdgpu/vcn: Enable VCN2.5 encoding
>
> After VCN2.5 firmware (Version ENC: 1.1 Revision: 11),
> VCN2.5 en
Hi Andrey,
No, I don't want to see amdgpu_ras_recovery_init being called at different
places.
If calling amdgpu_ras_recovery_init as much early as we can is not doable, due
to arcturus i2c code ready timeline, I am fine with this patch.
Regards,
Guchun
-Original Message-
From: Grodzovs
From: Marek Olšák
Allow userspace to read the same status registers for every family.
Based on commit c7890fea, added any of these registers if defined in
the include files of each architecture.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
drivers/gpu/drm/am
From: Trek
Allow userspace to read the same status registers for every family.
Based on commit c7890fea, added any of these registers if defined in
the include files of each architecture.
Signed-off-by: Trek
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/cik.c
On 10/22/19 4:04 PM, Yang, Philip wrote:
>
> On 2019-10-22 3:36 p.m., Grodzovsky, Andrey wrote:
>> On 10/22/19 3:19 PM, Yang, Philip wrote:
>>> On 2019-10-22 2:40 p.m., Grodzovsky, Andrey wrote:
On 10/22/19 2:38 PM, Grodzovsky, Andrey wrote:
> On 10/22/19 2:28 PM, Yang, Philip wrote:
On Mon, Oct 21, 2019 at 10:36:02PM -0400, Lyude Paul wrote:
> This probably hasn't caused any problems up until now since it's
> probably nearly impossible to encounter this in the wild, however if we
> were to receive a connection status notification from the MST hub after
> resume while we're in
On Mon, Oct 21, 2019 at 10:36:01PM -0400, Lyude Paul wrote:
> This is a complicated one. Essentially, there's currently a problem in the MST
> core that hasn't really caused any issues that we're aware of (emphasis on
> "that
> we're aware of"): locking.
>
> When we go through and probe the link
On 2019-10-22 3:36 p.m., Grodzovsky, Andrey wrote:
>
> On 10/22/19 3:19 PM, Yang, Philip wrote:
>>
>> On 2019-10-22 2:40 p.m., Grodzovsky, Andrey wrote:
>>> On 10/22/19 2:38 PM, Grodzovsky, Andrey wrote:
On 10/22/19 2:28 PM, Yang, Philip wrote:
> If device reset/suspend/resume failed fo
On 2019-10-22 2:44 p.m., Kuehling, Felix wrote:
> On 2019-10-22 14:28, Yang, Philip wrote:
>> If device reset/suspend/resume failed for some reason, dqm lock is
>> hold forever and this causes deadlock. Below is a kernel backtrace when
>> application open kfd after suspend/resume failed.
>>
>> Inst
On 10/22/19 3:19 PM, Yang, Philip wrote:
>
> On 2019-10-22 2:40 p.m., Grodzovsky, Andrey wrote:
>> On 10/22/19 2:38 PM, Grodzovsky, Andrey wrote:
>>> On 10/22/19 2:28 PM, Yang, Philip wrote:
If device reset/suspend/resume failed for some reason, dqm lock is
hold forever and this causes d
On 2019-10-22 2:40 p.m., Grodzovsky, Andrey wrote:
>
> On 10/22/19 2:38 PM, Grodzovsky, Andrey wrote:
>> On 10/22/19 2:28 PM, Yang, Philip wrote:
>>> If device reset/suspend/resume failed for some reason, dqm lock is
>>> hold forever and this causes deadlock. Below is a kernel backtrace when
>>>
On 10/22/19 10:58 AM, Andrey Grodzovsky wrote:
>
> On 10/20/19 9:44 PM, Chen, Guchun wrote:
>> Comment inline.
>>
>>
>> Regards,
>> Guchun
>>
>> -Original Message-
>> From: Andrey Grodzovsky
>> Sent: Saturday, October 19, 2019 4:48 AM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Chen, Guch
On 2019-10-22 14:28, Yang, Philip wrote:
> If device reset/suspend/resume failed for some reason, dqm lock is
> hold forever and this causes deadlock. Below is a kernel backtrace when
> application open kfd after suspend/resume failed.
>
> Instead of holding dqm lock in pre_reset and releasing dqm
On 10/22/19 2:38 PM, Grodzovsky, Andrey wrote:
> On 10/22/19 2:28 PM, Yang, Philip wrote:
>> If device reset/suspend/resume failed for some reason, dqm lock is
>> hold forever and this causes deadlock. Below is a kernel backtrace when
>> application open kfd after suspend/resume failed.
>>
>> Inst
On 10/22/19 2:28 PM, Yang, Philip wrote:
> If device reset/suspend/resume failed for some reason, dqm lock is
> hold forever and this causes deadlock. Below is a kernel backtrace when
> application open kfd after suspend/resume failed.
>
> Instead of holding dqm lock in pre_reset and releasing dqm
If device reset/suspend/resume failed for some reason, dqm lock is
hold forever and this causes deadlock. Below is a kernel backtrace when
application open kfd after suspend/resume failed.
Instead of holding dqm lock in pre_reset and releasing dqm lock in
post_reset, add dqm->device_stopped flag w
No problem on Vega 20
Andrey
On 10/22/19 1:46 PM, Zeng, Oak wrote:
> Sorry I searched my kconfig and I didn't find the stack size configure
> anymore...Maybe today kernel stack size is not configurable anymore...
>
> Can you try your kernel on vega10 or 20 or navi10? We want to know whether
> t
Sorry I searched my kconfig and I didn't find the stack size configure
anymore...Maybe today kernel stack size is not configurable anymore...
Can you try your kernel on vega10 or 20 or navi10? We want to know whether this
is mi100 specific issue.
Oak
-Original Message-
From: Grodzovsky
I don't know - what Kconfig flag should I look at ?
Andrey
On 10/22/19 1:17 PM, Zeng, Oak wrote:
> Sorry I meant is the kernel stack size 16KB in your kconfig?
>
> Oak
>
> -Original Message-
> From: Grodzovsky, Andrey
> Sent: Tuesday, October 22, 2019 12:49 PM
> To: Zeng, Oak ; Kuehling,
Sorry I meant is the kernel stack size 16KB in your kconfig?
Oak
-Original Message-
From: Grodzovsky, Andrey
Sent: Tuesday, October 22, 2019 12:49 PM
To: Zeng, Oak ; Kuehling, Felix
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: Stack out of bounds in KFD on Arcturus
On 10/18/19 5:31
This seems to help with https://bugs.freedesktop.org/show_bug.cgi?id=111481.
v2: insert a NOP instead of skipping all 0-sized IBs to avoid breaking older hw
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
On 10/18/19 5:31 PM, Zeng, Oak wrote:
> Hi Andrey,
>
> What is your system configuration? I didn’t see this issue before. Also see
> attached QA's configuration - you can compare to see any difference.
Attached is my lshw
>
> Also I believe for x86-64, the default kernel stack size is 16kb? Is
On 2019-10-20 11:21 p.m., Meelis Roos wrote:
> I tried 5.2, 5.3 and 5.4-rc4 on my old Fujitsu RX220 with integrated
> Radeon RV100. Dmesg tells that GPU acceleration is disabled. I do not
> know if it has been enabled in the past - no old kernels handy at the
> moment.
>
> From dmesg it looks like
On Mon, Oct 21, 2019 at 10:36:00PM -0400, Lyude Paul wrote:
> Currently, MST lacks locking in a lot of places that really should have
> some sort of locking. Hotplugging and link address code paths are some
> of the offenders here, as there is actually nothing preventing us from
> running a link ad
On 2019-10-21 9:03 p.m., Kuehling, Felix wrote:
>
> On 2019-10-21 5:04 p.m., Yang, Philip wrote:
>> If device reset/suspend/resume failed for some reason, dqm lock is
>> hold forever and this causes deadlock. Below is a kernel backtrace when
>> application open kfd after suspend/resume failed.
>
Hi Christian,
I checked that Arcturus firmware haven't been published yet.
Best Regards!
James Zhu
On 2019-10-22 8:52 a.m., Christian König wrote:
> Have we ever published an older version of the firmware?
>
> I strongly assume the answer is "no" and if that's the case feel free
> to add an Re
Have we ever published an older version of the firmware?
I strongly assume the answer is "no" and if that's the case feel free to
add an Reviewed-by: Christian König .
Regards,
Christian.
Am 22.10.19 um 16:50 schrieb Liu, Leo:
Reviewed-by: Leo Liu
-Original Message-
From: amd-gfx
On 10/20/19 9:44 PM, Chen, Guchun wrote:
> Comment inline.
>
>
> Regards,
> Guchun
>
> -Original Message-
> From: Andrey Grodzovsky
> Sent: Saturday, October 19, 2019 4:48 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chen, Guchun ; Zhou1, Tao ;
> Deucher, Alexander ; noreply-conflue...@a
Reviewed-by: Leo Liu
-Original Message-
From: amd-gfx On Behalf Of Zhu, James
Sent: Tuesday, October 22, 2019 10:49 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, James
Subject: [PATCH] drm/amdgpu/vcn: Enable VCN2.5 encoding
After VCN2.5 firmware (Version ENC: 1.1 Revision: 11),
VCN2.5
After VCN2.5 firmware (Version ENC: 1.1 Revision: 11),
VCN2.5 encoding can work properly.
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
index
I am well aware that we want to do it ASAP, but what is your suggestion
for the Arcturus use case where we have to do it AFTER SMU is up and
running ? Do you want to call amdgpu_ras_recovery_init in two different
places depending if this is Vega 20 or Arcturus ? This will over
complicate an alr
On 2019-10-22 9:33 a.m., Li, Roman wrote:
>> Any reason why we're skipping a flag here going from 0x2 to 0x8?
>
> 0x4 is reserved for fractional pwm mask:
> https://patchwork.freedesktop.org/patch/336923/
Ah, missed that patch. No problem then, feel free to go ahead with this.
Nicholas Kazlausk
Reviewed-by: Anthony Koo
-Original Message-
From: sunpeng...@amd.com
Sent: Monday, October 21, 2019 3:44 PM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
lskre...@gmail.com
Cc: Koo, Anthony ; Wentland, Harry
; Li, Sun peng (Leo)
Subject: [PATCH v2] drm/amdgpu: A
On 2019-10-21 22:02, Zeng, Oak wrote:
> If we decline the queue creation request in suspend state by returning
> -EAGAIN, then this approach works for both hws and non-hws. This way the
> driver is clean but application need to re-create queue later when it get a
> EAGAIN. Currently application
> -Original Message-
> From: amd-gfx On Behalf Of
> Chen, Guchun
> Sent: Monday, October 21, 2019 11:43 PM
> To: amd-gfx@lists.freedesktop.org; Zhang, Hawking
> ; Li, Dennis ;
> Grodzovsky, Andrey ; Zhou1, Tao
>
> Cc: Chen, Guchun
> Subject: [PATCH] drm/amdgpu: define macros for retire p
> Any reason why we're skipping a flag here going from 0x2 to 0x8?
0x4 is reserved for fractional pwm mask:
https://patchwork.freedesktop.org/patch/336923/
Thank you Nicholas for the review.
-Original Message-
From: Kazlauskas, Nicholas
Sent: Tuesday, October 22, 2019 8:39 AM
To: Li,
> -Original Message-
> From: amd-gfx On Behalf Of
> Chen, Guchun
> Sent: Monday, October 21, 2019 10:29 PM
> To: amd-gfx@lists.freedesktop.org; Koenig, Christian
> ; Zhang, Hawking
> ; Li, Dennis ;
> Grodzovsky, Andrey ; Zhou1, Tao
>
> Cc: Li, Candice ; Chen, Guchun
>
> Subject: [PATCH]
On 2019-10-21 5:45 p.m., roman...@amd.com wrote:
> From: Roman Li
>
> [Why]
> Adding psr mask to dc features allows selectively disable/enable psr.
> Current psr implementation may not work with non-pageflipping application.
> Until resolved it should be disabled by default.
>
> [How]
> Add dcfe
On 2019-10-21 3:36 p.m., Liu, Zhan wrote:
> [PATCH] drm/amd/display: Change Navi14's DWB flag to 1
>
> [Why]
> DWB (Display Writeback) flag needs to be enabled as 1, or system
> will throw out a few warnings when creating dcn20 resource pool.
> Also, Navi14's dwb setting needs to match Navi10's,
>
Hi All,
More testing over the last few days showed that only either the lowest
power mode, or slightly above can work. Oh, I also tested 5.4-rc3 just
in case but same results.
It doesn't seem to be the affected by PCIe lane speed, Memory seems
stable at 625M and almost at 1500M (only the sustained
Am 22.10.19 um 05:43 schrieb Chen, Guchun:
Easy for maintainance.
Signed-off-by: Guchun Chen
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras
Am 22.10.19 um 04:28 schrieb Chen, Guchun:
> Ras reboot debugfs node allows user one easy control to avoid
> gpu recovery hang problem and directly reboot system per card
> basis, after ras uncorrectable error happens. However, it is
> one common entry, which should get rid of ras_ctrl node and
> r
On Mon, Oct 21, 2019 at 03:12:26PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 02:28:46PM +, Koenig, Christian wrote:
> > Am 21.10.19 um 15:57 schrieb Jason Gunthorpe:
> > > On Sun, Oct 20, 2019 at 02:21:42PM +, Koenig, Christian wrote:
> > >> Am 18.10.19 um 22:36 schrieb Jason
On Mon, Oct 21, 2019 at 03:11:57PM -0400, Jerome Glisse wrote:
> > Since that reader is not locked we need release semantics here to
> > ensure the unlocked reader sees a fully initinalized mmu_notifier_mm
> > structure when it observes the pointer.
>
> I thought the mm_take_all_locks() would have
On Mon, Oct 21, 2019 at 02:40:41PM -0400, Jerome Glisse wrote:
> On Tue, Oct 15, 2019 at 03:12:27PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
> > scif_dma, vhost, gntdev, hmm) drivers are using a commo
In the impelementation of amdgpu_fence_emit() if dma_fence_wait() fails
and returns an errno, before returning the allocated memory for fence
should be released.
Fixes: 3d2aca8c8620 ("drm/amdgpu: fix old fence check in amdgpu_fence_emit")
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/amd/am
On Mon, Oct 21, 2019 at 02:28:46PM +, Koenig, Christian wrote:
> Am 21.10.19 um 15:57 schrieb Jason Gunthorpe:
> > On Sun, Oct 20, 2019 at 02:21:42PM +, Koenig, Christian wrote:
> >> Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
> >>> On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig, Christ
On Mon, Oct 21, 2019 at 02:38:24PM -0400, Jerome Glisse wrote:
> On Tue, Oct 15, 2019 at 03:12:42PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > The only two users of this are now converted to use mmu_range_notifier,
> > delete all the code and update hmm.rst.
>
> I guess i sh
On Mon, Oct 21, 2019 at 02:30:56PM -0400, Jerome Glisse wrote:
> > +/**
> > + * mmu_range_read_retry - End a read side critical section against a VA
> > range
> > + * mrn: The range under lock
> > + * seq: The return of the paired mmu_range_read_begin()
> > + *
> > + * This MUST be called under a
On 10/15/2019 2:12 PM, Jason Gunthorpe wrote:
This is still being tested, but I figured to send it to start getting help
from the xen, amd and hfi drivers which I cannot test here.
Sorry for the delay, I never seen this. Was not on Cc list and didn't
register to me it impacted hfi. I'll take a
On Sun, Oct 20, 2019 at 02:21:42PM +, Koenig, Christian wrote:
> Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
> > On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig, Christian wrote:
> >
> >>> get_user_pages/hmm_range_fault() and invalidate_range_start() both are
> >>> called while holding mm->m
On Wed, Oct 16, 2019 at 06:35:15AM +, Oleksandr Andrushchenko wrote:
> On 10/16/19 8:11 AM, Jürgen Groß wrote:
> > On 15.10.19 20:12, Jason Gunthorpe wrote:
> >> From: Jason Gunthorpe
> >>
> >> DMA_SHARED_BUFFER can not be enabled by the user (it represents a
> >> library
> >> set in the kern
On Mon, Oct 21, 2019 at 11:55:51AM -0400, Dennis Dalessandro wrote:
> On 10/15/2019 2:12 PM, Jason Gunthorpe wrote:
> > This is still being tested, but I figured to send it to start getting help
> > from the xen, amd and hfi drivers which I cannot test here.
>
> Sorry for the delay, I never seen t
58 matches
Mail list logo
