lkml.org 
[lkml]   [2009]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars
Ingo Molnar wrote:
>
> Look at the drivers that define their own wrappers:
>
> #ifndef readq
> static inline unsigned long long readq(void __iomem *addr)
> {
> return readl(addr) | (((unsigned long long)readl(addr + 4)) << 32LL);
> }
> #endif
>
> ... it's the obvious 32-bit semantics for reading a 64-bit value
> from an mmio address. We made that available on 32-bit too.
>
> It's being used ... and has been in use for some time. Where's the
> problem? readl is serializing on all default-ioremap mmio targets on
> x86 so there's no ambiguity in ordering.
>

I think his point is that they're not atomic. For what it's worth,
atomic readq()/writeq() *are* possible with any x86-32 CPU which
supports MMX, but it is very costly to do in the kernel since it
involves touching the FPU state.

For the vast number of users, a non-atomic primitive which is available
for both 32- and 64-bit x86 is a win. For a small number of users,
it'll be confusing, and for a very small minority it's going to be
desirable to have the atomic primitive.

The reason the non-atomic is generally fine is because most device
drivers are inherently single-threaded on a per-hardware device basis.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.



\
 
 \ /
  Last update: 2009-04-20 00:05    [W:0.076 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site