Messages in this thread | | | From | Ard Biesheuvel <> | Date | Mon, 6 Aug 2018 14:22:00 +0200 | Subject | Re: framebuffer corruption due to overlapping stp instructions on arm64 |
| |
On 6 August 2018 at 14:19, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 6 August 2018 at 14:09, Mikulas Patocka <mpatocka@redhat.com> wrote: >> >> >> On Mon, 6 Aug 2018, Ard Biesheuvel wrote: >> >>> >> Are we talking about a quirk for the Armada 8040 or about PCIe on ARM >>> >> in general? >>> > >>> > I don't know - there are not any other easily available PCIe ARM boards >>> > except for Armada 8040. >>> >>> ... indeed, and sadly, the ones that are available all have this >>> horrible Synopsys DesignWare PCIe IP that does not implement a true >>> root complex at all, but is simply repurposed endpoint IP with some >>> tweaks so it vaguely resembles a root complex. >>> >>> But this is exactly why I am asking: I use a AMD Seattle Overdrive as >>> my main Linux development system, and it runs the gnome-shell stack >>> flawlessly (using the nouveau driver), as well as a UEFI framebuffer >>> using efifb. So my suspicion is that this is either a Synopsys IP >>> issue or an interconnect issue, and has nothing to do with the >>> impedance mismatch between AMBA and PCIe. >> >> If you run the program for testing memcpy on framebuffer that I posted in >> this thread - does it detect some corruption for you? >> > > I won't be able to check that for a while - I'm currently travelling. > >> >> BTW. does the Radeon GPU driver work for you? >> >> My observation is that OpenGL with Nouveau works, but it's slow and the >> whole system locks up when playing video in chromium. >>
Are you setting the pstate to auto? That helps a lot in my experience.
I.e.,
echo auto > /sys/kernel/debug/dri/0/pstate
| |