>
>> 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