> >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 ra
>
>> 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/leng
> 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 pai
>> >My understanding is that you need a dmamap for every buffer that you want
>> >to map into bus space.
>>
>> You need one dmamap for each independantly manageable mapping. A
>> single mapping may result in a long list of segments, regardless
>> of whether you have a single KVA buffer or multip
> >My understanding is that you need a dmamap for every buffer that you want
> >to map into bus space.
>
> You need one dmamap for each independantly manageable mapping. A
> single mapping may result in a long list of segments, regardless
> of whether you have a single KVA buffer or multiple KVA
>
>Correction.
>
>This sample:
>>
>> if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim,
>> BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
>> BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) {
>> isp_prt(isp, ISP_LOGERR,
>>
>Every hear the phrase "you get what you pay for?" The API isn't all that
>clear, and we don't have a man page or document that describes in detail
>how to use it properly. Rather than whining about that, I decided to
>tinker with it and Use The Source, Luke (tm). This is the result.
Fair enough.
Correction.
This sample:
>
> if (bus_dma_tag_create(pci->parent_dmat, PAGE_SIZE, lim,
> BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR, NULL, NULL, len, 1,
> BUS_SPACE_MAXSIZE_32BIT, 0, &pci->cntrol_dmat) != 0) {
> isp_prt(isp, ISP_LOGERR,
>
On Mon, 20 Aug 2001, Bill Paul wrote:
> Every hear the phrase "you get what you pay for?" The API isn't all that
> clear, and we don't have a man page or document that describes in detail
> how to use it properly. Rather than whining about that, I decided to
> tinker with it and Use The Source,
>
> Another thing- maybe I'm confused- but I still don't see why you want to
> require the creating of a map each time you want to load an mbuf
> chain. Wouldn't it be better and more efficient to let the driver decide when
> and where the map is created and just use the common code for loads/unl
Another thing- maybe I'm confused- but I still don't see why you want to
require the creating of a map each time you want to load an mbuf
chain. Wouldn't it be better and more efficient to let the driver decide when
and where the map is created and just use the common code for loads/unloads?
On
Yay!
The current suggestion is fine except that each platform might have a more
efficient, or even required, actual h/w mechanism for mapping mbufs.
I'd also be a little concerned with the way you're overloading stuff into mbuf
itself- but I'm a little shakier on this.
Finally- why not make th
Okay, I decided today to write a bus_dmamap_load_mbuf() routine to
make it a little easier to convert the PCI NIC drivers to use the
busdma API. It's not the same as the NetBSD code. There are four
new functions:
bus_dmamap_load_mbuf()
bus_dmamap_unload_mbuf()
bus_dmamap_sync_mbuf()
bus_dmamap_de
13 matches
Mail list logo
