Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 2 Aug 2018 15:31:15 -0400 (EDT)
From:   Mikulas Patocka <mpatocka@redhat.com>
To:     Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will.deacon@arm.com>,
        Russell King <linux@armlinux.org.uk>,
        Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
cc:     linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        libc-alpha@sourceware.org
Subject: framebuffer corruption due to overlapping stp instructions on
 arm64
Message-ID: <alpine.LRH.2.02.1808021242320.31834@file01.intranet.prod.int.rdu2.redhat.com>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi

I tried to use a PCIe graphics card on the MacchiatoBIN board and I hit a 
strange problem.

When I use the links browser in graphics mode on the framebuffer, I get 
occasional pixel corruption. Links does memcpy, memset and 4-byte writes 
on the framebuffer - nothing else.

I found out that the pixel corruption is caused by overlapping unaligned 
stp instructions inside memcpy. In order to avoid branching, the arm64 
memcpy implementation may write the same destination twice with different 
alignment. If I put "dmb sy" between the overlapping stp instructions, the 
pixel corruption goes away.

This seems like a hardware bug. Is it a known errata? Do you have any 
workarounds for it?

I tried AMD card (HD 6350) and NVidia (NVS 285) and both exhibit the same 
corruption. OpenGL doesn't work (it results in artifacts on the AMD card 
and lock-up on the NVidia card), but it's quite expected if even simple 
writing to the framebuffer doesn't work.

Mikulas