[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.1808071010240.11209@file01.intranet.prod.int.rdu2.redhat.com>
Date: Tue, 7 Aug 2018 10:14:13 -0400 (EDT)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
cc: Florian Weimer <fweimer@...hat.com>,
Andrew Pinski <pinskia@...il.com>,
Richard Earnshaw <Richard.Earnshaw@....com>,
Ramana Radhakrishnan <ramana.gcc@...glemail.com>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
GNU C Library <libc-alpha@...rceware.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Russell King <linux@...linux.org.uk>,
LKML <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: framebuffer corruption due to overlapping stp instructions on
arm64
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> No that works fine for me. VDPAU acceleration works as well, but it
> depends on your chromium build whether it can actually use it, I
> think? In any case, mplayer can use vdpau to play 1080p h264 without
> breaking a sweat on this system.
>
> Note that the VDPAU driver also relies on memory semantics, i.e., it
> may use DC ZVA (zero cacheline) instructions which are not permitted
> on device mappings. This is probably just glibc's memset() being
> invoked, but I remember hitting this on another PCIe-impaired arm64
> system with Synopsys PCIe IP
DC ZVA can be disabled with the SCTRL_EL1.DZE bit, so that neither kernel
nor userspace will use it. If the mapping didn't support unaligned writes,
it would be worse.
Mikulas
Powered by blists - more mailing lists