Messages in this thread | | | Date | Tue, 21 Apr 2009 17:25:47 -0700 (PDT) | Subject | Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars | From | David Miller <> |
| |
From: Roland Dreier <rdreier@cisco.com> Date: Tue, 21 Apr 2009 10:07:50 -0700
> This only makes sense if we define a 32-bit fallback for > readq()/writeq() for all 32-bit architectures -- in fact it would be > good to do it in asm-generic so that there can be a single > implementation that guarantees that non-atomic versions always do, say, > low 32 bits then high 32 bits. (So eg niu can use the generic version) > And then drivers like drivers/infiniband/hw/mthca can be switched to > "#ifndef writeq_atomic <...hardware specific fallback...>"
I think if you want to do this right you have to provide two versions of the 32-bit implementations, when the cpu cannot generate full 64-bit transactions. Especially for readq().
Some devices clear the status bits of a 64-bit register when read, so it might matter deeply whether the top-half or the bottom-half 32-bits are read first.
The following are ugly names, but something like "readq_hifirst()" and "readq_lofirst()" and they just get defined to play "readq()" in situations where a full 64-bit transaction can be generated by the cpu.
The driver author has to figure out which is appropriate.
And I'm pretty sure similar high-first/low-first issues can exist for writeq() as well.
| |