Re: [RFC] dma: passing "attributes" to dma_map_* routines

[Stefan Richter]

akepner@xxxxxxx wrote:
> On Fri, Dec 21, 2007 at 07:56:25AM +1100, Benjamin Herrenschmidt wrote:
>> ...
>> Can't you just have a primitive to sync things up that you call
>> explicitely from your driver after fetching a new status entry ?
> 
> Well, the only mechanisms I know to get things synced are the ones 
> I mentioned before: 1) generate an interrupt, 2) write to memory 
> which has the "barrier" attribute. Obviously 1 is out - giving  
> the memory used for status indications the barrier attribute is 
> the most primitive means I'm aware of.

I don't know what it is in detail what Arthur et al are facing, but this
is how it looks to me:

A sync call like Benjamin suggests has two preconditions.

  1. The interconnect hardware actually offers such a functionality.
I.e. there is a way for the CPU to request flushing of pending DMAs, and
the interconnect is able to generate an interrupt to signal when it is done.

  2. The protocols which the devices use are suitable for this.  I.e.
 there are no race conditions during the window between when the DMAs
were flushed and when the CPU has finished reading the status memory area.

Even _if_ both is true, a regime with such a call would obviously be
more complex and might be harder to get to perform well, compared to the
regime where the interconnect hardware is told beforehand that some
particular DMA writes must never be reordered relative to earlier and
later DMA writes.
-- 
Stefan Richter
-=====-=-=== ==-- =-=-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/