> people to point out a real example and investigate. In practice, all
> USB controllers seem to be implimentations of {O,U,E}HCI, which is
> based on bus mastering rather than using a PC's DMA controller, and
> the controllers are either PCI devices or are embedded on the CPU
> or motherboard chipset.
32bit DMA only
> >The DMA mapping document also says
>
> >| This rule also means that you may not use kernel image addresses
> >| (ie. items in the kernel's data/text/bss segment, or your driver's)
> >| nor may you use kernel stack addresses for DMA. Both of these items
> >| might be mapped somewhere entirely different than the rest of physical
> >| memory.
>
> The USB drivers do not DMA from those values directly. They
> DMA from the result of pci_map_single, which is supposed to handle
> that remapping on architectures that require it (and just returns the
> address on the architectures where no remapping is required).
vmalloc area is not usable with pci_map_* and module text/data is vmalloc
> I want to eliminate eventually. There are other cases (which currently
> call usb_control_cmd), where I think I would want to still have the
> performance benefit of using the stack rather than kmalloc/kfree.
Then you will have to rewrite all your code again later. I just scanned the
arch stuff including pending trees. The kernel stack is not DMAable on
PPC64. It does not appear to be reliably DMAable (64bit high page) on
IA64 either.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
