linux-stable.git/drivers/gpu/drm/amd/amdgpu/amdgpu.h, branch linux-5.16.y

drm/amd: add support to check whether the system is set to s3

2022-02-23T11:05:51+00:00

[ Upstream commit f52a2b8badbd24faf73a13c9c07fdb9d07352944 ]

This will be used to help make decisions on what to do in
misconfigured systems.

v2: squash in semicolon fix from Stephen Rothwell

Signed-off-by: Mario Limonciello 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd: Warn users about potential s0ix problems

2022-02-23T11:05:51+00:00

[ Upstream commit a6ed2035878e5ad2e43ed175d8812ac9399d6c40 ]

On some OEM setups users can configure the BIOS for S3 or S2idle.
When configured to S3 users can still choose 's2idle' in the kernel by
using `/sys/power/mem_sleep`.  Before commit 6dc8265f9803 ("drm/amdgpu:
always reset the asic in suspend (v2)"), the GPU would crash.  Now when
configured this way, the system should resume but will use more power.

As such, adjust the `amdpu_acpi_is_s0ix function` to warn users about
potential power consumption issues during their first attempt at
suspending.

Reported-by: Bjoren Dasse 
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1824
Reviewed-by: Alex Deucher 
Signed-off-by: Mario Limonciello 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu: disable runpm if we are the primary adapter

2021-12-31T13:57:45+00:00

If we are the primary adapter (i.e., the one used by the firwmare
framebuffer), disable runtime pm.  This fixes a regression caused
by commit 55285e21f045 which results in the displays waking up
shortly after they go to sleep due to the device coming out of
runtime suspend and sending a hotplug uevent.

v2: squash in reworked fix from Evan

Fixes: 55285e21f045 ("fbdev/efifb: Release PCI device's runtime PM ref during FB destroy")
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215203
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1840
Signed-off-by: Alex Deucher

drm/amdgpu: Add kernel parameter support for ignoring bad page threshold

2021-10-28T18:26:12+00:00

When a GPU hits the bad_page_threshold, it will not be initialized by
the amdgpu driver. This means that the table cannot be cleared, nor can
information gathering be performed (getting serial number, BDF, etc).

If the bad_page_threshold kernel parameter is set to -2,
continue to initialize the GPU, while printing a warning to dmesg that
this action has been done

v2: squash in Luben's fix to restore RAS info reporting

Cc: Luben Tuikov 
Cc: Mukul Joshi 
Signed-off-by: Kent Russell 
Acked-by: Felix Kuehling 
Reviewed-by: Luben Tuikov 
Signed-off-by: Alex Deucher

drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume

2021-10-05T16:23:56+00:00

In current code, when a PCI error state pci_channel_io_normal is detectd,
it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI
driver will continue the execution of PCI resume callback report_resume by
pci_walk_bridge, and the callback will go into amdgpu_pci_resume
finally, where write lock is releasd unconditionally without acquiring
such lock first. In this case, a deadlock will happen when other threads
start to acquire the read lock.

To fix this, add a member in amdgpu_device strucutre to cache
pci_channel_state, and only continue the execution in amdgpu_pci_resume
when it's pci_channel_io_frozen.

Fixes: c9a6b82f45e2 ("drm/amdgpu: Implement DPC recovery")
Suggested-by: Andrey Grodzovsky 
Signed-off-by: Guchun Chen 
Reviewed-by: Andrey Grodzovsky 
Signed-off-by: Alex Deucher

drm/amdgpu: revert "Add autodump debugfs node for gpu reset v8"

2021-10-05T16:22:36+00:00

This reverts commit 728e7e0cd61899208e924472b9e641dbeb0775c4.

Further discussion reveals that this feature is severely broken
and needs to be reverted ASAP.

GPU reset can never be delayed by userspace even for debugging or
otherwise we can run into in kernel deadlocks.

Signed-off-by: Christian König 
Acked-by: Alex Deucher 
Acked-by: Nirmoy Das 
Signed-off-by: Alex Deucher

drm/amdgpu: convert IP version array to include instances

2021-10-04T19:23:01+00:00

Allow us to query instances versions more cleanly.

Instancing support is not consistent unfortunately. SDMA is a
good example.  Sienna cichlid has 4 total SDMA instances, each
enumerated separately (HWIDs 42, 43, 68, 69).  Arcturus has 8
total SDMA instances, but they are enumerated as multiple
instances of the same HWIDs (4x HWID 42, 4x HWID 43).  UMC
is another example.  On most chips there are multiple
instances with the same HWID.  This allows us to support both
forms.

v2: rebase
v3: clarify instancing support

Reviewed-by: Christian König 
Signed-off-by: Alex Deucher

drm/amdgpu: add VCN1 hardware IP

2021-10-04T19:23:01+00:00

So we can store the VCN IP revision for each instance of VCN.

Acked-by: Christian König 
Signed-off-by: Alex Deucher

drm/amdgpu: add DCI HWIP

2021-10-04T19:22:59+00:00

So we can track grab the appropriate DCE info out of the
IP discovery table.  This is a separare IP from DCN.

Acked-by: Harry Wentland 
Acked-by: Christian König 
Signed-off-by: Alex Deucher

drm/amdgpu: add XGMI HWIP

2021-10-04T19:22:58+00:00

So we can track grab the appropriate XGMI info out of the
IP discovery table.

Reviewed-by: Christian König 
Signed-off-by: Alex Deucher