On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
[drm:amdgpu_job_run] *ERROR* Error scheduling IBs (-22)
...
amdgpu_device_ip_resume_phase2 resumed gfx_v9_0
amdgpu_device_ip_resume_phase2
Am 25.10.19 um 12:08 schrieb S, Shirish:
On 10/25/2019 2:56 PM, Koenig, Christian wrote:
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
if no disable gfx CGPG when suspend smu, enabling gfx CGPG will fail when
resume smu.
Platform: Renoir
dmesg log information:
[ 151.844110 ] amdgpu: [powerplay] SMU is resuming...
[ 151.844116 ] amdgpu: [powerplay] dpm has been disabled
[ 151.844604 ] amdgpu: [powerplay] Failed to send
Add an DMA-buf export implementation independent of the DRM helpers.
This not only avoids the caching of DMA-buf mappings, but also
allows us to use the new dynamic locking approach.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging
Why do you disable CGPG for all APU?
Thanks,
Ray
-Original Message-
From: amd-gfx On Behalf Of chen gong
Sent: Friday, October 25, 2019 7:07 PM
To: amd-gfx@lists.freedesktop.org
Cc: Gong, Curry
Subject: [PATCH] drm/amd/powerplay: Disable gfx CGPG when suspend smu
if no disable gfx
From: Emily Deng
[ Upstream commit 526c654a8a0641d4289bf65effde4d6095bd8384 ]
Issue:
Will have follow error when reload driver:
[ 3986.567739] sysfs: cannot create duplicate filename
'/devices/pci:00/:00:07.0/drm_dp_aux_dev'
[ 3986.567743] CPU: 6 PID: 1767 Comm: modprobe Tainted: G
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach
On Thu, Oct 24, 2019 at 09:16:55PM +, Tuikov, Luben wrote:
> The GRBM interface is now capable of bursting 1-cycle op per register,
> a WRITE followed by another WRITE, or a WRITE followed by a READ--much
> faster than previous muti-cycle per completed-transaction interface.
> This causes a
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
[drm:amdgpu_job_run] *ERROR* Error scheduling IBs (-22)
...
amdgpu_device_ip_resume_phase2 resumed
In the highly unlikely event that we fail to allocate the "radeon-crtc"
workqueue, we should bail cleanly rather than blindly march on with a
NULL pointer installed for the 'flip_queue' field of the 'radeon_crtc'
structure.
This was reported previously by Nicolas, but I don't think his fix was
On 25.10.2019 8:06, Kazlauskas, Nicholas wrote:
> On 2019-10-24 5:06 p.m., mikita.lip...@amd.com wrote:
>> From: Mikita Lipski
>>
>> - Adding encoder atomic check to find vcpi slots for a connector
>> - Using DRM helper functions to calculate PBN
>> - Adding connector atomic check to release
I try to write a patch based on the patch of Tuikov,Luben.
Inspired by Luben,here is the patch:
From 1980d8f1ed44fb9a84a5ea1f6e2edd2bc25c629a Mon Sep 17 00:00:00 2001
From: changzhu
Date: Thu, 10 Oct 2019 11:02:33 +0800
Subject: [PATCH] drm/amdgpu: add dummy read by engines for some GCVM status
On 2019-10-24 5:06 p.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> - Adding encoder atomic check to find vcpi slots for a connector
> - Using DRM helper functions to calculate PBN
> - Adding connector atomic check to release vcpi slots if connector
> loses CRTC
> - Calculate PBN
On 10/25/2019 2:56 PM, Koenig, Christian wrote:
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
[drm:amdgpu_job_run] *ERROR* Error scheduling IBs
Am 25.10.19 um 01:44 schrieb Tuikov, Luben:
> Simplify padding calculations.
>
> Signed-off-by: Luben Tuikov
> ---
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 ++--
>
Am 24.10.19 um 23:16 schrieb Tuikov, Luben:
> The GRBM interface is now capable of bursting
> 1-cycle op per register, a WRITE followed by
> another WRITE, or a WRITE followed by a READ--much
> faster than previous muti-cycle per
> completed-transaction interface. This causes a
> problem, whereby
Reviewed-by: Huang Rui
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Thursday, October 24, 2019 7:17 PM
To: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; Zhou,
David(ChunMing)
Subject: [PATCH] drm/ttm: use the parent resv for ghost objects v3
On Thu, Oct 24, 2019 at 03:26:28PM +0300, Jani Nikula wrote:
> On Wed, 23 Oct 2019, Mark Salyzyn wrote:
> > I will split this between pure and inert documentation/comments for now,
> > with a followup later for the code portion which understandably is more
> > controversial.
>
> Please split
On Wed, Oct 23, 2019 at 08:40:59AM -0700, Mark Salyzyn wrote:
> On 10/23/19 4:56 AM, Jarkko Sakkinen wrote:
> > On Tue, Oct 22, 2019 at 02:41:45PM -0700, Mark Salyzyn wrote:
> > > Replace all occurrences of prefered with preferred to make future
> > > checkpatch.pl's happy. A few places the
On Wed, Oct 23, 2019 at 03:09:34PM +, Harry Wentland wrote:
> On 2019-10-19 3:24 a.m., Wambui Karuga wrote:
> > Make the `amdgpu_lockup_timeout` and `amdgpu_exp_hw_support` variables
> > static to remove the following sparse warnings:
> > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:103:19:
On Wed, Oct 16, 2019 at 4:02 PM Nick Desaulniers
wrote:
>
> The x86 kernel is compiled with an 8B stack alignment via
> `-mpreferred-stack-boundary=3` for GCC since 3.6-rc1 via
> commit d9b0cde91c60 ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if
> supported")
> or `-mstack-alignment=8` for
On Wed, Oct 23, 2019 at 08:40:59AM -0700, Mark Salyzyn wrote:
> On 10/23/19 4:56 AM, Jarkko Sakkinen wrote:
> > On Tue, Oct 22, 2019 at 02:41:45PM -0700, Mark Salyzyn wrote:
> > > Replace all occurrences of prefered with preferred to make future
> > > checkpatch.pl's happy. A few places the
Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
Problem:
When run_job fails and HW fence returned is NULL we still signal
the s_fence to avoid hangs but the user has no way of knowing if
the actual HW job was ran and finished.
Fix:
Allow .run_job implementations to return ERR_PTR in the fence
Here is the call trace:
Call Trace:
dump_stack+0x4d/0x63
amdgpu_ib_schedule+0x86/0x4b7
? __mod_timer+0x21e/0x244
amdgpu_job_run+0x108/0x178
drm_sched_main+0x253/0x2fa
? remove_wait_queue+0x51/0x51
? drm_sched_cleanup_jobs.part.12+0xda/0xda
kthread+0x14f/0x157
? kthread_park+0x86/0x86
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
[drm:amdgpu_job_run] *ERROR* Error scheduling IBs (-22)
...
amdgpu_device_ip_resume_phase2 resumed gfx_v9_0
amdgpu_device_ip_resume_phase2 resumed sdma_v4_0
amdgpu_device_ip_resume_phase2
On 10/25/19 4:44 AM, Christian König wrote:
> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
>> Problem:
>> When run_job fails and HW fence returned is NULL we still signal
>> the s_fence to avoid hangs but the user has no way of knowing if
>> the actual HW job was ran and finished.
>>
>> Fix:
On 10/25/19 5:26 AM, Koenig, Christian wrote:
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
[drm:amdgpu_job_run] *ERROR* Error scheduling IBs (-22)
On 10/25/19 11:57 AM, Koenig, Christian wrote:
Am 25.10.19 um 17:35 schrieb Grodzovsky, Andrey:
On 10/25/19 5:26 AM, Koenig, Christian wrote:
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu
Am 25.10.19 um 17:35 schrieb Grodzovsky, Andrey:
On 10/25/19 5:26 AM, Koenig, Christian wrote:
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
Am 25.10.19 um 17:56 schrieb Grodzovsky, Andrey:
> On 10/25/19 11:55 AM, Koenig, Christian wrote:
>> Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
>>> On 10/25/19 4:44 AM, Christian König wrote:
Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
> Problem:
> When run_job fails and HW
Hi Changfeng,
that won't work, you can't add this to
amdgpu_ring_emit_reg_write_reg_wait_helper or break all read triggered
registers (like the semaphore ones).
Additional to that it will never work on GFX9, since the CP firmware
there uses the integrated write/wait command and you can't add
Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
> On 10/25/19 4:44 AM, Christian König wrote:
>> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
>>> Problem:
>>> When run_job fails and HW fence returned is NULL we still signal
>>> the s_fence to avoid hangs but the user has no way of knowing if
On 10/25/19 11:55 AM, Koenig, Christian wrote:
> Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
>> On 10/25/19 4:44 AM, Christian König wrote:
>>> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
Problem:
When run_job fails and HW fence returned is NULL we still signal
the s_fence
From: Kyle Mahlkuch
During kexec some adapters hit an EEH since they are not properly
shut down in the radeon_pci_shutdown() function. Adding
radeon_suspend_kms() fixes this issue.
Enabled only on PPC because this patch causes issues on some other
boards.
Signed-off-by: Kyle Mahlkuch
---
On Sat, Oct 19, 2019 at 8:07 PM Chen Wandun wrote:
>
> From: Chenwandun
>
> drivers/gpu/drm/amd/display/dc/dce/dce_aux.c: In function
> dce_aux_configure_timeout:
> drivers/gpu/drm/amd/display/dc/dce/dce_aux.c: warning: variable timeout set
> but not used [-Wunused-but-set-variable]
>
>
On Fri, Oct 25, 2019 at 06:06:26PM +0200, Michel Dänzer wrote:
> On 2019-10-25 1:04 p.m., Will Deacon wrote:
> > In the highly unlikely event that we fail to allocate the "radeon-crtc"
> > workqueue, we should bail cleanly rather than blindly march on with a
> > NULL pointer installed for the
On Fri, Oct 25, 2019 at 2:49 AM Koenig, Christian
wrote:
>
> Am 24.10.19 um 23:16 schrieb Tuikov, Luben:
> > The GRBM interface is now capable of bursting
> > 1-cycle op per register, a WRITE followed by
> > another WRITE, or a WRITE followed by a READ--much
> > faster than previous muti-cycle
On 2019-10-25 1:04 p.m., Will Deacon wrote:
> In the highly unlikely event that we fail to allocate the "radeon-crtc"
> workqueue, we should bail cleanly rather than blindly march on with a
> NULL pointer installed for the 'flip_queue' field of the 'radeon_crtc'
> structure.
>
> This was reported
On 2019-10-25 6:18 p.m., Will Deacon wrote:
> On Fri, Oct 25, 2019 at 06:06:26PM +0200, Michel Dänzer wrote:
>> On 2019-10-25 1:04 p.m., Will Deacon wrote:
>>> In the highly unlikely event that we fail to allocate the "radeon-crtc"
>>> workqueue, we should bail cleanly rather than blindly march on
Am 25.10.19 um 18:05 schrieb Alex Deucher:
> On Fri, Oct 25, 2019 at 2:49 AM Koenig, Christian
> wrote:
>> Am 24.10.19 um 23:16 schrieb Tuikov, Luben:
>>> The GRBM interface is now capable of bursting
>>> 1-cycle op per register, a WRITE followed by
>>> another WRITE, or a WRITE followed by a
On Mon, Oct 21, 2019 at 04:51:45PM +0200, Geert Uytterhoeven wrote:
> Variables of type atomic{,64}_t can be used fine with
> debugfs_create_u{32,64}, when passing a pointer to the embedded counter.
> This allows to get rid of the casts, which prevented compiler checks.
>
> Signed-off-by: Geert
On Fri, Oct 25, 2019 at 4:12 AM Nick Desaulniers
wrote:
>
> On Wed, Oct 16, 2019 at 4:02 PM Nick Desaulniers
> wrote:
> >
> > The x86 kernel is compiled with an 8B stack alignment via
> > `-mpreferred-stack-boundary=3` for GCC since 3.6-rc1 via
> > commit d9b0cde91c60 ("x86-64, gcc: Use
On 10/10/19 11:27 PM, Greg KH wrote:
On Thu, Oct 10, 2019 at 02:44:29PM -0500, KyleMahlkuch wrote:
During kexec some adapters hit an EEH since they are not properly
shut down in the radeon_pci_shutdown() function. Adding
radeon_suspend_kms() fixes this issue.
Enabled only on PPC because this
On 2019-10-25 2:54 a.m., Koenig, Christian wrote:
> Am 25.10.19 um 01:44 schrieb Tuikov, Luben:
>> Simplify padding calculations.
>>
>> Signed-off-by: Luben Tuikov
>> ---
>> drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
>> drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
>>
Given amdkfd.ko has been merged into amdgpu.ko, this switch is no
longer useful.
Change-Id: If56b80e086f4ea26f347c70b620b3892afc24ddf
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 4
Applied. Thanks!
Alex
On Wed, Oct 23, 2019 at 11:09 AM Harry Wentland wrote:
>
> On 2019-10-19 3:32 a.m., Wambui Karuga wrote:
> > Remove unnecessary assignment for return value and have the
> > function return the required value directly.
> > Issue found by coccinelle:
> > @@
> > local
Applied. thanks!
Alex
On Wed, Oct 23, 2019 at 9:35 AM Harry Wentland wrote:
>
> On 2019-10-23 4:32 a.m., zhongshiqi wrote:
> > dc.c:583:null check is needed after using kzalloc function
> >
> > Signed-off-by: zhongshiqi
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> >
Hi Dave, Daniel,
More new stuff for 5.5. I tested a back merge and it was clean.
The following changes since commit 1cd4d9eead73c004d08a58536dc726bd172eaaec:
drm/amdkfd: update for drmP.h removal (2019-10-09 12:04:48 -0500)
are available in the Git repository at:
On Fri, Oct 25, 2019 at 8:16 AM Christian König
wrote:
>
> Add an DMA-buf export implementation independent of the DRM helpers.
>
> This not only avoids the caching of DMA-buf mappings, but also
> allows us to use the new dynamic locking approach.
>
> This is also a prerequisite of unpinned
On 2019-10-25 12:19 p.m., Koenig, Christian wrote:
> Am 25.10.19 um 18:05 schrieb Alex Deucher:
>> On Fri, Oct 25, 2019 at 2:49 AM Koenig, Christian
>> wrote:
>>> Am 24.10.19 um 23:16 schrieb Tuikov, Luben:
The GRBM interface is now capable of bursting
1-cycle op per register, a WRITE
Simplify padding calculations.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++--
Simplify padding calculations.
v2: Comment update and spacing.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++--
The GRBM interface is now capable of bursting
1-cycle op per register, a WRITE followed by
another WRITE, or a WRITE followed by a READ--much
faster than previous muti-cycle per
completed-transaction interface. This causes a
problem, whereby status registers requiring a
read/write by hardware,
53 matches
Mail list logo
