dyoung@pobox.com wrote:

> BUS_DMA_COHERENT is advice for the bus_dma backend.  The backend may
> ignore it.  Quoting bus_dma(9),

Yes, I know it's just a hint, and that was a reason why I put
BUS_DMA_COHERENT _after_ I tweaked descriptor accesses and put
necessary bus_dmamap_sync() calls.

Anyway, there are quite few (no?) drivers which will work
without the hint on non DMA cache coherent systems.
(i.e. most drivers lack some of required bus_dmamap_sync(9) calls
 especially against DMA descriptors)

Fortunately, currently most machines (mips, arm etc) supports
BUS_DMA_COHERENT for a linear buffer, so it would work properly
for DMA descriptors on most machines, then many people wouldn't
bother to put such bus_dmamap_sync properly.
(It seem that few FreeBSD people know why such bus_dmamap_sync()
 are required against DMA descriptors... ;-p)

On the other hand, IIRC HPPA doesn't support it so osiop(4) and
siop(4) might have trouble on such machines, I guess.

> You must pad struct rtk_desc to the cacheline size to avoid cacheline
> interference.  I cannot emphasize enough how important that is!
 :
> bus_dma really ought to provide a #define for the machine's cacheline
> size.

But I don't know the way how to determine possible maximum cacheline
size at compile time because cache design could be configurable.
Some sgimips machines could have 128 bytes, but HPPA machines
might have larger one. Do you have any good idea how to implement it?
Check it at runtime and calculate offsets dynamically?
I think it's unlikely...

Furthermore, some hardware (especially designed for Intel) could have
awful DMA descriptor design which doesn't consider possible race
condition between CPU and busmaster on non DMA cache coherent systems.
Such device will never work on non DMA cache coherent system, but
should we check and warn it on attachment?
---
Izumi Tsutsui