Messages in this thread | | | Date | Tue, 28 Oct 2014 12:23:24 +0000 | From | Will Deacon <> | Subject | Re: [PATCH] ARM: supplementing IO accessors with 64 bit capability |
| |
On Mon, Oct 27, 2014 at 10:14:41PM +0000, Mathieu Poirier wrote: > On 27 October 2014 09:54, Will Deacon <will.deacon@arm.com> 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
| |