Thermal control is performed by PMFW. What handled in driver is
just whether or not to enable the alert(to driver).
Change-Id: Icf857054b74f021e7fee2bf3aa9b314aa0d5ef09
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 8
drivers/gpu/drm/amd/powerplay/arcturu
Also the new logics for MP1 SW IRQs disablement/enablement are added.
Change-Id: I57ef8f21ab3d51aa0d557f511d89f5fa2ce08144
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 79 ---
1 file changed, 57 insertions(+), 22 deletions(-)
diff --git a/drivers/
Added missing thermal IRQs disablement on suspend.
Change-Id: I959a1d56930de434cc8534334220d3faeadf79f8
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
b/drivers/gpu/drm/
Well we still need implicit sync or otherwise the GPU scheduler would
pick up the jobs in the wrong order.
See without this when we have the following sequence of submission:
Client IB1 using buffer A
Client IB2
X IB1 using buffer A
We could end up with the execution order
X IB1 using buffer
On 2020-05-28 11:11 a.m., Christian König wrote:
> Well we still need implicit sync [...]
Yeah, this isn't about "we don't want implicit sync", it's about "amdgpu
doesn't ensure later jobs fully see the effects of previous implicitly
synced jobs", requiring userspace to do pessimistic flushing.
Hi,
Why can't virtual_display be used along with a physical display?
I see from here: https://bugzilla.kernel.org/show_bug.cgi?id=203339 that the
intention of the virtual_display module option is to allow for virtual displays
and purposely disable physical/real displays.
Is there a technical li
Ping?
On Wed, May 27, 2020 at 6:52 PM Alex Deucher wrote:
>
> Otherwise we disable sysfs/debugfs access with runtime pm.
>
> Fixes: f7c8d853b029df ("drm/amdgpu/pm: return an error during GPU reset or
> suspend")
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 114
I still think we should just drop the reduction loop.
The problem with checking plane_state at all is that this logic will
always be broken - plane_state isn't a good indicator of whether the
stream is blanked or not since we can leave an OTG running with no
planes at all while unblanked.
Re
[AMD Public Use]
Series is:
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Thursday, May 28, 2020 5:02 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH 1/3] drm/amd/powerplay: stop thermal IRQs on suspend
Added missin
On 2020-05-12 10:59, Daniel Vetter wrote:
Design is similar to the lockdep annotations for workers, but with
some twists:
- We use a read-lock for the execution/worker/completion side, so that
this explicit annotation can be more liberally sprinkled around.
With read locks lockdep isn't go
Fix the fru eeprom header guard and include it in the .c file.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.h | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/
This reverts commit 96cb7cf13d8530099c256c053648ad576588c387.
This change was used for DCN2 bringup and is no longer desired.
In fact it breaks backlight on DCN2 systems.
Cc: Alexander Monakov
Cc: Hersen Wu
Cc: Anthony Koo
Cc: Michael Chiu
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/a
Am 27.05.20 um 02:57 schrieb Yong Zhao:
Use words insteads of acronym for better understanding.
Signed-off-by: Yong Zhao
Good idea, Reviewed-by: Christian König
---
include/uapi/drm/amdgpu_drm.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/uapi/
The logic for blanked is not the same as having a plane_state. Technically
you can drive an OTG without anything connected in the front end and it'll
just draw out the back color which is distinct from having the OTG be blanked.
If we add planes or unblank the OTG later then we'll still want the
sy
On 2020-05-28 9:54 a.m., Alexander Monakov wrote:
>
>
> On Thu, 28 May 2020, Harry Wentland wrote:
>
>> This reverts commit 96cb7cf13d8530099c256c053648ad576588c387.
>>
>> This change was used for DCN2 bringup and is no longer desired.
>> In fact it breaks backlight on DCN2 systems.
>
> Reporte
On Thu, 28 May 2020, Harry Wentland wrote:
> This reverts commit 96cb7cf13d8530099c256c053648ad576588c387.
>
> This change was used for DCN2 bringup and is no longer desired.
> In fact it breaks backlight on DCN2 systems.
Reported-and-tested-by: Alexander Monakov
Thanks.
> Cc: Alexander Mo
On Thu, May 28, 2020 at 9:47 AM Harry Wentland wrote:
>
> This reverts commit 96cb7cf13d8530099c256c053648ad576588c387.
>
> This change was used for DCN2 bringup and is no longer desired.
> In fact it breaks backlight on DCN2 systems.
>
> Cc: Alexander Monakov
> Cc: Hersen Wu
> Cc: Anthony Koo
On 2020-05-28 10:08 a.m., Alex Deucher wrote:
On Thu, May 28, 2020 at 9:47 AM Harry Wentland wrote:
This reverts commit 96cb7cf13d8530099c256c053648ad576588c387.
This change was used for DCN2 bringup and is no longer desired.
In fact it breaks backlight on DCN2 systems.
Cc: Alexander Monakov
On Thu, 28 May 2020, Harry Wentland wrote:
> On 2020-05-28 9:54 a.m., Alexander Monakov wrote:
> >
> >
> > On Thu, 28 May 2020, Harry Wentland wrote:
> >
> >> This reverts commit 96cb7cf13d8530099c256c053648ad576588c387.
> >>
> >> This change was used for DCN2 bringup and is no longer desire
On Thu, May 28, 2020 at 3:37 PM Thomas Hellström (Intel)
wrote:
>
> On 2020-05-12 10:59, Daniel Vetter wrote:
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> >this explicit
On 2020-05-28 10:13 a.m., Alexander Monakov wrote:
>
>
> On Thu, 28 May 2020, Harry Wentland wrote:
>
>> On 2020-05-28 9:54 a.m., Alexander Monakov wrote:
>>>
>>>
>>> On Thu, 28 May 2020, Harry Wentland wrote:
>>>
This reverts commit 96cb7cf13d8530099c256c053648ad576588c387.
Th
Am 28.05.20 um 12:06 schrieb Michel Dänzer:
On 2020-05-28 11:11 a.m., Christian König wrote:
Well we still need implicit sync [...]
Yeah, this isn't about "we don't want implicit sync", it's about "amdgpu
doesn't ensure later jobs fully see the effects of previous implicitly
synced jobs", requi
On Thu, May 28, 2020 at 10:40 AM Christian König
wrote:
> Am 28.05.20 um 12:06 schrieb Michel Dänzer:
> > On 2020-05-28 11:11 a.m., Christian König wrote:
> >> Well we still need implicit sync [...]
> > Yeah, this isn't about "we don't want implicit sync", it's about "amdgpu
> > doesn't ensure la
Am 28.05.20 um 18:06 schrieb Marek Olšák:
On Thu, May 28, 2020 at 10:40 AM Christian König
mailto:christian.koe...@amd.com>> wrote:
Am 28.05.20 um 12:06 schrieb Michel Dänzer:
> On 2020-05-28 11:11 a.m., Christian König wrote:
>> Well we still need implicit sync [...]
> Yeah, th
On Thu, May 28, 2020 at 2:12 PM Christian König
wrote:
> Am 28.05.20 um 18:06 schrieb Marek Olšák:
>
> On Thu, May 28, 2020 at 10:40 AM Christian König
> wrote:
>
>> Am 28.05.20 um 12:06 schrieb Michel Dänzer:
>> > On 2020-05-28 11:11 a.m., Christian König wrote:
>> >> Well we still need implici
On Thu, May 28, 2020 at 3:47 AM Ian Rogers wrote:
>
> Hi,
>
> Why can't virtual_display be used along with a physical display?
>
We've never had a use case to mix the two.
> I see from here: https://bugzilla.kernel.org/show_bug.cgi?id=203339 that the
> intention of the virtual_display module op
navi never supported the pci config reset. Neither did
vega.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c | 34 -
1 file changed, 34 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 61eea26922ce
Rather than relying on gpu info firmware.
Signed-off-by: Alex Deucher
---
Can someone test this on renoir?
drivers/gpu/drm/amd/amdgpu/soc15.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15
For access via ioctl for tools like umr and mesa.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 6655dd2009b6..61eea26922ce 100644
--- a/drivers/gpu/drm/a
Rather than checking of the variable is enabled and the
chip is the right family check for the presence of the
discovery table.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/a
gpu reset is implemented for navi so we can enable this.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 0f927fcff0d5..fd3b9e21a5bd 100
The GPU info firmware is only applicable at bring up when the
IP discovery table is not present. If it's available, use that
first and then fallback to parsing the gpu info firmware.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 13 ++---
1 file changed, 6
On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lock
On 2020-05-28 18:24, Colin King wrote:
From: Colin Ian King
Currently pointer pdd is being dereferenced when assigning pointer
dpm and then pdd is being null checked. Fix this by checking if
pdd is null before the dereference of pdd occurs.
Addresses-Coverity: ("Dereference before null check"
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Thursday, May 28, 2020 9:45 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/fru: fix header guard and inc
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Thursday, May 28, 2020 9:00 PM
To: amd-gfx list
Cc: Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu/pm: don't bail for in_suspend
Ping?
On
[AMD Official Use Only - Internal Distribution Only]
The series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Friday, May 29, 2020 05:35
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 6/6] drm/
[AMD Official Use Only - Internal Distribution Only]
Patch 1-4 are acked-by: Evan Quan
Patch 5,6 are reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Friday, May 29, 2020 5:35 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [
Use ip discovery GC table instead of gpu info firmware
for exporting gpu info to inquire interface.As Renoir discovery
has same version with Navi1x therefore just enable it same way
as Navi1x.
Signed-off-by: Prike.Liang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 23 ---
On Thu, May 28, 2020 at 11:54 PM Luben Tuikov wrote:
>
> On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> > this explicit annotati
From: Colin Ian King
Currently pointer pdd is being dereferenced when assigning pointer
dpm and then pdd is being null checked. Fix this by checking if
pdd is null before the dereference of pdd occurs.
Addresses-Coverity: ("Dereference before null check")
Fixes: 522b89c63370 ("drm/amdkfd: Track
41 matches
Mail list logo
