Date: Wed, 29 Jan 2003 13:23:34 -0700 From: Scott Long <scott_long@btc.adaptec.com> To: Hiten Pandya <hiten@unixdaemons.com> Cc: arch@freebsd.org Subject: Re: bus_dmamem_alloc_size() Message-ID: <3E383846.20308@btc.adaptec.com> In-Reply-To: <20030129184211.GA70010@unixdaemons.com> References: <3E35DE8E.2080706@btc.adaptec.com> <20030129184211.GA70010@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hiten Pandya wrote: > On Mon, Jan 27, 2003 at 06:36:14PM -0700, Scott Long wrote the words in effect of: > >>All, >> >>With the ongoing effort to convert all of our drivers to busdma, it's >>becoming painfully apparrent that bus_dmamem_alloc() needs to >>be able to specify the size of the buffer to create, and not just >>default to the max_size field of the dma tag. The reason is that a >>lot of simple hardware out there do understand scatter-gather lists, >>so any data passed to them must be physically contiguous in a >>single segment. This in turn means that drivers need to allocate a >>single segment buffer via busdma and copy their i/o contents >>into/out of it when talking to the card. These i/o lengths are often >>extremely variable in size. Without the ability to allocate variable >>sized buffers, you're forced to either create a custom dma tag per >>i/o transaction, or pre-allocate a huge chunk up front and do your >>own sub allocations out of it. Both are rather tedious and >>inefficient. >> >>So, how about adding a method called bus_dmamem_alloc_size() >>that takes the normal arguments of bus_dmamem_alloc(), plus an >>allocation size. Driver writers would still be encouraged to be smart >>about memory management since contigmalloc() would still be the >>underlying allocator, and contigmalloc rounds all requests up >>PAGE_SIZE. >> >>Patches to do this are trivial and can be provided on request. If >>I don't hear any arguments against this, I'll commit it this week. >>In case anyone cares, the my motivation for this comes from trying >>to convert the usb driver to busdma. > > > NetBSD had added a size parameter to their bus_dmamem_alloc() at some > point. It was merged from thorpej's branch. We should probably do the > same, but I think this will be a harder/tedious task. > > JFYI. > Cheers. > Well, doing it wasn't that hard (though the sparc64 side of things was horribly tedious). What I probably didn't stress enough in my proposal is that this is just a stop-gap to allow the busdma work to go on. What really needs to happen in for bus_dmamap_load() to learn how to coelesce segments. That way, you define a tag with a max_segs field on 1, pass your data buffer to bus_dmamap_load(), and it does whatever memcpy()'ing or IOMMU magic is neccessary to get it to one physical segment (the same applies to having more than one segment, but it is most relevant with 1). This is the thing that's not very easy to do. I don't have the time or foo right now to do a good job at it. If someone is interested in working on this, it would be very nice to have for 5-STABLE. Things that you would want to consider are 1) sparc64 IOMMU, 2) AGP GART, 3) whatever magic exists for alpha and ia64, 4) how to make this work with PAE on i386. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E383846.20308>