> For consistencies sake we really want to have readq() and writeq() available > on all platforms. I remember that some IB cards require it to actually > be a 64bit transactions, otherwise they have to do funny workarounds. > I think the best solution is to define ARCH_HAS_ATOMIC_READQ_WRITEQ > and let drivers do their workarounds based on that. > > I've Cc'ed Roland because he should be able to explain the IB issue in > details.
The issue I know about is drivers/infiniband/hw/mthca. The card has 64-bit "doorbell registers", and the restriction is that if you write the doorbell write two 32-bit writes, you can't write anything else on the same register page in between writing the two halves. Since different CPUs might be doing stuff on the same doorbell page at the same time, there are two things we can do: - If writeq() exists then use that and assume it will generate only a single bus transaction that can't let anything sneak in the middle. (That's a fairly safe assumption because the devices being driven are either 64-bit PCI-X or PCIe only) - If writeq() doesn't exist, use a spinlock to protect access to each doorbell page. ARCH_HAS_ATOMIC_READQ_WRITEQ would be fine for that, but of course the tricky thing is writing down the exact semantics that "HAS_ATOMIC" is actually promising. - R. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
