Screen flickering with 4k resolution on Prairie Falcon

Submitted by Kai-Heng Feng

Assigned to Default DRI bug account

Link to original bug (#112308)

Description

The issue is still there on amd-staging-drm-next branch.

The issue is gone with kernel parameter "iommu=off".

added AMDgpu bugzilla labels

Kai-Heng Feng uploaded an attachment:

Attachment 145984, "kernel message with iommu":
iommu

Kai-Heng Feng uploaded an attachment:

Attachment 145985, "kernel message without iommu":
no-iommu

Alex Deucher @agd5f submitted a patch:

Does this patch fix the issue?

Patch 145993, "fix test":
0001-pci-drop-stoney-quirk.patch

Kai-Heng Feng said:

(In reply to Alex Deucher from comment 3)

Created attachment 145993 [details] [review]
fix test

Does this patch fix the issue?

No, the same issue persists.

@agd5f In addition to the ATS quirk, I've also tried to revert .max_hdmi_pixel_clock from 300000 back to 594000, still doesn't help.

The problem is the IOMMU adds extra latency to device access to memory. IIRC, windows doesn't use the IOMMU.

Good to know that Windows doesn't use IOMMU.

I attempted to use PID and VID to disable IOMMU in amd_iommu_init.c, but seems like it's too late to disable IOMMU when PID and VID become available.

Is this still an issue on a a 5.4 kernel? There were several changes to use uncached memory for scatter gather display which may help.

Yes. Both latest amdgpu branch and drm-tip have this issue.

I guess there are two options:

1. disable IOMMU
2. disable S/G display

Disabling the IOMMU is probably the best option. Disabling S/G display support means all display buffers must be in carve out memory which many be really limited on some platforms.

1. disable IOMMU

Is it doable in AMDGPU? It doesn't seem to be trivial to do this in amd_iommu_init.c.

2. disable S/G display

Isn't S/G more efficient? Is there a way quick way to disable it?

You have do disable IOMMU in the bios or via kernel command line (iommu=pt or iommu=off). As for scatter/gather display, that allows the GPU to use buffers in system memory for display rather than just carve out (vram). On systems with limited carve out, this limits the size and number of displays which can be supported. There is no direct way to disable S/G display support. It only works with DC, so disabling DC (amdgpu.dc=0) will disable S/G display support.

bug961.diff

Here is a patch to disable S/G display.

dmesg

[ 6.127359] amdgpu 0000:00:01.0: 00000000a69ee0b2 pin failed
[ 6.127598] [drm:dm_plane_helper_prepare_fb [amdgpu]] ERROR Failed to pin framebuffer with error -12

Graphical session doesn't start with the patch.

You don't have enough free vram (carve out). Your system only has 80M: [ 5.034496] [drm] Detected VRAM RAM=80M, BAR=80M

There's a setting in BIOS to vram size. If it's set to bigger size like 256M, in conjunction with your patch there's no flickering.

However with bigger vram size there's also no flickering without your patch.

Windows works fine though with the default vram size.

With the bigger vram size, the display buffers end up in vram rather than system ram so it doesn't matter if S/G display is enabled or not. We only use S/G display when there is not enough vram to support the requested display surfaces. Windows doesn't use the IOMMU, that's why it works regardless of the vram size.

So how does Windows know IOMMU shouldn't be enabled on Stoney Ridge/Prairie Falcon? Or should I raise the issue to IOMMU mailing list?

It doesn't use the IOMMU at all AFAIK.

Hi Kai-Heng,

I saw this iommu email thread: https://lists.linuxfoundation.org/pipermail/iommu/2019-December/040544.html

It sounds like that there is a configuration issue about IVMD (I/O Virtualization Memory Definition) in ACPI table.

Could you please try the following patch: https://lists.linuxfoundation.org/pipermail/iommu/2019-November/040195.html

And, this patch applies the identity mapping (just like what Christoph Hellwig mentioned).

-- Adrian

Unfortunately the patch doesn't help. The system in question doesn't have any IVMD_FLAG_EXCL_RANGE flagged.

That said, I wonder if you know how to use set_device_exclusion_range() to exclude one PCI device from IOMMU?

If the IVMD_FLAG_EXCL_RANGE is not flagged, set_device_exclusion_range() is never called.

AMD IOMMU allows device accesses that target addresses in the exclusion range (set_device_exclusion_range()) are neither translated nor access checked if the EX bit in the Device Table is set for the device, which means the addresses of the exclusion range are identity-mapped. And, the IVRS (I/O Virtualization Reporting Structure) table of ACPI should define the corresponding IVMD entry with exclusion range. So, set_device_exclusion_range() is not used to exclude one PCI device from IOMMU. When enabling IOMMU, all target addresses should be translated by IOMMU except for the exclusion range configured by set_device_exclusion_range().

BTW, may I have the acpi table and lspci log to check?

[Reference] https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf

Yes, I know that set_device_exclusion_range() can't exclude one PCI device from IOMMU, but I guess it's still possible to achieve that if we can get the calculate the range and use a modified version of set_device_exclusion_range() to ignore the flag.

acpidump

Fix: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3dfee47b215e49788cfc80e474820ea2e948c031

Seems like I can't close the bug.

closed