Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
via amd-gfx
Sent: 2019年2月13日 5:11
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/psp11: TA firmware is optional (v3)
Don't warn or fail if it's
From: Charlene Liu
[ Upstream commit 20300db4aec5ba5edf6f0ad6f7111a51fbea7e10 ]
[Why]
PPLIB not receive the PME when unplug.
Signed-off-by: Charlene Liu
Reviewed-by: Chris Park
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/dce110/dc
From: Felix Kuehling
[ Upstream commit bbdf514fe5648566b0754476cbcb92ac3422dde2 ]
dGPUs need their own topology devices. Don't assign them to APU topology
devices with CPU cores.
Bug: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/issues/66
Signed-off-by: Felix Kuehling
Tested-by: Eli
From: Charlene Liu
[ Upstream commit 20300db4aec5ba5edf6f0ad6f7111a51fbea7e10 ]
[Why]
PPLIB not receive the PME when unplug.
Signed-off-by: Charlene Liu
Reviewed-by: Chris Park
Acked-by: Leo Li
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/dce110/dc
From: Felix Kuehling
[ Upstream commit bbdf514fe5648566b0754476cbcb92ac3422dde2 ]
dGPUs need their own topology devices. Don't assign them to APU topology
devices with CPU cores.
Bug: https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/issues/66
Signed-off-by: Felix Kuehling
Tested-by: Eli
On Mon, Feb 11, 2019 at 6:04 PM Daniel Vetter wrote:
>
> On Mon, Feb 11, 2019 at 4:01 PM Kazlauskas, Nicholas
> wrote:
> >
> > On 2/11/19 3:35 AM, Daniel Vetter wrote:
> > > On Mon, Feb 11, 2019 at 04:22:24AM +0100, Mario Kleiner wrote:
> > >> The pageflip completion timestamps transmitted to use
Don't warn or fail if it's missing.
v2: handle xgmi case more gracefully.
v3: handle older kernels properly
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 9 ++--
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 28 ++---
2 files changed, 23 insertio
Don't warn or fail if it's missing.
v2: handle xgmi case more gracefully.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 9 ++--
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 28 ++---
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git
Am 12.02.19 um 15:05 schrieb Colin King:
> From: Colin Ian King
>
> There are several statements that are incorrectly indented. Fix these.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
> drivers/gpu/drm/am
On Tue, 12 Feb 2019 at 20:23, Grodzovsky, Andrey
wrote:
>
> It should recover you - so this looks like a bug. I noticed in one of
> the call traces this - drm_atomic_helper_suspend which points to system
> going into sleep mode, is it what happened, did it hang when system
> tried to sleep ?
>
It
Sure, that probably would be the solution, one missing detail here
(besides confirming with the debug prints that this is the scenario we
are hitting) is WHY we even stuck in
reservation_object_wait_timeout_rcu, in amdgpu_device_pre_asic_reset
(during GPU reset) we are first forcing all outstan
The MAX_SCHEDULE_TIMEOUT is probably not a good idea on the wait in DM.
I wonder if we could just do shorter wait and skip the FB
update/programming if it fails after some reasonable amount of time.
This would still allow recovery to happen at least even if the display
isn't showing the right b
On 2/12/19 7:34 AM, Mikhail Gavrilov wrote:
> Hi folks. Sorry for noise.
> But I really don't know Is it enough to send my logs or not.
> As I am understand different sequences may cause "ring gfx timeout".
> I am also not hear which version I need wait or which patch I needs
> apply before testin
They are useful. I am gonna take a look later.
Andrey
On 2/12/19 10:49 AM, Mikhail Gavrilov wrote:
> On Tue, 12 Feb 2019 at 20:23, Grodzovsky, Andrey
> wrote:
>> It should recover you - so this looks like a bug. I noticed in one of
>> the call traces this - drm_atomic_helper_suspend which points
Don't warn or fail if it's missing.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 6 --
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 28 ++---
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.
From: Colin Ian King
There are several statements that are incorrectly indented. Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c| 2 +-
drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
Oops, dropped the mailing ist from my reply, so again...
On Mon, Feb 11, 2019 at 4:01 PM Michel Dänzer wrote:
>
> On 2019-02-09 7:52 a.m., Mario Kleiner wrote:
> > In VRR mode, keep track of the vblank count of the last
> > completed pageflip in amdgpu_crtc->last_flip_vblank, as
> > recorded in t
I suspect the issue is that amdgpu_dm_do_flip is holding the BO reserved
and then stack waiting for fences to signal in
reservation_object_wait_timeout_rcu (which won't signal because there
was a VM_FAULT). Then when we try to shutdown display block during reset
recovery from drm_atomic_helper_
I pushed my patch series that simplifies eviction fence handling in KFD.
If you rebase this, it should be OK now.
Regards,
Felix
On 2019-02-04 7:42 a.m., Christian König wrote:
> Let's start to allocate VM PDs/PTs on demand instead of pre-allocating
> them during mapping.
>
> Signed-off-by: C
Don't warn or fail if it's missing.
v2: handle xgmi case more gracefully.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 9 ++--
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 28 ++---
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git
Am 11.02.19 um 22:52 schrieb Alex Deucher via amd-gfx:
This prevents us from accessing extended registers in tools like
umr. The register access functions already check if the offset
is beyond the BAR size and use the indirect accessors with locking
so this is safe.
Signed-off-by: Alex Deucher
Hi all,
Unfortunately, freedesktop.org's job of sending mail to a huge number
of people whilst pretending to be other people, has just got even
harder than it was.
fd.o can no longer (at least for the moment) send mail with the From
addresses of DMARC/DKIM/SPF-protected sender domains. When we try
On 2019-02-12 9:39 a.m., Mario Kleiner via dri-devel wrote:
> On Mon, Feb 11, 2019 at 4:01 PM Michel Dänzer wrote:
>>
>> On 2019-02-09 7:52 a.m., Mario Kleiner wrote:
>>> In VRR mode, keep track of the vblank count of the last
>>> completed pageflip in amdgpu_crtc->last_flip_vblank, as
>>> recorde
On Mon, Feb 11, 2019 at 7:44 PM Kazlauskas, Nicholas
wrote:
>
> On 2/11/19 10:01 AM, Michel Dänzer wrote:
> > On 2019-02-09 7:52 a.m., Mario Kleiner wrote:
> >> In VRR mode, keep track of the vblank count of the last
> >> completed pageflip in amdgpu_crtc->last_flip_vblank, as
> >> recorded in the
24 matches
Mail list logo
