From: David B. <da...@pa...> - 2002-09-17 16:25:35
|
> I was looking for opinons on which way to approach the problem, I dont wan't > to reinvent the wheel (especially as mine seem start out as a triangle) I noticed that ... :) > On the SLAB_DMA being smarter, that is good does it relate to those comments > about some hardware only working with DMA in the 1st 1MiB of memory, less > even then some ISA hardware. Smarter for that particular platform. In general, what the PCI DMA calls do is arch-specific; in that one, it's slab code underneath. > complexity and hits that axiom again, it is not good to duplicate code among > the HCDs either, so I would have likely aimed for the hcd-pci.o file and > suggest the fake-pci.o file with the kmalloc/NOP equivialents for ARMs OHCI, > and leave uml-hcd without either. UML will need _something_ to implement those usb_operations. > 0) UML private fake pci support > pro: easist, no changes to other subsystems, already present with patches I > am using > con: no code shareing, duplicated code in 3 places (mainline + ARM + UML) This fits best with the "null pci_dev is platform-defined" policy that's been the standard hack for a couple years now. That "con" would IMO be best addressed by moving DMA memory issues into the device model, but then UML would _still_ need to have a solution to this problem. > 2) reverting buffer.c etc. > pro: it used to work, it might also simpilfy ARM > con: I assume that there was a reason to put this in to begin with :) > But what is that reason? Kerneldoc for the usb_buffer_*() functions describes some reasons, like elimination of buffer copies (for SA-1111 and others), reducing IOMMU overhead (for SPARC and some others), and enabling better IOMMU mappings. If it simplified ARM, it'd do so at the cost of ensuring every SA-1111 I/O involve copying through a DMA bounce buffer ... right now, drivers can eliminate them by using usb_buffer_{alloc,free}(). - Dave |