Re: [linux-usb-devel] PROBLEM: Nokia 6280 + provided USB cable throws BUG's and hardlocks.
Am Dienstag, 26. September 2006 09:45 schrieb James: If i blacklist cdc-ether and cdc-acm, I cannot reproduce the error, and my phone works fine as a usb-storage device. Please black list each driver independently. It looks like cdc-ether, but verification is needed. Secondly, if you report a USB problem, lsusb is far more useful than lspci Regards Oliver - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] PROBLEM: Nokia 6280 + provided USB cable throws BUG's and hardlocks.
Hey Attempting to connect and use my Nokia 6280 with the supplied Nokia USB cable (reads: 'Type: CA-53') causes the kernel to through BUG's, and has on occasion caused a complete lock up of the system. This is running 2.6.18, and also occurs on the 2.6.17 series, which was what I was using when I received the phone. I have no idea about kernels before. Linux sara 2.6.18-ARCH #1 SMP PREEMPT Fri Sep 22 12:13:37 CEST 2006 i686 Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux Only modification to kernel is the addition of this a patch to add jmicron IDE support, however it still occurs without this patch applied. If i blacklist cdc-ether and cdc-acm, I cannot reproduce the error, and my phone works fine as a usb-storage device. I repeated the following trials to reproduce, each on a fresh boot: 1) Plug phone onto cable, already attached to computer. dmesg shows no recognition of the connection and it's the same as that on a clean boot. 2) Cancel on the phone, or select it's default mode 3) dmesg show's kernel BUG. dmesg after bug is below. If I select USB storage, the phone goes into storage mode fine, however upon leaving the storage mode, it drops back to it's default mode, and causes the above BUG. This seems to be the only BUG i can continually and safely reproduce, the others issues such as hardlocks seem random and sporadic, and have at times occured many minutes after unplugging the phone. Occasionally, it doesnt bug, and I experience a wide range of lockups or problems. I gave up my debugging when, after it entering default mode, all my app's started dying, and would not restart saying my libc.so file was too short, however it was fine after a reboot. The lockups are hard lockups, sysrq is completely ignored. a trace has been output only once upon lockup, which i am attempting to get off the phone in question. Kernel is a stock distro kernel, which has only one patch applied, to add support for a jmicron IDE controller, however removing this does not make a difference. This problem occurs on two different computers: desktop, Asus P5LD2 motherboard, 945P chipset, Pentium D. SMP kernel laptop, Early centrino, pretty sure it's 855 chipset, Pentium M 1.4, SMP distro kernel. I've attempted to CC all the correct people from the maintainer's file, sorry if i have left anyone out or added anyone extra by accident. Thanks for your help, id there's anything you'd like me to try or further information you would like, dont hesitate to ask, im greatful for anything you can do to help. James Below are all the mentioned things in REPORTING-BUGS. Excuse any nvidia mentions in the proc files, nvidia was blacklisted before booting to do the tests and was never loaded for the tests. nor was it loaded in the dmesg below. config is linked as I was unsure whether it was too big. it's a stock distro config so it has nearly everythin. http://archlinux.org/~james/config Linux version 2.6.18-ARCH ([EMAIL PROTECTED]) (gcc version 4.1.1) #1 SMP PREEMPT Fri Sep 22 12:13:37 CEST 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ffa (usable) BIOS-e820: 3ffa - 3ffae000 (ACPI data) BIOS-e820: 3ffae000 - 3ffe (ACPI NVS) BIOS-e820: 3ffe - 4000 (reserved) BIOS-e820: ffb8 - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000ff780 On node 0 totalpages: 262048 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 32672 pages, LIFO batch:7 DMI 2.3 present. ACPI: RSDP (v002 ACPIAM) @ 0x000fad00 ACPI: XSDT (v001 A M I OEMXSDT 0x05000531 MSFT 0x0097) @ 0x3ffa0100 ACPI: FADT (v003 A M I OEMFACP 0x05000531 MSFT 0x0097) @ 0x3ffa0290 ACPI: MADT (v001 A M I OEMAPIC 0x05000531 MSFT 0x0097) @ 0x3ffa0390 ACPI: OEMB (v001 A M I AMI_OEM 0x05000531 MSFT 0x0097) @ 0x3ffae040 ERROR: Invalid checksum ACPI: MCFG (v001 A M I OEMMCFG 0x05000531 MSFT 0x0097) @ 0x3ffa85e0 ACPI: DSDT (v001 A0227 A0227000 0x INTL 0x02002026) @ 0x ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by
Re: [linux-usb-devel] /drivers/usb/class/cdc-acm.c patch question, please cc
Am Montag, 25. September 2006 20:22 schrieb Ryan Moszynski: here is the info you requested. i got it with my 2.6.15 running as well as 2.6.18. the dmesg's are different but the lsusb's are the same. just a guess, i think that this line from lsusb ## bMaxPacketSize064 ## should be 2048 for evdo cards, if this is the same as my maxSize It seems to me that under both kernels you are using usbserial. Why do you patch the acm driver at all? Regards Oliver - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Issue with umount and nautilus
Hi, I have a multifunction PCMCIA card hosting a USB and UART port. Basically I am facing two problems while doing some operations. 1. PCMCIA card removal while bulk transfer through USB key in progress causes oops and crashes. The log is given bellow. Unable to handle kernel paging request at virtual address baf94038 printing eip: c01e7a94 *pde = Oops: [#1] Modules linked in: vfat fat sd_mod usb_storage scsi_mod spca5xx videodev myhcd_cs serial_cs myhcd 8250 serial_core parport_pc lp parport autofs4 i2c_dev i2c_core rfcomm l2cap bluetooth sunrpc dm_mod ipv6 ohci_hcd ehci_hcd shpchp snd_intel8x0m snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc sis900 mii joydev ext3 jbd CPU:0 EIP:0060:[c01e7a94]Not tainted VLI EFLAGS: 00010293 (2.6.16.28 #1) EIP is at kobject_uevent+0x34/0x490 eax: c03631df ebx: c7dad07f ecx: b0048000 edx: baf94010 esi: c2abaa00 edi: cca81140 ebp: c5ee2f50 esp: c5ee2ed4 ds: 007b es: 007b ss: 0068 Process umount (pid: 5292, threadinfo=c5ee2000 task=c0050550) Stack: 0caa10840 cbeef1c0 c0f80820 c03a0c1c baf94010 c03631df 0001 0001 cbeeef20 cbeeef10 c0f80840 0002 caa10840 cbeef1c0 c0f80820 c7dad07f c2abaa00 cca81140 c5ee2f50 c0167c1e c2abaa3c c2abaa00 c0167e69 Call Trace: [c0167c1e] kill_block_super+0x1e/0x40 [c0167e69] deactivate_super+0x99/0xc0 [c017e73a] sys_umount+0x4a/0x2a0 [c013fef5] audit_syscall_entry+0x135/0x160 [c0104c6a] do_syscall_trace+0x21a/0x240 [c017e9a5] sys_oldumount+0x15/0x20 [c0102e7d] syscall_call+0x7/0xb Code: 40 89 74 24 44 89 7c 24 48 89 6c 24 4c 89 44 24 10 0f 87 90 03 00 00 ff 24 95 b8 6a 34 c0 b8 8f be 35 c0 89 44 24 14 8b 54 24 10 8b 42 28 85 c0 89 c6 0f 84 d7 03 00 00 8b 6e 54 85 ed 74 17 8b I went through the mailing list and found a thread discussing the same crash stack. But it seems the above issue has been resolved in 2.6.16.28. Then what might cause the above crash.Please suggest. 2. Suspending the card (pccardctl suspend) while bulk transfer through USB key in progress also causes oops and crashes. Just to let you know by suspending the PCMCIA card, PCMCIA sub-system powers off the socket and hence the card becomes pwered off. The log is given below. Unable to handle kernel paging request at virtual address 6f74732f printing eip: c01e76bd *pde = Oops: [#2] Modules linked in: vfat fat sd_mod usb_storage scsi_mod spca5xx videodev myhcd_cs serial_cs myhcd 8250 serial_core parport_pc lp parport autofs4 i2c_dev i2c_core rfcomm l2cap bluetooth sunrpc dm_mod ipv6 ohci_hcd ehci_hcd shpchp snd_intel8x0m snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc sis900 mii joydev ext3 jbd CPU: 0 EIP: 0060:[c01e76bd] Not tainted VLI EFLAGS: 00010202 (2.6.16.28 #1) EIP is at kobject_get_path+0x2d/0xd0 eax: ebx: 002c ecx: edx: esi: c7daa8b0 edi: 6f74732f ebp: 002b esp: c3b7eed8 ds: 007b es: 007b ss: 0068 Process nautilus (pid: 2295, threadinfo=c3b7e000 task=c221e550) Stack: 0c01e7a3d 00d0 c7f13e48 c3b7ef18 c6b00780 c92f53d8 c7f13da0 07ae c01de088 c92f53d8 001a c3b7ef1c cada4852 07ae c3b7ef20 c0362a33 0008 0002 0010 cada4852 c03ab560 c01ddf80 c03ab5d4 c01e7c25 Call Trace: [c01e7a3d] add_uevent_var+0x7d/0xa0 [c01de088] block_uevent+0x108/0x210 [c01ddf80] block_uevent+0x0/0x210 [c01e7c25] kobject_uevent+0x1c5/0x490 [c0167c1e] kill_block_super+0x1e/0x40 [c0167e69] deactivate_super+0x99/0xc0 [c015f847] filp_close+0x47/0x90 [c0102e7d] syscall_call+0x7/0xb Code: 56 89 c6 53 bb 01 00 00 00 83 ec 10 89 54 24 04 31 d2 89 44 24 08 90 8d b4 26 00 00 00 00 8b 3e 85 ff 74 1d b9 ff ff ff ff 89 d0 f2 ae f7 d1 49 8b 76 24 8d 2c 19 8d 5d 01 85 f6 75 e1 85 db 75 This seems the nautilus process crash. So I tried the same with console and KDE environment and did not get any crash. So is this really a nautilus crash for which I need not to worry. Thanks, Rasmit. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Growth alert that brings profit
I'm gutted, distraught and close to tears. But most of all I'm proud. The lads playedchampions was over for another four years. Gerrard was far more impressive than Lampard in Germany, and McClaren mustArgentina lit up Group C with some great efforts, most notably Esteban Cambiasso'sInternet2 announced a partnership to deploy a highly reliable, high capacity nationwide network.every American very, very proud.The U.S. Department of State has a special website just for students, parents, and teachers.The Office of Electronic Information, Bureau of Public Affairs, manages this site as aIf he was to cast off his cloak of conservatism, he should go for Gerrard, who hascame from the group stages.cost him a second World Cup title.Called ESnet4, the new network created through this partnership will initially operateItaly beat France 5-3 in a penalty shoot-out to win the World Cup after an absorbing 1-1 draw in Berlin.participate in the DOE's scientific research efforts.me, the final was like the whole tournament - started well then deterioratedHow to make England's gifted midfield work - and decide whether Lampard and Gerrard can play together?Afghanistan in its efforts to counter cultivation, production.McClaren was almost absolved from blame for England's poor 2006 World Cup finalsof having a business address.run the ball into the corner to preserve a 0-0 draw at home to Liverpool on the - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] FW: Fwd: Re: USB DISK does not work
On Mon, 25 Sep 2006, Steve Calfee wrote: This indicates that the problem is a small hardware incompatibility, as I have said before. We attached a High Speed hub to our system and inserted this disk in the hub. The device works perfectly in such mode. This is more than a small hardware problem. Assuming this HS hub was self powered, it indicates either your device took too much VBUS current, your host could not supply enough vbus power, your host transceiver has a problem, OR you have a major fussy device in receiving data. And even with this test info I have to assume that you used the same cable (a possible failure) between the good hub and the root hub. We also attached a Full speed hub (used in both bus and self powered mode) to our system and inserted this disk in the hub. The device fails to work in such mode. The reasons for device failure are identicle to case when it is directly connected to our system. Probably the high-speed hub re-buffers or re-times the signals whereas the full-speed hub doesn't. What did your bus analyzer say in this case? Full speed is much more forgiving than high speed. I have seen a high speed mass storage device which would fail during enumeration in full speed (a small percentage of the time). HS is supposed to fall back to FS for all usb 2.0 devices, but it does seem that occasionally some devices are not 100% compliant :) The above experiments do not indicate hardware incompatibility. Do you agree ? Not in my opinion, this seems likes a major hardware problem somewhere. I agree with Steve. The experiments _definitely_ indicate a hardware incompatibility. If it were a software problem then the presence or absence of intermediate hubs wouldn't make any difference. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] RNDIS ethernet gadget treated as CDC in 2.6.18 even if RNDIS host support enabled
Hello,
I'm working with PXA27x hardware and going to check USB ethernet gadget (RNDIS
mode)
with 2.6.18 on PC host. After a short investigation, I was stucked because:
1) help on CONFIG_USB_ETH_RNDIS (taken from drivers/usb/gadget/Kconfig) says
that
RNDIS-aware configuration will be second (behind CDC);
2) gadget code (taken from drivers/usb/gadget/ether.c) says list the RNDIS
config
first, to make Microsoft's drivers happy;
3) choose_configuration() from drivers/usb/core/hub.c will choose 2nd
configuration
even if CONFIG_USB_NET_RNDIS_HOST is enabled.
I believe that the valid configuration order (if RNDIS is enabled) is RNDIS
1st, CDC
2nd (mostly to be compatible with Microsoft stuff, as comment from 2) says).
But,
if this is true, then choose_configuration() works wrong - if RNDIS support is
enabled,
it should choose 1st configuration and relax about others. Moreover, since
RNDIS host
support may be modular, CONFIG_USB_NET_RNDIS_HOST_MODULE should also be taken
into
account. So, here is a tiny patch.
--- 2.6.18/drivers/usb/core/hub.c 2006-09-22 14:49:57.0 +0400
+++ 2.6.18.devel/drivers/usb/core/hub.c 2006-09-26 18:32:25.0 +0400
@@ -1244,10 +1244,11 @@
desc-bInterfaceClass == USB_CLASS_COMM
desc-bInterfaceSubClass == 2
desc-bInterfaceProtocol == 0xff) {
-#ifndef CONFIG_USB_NET_RNDIS_HOST
- continue;
-#else
+#if defined(CONFIG_USB_NET_RNDIS_HOST) ||
defined(CONFIG_USB_NET_RNDIS_HOST_MODULE)
best = c;
+ break;
+#else
+ continue;
#endif
}
What do you think about it ?
TIA, Dmitry
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Fwd: USB device not getting detected.
pankaj chauhan wrote: dave, Thanks alot for useful information. Is there any way in which i can verify that is it the fault of device (i.e device is trying to draw more current) or my host controller is faulty (as you mentioned that some Host controllers behave in such way)? lsusb -v | grep -i power will show you the numbers that usb-core is working with. If youve got another linux box, and/or another hub, try some cross-testing, see if you can isolate it. Thanks PC --- David Brownell [EMAIL PROTECTED] wrote: i am using 2.6.11, Try to use a more current kernel. Likely it won't matter here, but 2.6.11 is over 18 months old by now ... :) and EHCI HCD. during boot up i get following message: usb 1-0:1.0: over-current change on port 1 and after the system is up none of the USB device connected to USB port are detected. can you please tell me what over-current change mean. USB devices can draw a certain amount of current, with a maximum of 500 mA in high power configurations. USB hubs, like root hubs, may be able to detect when that current limit is exceeded; if so, it's reported as an over current error. and Is this error responsible for my device not getting detected. Likely. When a port issues an overcurrent fault, the device connected to it is disconnected. We have seen cases where some USB controllers (EHCI and UHCI, I don't recall it with OHCI) *wrongly* report such over-current errors ... at least, wrongly in the sense that no device is connected, so we think the motherboard must be at fault, badly wired or whatever. - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PROBLEM: Nokia 6280 + provided USB cable throws BUG's and hardlocks.
On 9/26/06, Oliver Neukum [EMAIL PROTECTED] wrote: Am Dienstag, 26. September 2006 09:45 schrieb James: If i blacklist cdc-ether and cdc-acm, I cannot reproduce the error, and my phone works fine as a usb-storage device. Please black list each driver independently. It looks like cdc-ether, but verification is needed. Secondly, if you report a USB problem, lsusb is far more useful than lspci was cdc-ether, first try gave me a hard lock, whereas with cdc-acm, I couldnt cause a bug or lock no matter what I tried. James -- excuse me for not replying to all the first time Below is lsusb -vv as root: Bus 005 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 Linux 2.6.18-ARCH uhci_hcd iProduct2 UHCI Host Controller iSerial 1 :00:1d.3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 PortPwrCtrlMask0xf4 Hub Port Status: Port 1: .0100 power Port 2: .0100 power Bus 001 Device 002: ID 045e:00db Microsoft Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x045e Microsoft Corp. idProduct 0x00db bcdDevice1.73 iManufacturer 1 Microsoft iProduct2 Natural(r) Ergonomic Keyboard 4000 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.11 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 60 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.11 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report
Re: [linux-usb-devel] Webcam Driver
On Tue, 2006-09-26 at 17:35 +1200, Shane wrote: I have a USB webcam with no linux driver G My windows driver names the device and driver as CMOS 100K-X Rev 2.01.0025.0 #2 lsusb sees the device as Bus 001 Device 007: ID 0572:0001 Conexant Systems (Rockwell), Inc. Ezcam II WebCam After a google I find no linux drivers for the device. Not to be outdone I am researching the possibility of writing a driver myself I have installed SnoopyPro in windows, and captured around 2600 packets watching the device connect, be interrogated by the host, idle for a period, and data being sent for a webcam viewer application My next question is.. what now? Usb-robot doesnt appear to handle isochronous devices. Thanks in advance Shane - Try to find wich usb chip is used inside, In this webcam, three different chipsets are used IIRC, check the label to see which type or check with, lsusb -v, sane-find-scanner -v -v 1. CPIA (Conexant), 2. OV511 (OV6620) and 3. ICM532 (UVT8532) At this moment all three are supported by a linux driver, but your usb vendor and product id is not always added to the program. Try sane-find-scanner -v -v to detect if it is a ICM532 (supported by the spca5xx kernel module). -- m.vr.gr. Gerard Klaver - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] HID interrupt endpoint read
On Tue, 26 Sep 2006, Lisa Ray wrote:
Hi
I have HID device which has 2 interrupt endpoints 0x81 for output and
0x02 for input. I tried hiddev ioctl approach but was unable to get any
response from device my command is 6 bytes char array {0x01 ,
0x02,'C','v',-x03,0x06,0x00}.
In case you didn't already realize this, endpoint 0x81 is _input_ and
endpoint 0x02 is _output_. Look again at your lsusb output. If you mixed
them up, it could explain a lot.
1st byts is report id and rest device command, I tried to write to
device interrupt endpoint by using FILL_INT_URB(hid-outurb,,0x081)
; usb_submit_urb(hid-outurb). I had added this function call at end of
hid-probe() in hid-core.c. But I am getting bogus endpoints error and
device is not responding.
Can you be more specific? What error exactly do you get? Does the error
occur when you submit the URB or when it completes?
lsusb -vvv shows 0x081 (output) and 0x02 (input) endpoints same thing
works on windows.
Alan Stern
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] FW: Fwd: Re: USB DISK does not work
Hi hub was self powered, it indicates either your device took too much VBUS current, your host could not supply enough vbus power, your host transceiver has a problem, OR you have a major fussy device in receiving data. We have couple of other 1.1 devices who works with our system in bus powered mode. Obviously for such devices, the host could supply enough vbus power and host transreceiver did not have any problem. What did your bus analyzer say in this case? Full speed is much more forgiving than high speed. The analyzer indicated that the device failed to generate ACK for certain CBW (31 byte OUT transaction) three times in row. That caused ohci driver to reset the device. Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Calfee Sent: Monday, September 25, 2006 4:33 PM To: linux-usb-devel@lists.sourceforge.net Subject: [linux-usb-devel] FW: Fwd: Re: USB DISK does not work This indicates that the problem is a small hardware incompatibility, as I have said before. We attached a High Speed hub to our system and inserted this disk in the hub. The device works perfectly in such mode. This is more than a small hardware problem. Assuming this HS hub was self powered, it indicates either your device took too much VBUS current, your host could not supply enough vbus power, your host transceiver has a problem, OR you have a major fussy device in receiving data. And even with this test info I have to assume that you used the same cable (a possible failure) between the good hub and the root hub. We also attached a Full speed hub (used in both bus and self powered mode) to our system and inserted this disk in the hub. The device fails to work in such mode. The reasons for device failure are identicle to case when it is directly connected to our system. What did your bus analyzer say in this case? Full speed is much more forgiving than high speed. I have seen a high speed mass storage device which would fail during enumeration in full speed (a small percentage of the time). HS is supposed to fall back to FS for all usb 2.0 devices, but it does seem that occasionally some devices are not 100% compliant :) The above experiments do not indicate hardware incompatibility. Do you agree ? Not in my opinion, this seems likes a major hardware problem somewhere. Regards, Steve -- --- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforge CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Fwd: Re: FW: Fwd: Re: USB DISK does not work
Hi hub was self powered, it indicates either your device took too much VBUS current, your host could not supply enough vbus power, your host transceiver has a problem, OR you have a major fussy device in receiving data. We have couple of other 1.1 devices who works with our system in bus powered mode. Obviously for such devices, the host could supply enough vbus power and host transreceiver did not have any problem. The fact that device A works and device B doesn't on the same port/cables etc does not elliminate the possibility of a VBUS power problem. All devices use different amounts of power, have different needs on vbus rise times, and even different +- voltage level requirements on the data lines. If everything was in spec you would not be having problems. What did your bus analyzer say in this case? Full speed is much more forgiving than high speed. The analyzer indicated that the device failed to generate ACK for certain CBW (31 byte OUT transaction) three times in row. That caused ohci driver to reset the device. The no response is actually quite a clever part of the spec. The problem is what does one end of a communication do if there is a detected error? If something bad is going on, the worst thing that you can do is try to send on the problem data path, so sending a hypothetical ERR PID would just cause more problems, like what if the ERR PID was lost? So the proper response from either end of a communicaton with a detected problem (such as no sync, CRC, bad PID etc) is no response. All device hardware is supposed to automatically check things like PID, CRC, EOP etc and then respond with ACK if the data was received and it is ready for more or NAK which means data is received correctly but the device cannot handle it right now. If there is no response, the hardware will retry quickly a few times but then give up and let higher level software deal with it (such as resetting the device). In your case there is either a major data path problem and data cannot be passed to the device OR your device is dead and cannot respond to anything. I had a HS USB flash drive that would fail during enumeration as a full speed device about 5% of the time. A bus reset would not recover the device. A port power off then on would get it started again. I don't remember the brand of that key, What is your key string descriptors, maybe I will remember if that is the flaky device if I have a name to remind me. Regards, Steve - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH revision] USB: fix autosuspend when CONFIG_PM isn't set
This patch (as791b) fixes things up to avoid compiler warnings or
errors when CONFIG_USB_SUSPEND or CONFIG_PM isn't set.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
This revises the as791 patch (fix statement with no effect) submitted
yesterday. It fixes compile problems when either CONFIG_USB_SUSPEND or
CONFIG_PM isn't set. It includes the changes suggested by Andrew and
goes beyond them.
Index: usb-2.6/drivers/usb/core/usb.h
===
--- usb-2.6.orig/drivers/usb/core/usb.h
+++ usb-2.6/drivers/usb/core/usb.h
@@ -36,6 +36,16 @@ extern int usb_resume_both(struct usb_de
extern int usb_port_suspend(struct usb_device *dev);
extern int usb_port_resume(struct usb_device *dev);
+static inline void usb_pm_lock(struct usb_device *udev)
+{
+ mutex_lock_nested(udev-pm_mutex, udev-level);
+}
+
+static inline void usb_pm_unlock(struct usb_device *udev)
+{
+ mutex_unlock(udev-pm_mutex);
+}
+
#else
#define usb_suspend_both(udev, msg)0
@@ -45,6 +55,8 @@ static inline int usb_resume_both(struct
}
#define usb_port_suspend(dev) 0
#define usb_port_resume(dev) 0
+static inline void usb_pm_lock(struct usb_device *udev) {}
+static inline void usb_pm_unlock(struct usb_device *udev) {}
#endif
@@ -58,7 +70,11 @@ extern int usb_autoresume_device(struct
#else
#define usb_autosuspend_device(udev, dec_busy_cnt) do {} while (0)
-#define usb_autoresume_device(udev, inc_busy_cnt) 0
+static inline int usb_autoresume_device(struct usb_device *udev,
+ int inc_busy_cnt)
+{
+ return 0;
+}
#endif
Index: usb-2.6/drivers/usb/core/hub.c
===
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -1814,7 +1814,7 @@ static int remote_wakeup(struct usb_devi
* to the parent hub! */
usb_lock_device(udev);
- mutex_lock_nested(udev-pm_mutex, udev-level);
+ usb_pm_lock(udev);
if (udev-state == USB_STATE_SUSPENDED) {
dev_dbg(udev-dev, usb %sresume\n, wakeup-);
/* TRSMRCY = 10 msec */
@@ -1823,7 +1823,7 @@ static int remote_wakeup(struct usb_devi
if (status == 0)
udev-dev.power.power_state.event = PM_EVENT_ON;
}
- mutex_unlock(udev-pm_mutex);
+ usb_pm_unlock(udev);
if (status == 0)
usb_autoresume_device(udev, 0);
Index: usb-2.6/include/linux/usb.h
===
--- usb-2.6.orig/include/linux/usb.h
+++ usb-2.6/include/linux/usb.h
@@ -381,10 +381,10 @@ struct usb_device {
int maxchild; /* Number of ports if hub */
struct usb_device *children[USB_MAXCHILDREN];
+ int pm_usage_cnt; /* usage counter for autosuspend */
#ifdef CONFIG_PM
struct work_struct autosuspend; /* for delayed autosuspends */
struct mutex pm_mutex; /* protects PM operations */
- int pm_usage_cnt; /* usage counter for autosuspend */
unsigned auto_pm:1; /* autosuspend/resume in progress */
unsigned do_remote_wakeup:1;/* remote wakeup should be enabled */
Index: usb-2.6/drivers/usb/core/driver.c
===
--- usb-2.6.orig/drivers/usb/core/driver.c
+++ usb-2.6/drivers/usb/core/driver.c
@@ -304,11 +304,11 @@ int usb_driver_claim_interface(struct us
dev-driver = driver-drvwrap.driver;
usb_set_intfdata(iface, priv);
- mutex_lock_nested(udev-pm_mutex, udev-level);
+ usb_pm_lock(udev);
iface-condition = USB_INTERFACE_BOUND;
mark_active(iface);
iface-pm_usage_cnt = !(driver-supports_autosuspend);
- mutex_unlock(udev-pm_mutex);
+ usb_pm_unlock(udev);
/* if interface was already added, bind now; else let
* the future device_add() bind it, bypassing probe()
@@ -357,11 +357,11 @@ void usb_driver_release_interface(struct
dev-driver = NULL;
usb_set_intfdata(iface, NULL);
- mutex_lock_nested(udev-pm_mutex, udev-level);
+ usb_pm_lock(udev);
iface-condition = USB_INTERFACE_UNBOUND;
mark_quiesced(iface);
iface-needs_remote_wakeup = 0;
- mutex_unlock(udev-pm_mutex);
+ usb_pm_unlock(udev);
}
EXPORT_SYMBOL(usb_driver_release_interface);
@@ -792,7 +792,7 @@ EXPORT_SYMBOL_GPL_FUTURE(usb_deregister)
#ifdef CONFIG_PM
-/* Caller has locked udev-pm_mutex */
+/* Caller has locked udev's pm_mutex */
static int suspend_device(struct usb_device *udev, pm_message_t msg)
{
struct usb_device_driver*udriver;
@@ -819,7 +819,7 @@ done:
return status;
}
-/* Caller has locked udev-pm_mutex */
+/* Caller has locked udev's pm_mutex */
static int resume_device(struct usb_device *udev)
{
struct
[linux-usb-devel] [PATCH 3b/3] OHCI: add auto-stop support
This patch (as790b) adds autostop support to ohci-hcd: the driver
will automatically stop the host controller when no devices have been
connected for at least one second. This feature is useful when the
USB autosuspend facility isn't available, such as when
CONFIG_USB_SUSPEND hasn't been set.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
This revised version of the patch includes a fix so that it will build
correctly when CONFIG_PM isn't set.
Index: usb-2.6/drivers/usb/host/ohci-hcd.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-hcd.c
+++ usb-2.6/drivers/usb/host/ohci-hcd.c
@@ -715,17 +715,8 @@ static irqreturn_t ohci_irq (struct usb_
return IRQ_NOTMINE;
}
- /* NOTE: vendors didn't always make the same implementation
-* choices for RHSC. Sometimes it triggers on an edge (like
-* setting and maybe clearing a port status change bit); and
-* it's level-triggered on other silicon, active until khubd
-* clears all active port status change bits. Poll by timer
-* til it's fully debounced and the difference won't matter.
-*/
if (ints OHCI_INTR_RHSC) {
ohci_vdbg (ohci, rhsc\n);
- ohci_writel (ohci, OHCI_INTR_RHSC, regs-intrdisable);
- hcd-poll_rh = 1;
ohci-next_statechange = jiffies + STATECHANGE_DELAY;
ohci_writel (ohci, OHCI_INTR_RHSC, regs-intrstatus);
usb_hcd_poll_rh_status(hcd);
@@ -743,13 +734,18 @@ static irqreturn_t ohci_irq (struct usb_
if (ints OHCI_INTR_RD) {
ohci_vdbg (ohci, resume detect\n);
ohci_writel (ohci, OHCI_INTR_RD, regs-intrstatus);
- if (hcd-state != HC_STATE_QUIESCING)
+ hcd-poll_rh = 1;
+ if (ohci-autostop) {
+ spin_lock (ohci-lock);
+ ohci_rh_resume (ohci);
+ spin_unlock (ohci-lock);
+ } else
usb_hcd_resume_root_hub(hcd);
}
if (ints OHCI_INTR_WDH) {
if (HC_IS_RUNNING(hcd-state))
- ohci_writel (ohci, OHCI_INTR_WDH, regs-intrdisable);
+ ohci_writel (ohci, OHCI_INTR_WDH, regs-intrdisable);
spin_lock (ohci-lock);
dl_done_list (ohci, ptregs);
spin_unlock (ohci-lock);
Index: usb-2.6/drivers/usb/host/ohci.h
===
--- usb-2.6.orig/drivers/usb/host/ohci.h
+++ usb-2.6/drivers/usb/host/ohci.h
@@ -388,6 +388,7 @@ struct ohci_hcd {
u32 hc_control; /* copy of hc control reg */
unsigned long next_statechange; /* suspend/resume */
u32 fminterval; /* saved register */
+ unsignedautostop:1; /* rh auto stopping/stopped */
unsigned long flags; /* for HC bugs */
#defineOHCI_QUIRK_AMD756 0x01/* erratum #4 */
Index: usb-2.6/drivers/usb/host/ohci-hub.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-hub.c
+++ usb-2.6/drivers/usb/host/ohci-hub.c
@@ -41,31 +41,20 @@ static void ohci_rhsc_enable (struct usb
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
- hcd-poll_rh = 0;
ohci_writel (ohci, OHCI_INTR_RHSC, ohci-regs-intrenable);
}
-#ifdef CONFIG_PM
-
#define OHCI_SCHED_ENABLES \
(OHCI_CTRL_CLE|OHCI_CTRL_BLE|OHCI_CTRL_PLE|OHCI_CTRL_IE)
static void dl_done_list (struct ohci_hcd *, struct pt_regs *);
static void finish_unlinks (struct ohci_hcd *, u16 , struct pt_regs *);
-static int ohci_restart (struct ohci_hcd *ohci);
-static int ohci_bus_suspend (struct usb_hcd *hcd)
+static int ohci_rh_suspend (struct ohci_hcd *ohci, int autostop)
+__releases(ohci-lock)
+__acquires(ohci-lock)
{
- struct ohci_hcd *ohci = hcd_to_ohci (hcd);
int status = 0;
- unsigned long flags;
-
- spin_lock_irqsave (ohci-lock, flags);
-
- if (unlikely(!test_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags))) {
- spin_unlock_irqrestore (ohci-lock, flags);
- return -ESHUTDOWN;
- }
ohci-hc_control = ohci_readl (ohci, ohci-regs-control);
switch (ohci-hc_control OHCI_CTRL_HCFS) {
@@ -81,15 +70,16 @@ static int ohci_bus_suspend (struct usb_
ohci_dbg (ohci, needs reinit!\n);
goto done;
case OHCI_USB_SUSPEND:
- ohci_dbg (ohci, already suspended\n);
- goto done;
+ if (!ohci-autostop) {
+ ohci_dbg (ohci, already suspended\n);
+ goto done;
+ }
}
- ohci_dbg (ohci, suspend root hub\n);
+
Re: [linux-usb-devel] Fwd: Re: FW: Fwd: Re: USB DISK does not work
The fact that device A works and device B doesn't on the same port/cables etc does not eliminate the possibility of a VBUS power problem. All devices use different amounts of power, have different needs on vbus rise times, and even different +- voltage level requirements on the data lines. If everything was in spec you would not be having problems. Agreed. If there is no response, the hardware will retry quickly a few times but then give up and let higher level software deal with it (such as resetting the device). In your case there is either a major data path problem and data cannot be passed to the device OR your device is dead and cannot respond to anything. I used the patch provided by Alan to increase the no. of retries. The patch caused the ohci hardware to retry the command 4 times in a row instead of 3 times. So the host controller is willing to talk to device but the device appear to be dead. What is your key string descriptors ? 3SYSTEM USB POCKET DISK Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Calfee Sent: Tuesday, September 26, 2006 10:01 AM To: linux-usb-devel@lists.sourceforge.net Subject: Re: [linux-usb-devel] Fwd: Re: FW: Fwd: Re: USB DISK does not work Hi hub was self powered, it indicates either your device took too much VBUS current, your host could not supply enough vbus power, your host transceiver has a problem, OR you have a major fussy device in receiving data. We have couple of other 1.1 devices who works with our system in bus powered mode. Obviously for such devices, the host could supply enough vbus power and host transreceiver did not have any problem. The fact that device A works and device B doesn't on the same port/cables etc does not elliminate the possibility of a VBUS power problem. All devices use different amounts of power, have different needs on vbus rise times, and even different +- voltage level requirements on the data lines. If everything was in spec you would not be having problems. What did your bus analyzer say in this case? Full speed is much more forgiving than high speed. The analyzer indicated that the device failed to generate ACK for certain CBW (31 byte OUT transaction) three times in row. That caused ohci driver to reset the device. The no response is actually quite a clever part of the spec. The problem is what does one end of a communication do if there is a detected error? If something bad is going on, the worst thing that you can do is try to send on the problem data path, so sending a hypothetical ERR PID would just cause more problems, like what if the ERR PID was lost? So the proper response from either end of a communicaton with a detected problem (such as no sync, CRC, bad PID etc) is no response. All device hardware is supposed to automatically check things like PID, CRC, EOP etc and then respond with ACK if the data was received and it is ready for more or NAK which means data is received correctly but the device cannot handle it right now. If there is no response, the hardware will retry quickly a few times but then give up and let higher level software deal with it (such as resetting the device). In your case there is either a major data path problem and data cannot be passed to the device OR your device is dead and cannot respond to anything. I had a HS USB flash drive that would fail during enumeration as a full speed device about 5% of the time. A bus reset would not recover the device. A port power off then on would get it started again. I don't remember the brand of that key, What is your key string descriptors, maybe I will remember if that is the flaky device if I have a name to remind me. Regards, Steve -- --- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforge CID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Webcam Driver
On Wednesday 27 September 2006 04:11, Gerard Klaver wrote: On Tue, 2006-09-26 at 17:35 +1200, Shane wrote: I have a USB webcam with no linux driver G My windows driver names the device and driver as CMOS 100K-X Rev 2.01.0025.0 #2 lsusb sees the device as Bus 001 Device 007: ID 0572:0001 Conexant Systems (Rockwell), Inc. Ezcam II WebCam After a google I find no linux drivers for the device. Not to be outdone I am researching the possibility of writing a driver myself I have installed SnoopyPro in windows, and captured around 2600 packets watching the device connect, be interrogated by the host, idle for a period, and data being sent for a webcam viewer application My next question is.. what now? Usb-robot doesnt appear to handle isochronous devices. Thanks in advance Shane - Try to find wich usb chip is used inside, In this webcam, three different chipsets are used IIRC, check the label to see which type or check with, lsusb -v, sane-find-scanner -v -v 1. CPIA (Conexant), 2. OV511 (OV6620) and 3. ICM532 (UVT8532) At this moment all three are supported by a linux driver, but your usb vendor and product id is not always added to the program. Try sane-find-scanner -v -v to detect if it is a ICM532 (supported by the spca5xx kernel module). I have run lsusb -v and sane-find-scanner -v -v as you suggested (The box/labelling for the camera has long gone) I have to say I cannot see the chipset mentioned in the outputs, I have pasted the [edited] outputs at pastebin if you wish to look over them yourself lsusb -v http://pastebin.com/794994 and sane-find-scanner -v -v http://pastebin.com/795000 Supposing the chipsets are supported, is it just a matter of modprobe library ? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Fwd: Re: FW: Fwd: Re: USB DISK does not work
On Tue, 26 Sep 2006, Vivek Dharmadhikari wrote: I used the patch provided by Alan to increase the no. of retries. The patch caused the ohci hardware to retry the command 4 times in a row instead of 3 times. For some strange reason, the OHCI specification document doesn't say exactly how the retry mechanism should work. There is a 2-bit error counter, normally set to 0. It gets reset to 0 every time a transaction succeeds. When a transaction fails the counter gets incremented, unless it is already equal to 2, in which case the host controller returns an error. The spec doesn't say what should happen if the counter is initially equal to 3. Normally you would expect it to just stay there, with no change, no errors reported, and unlimited retries. But apparently your hardware increments it to 0, giving a total of 4 attempts instead of 3. So the host controller is willing to talk to device but the device appear to be dead. Actually the device is not dead. Not at all. If it were then the class-specific device reset (which is nothing more than a USB control transfer) would fail. But it doesn't fail; it succeeds and the device continues operating. Until the command is retried... I think it's significant that the device always fails at exactly the same spot. That is, one particular command causes the failure. It could be that the device doesn't want to carry out the command -- but we know that it _does_ carry out the command when running at full speed or using a self-powered high-speed hub. More likely the bit pattern of that command string is, for some reason, not received correctly by the device. Maybe it thinks there's a bit-stuffing violation when there really isn't. However this is sheer speculation. We don't really have enough information to say why it doesn't work. IMO you should just accept that this is hardware problem which can't be solved in software and won't get better, and either use that self-powered hub all the time or else use a different brand of flash memory device. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Fwd: Re: FW: Fwd: Re: USB DISK does not work
Actually the device is not dead. Not at all. If it were then the class-specific device reset (which is nothing more than a USB control transfer) would fail. Agreed ! I actually meant to say that data path from device to host is somehow broken. The fact that the device always responds to class specific device reset is enough to prove that device is alive. I think it's significant that the device always fails at exactly the same spot. That is, one particular command causes the failure. The device do not fails exactly at the same spot. Early on the device always failed to respond to MODE_SENSE(6). After updating unusal_dev.h to not send MODE_SENSE(6) command, the device failed to generate ACK for READ_10 command and other command. In some instance, I was able to mount and access the files on the disks and the device worked perfectly(no ACK issues). I have also noted that the device either generate ACK or no handshake for OUT 31 transaction. But the device never generated NAK for OUT 31 transaction. Thanks -Original Message- From: Alan Stern [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 26, 2006 1:21 PM To: Vivek Dharmadhikari Cc: Steve Calfee; linux-usb-devel@lists.sourceforge.net Subject: Re: [linux-usb-devel] Fwd: Re: FW: Fwd: Re: USB DISK does not work On Tue, 26 Sep 2006, Vivek Dharmadhikari wrote: I used the patch provided by Alan to increase the no. of retries. The patch caused the ohci hardware to retry the command 4 times in a row instead of 3 times. For some strange reason, the OHCI specification document doesn't say exactly how the retry mechanism should work. There is a 2-bit error counter, normally set to 0. It gets reset to 0 every time a transaction succeeds. When a transaction fails the counter gets incremented, unless it is already equal to 2, in which case the host controller returns an error. The spec doesn't say what should happen if the counter is initially equal to 3. Normally you would expect it to just stay there, with no change, no errors reported, and unlimited retries. But apparently your hardware increments it to 0, giving a total of 4 attempts instead of 3. So the host controller is willing to talk to device but the device appear to be dead. Actually the device is not dead. Not at all. If it were then the class-specific device reset (which is nothing more than a USB control transfer) would fail. But it doesn't fail; it succeeds and the device continues operating. Until the command is retried... I think it's significant that the device always fails at exactly the same spot. That is, one particular command causes the failure. It could be that the device doesn't want to carry out the command -- but we know that it _does_ carry out the command when running at full speed or using a self-powered high-speed hub. More likely the bit pattern of that command string is, for some reason, not received correctly by the device. Maybe it thinks there's a bit-stuffing violation when there really isn't. However this is sheer speculation. We don't really have enough information to say why it doesn't work. IMO you should just accept that this is hardware problem which can't be solved in software and won't get better, and either use that self-powered hub all the time or else use a different brand of flash memory device. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Trouble connecting to DCP
Hi,
I have a nice little USB Bar Code Scanner. It is set up as a USB device,
but I can not connect to the default control pipe. I'm thinking that
attaching the usbhid driver will help.
I have an usb mouse and keyboard which work just fine. Kernel is
2.6.15-1-486.
Here are my questions
1) What is used to setup the mouse/KB which aren't used for the bar
code scanner? I can't find the udev rules, and it seems like I'm missing
a big chunk of what happens during a usb hotplug.
2) Is there a way to see what udev rules are matched when a device is
plugged in?
3) Can I specify vendor=0x and product=0x get driver usbhid on
the command line?
Here is what I tried
Based on udevinfo I made a new rule.
SUBSYSTEM==usb, ATTR{bInterfaceProtocol}==01,
ATTR{bInterfaceSubClass}==01, ATTR{bInterfaceClass}==03,
ATTR{bNumEndpoints}==01 DRIVER==usbhid
I placed the rule in /etc/udev/usb.rule and softlinked
/etc/udev/rules.d/z80_usb.rules - ../usb.rules
$ udevinfo -a -p /devices/pci:00/:00:02.1/usb3/3-3/3-3:1.0
looking at device '/devices/pci:00/:00:02.1/usb3/3-3/3-3:1.0':
KERNEL==3-3:1.0
SUBSYSTEM==usb
DRIVER== no driver :(
ATTR{interface}==EP1
ATTR{modalias}==usb:v04B4pCFA1d0254dc00dsc00dp00ic03isc01ip01
ATTR{bInterfaceProtocol}==01
ATTR{bInterfaceSubClass}==01
ATTR{bInterfaceClass}==03
ATTR{bNumEndpoints}==01
ATTR{bAlternateSetting}== 0
ATTR{bInterfaceNumber}==00
Thanks
ERIC
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci:00/:00:02.1/usb3/3-3/3-3:1.0':
KERNEL==3-3:1.0
SUBSYSTEM==usb
DRIVER==
ATTR{interface}==EP1
ATTR{modalias}==usb:v04B4pCFA1d0254dc00dsc00dp00ic03isc01ip01
ATTR{bInterfaceProtocol}==01
ATTR{bInterfaceSubClass}==01
ATTR{bInterfaceClass}==03
ATTR{bNumEndpoints}==01
ATTR{bAlternateSetting}== 0
ATTR{bInterfaceNumber}==00
looking at parent device '/devices/pci:00/:00:02.1/usb3/3-3':
KERNELS==3-3
SUBSYSTEMS==usb
DRIVERS==usb
ATTRS{configuration}==HID KB
ATTRS{product}==Generic KB-HID
ATTRS{manufacturer}==Guest
ATTRS{maxchild}==0
ATTRS{version}== 1.10
ATTRS{devnum}==15
ATTRS{speed}==1.5
ATTRS{bMaxPacketSize0}==8
ATTRS{bNumConfigurations}==1
ATTRS{bDeviceProtocol}==00
ATTRS{bDeviceSubClass}==00
ATTRS{bDeviceClass}==00
ATTRS{bcdDevice}==0254
ATTRS{idProduct}==cfa1
ATTRS{idVendor}==04b4
ATTRS{bMaxPower}==100mA
ATTRS{bmAttributes}==a0
ATTRS{bConfigurationValue}==1
ATTRS{bNumInterfaces}== 1
looking at parent device '/devices/pci:00/:00:02.1/usb3':
KERNELS==usb3
SUBSYSTEMS==usb
DRIVERS==usb
ATTRS{configuration}==
ATTRS{serial}==:00:02.1
ATTRS{product}==OHCI Host Controller
ATTRS{manufacturer}==Linux 2.6.15-1-486 ohci_hcd
ATTRS{maxchild}==3
ATTRS{version}== 1.10
ATTRS{devnum}==1
ATTRS{speed}==12
ATTRS{bMaxPacketSize0}==64
ATTRS{bNumConfigurations}==1
ATTRS{bDeviceProtocol}==00
ATTRS{bDeviceSubClass}==00
ATTRS{bDeviceClass}==09
ATTRS{bcdDevice}==0206
ATTRS{idProduct}==
ATTRS{idVendor}==
ATTRS{bMaxPower}== 0mA
ATTRS{bmAttributes}==e0
ATTRS{bConfigurationValue}==1
ATTRS{bNumInterfaces}== 1
looking at parent device '/devices/pci:00/:00:02.1':
KERNELS==:00:02.1
SUBSYSTEMS==pci
DRIVERS==ohci_hcd
ATTRS{modalias}==pci:v10DEd0067sv103Csd12B9bc0Csc03i10
ATTRS{local_cpus}==1
ATTRS{irq}==177
ATTRS{class}==0x0c0310
ATTRS{subsystem_device}==0x12b9
ATTRS{subsystem_vendor}==0x103c
ATTRS{device}==0x0067
ATTRS{vendor}==0x10de
looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==
umonitor -env
UEVENT[1159287566.399867] add@/devices/pci:00/:00:02.1/usb3/3-3
ACTION=add
DEVPATH=/devices/pci:00/:00:02.1/usb3/3-3
SUBSYSTEM=usb
SEQNUM=2462
PHYSDEVBUS=usb
PHYSDEVDRIVER=usb
UDEV [1159287566.400759] add@/devices/pci:00/:00:02.1/usb3/3-3
UDEV_LOG=6
ACTION=add
DEVPATH=/devices/pci:00/:00:02.1/usb3/3-3
SUBSYSTEM=usb
SEQNUM=2462
PHYSDEVBUS=usb
PHYSDEVDRIVER=usb
UDEVD_EVENT=1
DRIVER=usb
UEVENT[1159287566.408099] add@/devices/pci:00/:00:02.1/usb3/3-3/3-3:1.0
ACTION=add
DEVPATH=/devices/pci:00/:00:02.1/usb3/3-3/3-3:1.0
SUBSYSTEM=usb
SEQNUM=2463
PHYSDEVBUS=usb
DEVICE=/proc/bus/usb/003/015
PRODUCT=4b4/cfa1/254
TYPE=0/0/0
INTERFACE=3/1/1
MODALIAS=usb:v04B4pCFA1d0254dc00dsc00dp00ic03isc01ip01
UDEV [1159287566.413632] add@/devices/pci:00/:00:02.1/usb3/3-3/3-3:1.0
UDEV_LOG=6
ACTION=add
Re: [linux-usb-devel] Fwd: Re: Fwd: Re: FW: Fwd: Re: USB DISK does not work
What is your key string descriptors ? 3SYSTEM USB POCKET DISK Thanks Nope, this is not my problem device. Also, you said in another message that it was not dead, just ignoring transmissions. That was not my devices problem. Congrats you found another problem device. Regards, Steve - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 0/3] Change ohci-hcd autosuspend mechanism
On Mon, 25 Sep 2006 15:40:58 -0400 (EDT) Alan Stern [EMAIL PROTECTED] wrote: Patch 3 is much more experimental than the first two, and probably also more controversial (I expect David will have a lot to say about it, even if no one else does). In fact, I won't even CC: Andrew on this one; let's just keep it in the USB tree at first. More details will appear in the patch message. I wondered where that patch went to. Lucky I'm subscribed to linux-usb-devel ;) I'll assume it's safe to queue up #3 as well. I don't plan on doing 2.6.18-mm2 for a few days yet. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH 0/15] ehci-hcd: full-featured EHCI budgeter/scheduler
Hello, This set of patches implements abstracted budgeting logic for the ehci scheduler that both takes advantage of hardware features not currently exploited by the current schedulers (FSTNs and sITD backpointers) and makes a greater effort to get the niggling corner cases of scheduling restrictions correct (eg, correct ordering of overlapping FS QHs of differing tree levels). As an example of need, with this new budgeter, I an finally able to use all of my full-speed eight-channel USB audio devices, sampling and playing back simultaneously across multiple USB 2.0 hubs, which is not possible with either the 'old' scheduler (=2.6.17) or the 'new improved' scheduler (2.6.18, TT_NEWSCHED). The new scheduler is fully capable of acheiving 10mbps full speed transfers through a TT even when shared across devices. The largest piece of the patchset is the new 'shadow budget' abstraction that tracks all promised periodic bandwidth, not just the fragments that happen to be present on the periodic schedule at any given moment. It may have been cleaner to reserve bandwidth with placeholders in the actual hardware schedule, however discussions came to the conclusion this would require an unacceptable amount of memory. Thus the reasoning behind the much smaller, seperate shadow budget. Patches 1-9 are [somewhat fluffy] code refactoring of the existing scheduler mechanisms to make the addition of the budgeter straightforward. The budgeting is added in patch 10, switched on in a passive mode (the scheduler is not yet using its decisions) in patch 11, and in patch 12 the scheduler is switched over to using it. Patch 13 implements complete FSTN support, patch 14 implements sITD backpointer and frame spanning for ISO transfers. The last patch in the set is a usb audio fix necessitated by fixing underrun reporting in the ehci-hcd driver (usbaudio nominal playback causes a harmless underrun in startup that the usbaudio code doesn't currently handle properly.) This patchset removes the current schedulers' slot decision logic entirely in patch 12. I see little reason to maintain four possible scheduler choices when, once stable, this one should be the clear performance winner in all cases. Otherwise it would have to be the new improved new scheduler, whch is getting a might bit silly. Users should see no change except that more devices now work properly, and those that previously worked will no longer randomly abort with ENOSPC from the current 'best guess' approach accidentally overallocating because it only works a few ms ahead at a time. This is longwinded already, but more detail is at: http://web.mit.edu/xiphmont/Public/kernel/#ehci-sched The patchset as it is about to be posted will apply cleany to at least 2.6.18 through 2.6.18-git6 Patches incoming! Monty - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH 1/15] ehci-hcd: full-featured EHCI budgeter/scheduler
Patch is against kernels 2.6.18 through at least 2.6.18-git7
patch 1: This patch slightly refactors isoch stream cleanup such that
stream state is more persistent; it is instantiated at first transfer
and not released until endpoint shutdown. This is to isoch transfers
something persistent to associate with bandwidth budget reservations
later.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-08-07 00:18:54.0 -0400
+++ b/drivers/usb/host/ehci.h 2006-09-26 22:06:01.0 -0400
@@ -604,6 +604,14 @@ struct ehci_fstn {
/*-*/
+#define EHCI_EP_QH(x) (((x)-desc.bmAttributes USB_ENDPOINT_XFERTYPE_MASK) \
+ != USB_ENDPOINT_XFER_ISOC ? (x)-hcpriv : NULL)
+#define EHCI_EP_STREAM(x) (((x)-desc.bmAttributes \
+ USB_ENDPOINT_XFERTYPE_MASK) == \
+ USB_ENDPOINT_XFER_ISOC ? (x)-hcpriv : NULL)
+
+/*-*/
+
#ifdef CONFIG_USB_EHCI_ROOT_HUB_TT
/*
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-hcd.c
b/drivers/usb/host/ehci-hcd.c
--- a/drivers/usb/host/ehci-hcd.c 2006-08-09 22:12:43.0 -0400
+++ b/drivers/usb/host/ehci-hcd.c 2006-09-26 22:06:01.0 -0400
@@ -815,62 +815,79 @@ ehci_endpoint_disable (struct usb_hcd *h
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
unsigned long flags;
struct ehci_qh *qh, *tmp;
+ struct ehci_iso_stream *iso;
/* ASSERT: any requests/urbs are being unlinked */
/* ASSERT: nobody can be submitting urbs for this any more */
-rescan:
spin_lock_irqsave (ehci-lock, flags);
- qh = ep-hcpriv;
- if (!qh)
- goto done;
+ iso = EHCI_EP_STREAM(ep);
- /* endpoints can be iso streams. for now, we don't
-* accelerate iso completions ... so spin a while.
-*/
- if (qh-hw_info1 == 0) {
- ehci_vdbg (ehci, iso delay\n);
- goto idle_timeout;
- }
+ if (iso){
+ /* for now, we don't accelerate iso completions ... so spin
+ a while. */
+
+ while(iso-refcount1){
+ spin_unlock_irqrestore (ehci-lock, flags);
+ schedule_timeout_uninterruptible(1);
+ spin_lock_irqsave (ehci-lock, flags);
+ }
- if (!HC_IS_RUNNING (hcd-state))
- qh-qh_state = QH_STATE_IDLE;
- switch (qh-qh_state) {
- case QH_STATE_LINKED:
- for (tmp = ehci-async-qh_next.qh;
- tmp tmp != qh;
- tmp = tmp-qh_next.qh)
- continue;
- /* periodic qh self-unlinks on empty */
- if (!tmp)
- goto nogood;
- unlink_async (ehci, qh);
- /* FALL THROUGH */
- case QH_STATE_UNLINK: /* wait for hw to finish? */
-idle_timeout:
+ /* we want to be sure completions deref the stream to 1,
+ then we finally pull the plug here */
+ iso_stream_put(ehci,iso);
+ ep-hcpriv = NULL;
spin_unlock_irqrestore (ehci-lock, flags);
- schedule_timeout_uninterruptible(1);
- goto rescan;
- case QH_STATE_IDLE: /* fully unlinked */
- if (list_empty (qh-qtd_list)) {
- qh_put (qh);
+ return;
+ }
+
+ while ( (qh = EHCI_EP_QH(ep)) ){
+
+ if (!HC_IS_RUNNING (hcd-state))
+ qh-qh_state = QH_STATE_IDLE;
+ switch (qh-qh_state) {
+ case QH_STATE_LINKED:
+ for (tmp = ehci-async-qh_next.qh;
+tmp tmp != qh;
+tmp = tmp-qh_next.qh)
+ continue;
+
+ /* periodic qh self-unlinks on empty */
+ if (!tmp) goto error;
+ unlink_async (ehci, qh);
+ /* FALL THROUGH */
+
+ case QH_STATE_UNLINK: /* wait for hw to finish? */
+
+ spin_unlock_irqrestore (ehci-lock, flags);
+ schedule_timeout_uninterruptible(1);
+ spin_lock_irqsave (ehci-lock, flags);
break;
+
+ case QH_STATE_IDLE: /* fully unlinked */
+
+ if (list_empty (qh-qtd_list)) {
+
[linux-usb-devel] [PATCH 2/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 2: Refactors periodic schedule startup and shutdown code such
that refcounting and code is centralized. Also adds hysteresis such
that shutdown does not occur until there's one full pass through the
periodic schedule with nothing to do.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-09-26 22:12:14.0 -0400
+++ b/drivers/usb/host/ehci.h 2006-09-26 22:12:24.0 -0400
@@ -479,6 +479,7 @@ struct ehci_iso_stream {
unsigned long rescheduled;
int next_uframe;
__le32 splits;
+int budget_state;
/* the rest is derived from the endpoint descriptor,
* trusting urb-interval == f(epdesc-bInterval) and
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:12:14.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09-26 22:12:24.0 -0400
@@ -36,6 +36,14 @@
static int ehci_get_frame (struct usb_hcd *hcd);
+/* enable/disable shedule-specific debugging output */
+static unsigned sched_verbose = 0;
+module_param (sched_verbose, uint, S_IRUGO);
+MODULE_PARM_DESC (sched_verbose,
+ schedule verbose: dump additional scheduling-specific
+ debugging information to syslog. Incurs large latencies in
+ near-realtime code; default is 0 (off));
+
/*-*/
/*
@@ -424,51 +432,105 @@ static int tt_no_collision (
#endif /* CONFIG_USB_EHCI_TT_NEWSCHED */
/*-*/
+/* enable_periodic - Activate the periodic schedule
+ *
+ * @ehci: pointer to ehci host controller device structure.
+ */
static int enable_periodic (struct ehci_hcd *ehci)
{
u32 cmd;
int status;
- /* did clearing PSE did take effect yet?
-* takes effect only at frame boundaries...
-*/
- status = handshake (ehci-regs-status, STS_PSS, 0, 9 * 125);
- if (status != 0) {
- ehci_to_hcd(ehci)-state = HC_STATE_HALT;
- return status;
- }
+ if(!ehci-periodic_sched){
+
+ if(sched_verbose)
+ printk(KERN_INFO ehci: enabling periodic schedule\n);
+
+ /* did clearing PSE did take effect yet?
+* takes effect only at frame boundaries...
+*/
+ status = handshake (ehci-regs-status, STS_PSS, 0, 9 * 125);
+ if (status != 0) {
+ ehci_to_hcd(ehci)-state = HC_STATE_HALT;
+ return status;
+ }
+
+ cmd = readl (ehci-regs-command) | CMD_PSE;
+ writel (cmd, ehci-regs-command);
+ /* posted write ... PSS happens later */
+ ehci_to_hcd(ehci)-state = HC_STATE_RUNNING;
+
+ /* make sure ehci_work scans these */
+ ehci-next_uframe = readl (ehci-regs-frame_index)
+ % (ehci-periodic_size 3);
+ }
+
+ if(ehci-periodic_sched2)
+ ehci-periodic_sched=2;
+
+ ehci-periodic_sched++;
- cmd = readl (ehci-regs-command) | CMD_PSE;
- writel (cmd, ehci-regs-command);
- /* posted write ... PSS happens later */
- ehci_to_hcd(ehci)-state = HC_STATE_RUNNING;
-
- /* make sure ehci_work scans these */
- ehci-next_uframe = readl (ehci-regs-frame_index)
- % (ehci-periodic_size 3);
return 0;
}
+/* deref_periodic - decrement refcount of periodic schedule use; will
+ * only take the schedule down to 'idle but running'; it is the
+ * responsibility of scan_periodic to actually halt a running schedule
+ * after it has been idle for one full sweep.
+ *
+ * @ehci: pointer to ehci host controller device structure.
+ */
+static void deref_periodic (struct ehci_hcd *ehci)
+{
+ /* deref as far as 'idle' */
+ if(ehci-periodic_sched2)
+ ehci-periodic_sched--;
+
+ /* should *never* happen. Watch anyway. */
+ if(ehci-periodic_sched2){
+ ehci_err(ehci,periodic schedule refcount incorrect;
+is %d, should be 2. Setting to 2.\n,
+ehci-periodic_sched);
+ ehci-periodic_sched=2;
+ }
+}
+
+/* disable_periodic - halt execution of the periodic schedule. Note
+ * that the periodic schedule is now disabled after a full pass
+ * through the periodic schedule in which it is unused. It's not
+ * immediately disabled when the last active transfer completes.
[linux-usb-devel] [PATCH 3/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 3: moves scattered interrupt endpoint (periodic QH) code to one
place. Also eliminates some vestigal patterning patterning after the
async QH code. There should be no functional difference after this
patch.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-hcd.c
b/drivers/usb/host/ehci-hcd.c
--- a/drivers/usb/host/ehci-hcd.c 2006-09-26 22:12:14.0 -0400
+++ b/drivers/usb/host/ehci-hcd.c 2006-09-26 22:17:38.0 -0400
@@ -764,7 +764,7 @@ static int ehci_urb_dequeue (struct usb_
break;
switch (qh-qh_state) {
case QH_STATE_LINKED:
- intr_deschedule (ehci, qh);
+ periodic_qh_deschedule (ehci, qh);
/* FALL THROUGH */
case QH_STATE_IDLE:
qh_completions (ehci, qh, NULL);
@@ -780,7 +780,7 @@ static int ehci_urb_dequeue (struct usb_
HC_IS_RUNNING (hcd-state)) {
int status;
- status = qh_schedule (ehci, qh);
+ status = periodic_qh_schedule (ehci, qh);
spin_unlock_irqrestore (ehci-lock, flags);
if (status != 0) {
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-q.c
b/drivers/usb/host/ehci-q.c
--- a/drivers/usb/host/ehci-q.c 2006-08-07 00:18:54.0 -0400
+++ b/drivers/usb/host/ehci-q.c 2006-09-26 22:17:38.0 -0400
@@ -269,8 +269,8 @@ __acquires(ehci-lock)
static void start_unlink_async (struct ehci_hcd *ehci, struct ehci_qh *qh);
static void unlink_async (struct ehci_hcd *ehci, struct ehci_qh *qh);
-static void intr_deschedule (struct ehci_hcd *ehci, struct ehci_qh *qh);
-static int qh_schedule (struct ehci_hcd *ehci, struct ehci_qh *qh);
+static void periodic_qh_deschedule (struct ehci_hcd *ehci, struct ehci_qh *qh);
+static int periodic_qh_schedule (struct ehci_hcd *ehci, struct ehci_qh *qh);
/*
* Process and free completed qtds for a qh, returning URBs to drivers.
@@ -430,8 +430,10 @@ halt:
*/
if ((__constant_cpu_to_le32 (QH_SMASK)
qh-hw_info2) != 0) {
- intr_deschedule (ehci, qh);
- (void) qh_schedule (ehci, qh);
+
+ periodic_qh_deschedule (ehci, qh);
+ periodic_qh_schedule (ehci, qh);
+
} else
unlink_async (ehci, qh);
break;
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:17:28.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09-26 22:17:38.0 -0400
@@ -67,29 +67,34 @@ periodic_next_shadow (union ehci_shadow
}
}
-/* caller must hold ehci-lock */
-static void periodic_unlink (struct ehci_hcd *ehci, unsigned frame, void *ptr)
+/* find position of a specific entry in the periodic schedule (ie,
+ * returns pointers such that we can update the predecessor's
+ * linkage); here-ptr == NULL indicates the find failed.
+ *
+ * @ehci: pointer to ehci host controller device structure.
+ * @frame: frame number of the shadow/hardware schedule to search
+ * @ptr: entry for which to search
+ * @hw_p: return pointer to hw_next field of preceeding entry
+ */
+static union ehci_shadow *
+periodic_find_entry(struct ehci_hcd *ehci,
+unsigned frame,
+void *ptr,
+__le32 **hw_p)
{
- union ehci_shadow *prev_p = ehci-pshadow [frame];
- __le32 *hw_p = ehci-periodic [frame];
- union ehci_shadow here = *prev_p;
-
- /* find predecessor of ptr; hw and shadow lists are in sync */
- while (here.ptr here.ptr != ptr) {
- prev_p = periodic_next_shadow (prev_p, Q_NEXT_TYPE (*hw_p));
- hw_p = here.hw_next;
- here = *prev_p;
+ union ehci_shadow *here = ehci-pshadow [frame % ehci-periodic_size];
+ __le32 type;
+
+ *hw_p = ehci-periodic [frame % ehci-periodic_size];
+ type = Q_NEXT_TYPE (**hw_p);
+
+ while (here-ptr here-ptr != ptr) {
+ *hw_p = here-hw_next;
+ here = periodic_next_shadow (here, type);
+ type = Q_NEXT_TYPE (**hw_p);
}
- /* an interrupt entry (at list end) could have been shared */
- if (!here.ptr)
- return;
-
- /* update shadow and hardware lists ... the old next pointers
-* from ptr may still be in use, the caller updates them.
-*/
- *prev_p = *periodic_next_shadow (here, Q_NEXT_TYPE
[linux-usb-devel] [PATCH 4/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 4: modes ehci_iso_sched funtions to one place. Trivial patch
that makes no funcitonal difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:19:16.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09-26 22:19:26.0 -0400
@@ -939,6 +939,36 @@ done:
}
/*-*/
+/* ISO scheduling temporary structure machinery necessitated by lazy
+ alloc of the iso_stream structure */
+
+static struct ehci_iso_sched *
+iso_sched_alloc (unsigned packets, gfp_t mem_flags)
+{
+ struct ehci_iso_sched *iso_sched;
+ int size = sizeof *iso_sched;
+
+ size += packets * sizeof (struct ehci_iso_packet);
+ iso_sched = kzalloc(size, mem_flags);
+ if (likely (iso_sched != NULL)) {
+ INIT_LIST_HEAD (iso_sched-td_list);
+ }
+ return iso_sched;
+}
+
+static void
+iso_sched_free (struct ehci_iso_stream *stream,
+ struct ehci_iso_sched *iso_sched)
+{
+ if (!iso_sched){
+ return;
+ }
+ // caller must hold ehci-lock!
+ list_splice (iso_sched-td_list, stream-free_list);
+ kfree (iso_sched);
+}
+
+/*-*/
/* ehci_iso_stream ops work with both ITD and SITD */
@@ -1164,24 +1194,6 @@ iso_stream_find (struct ehci_hcd *ehci,
return stream;
}
-/*-*/
-
-/* ehci_iso_sched ops can be ITD-only or SITD-only */
-
-static struct ehci_iso_sched *
-iso_sched_alloc (unsigned packets, gfp_t mem_flags)
-{
- struct ehci_iso_sched *iso_sched;
- int size = sizeof *iso_sched;
-
- size += packets * sizeof (struct ehci_iso_packet);
- iso_sched = kzalloc(size, mem_flags);
- if (likely (iso_sched != NULL)) {
- INIT_LIST_HEAD (iso_sched-td_list);
- }
- return iso_sched;
-}
-
static inline void
itd_sched_init (
struct ehci_iso_sched *iso_sched,
@@ -1223,19 +1235,6 @@ itd_sched_init (
}
}
-static void
-iso_sched_free (
- struct ehci_iso_stream *stream,
- struct ehci_iso_sched *iso_sched
-)
-{
- if (!iso_sched)
- return;
- // caller must hold ehci-lock!
- list_splice (iso_sched-td_list, stream-free_list);
- kfree (iso_sched);
-}
-
static int
itd_urb_transaction (
struct ehci_iso_stream *stream,
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH 5/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 5: first half of untangling intermixed ehci_iso_sched, itd and
sitd code; moves/groups scattered code into self-contained sections.
Adds kernel-doc entries for functions. This patch should result in no
functional difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:20:51.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09-26 22:21:02.0 -0400
@@ -969,9 +969,15 @@ iso_sched_free (struct ehci_iso_stream *
}
/*-*/
+/* ISO stream generic machinery; tracks the ITDs and sITDs associated
+ with an isochronous endpoint */
-/* ehci_iso_stream ops work with both ITD and SITD */
-
+/* iso_stream_alloc - allocate a new iso stream structure; and iso
+ * stream performs a role similar to QHs for ISO endpoints (both ITD
+ * and SITD)
+ *
+ * @mem_flags: flags for memory allocation
+ */
static struct ehci_iso_stream *
iso_stream_alloc (gfp_t mem_flags)
{
@@ -987,6 +993,14 @@ iso_stream_alloc (gfp_t mem_flags)
return stream;
}
+/* iso_stream_init - initialize fields of an ehci_iso_stream structure
+ *
+ * @ehci: pointer to ehci host controller device structure
+ * @stream: ehci_iso_stream structure to initialize
+ * @dev: endpoint usb device
+ * @pipe: pipe handle
+ * @interval: bInterval of endpoint; frames for FS/LS, uFrames for HS
+ */
static void
iso_stream_init (
struct ehci_hcd *ehci,
@@ -1082,6 +1096,12 @@ iso_stream_init (
stream-maxp = maxp;
}
+/* iso_stream_put - decrement refcount of passed in ehci_iso_stream
+ * structure, reaping it if count has fallen to zero.
+ *
+ * @ehci: pointer to ehci host controller device structure
+ * @stream: ehci_iso_stream structure
+ */
static void
iso_stream_put(struct ehci_hcd *ehci, struct ehci_iso_stream *stream)
{
@@ -1144,6 +1164,11 @@ iso_stream_put(struct ehci_hcd *ehci, st
}
}
+/* iso_stream_get - increment refcount of passed in ehci_iso_stream
+ * structure
+ *
+ * @stream: ehci_iso_stream structure
+ */
static inline struct ehci_iso_stream *
iso_stream_get (struct ehci_iso_stream *stream)
{
@@ -1152,6 +1177,14 @@ iso_stream_get (struct ehci_iso_stream *
return stream;
}
+/* iso_stream_find - returns ehci_iso_stream structure matching the
+ * passed in urb; if no match is found, a new ehci_iso_stream is
+ * allocated and initialized to match the urb. This function is thus
+ * used both for looup and lazy alloc.
+ *
+ * @ehci: pointer to ehci host controller device structure
+ * @urb: usb request block
+ */
static struct ehci_iso_stream *
iso_stream_find (struct ehci_hcd *ehci, struct urb *urb)
{
@@ -1194,114 +1227,6 @@ iso_stream_find (struct ehci_hcd *ehci,
return stream;
}
-static inline void
-itd_sched_init (
- struct ehci_iso_sched *iso_sched,
- struct ehci_iso_stream *stream,
- struct urb *urb
-)
-{
- unsignedi;
- dma_addr_t dma = urb-transfer_dma;
-
- /* how many uframes are needed for these transfers */
- iso_sched-span = urb-number_of_packets * stream-interval;
-
- /* figure out per-uframe itd fields that we'll need later
-* when we fit new itds into the schedule.
-*/
- for (i = 0; i urb-number_of_packets; i++) {
- struct ehci_iso_packet *uframe = iso_sched-packet [i];
- unsignedlength;
- dma_addr_t buf;
- u32 trans;
-
- length = urb-iso_frame_desc [i].length;
- buf = dma + urb-iso_frame_desc [i].offset;
-
- trans = EHCI_ISOC_ACTIVE;
- trans |= buf 0x0fff;
- if (unlikely (((i + 1) == urb-number_of_packets))
-!(urb-transfer_flags URB_NO_INTERRUPT))
- trans |= EHCI_ITD_IOC;
- trans |= length 16;
- uframe-transaction = cpu_to_le32 (trans);
-
- /* might need to cross a buffer page within a uframe */
- uframe-bufp = (buf ~(u64)0x0fff);
- buf += length;
- if (unlikely ((uframe-bufp != (buf ~(u64)0x0fff
- uframe-cross = 1;
- }
-}
-
-static int
-itd_urb_transaction (
- struct ehci_iso_stream *stream,
- struct ehci_hcd *ehci,
- struct urb *urb,
- gfp_t mem_flags
-)
-{
- struct ehci_itd *itd;
- dma_addr_t itd_dma;
- int i;
- unsignednum_itds;
- struct ehci_iso_sched *sched;
- unsigned long flags;
-
- sched =
[linux-usb-devel] [PATCH 6/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 6: Continue untangling ehci_iso_sched and sitd code. Remove
ifdefs and code for EHCI_URB_TRACE within ehci-sched in preference for
later additional debugging information tailored to the new code.
Aside from removal of unused ifdefs, this patch results in no
functional difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:22:18.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09-26 22:22:28.0 -0400
@@ -1864,17 +1864,6 @@ static int itd_submit (struct ehci_hcd *
goto done;
}
-#ifdef EHCI_URB_TRACE
- ehci_dbg (ehci,
- %s %s urb %p ep%d%s len %d, %d pkts %d uframes [%p]\n,
- __FUNCTION__, urb-dev-devpath, urb,
- usb_pipeendpoint (urb-pipe),
- usb_pipein (urb-pipe) ? in : out,
- urb-transfer_buffer_length,
- urb-number_of_packets, urb-interval,
- stream);
-#endif
-
/* allocate ITDs w/o locking anything */
status = itd_urb_transaction (stream, ehci, urb, mem_flags);
if (unlikely (status 0)) {
@@ -1899,8 +1888,6 @@ done:
return status;
}
-#ifdef CONFIG_USB_EHCI_SPLIT_ISO
-
/*-*/
/* Split-ISO transfer machinery; used for FS isoch transfers through the
* TTs in USB 2.0 hubs. */
@@ -2271,15 +2258,6 @@ static int sitd_submit (struct ehci_hcd
goto done;
}
-#ifdef EHCI_URB_TRACE
- ehci_dbg (ehci,
- submit %p dev%s ep%d%s-iso len %d\n,
- urb, urb-dev-devpath,
- usb_pipeendpoint (urb-pipe),
- usb_pipein (urb-pipe) ? in : out,
- urb-transfer_buffer_length);
-#endif
-
/* allocate SITDs */
status = sitd_urb_transaction (stream, ehci, urb, mem_flags);
if (status 0) {
@@ -2304,27 +2282,6 @@ done:
return status;
}
-#else
-
-static inline int
-sitd_submit (struct ehci_hcd *ehci, struct urb *urb, gfp_t mem_flags)
-{
- ehci_dbg (ehci, split iso support is disabled\n);
- return -ENOSYS;
-}
-
-static inline unsigned
-sitd_complete (
- struct ehci_hcd *ehci,
- struct ehci_sitd*sitd,
- struct pt_regs *regs
-) {
- ehci_err (ehci, sitd_complete %p?\n, sitd);
- return 0;
-}
-
-#endif /* USB_EHCI_SPLIT_ISO */
-
/* scan_periodic - completion worker; called out of interrupt (or
* poll) handler to finish processing of transactions that have been
* completed by the host controller. Also now has the responsibility
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/Kconfig
b/drivers/usb/host/Kconfig
--- a/drivers/usb/host/Kconfig 2006-08-09 22:12:43.0 -0400
+++ b/drivers/usb/host/Kconfig 2006-09-26 22:22:28.0 -0400
@@ -29,15 +29,6 @@ config USB_EHCI_HCD
To compile this driver as a module, choose M here: the
module will be called ehci-hcd.
-config USB_EHCI_SPLIT_ISO
- bool Full speed ISO transactions (EXPERIMENTAL)
- depends on USB_EHCI_HCD EXPERIMENTAL
- default n
- ---help---
- This code is new and hasn't been used with many different
- EHCI or USB 2.0 transaction translator implementations.
- It should work for ISO-OUT transfers, like audio.
-
config USB_EHCI_ROOT_HUB_TT
bool Root Hub Transaction Translators (EXPERIMENTAL)
depends on USB_EHCI_HCD EXPERIMENTAL
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH 7/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 7: slightly rearrange sitd patching and linking code flow to
simplify addition of sITD backpointer support later. This should
result in no functional difference.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:25:36.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09-26 22:25:46.0 -0400
@@ -2030,18 +2030,15 @@ sitd_urb_transaction (
*
* @stream: stream into which this request will be queued
* @sitd: New sITD that is to be added to the shadow/hardware schedule
- * @iso_sched: ehci_iso_sched holding transfer descriptors
- * @index: packet number
+ * @uf: iso stream packet
*/
static inline void
sitd_patch (
struct ehci_iso_stream *stream,
struct ehci_sitd*sitd,
- struct ehci_iso_sched *iso_sched,
- unsignedindex
-)
+ struct ehci_iso_packet*uf
+ )
{
- struct ehci_iso_packet *uf = iso_sched-packet [index];
u64 bufp = uf-bufp;
sitd-hw_next = EHCI_LIST_END;
@@ -2050,7 +2047,6 @@ sitd_patch (
sitd-hw_results = uf-transaction;
sitd-hw_backpointer = EHCI_LIST_END;
- bufp = uf-bufp;
sitd-hw_buf [0] = cpu_to_le32 (bufp);
sitd-hw_buf_hi [0] = cpu_to_le32 (bufp 32);
@@ -2058,26 +2054,47 @@ sitd_patch (
if (uf-cross)
bufp += 4096;
sitd-hw_buf_hi [1] = cpu_to_le32 (bufp 32);
- sitd-index = index;
}
/* sitd_link - fill in and link one sITD into the shadow/hardware
* schedule
*
* @ehci: pointer to ehci host controller device structure
+ * @urb: new USB request
* @frame: shadow/hardware schedule frame
- * @sitd: sitd to link
+ * @stream: stream to which ITD belongs
+ * @sched: ehci_iso_sched structure holding packets
+ * @index: index of packet to use from sched
*/
-static inline void
-sitd_link (struct ehci_hcd *ehci, unsigned frame, struct ehci_sitd *sitd)
+static inline void sitd_link (struct ehci_hcd *ehci,
+ struct urb *urb,
+ unsigned frame,
+ struct ehci_iso_stream *stream,
+ struct ehci_iso_sched *sched,
+ int index)
{
+ struct ehci_sitd *sitd;
+
+ /* get SITD from already allocated list */
+ BUG_ON (list_empty (sched-td_list));
+ sitd = list_entry (sched-td_list.next,
+ struct ehci_sitd, sitd_list);
+ list_move_tail (sitd-sitd_list, stream-td_list);
+ sitd-stream = iso_stream_get (stream);
+ sitd-urb = usb_get_urb (urb);
+
+ /* set the sitd fields */
+ sitd_patch (stream, sitd, sched-packet [index]);
+
/* note: sitd ordering could matter (CSPLIT then SSPLIT) */
+ sitd-frame = frame;
+ sitd-index = index;
sitd-sitd_next = ehci-pshadow [frame];
sitd-hw_next = ehci-periodic [frame];
ehci-pshadow [frame].sitd = sitd;
- sitd-frame = frame;
wmb ();
ehci-periodic [frame] = cpu_to_le32 (sitd-sitd_dma) | Q_TYPE_SITD;
+
}
/* sitd_link_urb - link urb's sITDs into the hardware schedule
@@ -2094,12 +2111,11 @@ sitd_link_urb (
struct urb *urb,
unsignedmod,
struct ehci_iso_stream *stream
-)
+ )
{
int packet;
unsignednext_uframe;
struct ehci_iso_sched *sched = urb-hcpriv;
- struct ehci_sitd*sitd;
next_uframe = stream-next_uframe;
@@ -2107,42 +2123,21 @@ sitd_link_urb (
/* usbfs ignores TT bandwidth */
ehci_to_hcd(ehci)-self.bandwidth_allocated
+= stream-bandwidth;
- ehci_vdbg (ehci,
- sched devp %s ep%d%s-iso [%d] %dms/%04x\n,
- urb-dev-devpath, stream-bEndpointAddress 0x0f,
- (stream-bEndpointAddress USB_DIR_IN) ? in : out,
- (next_uframe 3) % ehci-periodic_size,
- stream-interval, le32_to_cpu (stream-splits));
- stream-start = jiffies;
}
ehci_to_hcd(ehci)-self.bandwidth_isoc_reqs++;
/* fill sITDs frame by frame */
- for (packet = 0, sitd = NULL;
- packet urb-number_of_packets;
- packet++) {
-
- /* ASSERT: we have all necessary sitds */
- BUG_ON (list_empty (sched-td_list));
-
- /* ASSERT: no itds for this endpoint in this frame */
-
- sitd = list_entry (sched-td_list.next,
- struct ehci_sitd, sitd_list);
- list_move_tail
[linux-usb-devel] [PATCH 8/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 8: split frame scanning code out of the scan_periodic schedule
walking loop so that the same code can be used to scan preceeding
frame for completions when FSTN and sITD frame spanning support are
added. Add restrictions on the timing of processing QH and sITD
completions in the current frame to avoid a race where a current
frame's completion may inadvertantly be processed before a preceeding
frame's spanning completion (do not process current completions until
preceeding transactions were checked for completion at a time that
guarantees they'd have finished).
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:26:57.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09-26 22:27:05.0 -0400
@@ -2277,6 +2277,152 @@ done:
return status;
}
+/*-*/
+
+static int scan_frame(struct ehci_hcd *ehci, struct pt_regs *regs,
+ int frame, int uframes, int rescan){
+
+ unsigned modified = 0;
+ union ehci_shadow q, *q_p;
+ __le32 type, *hw_p;
+
+ frame = frame (ehci-periodic_size-1);
+
+ q_p = ehci-pshadow [frame];
+ hw_p = ehci-periodic [frame];
+
+ q.ptr = q_p-ptr;
+ type = Q_NEXT_TYPE (*hw_p);
+
+ while (q.ptr != NULL) {
+ unsigneduf;
+ union ehci_shadow temp;
+ int live;
+
+ live = HC_IS_RUNNING (ehci_to_hcd(ehci)-state);
+ switch (type) {
+ case Q_TYPE_QH:
+ /* handle any completions */
+ temp.qh = qh_get (q.qh);
+ q_p = q.qh-qh_next;
+ hw_p = q.qh-hw_next;
+ type = Q_NEXT_TYPE (*hw_p);
+
+ q = *q_p;
+
+ modified = qh_completions (ehci, temp.qh, regs);
+ if (unlikely (list_empty (temp.qh-qtd_list)))
+ periodic_qh_deschedule (ehci, temp.qh);
+
+ qh_put (temp.qh);
+ break;
+ case Q_TYPE_FSTN:
+
+ /* for save-place FSTNs, inspect all QH
+* entries in the previous frame for
+* completions, but not if we're already in
+* recovery mode. */
+
+ if (q.fstn-hw_prev != EHCI_LIST_END !rescan) {
+ modified = scan_frame (ehci,regs,frame-1,8,1);
+ rescan = 1;
+ }
+
+ q_p = q.fstn-fstn_next;
+ hw_p = q.fstn-hw_next;
+ type = Q_NEXT_TYPE (*hw_p);
+ q = *q_p;
+
+ break;
+
+ case Q_TYPE_ITD:
+ /* skip itds for later in the frame */
+ rmb ();
+ for (uf = live ? uframes : 8; uf 8; uf++) {
+ if (0 == (q.itd-hw_transaction [uf]
+ ITD_ACTIVE))
+ continue;
+ q_p = q.itd-itd_next;
+ hw_p = q.itd-hw_next;
+ type = Q_NEXT_TYPE (*hw_p);
+ q = *q_p;
+ break;
+ }
+ if (uf != 8)
+ break;
+
+ /* this one's ready ... HC won't cache the
+* pointer for much longer, if at all.
+*/
+ *q_p = q.itd-itd_next;
+ *hw_p = q.itd-hw_next;
+ type = Q_NEXT_TYPE (*hw_p);
+ wmb();
+ modified = itd_complete (ehci, q.itd, regs);
+ q = *q_p;
+ break;
+
+ case Q_TYPE_SITD:
+
+ /* is this a spanning dummy? */
+ if (q.sitd-hw_backpointer != EHCI_LIST_END){
+ q_p = q.sitd-sitd_next;
+ hw_p = q.sitd-hw_next;
+ type = Q_NEXT_TYPE (*hw_p);
+ q = *q_p;
+
+
[linux-usb-devel] [PATCH 9/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 9:
Standardize/unify 'period' and 'interval' values on uFrame granularity
instead of mixing frame and uframe depending on endpoint type (there's
no reason to use urb-interval directly).
Implement QH tree depth limit such that the lowest level of the QH
tree can be smaller than the width of the full periodic schedule;
useful for saving memory upon implementation of save-state FSTNs.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-09-26 22:17:28.0 -0400
+++ b/drivers/usb/host/ehci.h 2006-09-26 22:28:17.0 -0400
@@ -385,6 +385,11 @@ union ehci_shadow {
* These appear in both the async and (for interrupt) periodic schedules.
*/
+/* as per ehci spec guidelines, replicate QH tree linkage of a maximum
+ size that is less than the full periodic schedule size. This is
+ also necessary to limit memory usage of FSTN support. */
+#define PERIODIC_QH_MAX_PERIOD 256 // 32 frames * 8 uFrames/Frame
+
struct ehci_qh {
/* first part defined by EHCI spec */
__le32 hw_next; /* see EHCI 3.6.1 */
@@ -485,10 +490,9 @@ struct ehci_iso_stream {
* trusting urb-interval == f(epdesc-bInterval) and
* including the extra info for hw_bufp[0..2]
*/
- u8 interval;
+ u16 interval;
u8 usecs, c_usecs;
u16 tt_usecs;
- u16 maxp;
u16 raw_mask;
unsignedbandwidth;
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-q.c
b/drivers/usb/host/ehci-q.c
--- a/drivers/usb/host/ehci-q.c 2006-09-26 22:19:16.0 -0400
+++ b/drivers/usb/host/ehci-q.c 2006-09-26 22:28:17.0 -0400
@@ -667,17 +667,19 @@ qh_make (
if (urb-dev-speed == USB_SPEED_HIGH) {
qh-c_usecs = 0;
qh-gap_uf = 0;
-
- qh-period = urb-interval 3;
- if (qh-period == 0 urb-interval != 1) {
+ qh-period = urb-interval; /* uFrame */
+
+ /* XXX: remove once new budgeting code */
+if (urb-interval8 urb-interval != 1) {
/* NOTE interval 2 or 4 uframes could work.
* But interval 1 scheduling is simpler, and
* includes high bandwidth.
*/
- dbg (intr period %d uframes, NYET!,
- urb-interval);
- goto done;
- }
+dbg (intr period %d uframes, NYET!,
+urb-interval);
+goto done;
+}
+
} else {
struct usb_tt *tt = urb-dev-tt;
int think_time;
@@ -699,7 +701,7 @@ qh_make (
qh-tt_usecs = NS_TO_US (think_time +
usb_calc_bus_time (urb-dev-speed,
is_input, 0, max_packet (maxp)));
- qh-period = urb-interval;
+ qh-period = urb-interval 3; /* uFrame */
}
}
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:28:06.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09-26 22:28:17.0 -0400
@@ -96,6 +96,19 @@ periodic_find_entry(struct ehci_hcd *ehc
return here;
}
+/* covert a QH's period [expressed in uFrames] to tree level.
+ *
+ * @period: period (uFrames) of a QH
+ */
+static int _period_to_level(int period)
+{
+ if(period8)return 1;
+ if(period PERIODIC_QH_MAX_PERIOD){
+ return (PERIODIC_QH_MAX_PERIOD 3);
+ }
+ return period3;
+}
+
/* how many of the uframe's 125 usecs are allocated? */
static unsigned short
periodic_usecs (struct ehci_hcd *ehci, unsigned frame, unsigned uframe)
@@ -596,9 +609,8 @@ static void periodic_qh_deschedule(struc
periodic_qh_unlink_frame (ehci, i, qh);
/* update per-qh bandwidth for usbfs */
- ehci_to_hcd(ehci)-self.bandwidth_allocated -= qh-period
- ? ((qh-usecs + qh-c_usecs) / qh-period)
- : (qh-usecs * 8);
+ ehci_to_hcd(ehci)-self.bandwidth_allocated -=
+ (qh-usecs + qh-c_usecs) / qh-period;
dev_dbg (qh-dev-dev,
unlink qh%d-%04x/%p start %d [%d/%d
[linux-usb-devel] [PATCH 10/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 10: Drops in complete implementation of the shadow budget
abstraction, but does not yet call this code in any way. The shadow
budget is a means of indefinitely reserving bandwidth requested by a
periodic endpoint as well as logic for making scheduling decisions
based on previously budgeted allocations.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-09-26 22:29:36.0 -0400
+++ b/drivers/usb/host/ehci.h 2006-09-26 22:29:47.0 -0400
@@ -72,6 +72,10 @@ struct ehci_hcd {/* one per controlle
int next_uframe;/* scan periodic, start here */
unsignedperiodic_sched; /* periodic activity count */
+kmem_cache_t*budget_pool; /* Pool for shadow budget */
+struct ehci_shadow_budget **budget; /* pointer to the
shadow budget
+ of bandwidth placeholders */
+
/* per root hub port */
unsigned long reset_done [EHCI_MAX_ROOT_PORTS];
@@ -155,8 +159,8 @@ timer_action (struct ehci_hcd *ehci, enu
// to go OFF neither can matter, and afterwards the IO
// watchdog stops unless there's still periodic traffic.
if (action != TIMER_IAA_WATCHDOG
-t ehci-watchdog.expires
-timer_pending (ehci-watchdog))
+t ehci-watchdog.expires
+timer_pending (ehci-watchdog))
return;
mod_timer (ehci-watchdog, t);
}
@@ -377,6 +381,56 @@ union ehci_shadow {
/*-*/
+/* the shadow budget is a means of reserving bandwidth throughout the
+ periodic schedule (the hardware schedule is currently used as a
+ sliding window by the current transaction code). The shadow budget
+ follows the same list-then-tree structure as the hardware schedule. */
+
+/* must be equal to or smaller than PERIODIC_QH_MAX_PERIOD */
+#define BUDGET_SLOTS 32
+#define BUDGET_SLOT_MASK (BUDGET_SLOTS-1)
+
+/* Because EHCI cannot issue ssplits in uframe 7 and USB 2.0 does not
+ allow ssplits in uframe 6, EHCI can only generate an efficient FS
+ frame by scheduling according to best-case (not worst-case) bit
+ stuffing. Thus we purposely 'overcommit' the FS frame budget
+ within the buffering ability of the TT to buffer, and within the
+ limits of the 90/10 rule. The TT will catch up in the microframes
+ where we cannot issue start splits.
+*/
+
+#define BUDGET_WRAP_P(b) ((b)-cmask (~0xff))
+
+struct ehci_shadow_budget {
+ struct ehci_shadow_budget *next;
+
+ u16 s_usecs; /* highspeed usecs */
+ u16 c_usecs; /* highspeed completion usecs (FS/LS)*/
+ u16 tt_bytes; /* bytes to budget at TT (FS/LS)*/
+ u16 cmask;/* 16 bits: a 'too big' mask indicates the need for a
+frame wrap (FSTN or dummy SITD) */
+ u8 smask;
+
+#define BUDGET_TYPE_ITD 1 /* ITD or SITD; budgets early */
+#define BUDGET_TYPE_QH 2 /* QH; budgets late */
+ u8 type;
+
+ /* QHs and FSTNs are persistent in the periodic schedule, so they
+ own their own budget placeholders. [s]ITD placeholders are owned
+ by an ehci_iso_stream. */
+ union {
+ struct ehci_qh *qh; /* needed to extract
+ period and specific
+ TT */
+ struct ehci_iso_stream *iso; /* needed to extract
+ period and specific
+ TT */
+ void *ptr; /* used as an ID */
+ } owner;
+};
+
+/*-*/
+
/*
* EHCI Specification 0.95 Section 3.6
* QH: describes control/bulk/interrupt endpoints
@@ -388,7 +442,9 @@ union ehci_shadow {
/* as per ehci spec guidelines, replicate QH tree linkage of a maximum
size that is less than the full periodic schedule size. This is
also necessary to limit memory usage of FSTN support. */
-#define PERIODIC_QH_MAX_PERIOD 256 // 32 frames * 8 uFrames/Frame
+/* must be equal to or larger than BUDGET_SLOTS*8, otherwise the budget
+ will overcommit */
+#define PERIODIC_QH_MAX_PERIOD (BUDGET_SLOTS*8)
struct ehci_qh {
/* first part defined by EHCI spec */
@@ -433,10 +489,12 @@ struct ehci_qh {
u8 gap_uf; /* uframes split/csplit gap */
u8 c_usecs;/* ... split completion bw */
u16 tt_usecs; /*
[linux-usb-devel] [PATCH 11/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 11: adds necessary calls such that the shadow budget is actively
maintained, but the rest of the scheduler is not yet using the shadow
budget to make any decisions.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-hcd.c
b/drivers/usb/host/ehci-hcd.c
--- a/drivers/usb/host/ehci-hcd.c 2006-09-26 22:19:16.0 -0400
+++ b/drivers/usb/host/ehci-hcd.c 2006-09-26 22:30:54.0 -0400
@@ -255,6 +255,8 @@ static void ehci_quiesce (struct ehci_hc
/*-*/
static void ehci_work(struct ehci_hcd *ehci, struct pt_regs *regs);
+static void budget_unlink_entries_by_owner(struct ehci_hcd *ehci,void *owner);
+static unsigned sched_verbose = 0;
#include ehci-hub.c
#include ehci-mem.c
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-mem.c
b/drivers/usb/host/ehci-mem.c
--- a/drivers/usb/host/ehci-mem.c 2006-09-26 22:30:47.0 -0400
+++ b/drivers/usb/host/ehci-mem.c 2006-09-26 22:30:54.0 -0400
@@ -73,6 +73,15 @@ static void qh_destroy (struct kref *kre
ehci_dbg (ehci, unused qh not empty!\n);
BUG ();
}
+
+ /* remove from shadow budget */
+ if(sched_verbose)
+ ehci_info(ehci, Removing QH %p from budget:\n, qh);
+
+ if(qh-budget)
+ budget_unlink_entries_by_owner(ehci,qh);
+ qh-budget = NULL;
+
if (qh-dummy)
ehci_qtd_free (ehci, qh-dummy);
dma_pool_free (ehci-qh_pool, qh, qh-qh_dma);
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-q.c
b/drivers/usb/host/ehci-q.c
--- a/drivers/usb/host/ehci-q.c 2006-09-26 22:29:36.0 -0400
+++ b/drivers/usb/host/ehci-q.c 2006-09-26 22:30:54.0 -0400
@@ -682,8 +682,23 @@ qh_make (
} else {
struct usb_tt *tt = urb-dev-tt;
- int think_time;
+ int think_time, think_bytes;
+ think_time = tt ? tt-think_time : 0;
+ think_bytes = (think_time+665)/666;
+
+ if(urb-dev-speed == USB_SPEED_FULL)
+ /* full speed bytes +
+ think time [TT host delay] +
+ FS non-iso protocol overhead */
+ qh-tt_bytes = think_bytes + maxp + 14;
+ else
+ /* low speed bytes +
+ think time [TT host delay] +
+ low speed protocol overhead */
+ /* expressed in full speed bytes */
+ qh-tt_bytes = think_bytes + maxp*8 + 98;
+
/* gap is f(FS/LS transfer times) */
qh-gap_uf = 1 + usb_calc_bus_time (urb-dev-speed,
is_input, 0, maxp) / (125 * 1000);
@@ -697,7 +712,6 @@ qh_make (
qh-c_usecs = HS_USECS (0);
}
- think_time = tt ? tt-think_time : 0;
qh-tt_usecs = NS_TO_US (think_time +
usb_calc_bus_time (urb-dev-speed,
is_input, 0, max_packet (maxp)));
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-sched.c
b/drivers/usb/host/ehci-sched.c
--- a/drivers/usb/host/ehci-sched.c 2006-09-26 22:30:47.0 -0400
+++ b/drivers/usb/host/ehci-sched.c 2006-09-26 22:30:54.0 -0400
@@ -104,7 +104,6 @@
/* enable/disable shedule-specific debugging output */
-static unsigned sched_verbose = 0;
module_param (sched_verbose, uint, S_IRUGO);
MODULE_PARM_DESC (sched_verbose,
schedule verbose: dump additional scheduling-specific
@@ -1938,6 +1937,15 @@ static int periodic_qh_schedule (struct
qh-hw_next = EHCI_LIST_END;
frame = qh-start;
+ /* budget the qh if not already budgeted */
+ if(!qh-budget){
+
+ status = budget_add_endpoint (ehci, qh, BUDGET_TYPE_QH,
+ qh-period);
+ if(status)
+ return status;
+ }
+
/* reuse the previous schedule slots, if we can */
if (frame period) {
uframe = ffs (le32_to_cpup (qh-hw_info2) QH_SMASK);
@@ -1987,6 +1995,10 @@ static int periodic_qh_schedule (struct
/* stuff into the periodic schedule */
status = periodic_qh_link (ehci, qh);
done:
+ if(status){
+ budget_unlink_entries_by_owner(ehci,qh);
+ qh-budget = NULL;
+ }
[linux-usb-devel] [PATCH 12/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 12: Switches the existing scheduler mechanisms over to using the
shadow budget for all scheduling decisions. Removes all unused
bandwidth allocation logic from previous scheduler versions.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-09-26 22:30:47.0 -0400
+++ b/drivers/usb/host/ehci.h 2006-09-26 22:32:07.0 -0400
@@ -486,13 +486,9 @@ struct ehci_qh {
/* periodic schedule info */
u8 usecs; /* intr bandwidth */
- u8 gap_uf; /* uframes split/csplit gap */
u8 c_usecs;/* ... split completion bw */
- u16 tt_usecs; /* tt downstream bandwidth */
u16 tt_bytes; /* tt downstream bandwidth */
- unsigned short period; /* polling interval */
- unsigned short start; /* where polling starts */
-#define NO_FRAME ((unsigned short)~0) /* pick new start */
+ unsigned short period; /* polling interval; uFrame */
struct usb_device *dev; /* access to TT */
struct ehci_shadow_budget *budget; /* pointer to budget
placeholder */
} __attribute__ ((aligned (32)));
@@ -538,10 +534,7 @@ struct ehci_iso_stream {
struct usb_host_endpoint *ep;
/* output of (re)scheduling */
- unsigned long start; /* jiffies */
- unsigned long rescheduled;
int next_uframe;
- __le32 splits;
int budget_state;
/* the rest is derived from the endpoint descriptor,
@@ -550,7 +543,6 @@ struct ehci_iso_stream {
*/
u16 interval;
u8 usecs, c_usecs;
- u16 tt_usecs;
u16 tt_bytes;
u16 raw_mask;
unsignedbandwidth;
@@ -599,7 +591,7 @@ struct ehci_itd {
/* any/all hw_transactions here may be used by that urb */
unsignedframe; /* where scheduled */
unsignedpg;
- unsignedindex[8]; /* in urb-iso_frame_desc */
+ int index[8]; /* in urb-iso_frame_desc */
u8 usecs[8];
struct ehci_shadow_budget *budget; /* pointer to budget
placeholder */
} __attribute__ ((aligned (32)));
@@ -644,7 +636,7 @@ struct ehci_sitd {
struct ehci_iso_stream *stream;/* endpoint's queue */
struct list_headsitd_list; /* list of stream's sitds */
unsignedframe;
- unsignedindex;
+ int index;
struct ehci_shadow_budget *budget; /* pointer to budget
placeholder */
} __attribute__ ((aligned (32)));
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-q.c
b/drivers/usb/host/ehci-q.c
--- a/drivers/usb/host/ehci-q.c 2006-09-26 22:31:58.0 -0400
+++ b/drivers/usb/host/ehci-q.c 2006-09-26 22:32:07.0 -0400
@@ -633,9 +633,9 @@ qh_make (
struct urb *urb,
gfp_t flags
) {
+ int is_input, type = usb_pipetype (urb-pipe);
struct ehci_qh *qh = ehci_qh_alloc (ehci, flags);
u32 info1 = 0, info2 = 0;
- int is_input, type;
int maxp = 0;
if (!qh)
@@ -648,7 +648,6 @@ qh_make (
info1 |= usb_pipedevice (urb-pipe) 0;
is_input = usb_pipein (urb-pipe);
- type = usb_pipetype (urb-pipe);
maxp = usb_maxpacket (urb-dev, urb-pipe, !is_input);
/* Compute interrupt scheduling parameters just once, and save.
@@ -662,24 +661,12 @@ qh_make (
if (type == PIPE_INTERRUPT) {
qh-usecs = NS_TO_US (usb_calc_bus_time (USB_SPEED_HIGH,
is_input, 0,
hb_mult (maxp) * max_packet (maxp)));
- qh-start = NO_FRAME;
if (urb-dev-speed == USB_SPEED_HIGH) {
qh-c_usecs = 0;
- qh-gap_uf = 0;
+ qh-tt_bytes = 0;
qh-period = urb-interval; /* uFrame */
- /* XXX: remove once new budgeting code */
-if (urb-interval8 urb-interval != 1) {
- /* NOTE interval 2 or 4 uframes could work.
-* But interval 1 scheduling is simpler, and
-* includes high
[linux-usb-devel] [PATCH 13/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 13: Adds low-level scheduler mechanisms for linking, unlinking,
manipulating and maintaining FSTNs. Turns on shadow budget logic to
allow/use FSTNs in budgeting.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci.h
b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h 2006-09-26 22:33:14.0 -0400
+++ b/drivers/usb/host/ehci.h 2006-09-26 22:33:21.0 -0400
@@ -76,11 +76,14 @@ struct ehci_hcd { /* one per controlle
struct ehci_shadow_budget **budget; /* pointer to the
shadow budget
of bandwidth placeholders */
+ struct ehci_fstn*periodic_restore_fstn;
+ struct ehci_fstn**periodic_save_fstns; /*
[PERIODIC_QH_MAX_PERIOD] */
/* per root hub port */
unsigned long reset_done [EHCI_MAX_ROOT_PORTS];
/* per-HC memory pools (could be per-bus, but ...) */
struct dma_pool *qh_pool; /* qh per active urb */
+ struct dma_pool *fstn_pool; /* a qh has [up to] two fstns */
struct dma_pool *qtd_pool; /* one or more per qh */
struct dma_pool *itd_pool; /* itd per iso urb */
struct dma_pool *sitd_pool; /* sitd per split iso urb */
@@ -358,6 +361,7 @@ struct ehci_qtd {
/* next async queue entry, or pointer to interrupt/periodic QH */
#defineQH_NEXT(dma)(cpu_to_le32(((u32)dma)~0x01f)|Q_TYPE_QH)
+#defineFSTN_NEXT(dma) (cpu_to_le32(((u32)dma)~0x01f)|Q_TYPE_FSTN)
/* for periodic/async schedules and qtd lists, mark end of list */
#defineEHCI_LIST_END __constant_cpu_to_le32(1) /* null pointer to
hw */
@@ -658,6 +662,7 @@ struct ehci_fstn {
/* the rest is HCD-private */
dma_addr_t fstn_dma;
union ehci_shadow fstn_next; /* ptr to periodic q entry */
+ struct ehci_qh *fstn_prev; /* ptr to backlinked qh */
} __attribute__ ((aligned (32)));
/*-*/
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-hcd.c
b/drivers/usb/host/ehci-hcd.c
--- a/drivers/usb/host/ehci-hcd.c 2006-09-26 22:31:58.0 -0400
+++ b/drivers/usb/host/ehci-hcd.c 2006-09-26 22:33:21.0 -0400
@@ -427,6 +427,11 @@ static int ehci_init(struct usb_hcd *hcd
if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) 0)
return retval;
+ /* a periodic schedule that supports FSTNs always has a single
+ static restore FSTN that matches all possible save
+ FSTNs. */
+ periodic_init_link_restore_fstn(ehci);
+
/* controllers may cache some of the periodic schedule ... */
hcc_params = readl(ehci-caps-hcc_params);
if (HCC_ISOC_CACHE(hcc_params)) // full frame cache
diff -X b/Documentation/dontdiff -upr a/drivers/usb/host/ehci-mem.c
b/drivers/usb/host/ehci-mem.c
--- a/drivers/usb/host/ehci-mem.c 2006-09-26 22:31:58.0 -0400
+++ b/drivers/usb/host/ehci-mem.c 2006-09-26 22:33:21.0 -0400
@@ -62,6 +62,26 @@ static inline void ehci_qtd_free (struct
dma_pool_free (ehci-qtd_pool, qtd, qtd-qtd_dma);
}
+static struct ehci_fstn *ehci_fstn_alloc (struct ehci_hcd *ehci, gfp_t flags)
+{
+struct ehci_fstn *fstn = NULL;
+ dma_addr_t dma;
+
+ if(ehci-fstn_pool){ /* alloced only if HC actually supports fstn */
+ fstn = dma_pool_alloc (ehci-fstn_pool, flags, dma);
+ if (fstn != NULL) {
+ memset (fstn, 0, sizeof *fstn);
+ fstn-fstn_dma = dma;
+ }
+ }
+ return fstn;
+}
+
+static inline void ehci_fstn_free (struct ehci_hcd *ehci,
+ struct ehci_fstn *fstn)
+{
+dma_pool_free (ehci-fstn_pool, fstn, fstn-fstn_dma);
+}
static void qh_destroy (struct kref *kref)
{
@@ -144,6 +164,10 @@ static void ehci_mem_cleanup (struct ehc
dma_pool_destroy (ehci-qtd_pool);
ehci-qtd_pool = NULL;
+ if (ehci-fstn_pool)
+ dma_pool_destroy (ehci-fstn_pool);
+ ehci-fstn_pool = NULL;
+
if (ehci-qh_pool) {
dma_pool_destroy (ehci-qh_pool);
ehci-qh_pool = NULL;
@@ -163,6 +187,8 @@ static void ehci_mem_cleanup (struct ehc
ehci-periodic, ehci-periodic_dma);
ehci-periodic = NULL;
+ if(ehci-periodic_save_fstns)
+ kfree(ehci-periodic_save_fstns);
if(ehci-budget)
kfree(ehci-budget);
ehci-budget = NULL;
@@ -171,7 +197,8 @@ static void ehci_mem_cleanup (struct ehc
ehci-budget_pool = NULL;
/* shadow periodic table */
-
[linux-usb-devel] [PATCH 15/15] ehci-hcd: full-featured EHCI budgeter/scheduler
These patches are against kernels 2.6.18 through at least 2.6.18-git7.
patch 15: This fix is not actually to ehci-hcd, but is rather a fix to
usbaudio necessitated by fixing the isoch underrun detection/reporting
in ehci. usbaudio playback nominally causes one, specific harmless
underrun in startup that the usbaudio code doesn't currently handle
properly.
Signed-off-by: Christopher Monty Montgomery [EMAIL PROTECTED]
---
diff -X b/Documentation/dontdiff -upr a/sound/usb/usbaudio.c
b/sound/usb/usbaudio.c
--- a/sound/usb/usbaudio.c 2006-09-26 22:10:24.0 -0400
+++ b/sound/usb/usbaudio.c 2006-09-26 22:35:43.0 -0400
@@ -838,6 +838,9 @@ static int start_urbs(struct snd_usb_sub
subs-running = 1;
for (i = 0; i subs-nurbs; i++) {
err = usb_submit_urb(subs-dataurb[i].urb, GFP_ATOMIC);
+ if (err == -EL2NSYNC)
+ err = usb_submit_urb(subs-dataurb[i].urb, GFP_ATOMIC);
+
if (err 0) {
snd_printk(KERN_ERR cannot submit datapipe
for urb %d, error %d: %s\n,
@@ -849,6 +852,8 @@ static int start_urbs(struct snd_usb_sub
if (subs-syncpipe) {
for (i = 0; i SYNC_URBS; i++) {
err = usb_submit_urb(subs-syncurb[i].urb, GFP_ATOMIC);
+ if (err == -EL2NSYNC)
+ err = usb_submit_urb(subs-syncurb[i].urb,
GFP_ATOMIC);
if (err 0) {
snd_printk(KERN_ERR cannot submit syncpipe
for urb %d, error %d: %s\n,
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PROBLEM: Nokia 6280 + provided USB cable throws BUG's and hardlocks.
On Tue, Sep 26, 2006 at 05:45:26PM +1000, James wrote: Hey Attempting to connect and use my Nokia 6280 with the supplied Nokia USB cable (reads: 'Type: CA-53') causes the kernel to through BUG's, and has on occasion caused a complete lock up of the system. This is running 2.6.18, and also occurs on the 2.6.17 series, which was what I was using when I received the phone. I have no idea about kernels before. See: http://bugzilla.kernel.org/show_bug.cgi?id=7201 others are having the same issue. thanks, greg k-h - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
