> > .... At the end of this
> > message is the interface to what I'm working on just now.
> > As in, coded but not debugged.
And attached is an updated version with an implementation that
seems to basically behave (barely tested, very untuned). It's a
good time for comments.
This uses per-page bitmaps (like in Johannes' patch) rather
than freelists (like the slab allocator or that buddy allocator
in that SCSI driver), but since ffz() is one instruction on x86,
most folk shouldn't notice any extra cpu time ... :-)
> 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.
That's where pci_map_single() is supposed to be used, according
to linux/Documentation/DMA-mapping.txt ... which describes it
as a "streaming" mapping. (So Jamey's original StrongARM port
did exactly the right thing.)
> UHCI could use endpoint sized chunks, but I don't think that will work
> with OHCI, right?
I think I'm not following you here. A pci_pool would be used for
ED/QH/TD style data, used by host controller and driver in what's
more or less a random access mode. I/O buffers use streaming
access (to or from the HC, once; then done). The mapping would
be set up when the URB is submitted, torn down when it's returned
to the driver ... no matter how many HC-level Transfer Descriptors
are used to make that happen.
- Dave
pcipool.shar
