>} the bus dma framework makes no guarantee that the S/G list is
>}allocated in memory that can be dma'ed from, a requirement for many
>}clients. 
>
>If the format is different, and you need to translate, then this looks
>exactly like what BUS_DMAMEM_NOSYNC was for.  Matt Thomas needed this
>for FDDI statistics buffer, and I agitated loundly on behalf of other
>NIC-related uses. Did that get added after you forked off the FreeBSD
>busdma tree?

I fail to see what the attributes on the memory has to do with the S/G
lists that represent this memory.  Certainly the client can use the bus
dma APIs to allocate the storage where they place their S/G lists, but
the point is that the NetBSD API of putting a copy of the S/G list into
the dma map does not give the client this kind of control so a second
copy of the list needs to be maintained.

As for FreeBSD having all of the flags or having them all implemented,
I've already stated that we are probably behind in this regard, but these
additions are supportable with the APIs the way they are now.  It is 
simply a time/need issue to get them implemented.  I have no interest in
reducing the functionality or feature set over the NetBSD implementation.

>The other feature is adding a layer to let driver-level code construct
>a device-dependent representation of a dmamap.  If I'm grokking this,
>that just doesn't work on _some_ implementations of standard buses:
>you *have* to perform host-bridge-specific actions, and those *need* a
>non-device-dependent representation of the dmamap.

I just don't see what you are trying to say here.  The dmamap and dma tags
can hold whatever data you want which allows you to perform whatever 
actions that are needed to get the job done.  The point is that, at the
lowest level, the driver asking to have a map loaded doesn't need to look
into the dma map or tag to get its work done which further frees the 
implementation to represent it's maps and tags however it sees fit.  In
some implementations, no per dma map allocations are required, so why
force them to be allocated?

>That aside, has anyone got hard, measured numbers on how much the
>device-specific "SG" changes buy in performance (as opposed to space)?

What device-specific "SG" changes are you talking about?  The SG list
is compiled in a device-independent format.  The only difference is that
it is handed to you via a callback instead of stuffed into static storage.

>Justin again:
>
>}The client must assume that the lifetime of the passed in bus_dma_segment
>}array is that of the callback function.  Having static space allocated to
>}hold the mapping is of no use to the client in typical practice.
>
>There are buses (DEC TC machines with ioctl asics, and some Sparcs)
>where the DMA engines only have one hardware mapping register (or one,
>double-buffered), and the DMA engine interrupts to request a software
>reload on each physical page crossing.  On those buses, a static map
>*is* useful in the typical case. At least, I think it is.

Again, you are imagining limitations on the implementation that simply are 
not there.  The mapping is in effect from the time a bus_dmamap_load()
completes until the corresponding bus_dmamap_unload.  The only difference
is that the client must stash away the S/G entries (assuming it needs to) 
before it returns from bus_dmamap_load().  If the dma map needs to store
per transaction data of this type, so be it, but the interface should not
force this to be the case.  It's complete waste of space on the x86.

--
Justin