> > UMLs does not really deal with DMA itself and the other mid-layer for > > example SCSI & sound don't appear try to tinker with DMAable buffers > > themselves but defer that down to the driver, which after all has much more > > exact information about what the hardware is. > > USB has two levels of driver there. The upper level driver (think storage, > which talks SCSI) needs some way to "defer that down" to the HCD which, as > you said, has more exact information. > > Hmm, have you thought of just providing different versions of the code > in 'buffer.c' for "fake-pci" systems? Ones that just kmalloc/kfree/NOP, > or whatever is appropriate? We actually know that doing that would be > a better implementation on the SA-1111 since kmalloc(...,SLAB_DMA) is > smarter (by a lot :) than the pci_pool allocator, and it'd even save a > bit of object code in that context. > Well that was the thought I had with the fake-pci stuff, I was just copying the do-nothing pci routines so I would not have to make changes to the code for buffer.c etc. and could compile and try to run the uml-hcd
Asking first was my intent, as I could easily just have a ARCH=um private version of the fake-pci stuff, but that goes against my axiom "if the same thing is done in two different places, one of them will be broken" 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) 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. I am willing if not happy to attack subsystems to fix this problem, rather than papering over the gaps, but where to attack is a question, the fake-pci was a first offer for ARM/UML to deal with their common lack of PCI, it is local and reasonably specific... Pulling the pci_ stuff back out of buffer.c etc. would also be local but it seems people had already discussed this earlier. Another option would be to pull the pci_ stuff out and put it into the HCD themselves possiblily as seperate device op for the HCDs, this may add 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. > That'd be easier than extending the driver model stuff to handle DMA, > and would let you get past link errors to focus on what a "uml-hcd" > might be able to do. I don't think any other PCI dependencies will > have had a chance to sneak into usbcore yet, though there might be > an issue with the macros used to access scatterlist mapping entries. > I too am fond of easier :) but in some respects fixing the underlying cause is better if the problem is not too hard to work. levels of change 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) 1) fake-pci pro: few changes to USB subsystem, possible shareing with ARM, example exists con: still duplicated code but only 2 places (mainline + USB) 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? Working with a DMA buffer in the common code, while I think it would be done at the HCD level, I have mostly looked at the HCDs and wandered about... The QH & TD setup would seem to be the time to copy the data to/from the DMA spaces before then the data could be sitting in zone normal (users should only get zone normal), when allocing a urb for a in kernel driver, the HCD could be asked for the buffer, which I think might be where the common code is doing it instead. 3) moveing pci_ stuff down to hcd-pci pro: it seems logical to have it there con: it may add complexity, it may moot since it might be part of the "new driver model" anyway 4) changeing PCI subsystem to include the support funcitons even without the PCI bus pro: it looks like this may be intended as part of "NDM", may be right thing to do con: harder still, tinkering with a core subsystem. > - Dave > > > > ------------------------------------------------------- Sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
