From owner-freebsd-hackers Wed Aug 22 15:17:31 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id C467537B420; Wed, 22 Aug 2001 15:17:08 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.5/8.11.5) with ESMTP id f7MMH7Y18044; Wed, 22 Aug 2001 16:17:07 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200108222217.f7MMH7Y18044@aslan.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 In-Reply-To: Your message of "Wed, 22 Aug 2001 14:53:51 PDT." <20010822215351.3090537B40B@hub.freebsd.org> Date: Wed, 22 Aug 2001 16:17:07 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >> 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