Date: Sun, 20 Sep 1998 16:22:43 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Eivind Eklund <eivind@yes.no> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, hackers@FreeBSD.ORG Subject: Re: malloc()ing 64K physically contiguous buffer in kernel Message-ID: <199809202229.QAA20167@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 21 Sep 1998 00:16:37 %2B0200." <19980921001637.40216@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>> You should use bus_dma instead of contigmalloc, but I won't think >> badly of you until I've gotten off my duff and written the man >> pages for it. (bus_dma eventually uses contigmalloc to satisfy the >> request, but this may change (very likely on other platforms)). > >Speaking of this - what is the relationship between the bus_space >stuff you've brought in from NetBSD, and the bus framework dfr has >made for the alpha port? I don't know as I haven't caught up with dfr's code yet. I suspect that dfr's code would be responsible for telling drivers what their parent bus space/dma tags are (something I've hacked around until our config code becomes sane) but that the bus space/dma calls are still needed. >How far is what you've written from the NetBSD original? Bus Space should be almost identical. The only reason why it's not is I haven't had time to resync with some changes in NetBSD (new API calls, etc.). The only difference I know of in the bus space code is that in FreeBSD, you can selectively include headers for only the type of access you know the hardware will support (e.g. the AdvanSys Narrow cards cannot handle PCI memory mapped accesses, so I don't bloat the code by adding support for memio). Bus DMA is somewhat different. The main push for the changes was to make it more efficient on some platforms (like the x86) to handle allocation of per transaction bus mapping resources (you need a lot of these for tagged SCSI I/O for example), and to allow deferred execution of a mapping operation if resources are limited. The second change allows us to allocate a trivial amount of bouncing memory for ISA busmasters and still achieve good performance instead of having to pre-allocate the worst case amount of resources up front. Last I talked with Jason Thorpe about this stuff, it was undecided as to whether NetBSD is interested in these changes. The ball is essentially in my court right now to provide documentation of the new interface, how it differ from NetBSD, and the rational for the change. If only there were more time in the day... >Can I get by with using their docs, or is will this make me take a >wrong turn? Probably. If the fires start burning a little lower, I'll see what I can do. >Eivind. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809202229.QAA20167>