Subject: Re: FreeBSD Bus DMA (was Re: AdvanSys board support)
To: Justin T. Gibbs <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 06/11/1998 15:52:38
>Again, in my book, what you seem to mean by an "S/G list" is not a
> (i) If it's in a device-dependent format, then it DOESN'T WORK.
> (or, to be more precise, you incur the hair of a translation
> function from DD to an MI format, which as you pointed out is
> nasty; and on many (most?) NetBSD platforms, you save nothing,
> since the bus layer has to build a NetBSD-style dmamap and stash
> it away for the duration of the transfer, regardless.
> (ii) If it's not in a device-dependent format, but an MI format,
> then I really, really really don't understand your claims to be
> saving space by eliminating ``unecessary'' duplicated maps
> (one in devive-dependent format, another in MI format).
I'm sorry to keep harping on this point, but you keep using the term
"S/G list". I really dont think that's a good idea: it carries over
too much baggage from SCSI controllers.
On some machines, where DMA is non-cache-coherent, the hardware
_forces_ you to keep around a list of the physical buffer pages.
Your goal is to avoid actually building a dmamap for "simple"
The way you do this is to postpone building the map until the driver
calls a callback.
But how is the bus-dma layer supposed to get at the map itself if the
only way to construct the map is ot call the _driver's_ callback?
This makes no sense to me at all. It's the same issue as with the
outboard bus TLBs (mapping registers): if you need a virtual-to-physical
address map for every page in the DMA buffer, you need the dmamap;
and in your design, the bus layer itself cant' get at it.
I think it's entirely fair to claim that you roriginal claim is wrong:
there is a severe portability problem with the FreeBSD design in this
I think we need to reach agreement on this point before any further
progress can be made; do you agree to the need to reach agreement?.
I'm thinking about adding a "BUS_DMAMAP_TRIVIAL" flag which lets a
driver and the bus_dma layer conspire to avoid constructing a map, if
and only if *both* the bus_dma layer and the driver dont need the map
info. I think that's likely to be more successful than your approach.
Perhaps we could talk about that design approach?