From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752979AbcGSKnU (ORCPT ); Tue, 19 Jul 2016 06:43:20 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:55211 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752573AbcGSKnR (ORCPT ); Tue, 19 Jul 2016 06:43:17 -0400 From: Arnd Bergmann To: Cyrille Pitchen Cc: Brian Norris , linux-mtd@lists.infradead.org, nicolas.ferre@atmel.com, boris.brezillon@free-electrons.com, marex@denx.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mtd: atmel-quadspi: add driver for Atmel QSPI controller Date: Tue, 19 Jul 2016 12:42:42 +0200 Message-ID: <3594494.0P5B8Rztl3@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <512741bf-9dce-90f3-d969-3d3cb167fe25@atmel.com> References: <1715321.52KD2CMTqu@wuerfel> <512741bf-9dce-90f3-d969-3d3cb167fe25@atmel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:0GdjWywvc3F0rODwbWKeKk+cK4HnoxYtADgmkVPTumGX5PwQwNR mKryFIXwJWgyNfiejVTgRvYQ/ZhRtMwEtkvX12LsoSsQyg6RGrAvaNkeyzxOqOn9jrr25rR Utq2V/db90JlMe9f00fFUrrqHPnUPkmIQltSrplE9c9cM32S/Gxg/XLEAyFMwM3U4DtAJ6s f821GQu8NQv+Mr78XDPYw== X-UI-Out-Filterresults: notjunk:1;V01:K0:rv9ASPmffpA=:ELKUmj8q2R8NzE7g+90P3j O5Fsof+nRgqA2vVz+2Lz+WWpvfI9XT16abUIFkRRfMktRZOxyJ1XlFY9IfI9ppHKxY1KBiSsj CBzIGsf4hAcodi1D6EBanUxK8FQ45WNk3JIoFWazoElexGOvlHbFL74KTShkkLWpTIu43pzcl vc0KLiV9VDpgjTh3RKnuKqVGHJqW10cMukcvM9JUPgmltMIHzsR783alLjpyy+EtoAmZgN7Qj ELNas1nCrY79zsa1VK7nRU5ct36kx0dKVv3OSDYukrEari2MfdiAh0v3AWQ2HAZ3ZSyrkULZ2 dzORnVmtvz/b5gqfVQlyBgqKRMenhSBIR31ARKMaD08TBTJIldCv4rpuAVY5QcIs/m+8+dCLX 24IFOiqkD9UI+e8KJ+KzweL5ii644a50XpxkhfU/oBQXBWrGi8U+Ad4+ZgFXXGS6ZLwbV9rM8 qnSE1Oh2JiMrJFSjJoiBwgpwYC8bfwaXltWvCUZoYi/u3PlRa/h7f2nEPpUmhieXxIYPkGtY4 T8NDaT9WQZ8+hBB+aGOUYMKGTQwV2ZDNv9IBOzIHGOvIYfMyapkkgG6c+azGCOxkMRrG3bZLV wEf8zm7fsSeX3L2+TYDLShr1vofiHBg7hjfOI3r/PONLag9EHrQV3CAG3+Qs4aMBWHvIh0py7 Dz1+ZglXfnLWB2cMp6Hj5ICjX86TF9ufhb+ONippKuFHepTZGWCHxzLyHTkdP88Qe/tHLAJzg 5poV0DHEyeBZ/mQF Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, July 19, 2016 12:03:11 PM CEST Cyrille Pitchen wrote: > > Indeed I added the ARM dependency for the COMPILE_TEST case only for > _memcpy_toio() and _memcpy_fromio(). I thought it would be enough. > > Also, I use _memcpy_toio() and _memcpy_fromio() on purpose as opposed to > memcpy_toio() and mempcy_fromio(). I've tested the two latest functions quite > a long time ago and it didn't work. If I remember, on our architecture, > memcpy_toio() and memcpy_fromio() are simply implemented with the regular > memcpy(). They are implemented using "mmiocpy" when CONFIG_BIG_ENDIAN is not set. mmiocpy is an alias for the out-of-line memcpy() implementation, but it's different from calling memcpy() as the compiler can decide to replace small memcpy with a pointer dereference, and that can be unaligned on ARMv7 for non-MMIO pointers. > The additional memory barriers inserted by readb() and writeb() seems to be > needed to guarantee the IO accesses are not reordered on the system bus. Those barriers should not be needed at all, I've never seen an I/O bus that reorders consecutive reads to the same address range. > In the atmel-quadspi.c driver, there is a comment on the use of memcpy(): > /* Then fallback to a PIO transfer (memcpy() DOES NOT work!) */ Please try again, I think this was fixed with commit 1bd46782d08b01b73df0085b51ea1021b19b44fd Author: Russell King Date: Fri Jul 3 15:22:54 2015 +0100 ARM: avoid unwanted GCC memset()/memcpy() optimisations for IO variants We don't want GCC optimising our memset_io(), memcpy_fromio() or memcpy_toio() variants, so we must not call one of the standard functions. Provide a separate name for our assembly memcpy() and memset() functions, and use that instead, thereby bypassing GCC's ability to optimise these operations. GCCs optimisation may introduce unaligned accesses which are invalid for device mappings. Signed-off-by: Russell King Arnd