From: Colin Ian King
There are several spelling mistakes in PP_ASSERT_WITH_CODE messages.
Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c | 12 ++--
drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c | 12 ++--
2 files changed
I've seen hangs on a Raven AM4 system after the Ubuntu upgrade to kernel
5.3. I am able to work around it by disabling stutter mode with the
module parameter amdgpu.ppfeaturemask=0xfffdbfff. If that doesn't help,
you could also try disabling GFXOFF with amdgpu.ppfeaturemask=0xfffd3fff.
Regards
On 1/24/20 5:01 PM, Lyude Paul wrote:
On Fri, 2020-01-24 at 16:46 -0500, Lyude Paul wrote:
On Fri, 2020-01-24 at 14:20 -0500, Mikita Lipski wrote:
On 1/24/20 2:10 PM, Lyude Paul wrote:
Disabling a display on MST can potentially happen after the entire MST
topology has been removed, which me
Reverting this patch avoids the gmc_v8 errors (I previously sent kernel
logs, here's one for convenience):
[ 358.554335] [ cut here ]
[ 358.554338] kernel BUG at drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:725!
[ 358.554351] invalid opcode: [#1] SMP NOPTI
[ 358.554354]
The offending PDE address is: "3eff60"
Which looks like it was sign extended into the "reserved" section
between bits 40:58 (0x3fff) hence triggering the BUG() in the gmc_v8 driver.
Tom
On 2020-01-27 9:57 a.m., Tom St Denis wrote:
Reverting this patch avoids the gmc_v8 errors (I previ
OH, thanks for that hint! I was staring at the code for a day now
without having a clue what's going wrong.
Haven't realized that something could have been sign extended!
Probably going to figure it out by tomorrow now,
Christian.
Am 27.01.20 um 18:37 schrieb Tom St Denis:
The offending PDE a
No problemo, maybe we should split that BUG() statement to catch the
two halves of the PDE address so next time it'll be more obvious.
For ref though your 4 patches have applied cleanly on top of drm-next
every day and work fine on my navi10/raven1 system. So it seems like
just gmc8 is affec
Has been working fine for a while.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 1da03658891c..69248d1b2417 100644
--
Everything is in place.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 69248d1b2417..5030a09babb8 100644
--- a/drivers/gp
Series is Reviewed-by: Andrey Grodzovsky
Andrey
On 1/27/20 2:37 PM, Alex Deucher wrote:
Everything is in place.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/driv
On Fri, Jan 24, 2020 at 2:23 PM Harry Wentland wrote:
>
> From: Roman Li
>
> [Why]
> Driver crash with psr feature enabled due to divide-by-zero error.
> This is a regression after rework to calculate static screen frame
> number entry time.
>
> [How]
> Correct order of operations to avoid divide
Applied with Walter's comment included.
Thanks!
Alex
On Fri, Jan 17, 2020 at 9:45 AM walter harms wrote:
>
>
>
> Am 17.01.2020 14:33, schrieb Colin King:
> > From: Colin Ian King
> >
> > A for-loop is iterating from 0 up to 1000 however the loop variable count
> > is a u8 and hence not large e
Applied. Thanks!
Alex
On Sat, Jan 25, 2020 at 3:26 PM Colin King wrote:
>
> From: Colin Ian King
>
> There are several spelling mistakes in PP_ASSERT_WITH_CODE messages.
> Fix these.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c | 12 ++---
On 2020-01-24 6:45 p.m., Joseph Greathouse wrote:
In previous gfx9 parts, S_BARRIER shader instructions are implicitly
S_WAITCNT 0 instructions as well. This setting turns off that
mechanism in Arcturus and beyond. With this, shaders must follow
the ISA guide insofar as putting in explicit S_WAIT
amdgpu_device_suspend might return an error code since it can be called
from both runtime and system suspend flows. Add the missing return code
in case of a failure.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
So far the kfd driver implemented same routines for runtime and system
wide suspend and resume (s2idle or mem). During system wide suspend the
kfd aquires an atomic lock that prevents any more user processes to
create queues and interact with kfd driver and amd gpu. This mechanism
created problem w
When BACO is enabled by default, sometimes it can cause additional
trouble to debug KFD issues. This debugfs override allows to temporarily
disable BACO for debug purpose without having to reboot the machine.
However, in some cases one suspend-resume cycle might be needed if
the device is already
During system suspend the kfd driver aquires a lock that prohibits
further kfd actions unless the gpu is resumed. This adds some info which
can be useful while debugging.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 ++
1 file changed, 2 insertions(+)
diff -
This series aims to enable BACO by default on supported AMD platforms
and ensures that the AMD Kernel Fusion Driver can co-exist with this
feature when the GPU devices are runtime suspended and firmware pushes
the envelop to save more power with BACO entry sequence. Current
approach makes sure that
This allows runtime power management to kick in on amdgpu driver when
the underlying hardware supports either BOCO or BACO. This can still be
avoided if boot arg amdgpu.runpm = 0 is supplied.
BOCO: Bus Off, Chip Off
BACO: Bus Alive, Chip Off
Signed-off-by: Rajneesh Bhardwaj
---
20 matches
Mail list logo
