Re: bus_dmamap_sync semantics

2013-12-27 Thread David Gwynne 
Ok
On 27/12/2013 5:28 am, "Mark Kettenis"  wrote:

> Our bus_dmamap(9) man page says:
>
>   On platforms which implement reordered stores, bus_dmamap_sync()
>   will always cause the store buffer to be flushed.
>
> In 2003 NetBSD actually changed that to:
>
>   On platforms which implement a weak memory access ordering model,
>   bus_dmamap_sync() will always cause the appropriate memory barriers
>   to be issued.
>
> While the new wording is a bit ambiguous, it probably makes more sense
> than what we currently have.  Always flushing store buffers doesn't
> really make sense, especially on BUS_DMASYNC_POSTREAD and
> BUS_DMASYNC_POSTWRITE operations.  It just happens to be what the
> alpha implementation does (which is where the bus_dma(9) API started).
> But on sparc64 we certainly don't do this.
>
> Do people agree?  If so, I'll adjust the wording in the man page.
>
>

Re: bus_dmamap_sync semantics

2013-12-26 Thread Theo de Raadt 
> Our bus_dmamap(9) man page says:
> 
>   On platforms which implement reordered stores, bus_dmamap_sync()
>   will always cause the store buffer to be flushed.
> 
> In 2003 NetBSD actually changed that to:
> 
>   On platforms which implement a weak memory access ordering model,
>   bus_dmamap_sync() will always cause the appropriate memory barriers
>   to be issued.
> 
> While the new wording is a bit ambiguous, it probably makes more sense
> than what we currently have.  Always flushing store buffers doesn't
> really make sense, especially on BUS_DMASYNC_POSTREAD and
> BUS_DMASYNC_POSTWRITE operations.  It just happens to be what the
> alpha implementation does (which is where the bus_dma(9) API started).
> But on sparc64 we certainly don't do this.
> 
> Do people agree?  If so, I'll adjust the wording in the man page.

I understand the difference, and agree.

bus_dmamap_sync semantics

2013-12-26 Thread Mark Kettenis 
Our bus_dmamap(9) man page says:

  On platforms which implement reordered stores, bus_dmamap_sync()
  will always cause the store buffer to be flushed.

In 2003 NetBSD actually changed that to:

  On platforms which implement a weak memory access ordering model,
  bus_dmamap_sync() will always cause the appropriate memory barriers
  to be issued.

While the new wording is a bit ambiguous, it probably makes more sense
than what we currently have.  Always flushing store buffers doesn't
really make sense, especially on BUS_DMASYNC_POSTREAD and
BUS_DMASYNC_POSTWRITE operations.  It just happens to be what the
alpha implementation does (which is where the bus_dma(9) API started).
But on sparc64 we certainly don't do this.

Do people agree?  If so, I'll adjust the wording in the man page.