> On Wed, Mar 07, 2001 at 10:21:42AM -0800, Matthew Jacob wrote:
> 
>  > > Where is the documentation on this interface that I can read?
>  > 
>  > Section 9, Solaris
> 
> That doesn't really help me very much.  I don't have ready access to
> a Solaris machine on which to read these.

Fooey. That's easy to find. Go to http://docs.sun.com and search for
'ddi_dma_sync'. In particular, the paragraph for ddi_dma_memalloc is
pertinent:

 'flags' should be set to DDI_DMA_STREAMING if the device is doing sequential,
 unidirectional, block-sized, and block-aligned transfers to or from memory.
 The alignment and padding constraints specified by the minxfer and burstsizes
 fields in the DMA attribute structure, ddi_dma_attr(9S) (see
 ddi_dma_alloc_handle(9F)) will be used to allocate the most effective
 hardware support for large transfers. For example, if an I/O transfer can be
 sped up by using an I/O cache, which has a minimum transfer of one cache
 line, ddi_dma_mem_alloc() will align the memory at a cache line boundary and
 it will round up real_length to a multiple of the cache line size.

> 
> I need a URL or a .ps or .pdf document, or something.
> 
>  > "Sync operations" don't work for this platform in this way (it's not "Sync"
>  > for the CPU in this case, it's "Sync for the device", therefore
>  > bus_dmamem_alloc must return memory which is DMA coherent. We're in agreement
>  > on this *if* we don't change the spec to give a hint earlier.
> 
> There is no reason to change the spec -- bus_dmamem_alloc() is defined
> to DTRT.

With some expansion to the description to note that DMA 'safe' applies to
device as well as CPU 'safety'.

> 
> Sounds basically like the sparc64 needs to always return memory which
> is coherent from the device's perspective, and that the COHERENT flag
> in bus_dma needs only be concerned with the (write-back) cached'ness of
> memory from the CPU's perspective.

Uh, yeah, what I've been saying as one possibility. The other is to give a
hint earlier.

-matt