Re: [linux-usb-devel] Re: highmem and usb [was "sr: unaligned transfer" in 2.5.2-pre1]

[Jens Axboe <axboe@suse.de>]

On Tue, Jan 01 2002, David Brownell wrote:
> > > Not that I've seen a writeup about highmem (linux/Documentation
> > > doesn't seem to have one anyway) but if I infer correctly from that
> > > DMA-mapping.txt writeup, URBs don't support it because there's no way
> > > to specify buffers as a "struct page *" or an array of "struct
> > > scatterlist".  That's the only way that document identifies to access
> > > "highmem memory".
> > 
> > What kind of mapping does URBs require? A virtual mapping?
> 
> Each URB points to one transfer buffer, address plus length, where
> the USB device drivers directly read/write those addresses.   The
> requirement for drivers is that the transfer buffers can be passed to
> pci_map_single() calls by the Host Controller Drivers (HCDs).  The
> device drivers, and URBs, don't expose such mappings, they only
> require that they can be created/destroyed.

.. which is the requirement that you want to change to use pci_map_page
or pci_map_sg

> I'd be inclined to say transfer buffers must not be "virtual" mappings,
> but since terminology can differ I'll let you draw your conclusion.

They must not be, currently they are.

> Standard HC hardware (EHCI, OHCI, UHCI) can use 32bit addresses
> for their PCI DMA.  EHCI can also, in some implementations, handle 64bit
> addresses.

Good

> > > (And making all the "single" mapping calls in the HCDs use page
> > > mappings.)
> > 
> > exactly
> 
> So you're saying that pci_map_page() is not necessary?  And that
> highmem buffers (page+offset, or scatterlist thereof) can be turned
> into the form needed by URBs using some other mechanism?

Sorry if I wasn't clear, no that's not what I meant. See above.
pci_map_single requires a virtual mapping so it simply cannot support
highmem.

-- 
Jens Axboe