Subject: Re: Machine-independent bus DMA interface proposal
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>
List: tech-kern
Date: 09/24/1996 10:06:00
A few comments:

1) additional specifications:

 - the results of access to memory mapped by the dma handle in between
calls to bus_dmamap_sync(t, h, BUS_DMASYNC_PRE...) and
bus_dmamap_sync(t, h, BUS_DMASYNC_POST...) is undefined.

 - the results of calling bus_dmamap_load (t, h, ...) or
bus_dmamap_unload(t, h, ...)  between a bus_dmamap_sync(t, h,
BUS_DMASYNC_PRE...) and bus_dmamap_sync(t, h, BUS_DMASYNC_POST...) is
undefined.

2) some rationale for when/where to use bus_dmamap_alloc usage should
be given:

bus_dmamem_alloc is intended for ... (holding io control
blocks/buffers/...)

reasonable sizes for dmamem_alloc are ... (10 bytes/64kbytes/...)

"it's ok to hang onto this memory for the life of the driver"

"this is a scarce resource so you should only allocate this for the
duration of the I/O.."

3) I'm a little concerned about the use of the `op' argument to
bus_dmamap_sync(); I would think that the PRE vs POST part is going to
be a compile-time constant at most call sites, resulting in (needless)
run-time dispatching if the function needs to be implemented as a
function rather than a macro.

perhaps the split should be:

		bus_dmamap_presync(t, h, BUS_DMASYNC_READ);
		
		bus_dmamap_postsync(t, h, BUS_DMASYNC_READ);

(maybe sync/unsync as the verbs would be better..)

					- Bill