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

From: Jens Axboe (
Date: Wed Jan 02 2002 - 04:32:52 EST

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.


> > > (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

Jens Axboe

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:16 EST