Re: RFC bus_dma_tag_parent

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Fri, Nov 12, 2004 at 03:42:55PM -0800, Chuck Tuffli wrote:
> ok, I'm confused ...
> 
> On Fri, Nov 12, 2004 at 07:40:42PM +0100, Joerg Sonnenberger wrote:
> > On Fri, Nov 12, 2004 at 09:44:39AM -0800, Chuck Tuffli wrote:
> > >     parent_dmat = bus_dma_tag_parent(dev);
> > 
> > parent_dmat = bus_dma_tag_parent(dev, lowaddr, highaddr, maxsegments);
> 
> is the intent of the {low,high}addr and maxsegments parameters to
> define the properties of the parent tag? the object oriented nature of
> bus_dma would have made me think the bus (PCI, ISA, USB, etc), being
> the "base class", would define the {low,high}addr and maxsegments
> values and not burden each driver with knowing the specifics of the
> bus hierarchy.

It is to define the properties of the device. For example PCI does support
both 32bit and 64bit cards, meaning that some cards can directly address
memory above 4 GB and some not. This is import for two parts:
a) the internal mapping of resource done by "powerful" bridges, again Alpha
   has/had those. It's a wonderful property if you have a MMU in the bridge.
b) define characteristics for later memory allocation. This is necessary to
   correctly decide where [in system memory] to allocate memory or when to
   use bounce buffers.

About the maxsegments can be discussed, but I'm generally in favour of doing
all necessary allocations as soon as possible, because if you really care
about system memory and you have devices you don't use permanently, you can
always remove them from your kernel and load them as modules. Hopefully we
can make the whole tag allocation M_WAITOK save and most memory allocations
too, which helps to avoid failing in low memory situations in the global
system and the limited address ranges.

> 
> > This is useful if the bus DMA engine supports scatter/gather itself.
> > This can be done IIRC on the Alpha, maybe on other architectures too.
> > I don't mind if we have a UNKNOWN value, e.g. 0. This is not a problem
> > here, but for many drivers we know this in advantage and it might be
> > used to allocate the segment maps in the parent tag.
> > 
> > Joerg
> 
> so what you are saying is on these architectures there can be multiple
> parent tags differentiated by the address range and number of
> segments? even in this case, wouldn't there be an advantage to lazy
> allocation of segment maps? in this case, the maps aren't committed
> until the driver makes the subsequent calls to
> bus_dma_tag_create(parent_dmat, ...)

Like I said above, the bridge contains enough silicon to do scatter/gather
support too. This means that the bridge can provide you virtually
consecutive memory, which simplifies programming of the device DMA engine
and often also allows better use of resources there. E.g. for the sis(4)
it is often useful to defragment [insert correct mbuf function here] the
mbuf to save entries in the DMA table.

Lazy allocation seems a nice property at first, but keep in mind that for
device inuse this memory is allocated anyway, but then perhaps from a
critical path [e.g. intr context or the network stack].

> don't take any of the above as an objection to adding the parameters -
> it's more my way of making sure i understand what to code.

Sure, I would code it myself if my TODO list would be shorter :)
And clearly expressing the reasoning for a specific API is going to
help us in the future, when the question arise why we choose this.

Joerg

> 
> -- 
> Chuck Tuffli
> Agilent Technologies