Wrapper API for static bus_dma allocations

John Baldwin jhb at freebsd.org
Sat Jan 31 12:58:36 UTC 2015


On Friday, January 30, 2015 09:07:52 PM Warner Losh wrote:
> > On Jan 30, 2015, at 2:31 PM, John Baldwin <jhb at freebsd.org> wrote:
> > 
> > On Friday, January 30, 2015 05:21:50 PM Konstantin Belousov wrote:
> >> On Fri, Jan 30, 2015 at 09:56:31AM -0500, John Baldwin wrote:
> >>> On 1/29/15 4:54 PM, Poul-Henning Kamp wrote:
> >>>> --------
> >>>> 
> >>>> In message <2800970.jY4xzTy9Hz at ralph.baldwin.cx>, John Baldwin writes:
> >>>>> The bus_dma API to allocate a chunk of static DMA'able memory (e.g.
> >>>>> for
> >>>>> descriptor rings) can be a bit obtuse [...]
> >>>> 
> >>>> Isn't it time we take a good hard stare at all of the bus_dma API,
> >>>> and refactor it into something a lot more compact ?
> >>> 
> >>> Given the amount of oddball hardware out there I don't think there is a
> >>> lot you can cut out.  The filter function might be something we can lose
> >>> (and losing it would simplify the implementation), but all the other
> >>> weird constraints are actually used by something AFAIK.  I do think we
> >>> can provide some simpler wrappers for some of the more common cases, but
> >>> there will be some hardware for which those wrappers do not work.
> >>> 
> >>> One suggestion Scott has had is to at least make it easier to extend the
> >>> API by using getter/setter routines on the tag to work with tag
> >>> attributes instead of passing them all in bus_dma_tag_create().
> >> 
> >> BTW, filter function is useless.  It can deny specific bus address from
> >> being used, but it does not provide the busdma implementation even a hint
> >> what other address should be (tried to) used.  In dmar busdma, I simply
> >> ignored it.  And there is no real users of filter in the tree.
> > 
> > Yes, it is very annoying.  I think some old ISA SCSI HBA driver might have
> > used it to skip over some low-memory hole (i.e. there were two valid DMA
> > ranges and this was the kludge instead of having two sets of
> > lowaddr/highaddr exclusions).  (That is one part of the API we could
> > rototill is to just remove the highaddr arg just use a single arg which
> > is effectively lowaddr.  I think all drivers always set highaddr to
> > BUS_SPACE_MAXADDR.)
> 
> Not all. There’s some PCI cards that can’t do 64-bit cycles that pass in the
> 32-bit value on 64-bit systems. There’s 386 instances of this in the tree.
> But that may be lowaddr only. It’s hard to grep for this to be sure.

That is lowaddr only, not the filter callback.

However, even if we remove the filter and highaddr arguments from tags, you 
are still stuck with creating a tag, allocating memory, and loading it to get 
a bus address (and tracking the associated pointers, etc.).  I still think a 
wrapper API for the common case (static DMA allocations) would be useful.

Orthogonally I can explore removing the filter along with highaddr (it is 
always BUS_SPACE_MAXADDR).

-- 
John Baldwin


More information about the freebsd-arch mailing list