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
