> On Wed, Mar 07, 2001 at 08:55:33AM -0800, Matthew Jacob wrote:
> 
>  > I provided input on this, and there were many things you didn't agree with.
>  > One of them was the Solaris DDI DMA model differences which, btw, handles this
>  > stuff fine.
> 
> Where is the documentation on this interface that I can read?

Section 9, Solaris


> 
>  > >  > 3. Therefore, bus_dmamem_alloc'd memory must be assumed to be for
>  > >  > BUS_DMA_COHERENT purposes because there may be no way to 'change'
>  > >  > the identity of the memory alloc'd in bus_dmamem_alloc (it might be
>  > >  > from a pool that *can't* be made byte-coherent).
>  > > 
>  > > bus_dmamem_alloc() for a particular bus_dma_tag_t *should never* allocate
>  > > from memory which can not be made to DTRT for a particular bus.  All this
>  > > does it point to a bug in the sparc64 bus_dmamem_alloc() routines.
>  > 
>  > No - this is inflammatory, and you should be ashamed for saying it.
> 
> What?  Nonsense.  If the memory returned by a bus_dmamem_alloc()
> can't be DMA map'd in a coherent fashion *and* `sync' operations
> can't work on that memory region, then I am 100% correct in saying
> that bus_dmamem_alloc() failed to allocate "DMA safe memory" (which
> is what the manual page documents it as allocating).
> 
> Let me clarify -- by definition of what bus_dmamem_alloc() is, it MUST
> return memory for which at least one of the following statements is true:
> 
> 	(1) The memory is DMA coherent.
> 
> 	(2) Sync operations ensure that the device sees the correct
> 	    version of the page.
> 
> If neither of those are true for a region that bus_dmamem_alloc() returns,
> then the region is *not* "DMA safe memory", and therefore bus_dmamem_alloc()
> is buggy.

"Nonsense" isn't a technical term :-).

"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.

> 
>  > And, btw, just because you haven't handled peer-peer- you might at least
>  > document the issue.
> 
> Well, "peer-peer" needs to be better-defined, as well.  If you're talking
> about DMA'ing into a host memory region that another device accesses, then
> "DMA safe memory" should pretty well take care of it.  If you're talking
> about DMA'ing into a memory region that is present in *bus space* (e.g.
> a frame grabber DMA'ing into the frame buffer on a graphics adapter), that's
> a whole different issue (and a fairly complicated one).
> 
>  > So- please reconsider letting me update the man page with some clarifications.
> 
> Once I collect all the clarifications that need to be made (I kind of have
> a running list going), I'll be happy to make the updates.

Sooner rather than later. There are far, far, too many issues that just fall
on the floor.

-matt