Subject: Re: On the subject of bus_dma(9)
To: Jason R Thorpe <email@example.com>
From: Matthew Jacob <firstname.lastname@example.org>
Date: 03/07/2001 10:21:42
> 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.