radeon ring 0 test failed on arm64

[Robin Murphy]

On 2021-05-25 14:05, Alex Deucher wrote:
> On Tue, May 25, 2021 at 8:56 AM Peter Geis <pgwipeout at gmail.com> wrote:
>>
>> On Tue, May 25, 2021 at 8:47 AM Alex Deucher <alexdeucher at gmail.com> wrote:
>>>
>>> On Tue, May 25, 2021 at 8:42 AM Peter Geis <pgwipeout at gmail.com> wrote:
>>>>
>>>> Good Evening,
>>>>
>>>> I am stress testing the pcie controller on the rk3566-quartz64 prototype SBC.
>>>> This device has 1GB available at <0x3 0x00000000> for the PCIe
>>>> controller, which makes a dGPU theoretically possible.
>>>> While attempting to light off a HD7570 card I manage to get a modeset
>>>> console, but ring0 test fails and disables acceleration.
>>>>
>>>> Note, we do not have UEFI, so all PCIe setup is from the Linux kernel.
>>>> Any insight you can provide would be much appreciated.
>>>
>>> Does your platform support PCIe cache coherency with the CPU?  I.e.,
>>> does the CPU allow cache snoops from PCIe devices?  That is required
>>> for the driver to operate.
>>
>> Ah, most likely not.
>> This issue has come up already as the GIC isn't permitted to snoop on
>> the CPUs, so I doubt the PCIe controller can either.
>>
>> Is there no way to work around this or is it dead in the water?
> 
> It's required by the pcie spec.  You could potentially work around it
> if you can allocate uncached memory for DMA, but I don't think that is
> possible currently.  Ideally we'd figure out some way to detect if a
> particular platform supports cache snooping or not as well.

There's device_get_dma_attr(), although I don't think it will work 
currently for PCI devices without an OF or ACPI node - we could perhaps 
do with a PCI-specific wrapper which can walk up and defer to the host 
bridge's firmware description as necessary.

The common DMA ops *do* correctly keep track of per-device coherency 
internally, but drivers aren't supposed to be poking at that information 
directly.

Robin.