bus_dmamap_sync() for bounced client buffers from user address space

[Konstantin Belousov]

On Sat, Apr 25, 2015 at 12:55:13PM -0500, Jason Harmening wrote:
> Ah, that looks much better.  A few things though:
> 1) _bus_dmamap_load_ma (note the underscore) is still part of the MI/MD
> interface, which we tell drivers not to use.  It looks like it's
> implemented for every arch though.  Should there be a public and
> documented bus_dmamap_load_ma ?
Might be yes.  But at least one consumer of the KPI must appear before
the facility is introduced.

> 2) There is a bus_dmamap_load_ma_triv that's part of the MI interface,
> but it's not documented, and it seems like it would be suboptimal in
> certain cases, such as when dmar is enabled.
When DMAR is enabled, bus_dmamap_load_triv() should not be used.
It should not be used directly even when not.  Drivers should use
bus_dmamap_load_ma(), and implementation redirects to _triv() if
needed.

The _triv() is the helper to allow bus_dmamap_load_ma() to exists
on architectures which cannot implement, on not yet implemented,
proper page array load op.

> 3) Using bus_dmamap_load_ma would mean always using physcopy for bounce
> buffers...seems like the sfbufs would slow things down ?

For amd64, sfbufs are nop, due to the direct map.  But, I doubt that
we can combine bounce buffers and performance in the single sentence.