[ofa-general] [RFC 0/1] libmthca: CQ/DMA race on Altix

[Roland Dreier]

 > But isn't this an Altix specific issue, which makes the 32-bit issue
 > moot? (I'm assuming the "fix" to use dma_alloc_coherent() is only
 > implemented for Altix, which is in-arguably ugly).

Well, I don't want to have one code path just for Altix and another
for all normal systems.  It kind of goes against the spirit of the DMA
API, which is to provide an abstraction so that drivers can be written
without system-specific details.

 > >  - The property being asked for is not really coherent memory but
 > >    rather "set the magic bit in the bus address so the Altix chipset
 > >    flushes other DMAs", and I think it would be cleaner to ask for
 > >    that explicitly rather than relying on the side effect of
 > >    coherent memory.
 > 
 > That makes sense. However I didn't quite understand if the above means
 > that you're ok with the patch posted, or prefer a different (third)
 > approach?

I'm OK with the main idea, but I don't think adding a "coherent" flag
to the mapping API is the right way to ask for this bit to be set on
Altix.  I can think of two approaches that seem somewhat sane:

 - Add a flag that gets passed in the normal "direction" parameter of
   the DMA mapping APIs, which is ignored on most systems and not set
   by most drivers.  Adds some churn to the internal implementation on
   all archs, though.

or

 - Add new functions dma_map_single_flushing(), dma_map_sg_flushing() and
   dma_map_page_flushing() that are defined to be the same as the
   non-flushing variants except on Altix.  Fairly quick and easy to
   implement, but arguably makes the DMA API even more bloated with
   even more functions that are only slightly different.

Dunno...

 - R.