>
>> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to