[AMD Official Use Only - Internal Distribution Only]
Yes.
These two APIs get called only during hw/smu initialization. And although there
needs hw initialization also on resume/gpu reset.
They share no race conditions(there cannot be another gpu reset/resume unless
current gpu reset/resume done)
UVD dependent jobs should run on the same udv instance.
This patch disables gpu scheduler's load balancer for
a context which binds jobs from same the context to a udv
instance.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 +++-
1 file changed, 3 insertions(+), 1 del
Am 31.08.20 um 12:45 schrieb Nirmoy Das:
UVD dependent jobs should run on the same udv instance.
This patch disables gpu scheduler's load balancer for
a context which binds jobs from same the context to a udv
instance.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gp
Am 28.08.20 um 18:05 schrieb Andrey Grodzovsky:
Add DPC handlers with basic recovery functionality.
v2: remove pci_save_state to avoid breaking suspend/resume
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 9 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
On Mon, Aug 31, 2020 at 6:41 AM Nirmoy Das wrote:
>
> UVD dependent jobs should run on the same udv instance.
> This patch disables gpu scheduler's load balancer for
> a context which binds jobs from same the context to a udv
> instance.
typos: udv -> uvd
With that fixed:
Reviewed-by: Alex Deuche
On 8/28/20 3:23 PM, Alex Deucher wrote:
On Fri, Aug 28, 2020 at 12:06 PM Andrey Grodzovsky
wrote:
Add DPC handlers with basic recovery functionality.
v2: remove pci_save_state to avoid breaking suspend/resume
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h
On 8/28/20 10:07 PM, Luben Tuikov wrote:
On 2020-08-26 10:46, Andrey Grodzovsky wrote:
Add DPC handlers with basic recovery functionality.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 9 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 181 +++
On Mon, Aug 31, 2020 at 10:26 AM Andrey Grodzovsky
wrote:
>
>
> On 8/28/20 3:23 PM, Alex Deucher wrote:
> > On Fri, Aug 28, 2020 at 12:06 PM Andrey Grodzovsky
> > wrote:
> >> Add DPC handlers with basic recovery functionality.
> >>
> >> v2: remove pci_save_state to avoid breaking suspend/resume
>
Hi Alex,
On 8/31/20 4:17 PM, Alex Deucher wrote:
On Mon, Aug 31, 2020 at 6:41 AM Nirmoy Das wrote:
UVD dependent jobs should run on the same udv instance.
This patch disables gpu scheduler's load balancer for
a context which binds jobs from same the context to a udv
instance.
typos: udv -> uv
On 8/28/20 10:03 PM, Luben Tuikov wrote:
On 2020-08-26 10:46, Andrey Grodzovsky wrote:
At this point the ASIC is already post reset by the HW/PSP
so the HW not in proper state to be configured for suspension,
some bloks might be even gated and so best is to avoid touching it.
"blocks"
Signe
On 8/28/20 10:16 PM, Luben Tuikov wrote:
On 2020-08-26 10:46, Andrey Grodzovsky wrote:
DPC recovery involves ASIC reset just as normal GPU recovery so block
SW GPU shcedulers and wait on all concurent GPU resets.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.
From: Jaehyun Chung
[ Upstream commit b61f05622ace5b9498ae279cdfd1c9f0c1ce3f75 ]
[Why]
Revert HDCP disable sequence change that blanks stream before
disabling HDCP. PSP and HW teams are currently investigating the
root cause of why HDCP cannot be disabled before stream blank,
which is expected t
From: Nicholas Kazlauskas
[ Upstream commit 168f09cdadbd547c2b202246ef9a8183da725f13 ]
[Why]
These aren't stable on some platform configurations when driving
multiple displays, especially on higher resolution.
In particular the delay in asserting p-state and validating from
x86 outweights any p
From: Tong Zhang
[ Upstream commit ed9ab229fea24cbcab17f484297dc8344afb7ea9 ]
core_link_read_dpcd returns only DC_OK(1) and DC_ERROR_UNEXPECTED(-1),
the caller should check error using DC_OK instead of checking against 0
Signed-off-by: Tong Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sas
From: Wayne Lin
[ Upstream commit ef67d792a2fc578319399f605fbec2f99ecc06ea ]
[Why]
In dm_dp_aux_transfer() now, we forget to handle AUX_WR fail cases. We
suppose every write wil get done successfully and hence some AUX
commands might not sent out indeed.
[How]
Check if AUX_WR success. If not, r
From: Samson Tam
[ Upstream commit efbde23a3b0164cef27fd394e7d548f46af5b51d ]
[Why]
dongle_type is set during dongle connection but for passive dongles,
dongle_type is not set. If user starts with an active dongle and
then switches to a passive dongle, it will still report as an active
dongle. T
From: Brandon Syu
[ Upstream commit cba4b52e431e5de3d8012281cfe194f1c39a9052 ]
[Why]
When system enters s3/s0i3, backlight PWM would set user level.
[How]
ABM disable function add keep current gain to avoid it.
Signed-off-by: Brandon Syu
Reviewed-by: Josip Pavic
Acked-by: Eryk Brol
Signed-o
From: Furquan Shaikh
[ Upstream commit 5896585512e5156482335e902f7c7393b940da51 ]
In `amdgpu_dm_update_backlight_caps()`, there is a local
`amdgpu_dm_backlight_caps` object that is filled in by
`amdgpu_acpi_get_backlight_caps()`. However, this object is
uninitialized before the call and hence th
From: Dinghao Liu
[ Upstream commit b67a468a4ccef593cd8df6a02ba3d167b77f0c81 ]
When amdgpu_display_modeset_create_props() fails, state and
state->context should be freed to prevent memleak. It's the
same when amdgpu_dm_audio_init() fails.
Signed-off-by: Dinghao Liu
Signed-off-by: Alex Deucher
From: Dinghao Liu
[ Upstream commit b67a468a4ccef593cd8df6a02ba3d167b77f0c81 ]
When amdgpu_display_modeset_create_props() fails, state and
state->context should be freed to prevent memleak. It's the
same when amdgpu_dm_audio_init() fails.
Signed-off-by: Dinghao Liu
Signed-off-by: Alex Deucher
From: Wayne Lin
[ Upstream commit ef67d792a2fc578319399f605fbec2f99ecc06ea ]
[Why]
In dm_dp_aux_transfer() now, we forget to handle AUX_WR fail cases. We
suppose every write wil get done successfully and hence some AUX
commands might not sent out indeed.
[How]
Check if AUX_WR success. If not, r
From: Nicholas Kazlauskas
[ Upstream commit 168f09cdadbd547c2b202246ef9a8183da725f13 ]
[Why]
These aren't stable on some platform configurations when driving
multiple displays, especially on higher resolution.
In particular the delay in asserting p-state and validating from
x86 outweights any p
From: Furquan Shaikh
[ Upstream commit 5896585512e5156482335e902f7c7393b940da51 ]
In `amdgpu_dm_update_backlight_caps()`, there is a local
`amdgpu_dm_backlight_caps` object that is filled in by
`amdgpu_acpi_get_backlight_caps()`. However, this object is
uninitialized before the call and hence th
Wait for HW/PSP initiated ASIC reset to complete before
starting the recovery operations.
v2: Remove typo
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
dif
DPC recovery involves ASIC reset just as normal GPU recovery so blosk
SW GPU schedulers and wait on all concurrent GPU resets.
Signed-off-by: Andrey Grodzovsky
Acked-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 57 +++---
1 file changed, 53 insertion
XGMI support is more complicated then single device support as
questions of synchronization between the device recovering from
PCI error and other members of the hive is required.
Leaving this for next round.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amd
Reuse exsisting functions from GPU recovery to avoid code
duplications.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 73 +-
1 file changed, 12 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/
Cache the PCI state on boot and before each case were we might
loose it.
v2: Add pci_restore_state while caching the PCI state to avoid
breaking PCI core logic for stuff like suspend/resume.
v3: Extract pci_restore_state from amdgpu_device_cache_pci_state
to avoid superflous restores during GPU r
Many PCI bus controllers are able to detect a variety of hardware PCI errors on
the bus,
such as parity errors on the data and address buses, A typical action taken is
to disconnect
the affected device, halting all I/O to it. Typically, a reconnection mechanism
is also offered,
so that the a
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index fe720c2..16c7842 100644
--- a/drivers/gpu/drm/am
At this point the ASIC is already post reset by the HW/PSP
so the HW not in proper state to be configured for suspension,
some blocks might be even gated and so best is to avoid touching it.
v2: Rename in_dpc to more meaningful name
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Alex Deucher
---
Add DPC handlers with basic recovery functionality.
v2: remove pci_save_state to avoid breaking suspend/resume
v3: Fix style comments
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 9 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 162 ++
Hi Andrey,
I need to understand more about pci saved state. So excluding patch 5
the series is Acked-by: Nirmoy Das .
Regards,
Nirmoy
On 8/31/20 5:50 PM, Andrey Grodzovsky wrote:
Many PCI bus controllers are able to detect a variety of hardware PCI errors on
the bus,
such as parity err
On Mon, Aug 31, 2020 at 10:55 AM Nirmoy wrote:
>
> Hi Alex,
>
> On 8/31/20 4:17 PM, Alex Deucher wrote:
> > On Mon, Aug 31, 2020 at 6:41 AM Nirmoy Das wrote:
> >> UVD dependent jobs should run on the same udv instance.
> >> This patch disables gpu scheduler's load balancer for
> >> a context whic
On 2020-08-28 3:26 p.m., Alex Deucher wrote:
> On Fri, Aug 28, 2020 at 12:06 PM Andrey Grodzovsky
> wrote:
>>
>> At this point the ASIC is already post reset by the HW/PSP
>> so the HW not in proper state to be configured for suspension,
>> some bloks might be even gated and so best is to avoid to
On 2020-08-31 11:50 a.m., Andrey Grodzovsky wrote:
> Add DPC handlers with basic recovery functionality.
>
When this goes into the kernel log, it would
be quite unclear what "DPC" stands for,
as it is used undefined in this patch and this
patchset.
I'd write,
Add PCI Downstream Port Con
On 2020-08-31 11:50 a.m., Andrey Grodzovsky wrote:
> Add DPC handlers with basic recovery functionality.
>
> v2: remove pci_save_state to avoid breaking suspend/resume
> v3: Fix style comments
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 9 ++
> dr
On 2020-08-31 11:50 a.m., Andrey Grodzovsky wrote:
> DPC recovery involves ASIC reset just as normal GPU recovery so blosk
Again, typo: "blosk" --> "blocks".
> SW GPU schedulers and wait on all concurrent GPU resets.
>
> Signed-off-by: Andrey Grodzovsky
> Acked-by: Alex Deucher
> ---
> driver
On 2020-08-31 11:50 a.m., Andrey Grodzovsky wrote:
> Cache the PCI state on boot and before each case were we might
> loose it.
Typo: "were" --> "where".
>
> v2: Add pci_restore_state while caching the PCI state to avoid
> breaking PCI core logic for stuff like suspend/resume.
>
> v3: Extract p
On 2020-08-31 11:50 a.m., Andrey Grodzovsky wrote:
> XGMI support is more complicated then single device support as
Typo: "then" --> "than".
> questions of synchronization between the device recovering from
> PCI error and other members of the hive is required.
Typo: "is" --> "are", as the subje
On 2020-08-31 1:39 p.m., Alex Deucher wrote:
On Mon, Aug 31, 2020 at 10:55 AM Nirmoy wrote:
Hi Alex,
On 8/31/20 4:17 PM, Alex Deucher wrote:
On Mon, Aug 31, 2020 at 6:41 AM Nirmoy Das wrote:
UVD dependent jobs should run on the same udv instance.
This patch disables gpu scheduler's load b
On Mon, Aug 31, 2020 at 5:50 PM Leo Liu wrote:
>
>
> On 2020-08-31 1:39 p.m., Alex Deucher wrote:
> > On Mon, Aug 31, 2020 at 10:55 AM Nirmoy wrote:
> >> Hi Alex,
> >>
> >> On 8/31/20 4:17 PM, Alex Deucher wrote:
> >>> On Mon, Aug 31, 2020 at 6:41 AM Nirmoy Das wrote:
> UVD dependent jobs s
On 8/31/20 5:00 PM, Luben Tuikov wrote:
On 2020-08-31 11:50 a.m., Andrey Grodzovsky wrote:
DPC recovery involves ASIC reset just as normal GPU recovery so blosk
Again, typo: "blosk" --> "blocks".
SW GPU schedulers and wait on all concurrent GPU resets.
Signed-off-by: Andrey Grodzovsky
Ack
On 2020-08-31 5:53 p.m., Alex Deucher wrote:
On Mon, Aug 31, 2020 at 5:50 PM Leo Liu wrote:
On 2020-08-31 1:39 p.m., Alex Deucher wrote:
On Mon, Aug 31, 2020 at 10:55 AM Nirmoy wrote:
Hi Alex,
On 8/31/20 4:17 PM, Alex Deucher wrote:
On Mon, Aug 31, 2020 at 6:41 AM Nirmoy Das wrote:
UVD
When GPU is in reset, its status isn't stable and ring buffer also need
be reset when resuming. Therefore driver should protect GPU recovery
thread from ring buffer accessed by other threads. Otherwise GPU will
randomly hang during recovery.
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/
The crash log as the below:
[Thu Aug 20 23:18:14 2020] general protection fault: [#1] SMP NOPTI
[Thu Aug 20 23:18:14 2020] CPU: 152 PID: 1837 Comm: kworker/152:1 Tainted: G
OE 5.4.0-42-generic #46~18.04.1-Ubuntu
[Thu Aug 20 23:18:14 2020] Hardware name: GIGABYTE G482-Z53-YF/MZ5
On 8/31/20 9:17 PM, Dennis Li wrote:
When GPU is in reset, its status isn't stable and ring buffer also need
be reset when resuming. Therefore driver should protect GPU recovery
thread from ring buffer accessed by other threads. Otherwise GPU will
randomly hang during recovery.
Signed-off-by:
[AMD Official Use Only - Internal Distribution Only]
Hi, Andrey,
RE- Isn't adev->reset_sem non-recursive ? How this works when you try to access
registers from within GPU reset thread while adev->reset_sem is already write
locked from amdgpu_device_lock_adev earlier in the same thread ?
De
From: Hans Verkuil
Signed-off-by: Hans Verkuil
[sa...@chromium.org:
- rebased
- removed polling-related changes
- moved the calls to drm_dp_cec_(un)set_edid() into the next patch
]
Signed-off-by: Sam McNally
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/drm/drm_dp_
49 matches
Mail list logo
