From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Tue, 28 Oct 2014 12:23:24 +0000 Subject: [PATCH] ARM: supplementing IO accessors with 64 bit capability In-Reply-To: References: <1413993983-17310-1-git-send-email-mathieu.poirier@linaro.org> <20141022164454.GI15370@e104818-lin.cambridge.arm.com> <20141024092832.GD20534@e104818-lin.cambridge.arm.com> <20141024161634.GG20534@e104818-lin.cambridge.arm.com> <20141027155444.GW8768@arm.com> Message-ID: <20141028122324.GB12136@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Oct 27, 2014 at 10:14:41PM +0000, Mathieu Poirier wrote: > On 27 October 2014 09:54, Will Deacon wrote: > > On Fri, Oct 24, 2014 at 05:16:34PM +0100, Catalin Marinas wrote: > >> As I said, it's confusing. Anyway, you can go ahead and add the > >> readq/writeq for ARMv6 and later, though it won't be guaranteed to have > >> a 64-bit access, it depends on the bus. > > > > I'm really not comfortable with this... we don't make any guarantees for > > 32-bit CPUs that a double-word access will be single-copy atomic for MMIO. > > That means it could be subjected to things like reordering and merging, > > which I think means that it depends on both the bus *and* the endpoint as to > > whether or not this will work. Worse still, the endpoint could decide to > > return a SLVERR, which would appear as an external abort. > > I agree on all of the point you bring up. The person using these > should know their architecture and the target endpoint support this > kind of access. If they don't then a problem will show up pretty > quickly. That goes against the I/O abstractions provided by the kernel to allow for portable device drivers. readq/writeq *must* have some portable semantics and I don't think that we should implement them on a best-effort basis in io.h. > > > > Is it not possible to use 32-bit MMIO accesses for this driver? > > Sure it is but we wouldn't be using the HW to it's full capability. > Another solution is to move the accessors to the driver itself where > nobody else in the 32 bit world will have access to them. Russell, > what you're opinion on that? FWIW, I'd much prefer that, but I'd be interested to know how much of a a couple of {read,write}l_relaxed operations really cost you by comparison. Will