> I have running source 2.4.20 for SL811HS, an embedded host > controller from Cypress.
> If have view 2.6.0-test5 and very confus: Many modifired > functions, missing functions. > usb_new_device(), usb_packetid(), usb_pipeslow(). > Some I have found in 2.4.20 include/linux/usb.h, > some in 2.6.0 uhci-hcd.h
You likely want any drivers/usb/host/*.c file to be #including "../core/hcd.h", to get the interfaces that are provided only to HCDs.
> But big problem is usb_new_device(), > alias hcd_register_root() for old drivers.
Use the updated calls, which know how to work with the driver model code. You'll have to create some kind of (platform?) device for the sl811 and hook it in, for power management, sysfs linkage, and other goodies.
> Driver hc_sl811* can not compile: Many compiler errors.
Yes, I think I remember noticing nobody updated it during the 2.5 development cycle. You don't need to convert to use the "hcd" glue framework, though that would be a win eventually. You can update SL-811 to 2.6 while still using the old "struct usb_operations" interfaces, like the current code does.
> But the complete USB driver stack I have not understand.
Most folk don't! It's simpler and more orthogonal in the 2.6 kernels -- huge numbers of special cases are gone now, including cases where HCDs acted differently. And there's now reasonably accurate kerneldoc.
The URB model -- submission, and async completion -- is essentially the same as in 2.4 except for removing those special cases. All endpoints support urb queues. No endpoints automagically resubmit. And there are tests that you can run over the HCDs, to make sure they do the right things.
> I do not understand, why all Host Controllers handle > queues by self. I found duplicate source in uhci-*.c, > ehci-*.c, ohci-*.c and also hc_sl811*.c. And why not > all drivers use a shared source for queue handling and so?
What duplicate source? The structures of those HCDs (except the sl811 code) should be starting to look a lot more similar -- big improvement -- so each driver will have functions for a bunch more standard tasks. But the implementations will be hardware-specific.
The basic reason why the drivers don't share much queueing code (beyond the submit and giveback paths in drivers/usb/core/hcd.c) is that each hardware's DMA transfer queues work differently.
They could look more alike than they do ... folk have talked about making UHCI use a per-endpoint queue, like OHCI and EHCI do, as a big simplification. And once they all adopt that model, likely there'd be some opportunities for serious code sharing. The 2.7 kernel series should think about that.
> What is the best skeleton for a new host controller?
For PCI, I think OHCI is simplest.
And for non-PCI, the only working example in the 2.6 kernel is the ohci-sa1111.c code ... perhaps the two of those give you an answer! :)
- 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
