Hi David, Thanks a lot for your comments!
> I take it you're getting this ready to submit for merging to > the main kernel treee (2.6.11?), after you get some feedback > from other users (and more testing)? Yes, I would like to get it ready for inclusion into the mainline. But indeed, in its current state, the driver needs more testing. I have no idea, whether 2.6.11 would be realistic. Let's see. > - #define DRIVER_VERSION __DATE__ does suggest it's not quite > ready for merging ... I tend to use "dev/" __TIME__", to be > a bit more explicit (and highlight "wrong module" problems > just a smidgeon better), since I often use dates as version > codes and so __DATE__ gets ambiguous. Well, as I have no good idea, how far or close the driver is from the inclusion, it won't be easy for me to do this DRIVER_VERSION encoding "correctly". I'll leave it at the moment as it is (__DATE__) and you just please tell me, when it should be changed to something else. > - Please don't include "ohci.h". If there's stuff from there > you want to use, just copy it; this isn't an OHCI chip. > (The root port bits might even use the "hub.h" names...) OK, I will copy the bit definitions. Still a question: should this be done to avoid driver dependence (116x on ohci) or to avoid giving a wrong impression about ohci-compatibility of this chip or for some other reason? > - If you haven't run this with the "usbtest" driver, please try > to do so (see http://www.linux-usb.org/usbtest for scripts etc). > That does a reasonable job of forcing an HCD to use code paths > that normal/successful operation won't hit; those are the ones > where not acting like the "other" HCDs may cause trouble later. > (Testing interrupt transfers involves a module option.) As I understood from that page, I am not able to run these tests right now. I have no device with EZ-USB chip and I have no linux platform with gadget interface. How would it be to run the tests having just any available device plugged? Sure, device bugs will interfere with the results, but it may be still better than nothing? > - Do you really need to put a 2 msec floor on periodic transfers, > or is that just paranoia? If there are INT urbs submitted, the driver works on SOF interrupt. The chip functions so that after transfers are written to its fifo, it starts fifo processing and real usb traffic after the next SOF and continues until all transfers are succeeded/failed or the frame ends. Therefore the driver works currently so that in every second frame there are transfers and in other frames fifo reading/writing and data processing occurs. This is predictable operation. I could use also an ATL interrupt (which arrives after the usb transfers are finished) to start fifo reading/writing earlier, but this still won't guarantee that the full cycle occurs in every frame, while delivering two interrupts per frame instead on one. > - You can simplify the root port logic a lot by having a single > jiffies counter. I think that's how UHCI does it now; EHCI > does that, but it needs a per-port counter (since some silicon > has so many ports that the USB spec says just one isn't enough). I will look at the UHCI/EHCI code. > It's not polite to spin for 100 msec with IRQs blocked... Well, if you mean isp116x_hub_control(), the USB_PORT_FEAT_RESET case, then I think that code doesn't spin 100 ms with irqs blocked. As the debugging shows, most of the time is spent in msleep(10). Or am I missing something. > - Are there any reasons this shouldn't work for the ISP 1362, > after some more tweaks? One complication there is that a > driver for that chip should plan to support the gadget > functionality, HCD functionality, or both (and OTG). That > means factoring it can be a bit tricky. (I have some ideas > along those lines, not quite ready to share, for TDI243 > which has the same sort of configuration complexity.) Apart from the gadget functionality, there will also be differences in the HC functionality. In addition to the fifo ram mode, which is the only mode the 116x chips know of, 1362 has a random access mode to the onchip data ram and the "Done" bitmap for finished onchip transfers, which allows writing a more optimal driver for 1362. Having added an 116x support into Lothar's 1362 driver, it seems to me that it may be reasonable to write a separate driver for 1362. However, I won't be able to work on the 1362 code as I don't have that chip. > This looks quite promising!! Glad to hear! Thanks again for your comments. Olav ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
