Subject: Re: Machine-independent bus DMA interface proposal
To: Jason Thorpe <email@example.com>
From: Bill Sommerfeld <firstname.lastname@example.org>
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
2) some rationale for when/where to use bus_dmamap_alloc usage should
bus_dmamem_alloc is intended for ... (holding io control
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..)