We used pci_map_single() for the transfer buffer in my original version of
the StrongARM port. That way none of the drivers other than the controller
driver was affected.
Jamey
> -----Original Message-----
> From: Johannes Erdfelt [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 07, 2001 3:59 PM
> To: [EMAIL PROTECTED]
> Cc: Steve Longerbeam
> Subject: Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci
> patch
>
>
> On Tue, Mar 06, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > we also need to get rid of bus_to_virt().
> >
> > Hi Steve! Haven't forgotten about that. At the end of this
> > message is the interface to what I'm working on just now.
> > As in, coded but not debugged.
> >
> > This interface sort of combines kmem_cache() options
> > (flags like SLAB_POISON, GFP_ATOMIC) with the
> > pci_alloc_consistent() approach. The routine that would
> > be used instead of bus_to_virt() currently needs a name
> > change -- pci_pool_dmamap() doesn't quite cut it. The
> > first implementation can't be as functional as the slab
> > code, but I hope some later version can use this API to
> > get to some shared code.
>
> The only problem I have with an implementation like this, is that it
> doesn't take into consideration other pieces of data which need to be
> consistent as well, like urb->transfer_buffer. These can be varying
> sizes of data which this kind of API doesn't lend itself to.
>
> UHCI could use endpoint sized chunks, but I don't think that will work
> with OHCI, right?
>
> > Sounds like on MIPS, as on x86, that badly named
> > function could be in <arch/pci.h> (?) as a macro that
> > just returns its argument, and all would be well.
> >
> > The way I currently have it implemented, the cost of
> > that function on other platforms will be about linear
> > in the number of pages allocated in that pci_pool.
> > That's the obvious quick'n'dirty implementation; I'd
> > gladly see a better one, hashed or otherwise.
>
> If it's anything like my implementation, this can be optimized by
> throwing pages with known free entries in the beginning of the linked
> list.
>
> In reality, this will probably be a non issue.
>
> JE
>
>
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
