First of all, thanks to Olav for writing this driver. I think we owe you one. This definitely is the cleaner approach for this chip. By augmenting the OHCI layer using the isp1362 driver, we had to pretend the isp was using DMA, when it was in fact not using DMA at all.
I had to make a few changes to port this driver to 2.6.6, as well as, straighten out some little endian / big endian stuff, but all that was pretty straight forward. I will send Olav the changes later for his review. I have usb storage devices working so far, but instead of simply trying to plug in more and more devices, I would rather use the more systematic testing approach presented by the usbtest project (http://www.linux-usb.org/usbtest/). So I have a keyspan USA-19 PDA adapter that should allow the test firmware to be programmed into and run the tests defined in the usbtest module. Here is where I am at: o The adapter works in its intended use as a usbserial device on PC workstations. o On my board (PPC750FX), I can get the keyspan/keyspan_pda drivers to successfully upload the driver's firmware, but it seems after the driver (i.e. ezusb called from keyspan) issues the CPUCS reset nothing happens. I have a usb PTD dump that shows that the reset is being issued to the device, but I don't know, if the device ~actually~ resets. o I have the test kernel module compiled; fxload and the test program are in place. Again I can upload the testfw (i.e. ep2_inout.ihx by Martin Diehl - I don't know exactly what it does), but I don't see any re-numeration happening. So I think I am running into the same problem here as when loading the keyspan driver. I have changed the usbtest module to also include the device IDs for this device similar to the USA-19Qi, but I am thinking it should be using the re-numeration ID's instead. I'm just a bit unclear on how exactly this test procedure is supposed to work. I am unclear whether the usbtest module should use the pre-renumeration IDs or the renumeration IDs. I am not too familiar with EZUSB, so I am only assuming that once you issue a reset the controller should disconnect itself from the port and reconnect itself with the new descriptors (correct?). Could it be the HCD simply does not detect a change in root hub status (it does however detect (un)plugging)? Is there an easy way to force renumeration without powering down the device? Any help or pointers would be greatly appreciated (maybe I'm even missing the obvious). There is a number of people interested in this isp116x HCD, so I would like to help verify it. I won't be able to test it with later kernels, but I should be able to help flush out any undetected bugs, if there are any. -------------- info ----------------------- o When loading the HCD and usbtest drivers (after adding device ID to id_table): usb 1-1: new full speed USB device using address 2 usbtest 1-1:1.0: FX2 device usbtest 1-1:1.0: full speed {control bulk-in bulk-out} tests (+alt) o Device listing (doesn't change with firmware upload, should it change?): bash-2.05# cat /proc/bus/usb/devices T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 2.06 S: Manufacturer=Linux 2.6.6 isp116x-hcd S: Product=ISP116x Host Controller S: SerialNumber=isp1362 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=06cd ProdID=0103 Rev=80.01 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbtest I: If#= 0 Alt= 1 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbtest E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=10ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=08(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=89(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=09(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=8a(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=0a(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms I: If#= 0 Alt= 2 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbtest E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=10ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=88(I) Atr=01(Isoc) MxPS= 256 Ivl=1ms E: Ad=08(O) Atr=01(Isoc) MxPS= 256 Ivl=1ms E: Ad=89(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=09(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=8a(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms E: Ad=0a(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms o uploading firmware (uisng fx2, but fx and an21 seem to work as well) bash-2.05# fxload -v -t fx2 -I testfw.hex -D /proc/bus/usb/001/002 microcontroller type: fx2 single stage: load on-chip memory open RAM hexfile image testfw.hex stop CPU write on-chip, addr 0x0000 len 3 (0x0003) write on-chip, addr 0x0043 len 3 (0x0003) write on-chip, addr 0x0128 len 3 (0x0003) write on-chip, addr 0x012c len 3 (0x0003) write on-chip, addr 0x0200 len 206 (0x00ce) ... WROTE: 218 bytes, 5 segments, avg 43 reset CPU o Running tests: # test 0 (seems to complete, but its only a NOP) bash-2.05# ./testusb -D /proc/bus/usb/001/002 -t 0 ./testusb: /procRunning test #0 TEST 0: NOP /bus/usb/001/002 may see only control tests /proc/bus/usb/001/002 test 0, 0.044597 secs # test 1 (hangs) bash-2.05# ./testusb -D /proc/bus/usb/001/002 -t 1 ./testusb: /procRunning test #1 TEST 1: write 512 bytes 1000 times /bus/usb/001/002 may see only control tests < ... becomes unresponsive ... > ------------------------------------------------------- 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
