Date: Wed, 22 Aug 2001 16:17:07 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: wpaul@FreeBSD.ORG (Bill Paul) Cc: mjacob@feral.com, hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Where to put new bus_dmamap_load_mbuf() code Message-ID: <200108222217.f7MMH7Y18044@aslan.scsiguy.com> In-Reply-To: Your message of "Wed, 22 Aug 2001 14:53:51 PDT." <20010822215351.3090537B40B@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> The fact that the data is less than a page in size matters little >> to the bus dma concept. In other words, how is this packet presented >> to the hardware? Does it care that all of the component pieces are >> < PAGE_SIZE in length? Probably not. It just wants the list of >> address/length pairs that compose that packet and there is no reason >> that each chunk needs to have it own, and potentially expensive, dmamap. > >Maybe, but bus_dmamap_load() only lets you map one buffer at a time. >I want to map a bunch of little buffers, and the API doesn't let me >do that. And I don't want to change the API, because that would mean >modifying busdma_machdep.c on each platform, which is a hell that I >would rather avoid. bus_dmamap_load() is only one part of the API. bus_dmamap_load_mbuf or bus_dmamap_load_uio or also part of the API. They just don't happen to be impmeneted yet. 8-) Perhaps there should be an MD primitive that knows how to append to a mapping? This would allow you to write an MI loop that does exactly what you want. >> there are too many chunks for your driver to handle. Bus dma is >> supposed to handle that for you (the x86 implementation doesn't >> yet, but it should) but it can't if it doesn't understand the segment >> limit per transaction. You've hidden that from bus dma by using a >> map per segment. > >Ok, a slightly different question: what happens if I call >bus_dmamap_load() more than once with different buffers but with >the same dmamap? The behavior is undefined. >> >- Added routines to allocate a chunk of maps in a singly linked list, >> > from which the other routines can grab them as needed. >> >> Are these hung off the dma tag or something? dmamaps may hold settings >> that are peculuar to the device that allocated them, so they cannot >> be shared with other clients of bus_dmamap_load_mbuf. > >It's a separate list. The driver is reponsible for allocating the >head of the list, then it hands it to bus_dmamap_list_alloc() along >with the required dma tag. bus_dmamap_list_alloc() then calls >bus_dmapap_create() to populate the list. The driver doesn't have >to manipulate the list itself, until time comes to destroy it. Okay, but does this mean that bus_dmamap_load_mbuf no longer takes a dmamap? Drivers may want to allocate/manage the dmamaps in a different way. -- 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?200108222217.f7MMH7Y18044>