> Actually, I was trying to generalize the way the arm arch already did it > with the arch/arm/mach-sa1100/pcipool.c see the comments in pcipool.c as it > was added for the ohci case.
Which is why it works smoothly. "Better" is the issue I touched on. In this case UML could generalize in several ways. One is to always support the "null pci_dev" convention. Another is to formalize ways to detect non-support of that convention, and kick in alternatives. >>That is, that upper level of HCD code is linked into usbcore but >>is still logically separate. You _could_ write a 2.4-style HCD >>and do those DMA bits yourself. (I'd encourage you not to do so.) >>Linkage != layering. >> >>Is that the perfect/ideal setup? Certainly not. Factoring for >>better support of non-PCI HCDs is just one issue. And I confess >>I was a bit surprised to see such a simple solution for SA-1111, >>since I'd thought more work "generalizing" non-PCI drivers was >>going to be necessary ... longer term, it still seems to be. > > > Not so much linkage but that the usb core now includes references to the > pci_pool functions and seems to assume that everything is now PCI, the > execption appearing to be, the arm arch where a mem pool interface was > created seemingly for usb see the comments in arch/arm/mach-sa1100/pcipool.c Exactly. "usbcore" _links_ in something assumes the "null pci_dev" convention works; pci_pool is only part of that.. The layering says that convention is optional. That's what I meant by saying it's a linkage issue: it _could_ link in some arch-specific thing that knew the right way to do DMA mapping on that platform. But there's no way for drivers/usb/core/Makefile to know whether that convention is needed on any given platform, so today its choice is to assume it always is ... which is your linking issue. Perhaps a magic arch-level CONFIG_PCI_NULLDEV config option (the kind that doesn't appear in the config menus) should be defined. SA-11xx could define it, as would some others (maybe UML). The usbcore module would link the 'buffer.c' code given CONFIG_PCI or CONFIG_PCI_NULLDEV. Otherwise arch_specific implementations of those routines would be used ... and the SA-1111 in particular might want to do that with kmalloc there even given CONFIG_PCI_NULLDEV to make optimal use of that 1 MByte of DMA-ready memory. > By the way I found these comments quite helpful you might want to put them > up somewhere for expansion. It's on the list to do a bit later in the 2.5 series. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
