Re: ONDA N501HS (aka ZTE MF330) flow control
On Wed, Feb 13, 2008 at 03:54:38PM +, Sergio Callegari wrote: > Hi, > > I have an ONDA N501HS (namely a rebranded ZTE MF330) UMTS pc card. > > I am currently using this card with the sierra driver (as in current kernels). Which kernel version specifically? > However I am noticing the following problem: > > - when I use the card for downloading from the internet, everything is fine; > - when I use the card for uploading to the internet, after a few tens kB, the > card freezes. > > Freezing goes as follows: > > the card provides 3 ports: ttyUSB0 to ttyUSB2. The port ttyUSB0 that is used > for > data stops working completely. It becomes impossible to talk to it, until the > pc-card is extracted and put again in the pcmcia slot. The other ports keep > working. > > I wonder if this might have something to do with flow control (or lack > thereof) > that causes the card to be flooded with data from the computer until it locks. Probably. > I believe that flow control might be the issue, since if I use upload programs > that let me decide the data rate and I pick a low enough rate everything goes > just fine. > > I have also seen that the ZTE MF330 has just been moved from the sierra driver > to the option driver. > Is there any chance that this might fix my problem? Well, it might, as it turns out that this really is not a sierra wireless based device, it's something else. So try changing drivers and see if that gets better. > If this is the case, having my distribution kernel source, once I have applied > the patch, how can I rebuild _only_ the sierra and the option modules? make M=drivers/usb/serial/ will build only that one directory. Or: make drivers/usb/serial/option.ko should build only that module. You might have to do a 'make oldconfig' and 'make prepare' first though. Hope this helps, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handshaking on USB serial devices
On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote: > Consider a USB-attached serial port that is set to do RTS/CTS (or > DSR/DTR) handshaking: What stops the kernel sending more data to it when > the remote end lowers CTS (or DTR)? The tty layer should look at the proper flags and not send data on to the driver in this kind of instance. Is this not happening properly for you? If so, which USB serial driver? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Fwd: Re: [Linux-uvc-devel] 064e:a101 Suyin Corp. and Skype-2.0.0.43-suse partial success]
Original Message
Subject: Re: [Linux-uvc-devel] 064e:a101 Suyin Corp. and
Skype-2.0.0.43-suse partial success
Date: Wed, 13 Feb 2008 16:02:45 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
This list is now closed.
Please post to the linux-usb list as described at
http://vger.kernel.org/vger-lists.html#linux-usb instead.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--- Begin Message ---
This is with vanilla kernel 2.6.25-rc1.
Regards
Sid.
Laurent Pinchart wrote:
On Tuesday 12 February 2008, Sid Boyce wrote:
Laurent Pinchart wrote:
On Saturday 09 February 2008, Sid Boyce wrote:
With svn at revision 177, I can now get a picture when I do the skype
camera test, but it freezes after a few frames. Camera is built-in on
Acer Travelmate 7520 laptop.
Any suspicious message in the kernel log ?
Best regards,
Laurent Pinchart
I posted more dmesg info just a while ago. Also another post about build
errors on revision 179.
[10936.211150] compat_ioctl32: v4l2 ioctl VIDIOC_S_PARM, dir=rw
(0xc0cc5616) [10936.211166] ioctl32(skype:28263): Unknown cmd fd(28)
cmd(c0cc5616){t:'V';sz:204} arg(f6162e40) on /dev/video0
[10943.613436] compat_ioctl32: v4l2 ioctl VIDIOC_S_PARM, dir=rw
(0xc0cc5616) [10943.613436] ioctl32(skype:28263): Unknown cmd fd(28)
cmd(c0cc5616){t:'V';sz:204} arg(f6162e30) on /dev/video0
[10943.620761] compat_ioctl32: v4l2 ioctl VIDIOC_S_PARM, dir=rw
(0xc0cc5616) [10943.620769] ioctl32(skype:28263): Unknown cmd fd(28)
cmd(c0cc5616){t:'V';sz:204} arg(f6162e00) on /dev/video0
Funny, if you look at the timestamps, your computer jumps back in time at this
point. Are you experimenting with time travel ? :-)
[10942.250515] PGD 8063 PUD 0
[10942.250523] CPA 81008000 no pte level 0
[10942.367316] PGD 8063 PUD 0
[10942.367324] CPA 81008000 no pte level 0
[10942.415711] PGD 8063 PUD 0
[10942.415720] CPA 81008000 no pte level 0
I don't know where those messages come from, I'll just assume they don't hurt
(they look related to memory management).
[10962.712515] uvcvideo: Failed to resubmit video URB (-45).
[10962.712515] uvcvideo: Failed to resubmit video URB (-45).
[10962.712515] uvcvideo: Failed to resubmit video URB (-45).
[10962.712515] uvcvideo: Failed to resubmit video URB (-45).
[10962.712515] uvcvideo: Failed to resubmit video URB (-45).
Basically, the EHCI scheduler says that the time slot that the URBs should be
queued for has already elapsed. This is a valid error when a device driver
specifies a time slot, but not when asking the EHCI scheduler to queue URBs
ASAP. I believe this is a bug in the EHCI scheduler. Could you try to push
the issue on the linux-usb-devel mailing list ?
Best regards,
Laurent Pinchart
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--- End Message ---
Re: [PATCH] usb: convert usb.h struct usb_device to kernel-doc
On Wed, 13 Feb 2008 17:44:01 -0500 (EST) Alan Stern wrote:
> > + * @rawdescriptors: waw descriptors for each config
>
> Typo.
>
> > + * @children: child devices - these can be either new devices (if this is a
> > + * hub device), or different instances of this same device.
> > + * Each instance needs its own set of data structures.
>
> What does "different instances of this same device" mean? Apparently
> This is a fossil comment; IMO it should be removed. Only hubs have
> children.
>
> > + * @delayed_work autosuspend: for delayed autosuspends
>
> Typo: the variable is just "autosuspend". "delayed_work" is part of
> the structure tag.
Thanks, Alan. Updated patch... Any more comments/corrections?
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Convert struct usb_device to use kernel-doc notation.
Please especially check the @filelist and @usb_classdev descriptions.
Fix a few other kernel-doc lines that should be all on one line but were on
multiple lines.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
include/linux/usb.h | 175 +-
1 file changed, 106 insertions(+), 69 deletions(-)
--- linux-2625-rc1-kdoc.orig/include/linux/usb.h
+++ linux-2625-rc1-kdoc/include/linux/usb.h
@@ -342,102 +342,142 @@ struct usb_bus {
struct usb_tt;
-/*
+/**
* struct usb_device - kernel's representation of a USB device
+ * @devnum: device number; address on a USB bus
+ * @devpath: device ID string for use in messages (e.g., /port/...)
+ * @state: device state: configured, not attached, etc.
+ * @speed: device speed: high/full/low (or error)
+ * @tt: Transaction Translator info; used with low/full speed dev, highspeed
hub
+ * @ttport: device port on that tt hub
+ * @toggle: one bit for each endpoint, with ([0] = IN, [1] = OUT) endpoints
+ * @parent: our hub, unless we're the root
+ * @bus: bus we're part of
+ * @ep0: endpoint 0 data (default control pipe)
+ * @dev: generic device interface
+ * @descriptor: USB device descriptor
+ * @config: all of the device's configs
+ * @actconfig: the active configuration
+ * @ep_in: array of IN endpoints
+ * @ep_out: array of OUT endpoints
+ * @rawdescriptors: raw descriptors for each config
+ * @bus_mA: Current available from the bus
+ * @portnum: parent port number (origin 1)
+ * @level: number of USB hub ancestors
+ * @can_submit: URBs may be submitted
+ * @discon_suspended: disconnected while suspended
+ * @have_langid: whether string_langid is valid
+ * @authorized: policy has said we can use it;
+ * (user space) policy determines if we authorize this device to be
+ * used or not. By default, wired USB devices are authorized.
+ * WUSB devices are not, until we authorize them from user space.
+ * FIXME -- complete doc
+ * @wusb: device is Wireless USB
+ * @string_langid: language ID for strings
+ * @product: iProduct string, if present (static)
+ * @manufacturer: iManufacturer string, if present (static)
+ * @serial: iSerialNumber string, if present (static)
+ * @filelist: usbfs files that are open to this device
+ * @usb_classdev: USB class device that was created for usbfs device
+ * access from userspace
+ * @usbfs_dentry: usbfs dentry entry for the device
+ * @maxchild: number of ports if hub
+ * @children: child devices - USB devices that are attached to this hub
+ * @pm_usage_cnt: usage counter for autosuspend
+ * @quirks: quirks of the whole device
+ * @urbnum: number of URBs submitted for the whole device
+ * @active_duration: total time device is not suspended
+ * @autosuspend: for delayed autosuspends
+ * @pm_mutex: protects PM operations
+ * @last_busy: time of last use
+ * @autosuspend_delay: in jiffies
+ * @connect_time: time device was first connected
+ * @auto_pm: autosuspend/resume in progress
+ * @do_remote_wakeup: remote wakeup should be enabled
+ * @reset_resume: needs reset instead of resume
+ * @persist_enabled: USB_PERSIST enabled for this device
+ * @autosuspend_disabled: autosuspend disabled by the user
+ * @autoresume_disabled: autoresume disabled by the user
+ * @skip_sys_resume: skip the next system resume
*
- * FIXME: Write the kerneldoc!
- *
+ * Notes:
* Usbcore drivers should not set usbdev->state directly. Instead use
* usb_set_device_state().
- *
- * @authorized: (user space) policy determines if we authorize this
- * device to be used or not. By default, wired USB
- * devices are authorized. WUSB devices are not, until we
- * authorize them from user space. FIXME -- complete doc
*/
struct usb_device {
- int devnum; /* Address on USB bus */
- chardevpath [16]; /* Use in messages: /port/port/... */
- enum usb_device_state state; /* configured, not attached, etc */
- enum usb_device_speed speed; /* high/full/low (or error) */
+ int devnum;
+ chardevpath [16];
+ enum usb_device_state state;
+ enum usb_device_sp
Re: Flushing URBs for small control URBs
> You might want to add the "flash" functionality within the kernel > driver > itself, so you can get a bit tighter timing than relying on a > userspace/kernelspace turn around to provide an accurate timing loop. I was already considering this. At this point we fork a process to handle the GPIO functionality for us, so we can get reasonable timing on being able to flash the LED. Another process is worring about moving bytes. This is causing lockups in the and stalls in the communications. I've fixed the lockup issue, but I still am dealing with LED process stalling the two comms process. I was definitely considering changing the code so that all the user app would have to do is set the GPIO mode to off, on, and blink, and the Kernel would do all the dirty work. > > That would be interesting to find out. In the past, the company that > made this chip has been very unhelpful, going so far as to publish a > driver that violated the GPL and my copyright :( > Yeah that sucks. I talked to my manager (who did the first run at modifying the driver for GPIO support). He said that he sniffed out the packet with a usb protocol sniffer. He used the dev-kit and toggled the GPIOs to capture the packet with the sniffer. After I complete the changes I'm going to make to the driver, I can definitely forward them on if people are interested in them. I will likely need some guidance on coding standards and the like. > There are lots of other good and documented chips that work very well > with Linux that you might want to look into in the future for stuff > like > this (ftdi_sio is one, and there are others.) > Our hardware manager mentioned this today. That everyone has been giving us the gears for not using the ftdi part in the design. The problem is that their parts aren't rated for industrial temperature range. The cp210x family however is. Hardware requirements were more important than software requirements on that front. If I had my choice the cp210x parts would never be in any of our products. Andrew - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Flushing URBs for small control URBs
On Wed, Feb 13, 2008 at 05:27:57PM -0600, Andrew McKay wrote: > Greg KH wrote: >> On Wed, Feb 13, 2008 at 01:31:54PM -0600, Andrew McKay wrote: >>> Hi >>> >>> For a project I'm working on we had to add GPIO support to the cp2103 >>> driver in the 2.6.20.4 kernel. >> Can't you just do this from a usbfs/libusb application from userspace >> instead? Why add a custom ioctl to the driver? Or are you also using >> the serial portion of the driver and need that to also talk to the >> device? > > I've never heard of usbfs/libusb before. As I mentioned before. I'm a > complete newb to USB development. I got thrown into it because of some > serious bugs we were having with the CP2103. I'll have to look into this > as well. usbfs is a way to control usb devices directly from userspace, no kernel driver needed. libusb is a "nicer" wrapper on top of usbfs that makes it easier to control the devices, so that you don't have to write code that controls usbfs in a "raw" manner. > In our project we're using the serial portion of the driver already in the > kernel. On our hardware we added extra serial ports with the CP2103 on > board (don't ask why, I wasn't happy about that choice). Beside the serial > connectors we have an LED that gives the user a status of the port. The > userland application that is reading and writing from the serial port > controls the LEDs. Ah, so you need the serial port functionality, usbfs isn't going to really help out here, sorry. > Off = unactive > On = active > Flashing = error talking to connected device You might want to add the "flash" functionality within the kernel driver itself, so you can get a bit tighter timing than relying on a userspace/kernelspace turn around to provide an accurate timing loop. >>> This leads me to my question. Is there a buffer that the control URB >>> ends up sitting in that doesn't get flushed until a certain number of >>> bytes are sent to the USB end point? If this is the case, is there an >>> accepted method of fushing the URB to the USB endpoint? >> It should be there when you get called back. >> Do you have the docs for how this chip really works? If so, that might >> help out as the driver was written by reverse-engineering the protocol, >> so there might be bugs in the driver. > > No I don't have a lot of information about how this chip really works. We > managed to get some information about what byte sequence to send to it to > get the GPIOs to toggle on and off. That would be interesting to find out. In the past, the company that made this chip has been very unhelpful, going so far as to publish a driver that violated the GPL and my copyright :( There are lots of other good and documented chips that work very well with Linux that you might want to look into in the future for stuff like this (ftdi_sio is one, and there are others.) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Flushing URBs for small control URBs
Greg KH wrote: On Wed, Feb 13, 2008 at 01:31:54PM -0600, Andrew McKay wrote: Hi For a project I'm working on we had to add GPIO support to the cp2103 driver in the 2.6.20.4 kernel. Can't you just do this from a usbfs/libusb application from userspace instead? Why add a custom ioctl to the driver? Or are you also using the serial portion of the driver and need that to also talk to the device? I've never heard of usbfs/libusb before. As I mentioned before. I'm a complete newb to USB development. I got thrown into it because of some serious bugs we were having with the CP2103. I'll have to look into this as well. In our project we're using the serial portion of the driver already in the kernel. On our hardware we added extra serial ports with the CP2103 on board (don't ask why, I wasn't happy about that choice). Beside the serial connectors we have an LED that gives the user a status of the port. The userland application that is reading and writing from the serial port controls the LEDs. Off = unactive On = active Flashing = error talking to connected device This leads me to my question. Is there a buffer that the control URB ends up sitting in that doesn't get flushed until a certain number of bytes are sent to the USB end point? If this is the case, is there an accepted method of fushing the URB to the USB endpoint? It should be there when you get called back. Do you have the docs for how this chip really works? If so, that might help out as the driver was written by reverse-engineering the protocol, so there might be bugs in the driver. No I don't have a lot of information about how this chip really works. We managed to get some information about what byte sequence to send to it to get the GPIOs to toggle on and off. Andrew - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with starting 2.5.25-rc1 and latest git
Of course there is a typo in the subject :)
2.5.25-rc1 -> 2.6.25-rc1
> Hello,
>
> I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a
> problem.
> Linux boots but with huge delay due to some issue with loading usb modules.
> Udev complains:
>
> 'Could not lock modprobe uhci_hcd'
> 'Could not lock modprobe yenta_socket'
> 'Unknown symbol usb_*'
> 'Gave up waiting for init of module usbcore'
>
> at the same time I can see these messages in syslog (look at timing - grep by
> usb):
>
> Feb 13 21:34:22 laptop kernel: usbcore: registered new interface driver usbfs
> Feb 13 21:34:22 laptop kernel: usbcore: registered new interface driver hub
> Feb 13 21:34:22 laptop kernel: usbcore: registered new device driver usb
> Feb 13 21:34:22 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:34:22 laptop kernel: ehci_hcd: Unknown symbol usb_hcd_pci_suspend
> Feb 13 21:34:22 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:34:22 laptop kernel: ehci_hcd: Unknown symbol usb_free_urb
> Feb 13 21:34:31 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:34:31 laptop kernel: ehci_hcd: Unknown symbol
> usb_hub_tt_clear_buffer
> Feb 13 21:35:01 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:35:01 laptop kernel: ehci_hcd: Unknown symbol
> usb_hcd_resume_root_hub
> Feb 13 21:35:32 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:35:32 laptop kernel: ehci_hcd: Unknown symbol usb_hcd_pci_probe
> Feb 13 21:36:02 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:36:02 laptop kernel: ehci_hcd: Unknown symbol
> usb_hcd_unlink_urb_from_ep
> Feb 13 21:36:32 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:36:32 laptop kernel: ehci_hcd: Unknown symbol
> usb_hcd_check_unlink_urb
> Feb 13 21:37:02 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:37:02 laptop kernel: ehci_hcd: Unknown symbol usb_calc_bus_time
> Feb 13 21:37:32 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:38:02 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:38:02 laptop kernel: ehci_hcd: Unknown symbol usb_hcd_pci_shutdown
> Feb 13 21:38:32 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:38:32 laptop kernel: ehci_hcd: Unknown symbol usb_hcd_link_urb_to_ep
> Feb 13 21:39:02 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:39:02 laptop kernel: ehci_hcd: Unknown symbol usb_hcd_pci_resume
> Feb 13 21:39:32 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:39:32 laptop kernel: ehci_hcd: Unknown symbol usb_get_urb
> Feb 13 21:40:02 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:40:02 laptop kernel: ehci_hcd: Unknown symbol usb_hcd_giveback_urb
> Feb 13 21:40:32 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:40:32 laptop kernel: ehci_hcd: Unknown symbol usb_hcd_poll_rh_status
> Feb 13 21:41:02 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:41:02 laptop kernel: ehci_hcd: Unknown symbol usb_hcd_pci_remove
> Feb 13 21:41:32 laptop kernel: ehci_hcd: gave up waiting for init of module
> usbcore.
> Feb 13 21:41:32 laptop kernel: ehci_hcd: Unknown symbol
> usb_root_hub_lost_power
>
> Sysrq says:
>
> Feb 13 21:35:06 laptop kernel: Showing all locks held in the system:
> Feb 13 21:35:06 laptop kernel: 1 lock held by modprobe/1130:
> Feb 13 21:35:06 laptop kernel: #0: (module_mutex){--..}, at: []
> sys_init_module+0x3d/0x1749
> Feb 13 21:35:06 laptop kernel: 1 lock held by modprobe/1131:
> Feb 13 21:35:06 laptop kernel: #0: (module_mutex){--..}, at: []
> sys_init_module+0x128/0x1749
> Feb 13 21:35:06 laptop kernel: 2 locks held by modprobe/1143:
> Feb 13 21:35:06 laptop kernel: #0: (&p->lock){--..}, at: []
> seq_read+0x26/0x2b5
> Feb 13 21:35:06 laptop kernel: #1: (module_mutex){--..}, at: []
> m_start+0xf/0x1f
> Feb 13 21:35:06 laptop kernel: 2 locks held by modprobe/1144:
> Feb 13 21:35:06 laptop kernel: #0: (&p->lock){--..}, at: []
> seq_read+0x26/0x2b5
> Feb 13 21:35:06 laptop kernel: #1: (module_mutex){--..}, at: []
> m_start+0xf/0x1f
> Feb 13 21:35:06 laptop kernel: 2 locks held by modprobe/1352:
> Feb 13 21:35:06 laptop kernel: #0: (&p->lock){--..}, at: []
> seq_read+0x26/0x2b5
> Feb 13 21:35:06 laptop kernel: #1: (module_mutex){--..}, at: []
> m_start+0xf/0x1f
> Feb 13 21:35:06 laptop kernel: 2 locks held by modprobe/1354:
> Feb 13 21:35:06 laptop kernel: #0: (&p->lock){--..}, at: []
> seq_read+0x26/0x2b5
> Feb 13 21:35:06 laptop kernel: #1: (module_mutex){--..}, at: []
> m_start+0xf/0x1f
> Feb 13 21:35:06 laptop kernel: 2 locks held by modprobe/1547:
> Feb 13
Re: Flushing URBs for small control URBs
On Wed, Feb 13, 2008 at 01:31:54PM -0600, Andrew McKay wrote:
> Hi
>
> For a project I'm working on we had to add GPIO support to the cp2103
> driver in the 2.6.20.4 kernel.
Can't you just do this from a usbfs/libusb application from userspace
instead? Why add a custom ioctl to the driver? Or are you also using
the serial portion of the driver and need that to also talk to the
device?
> We are controlling a GPIO via ictl to flash an LED. We'd like to hit
> something along the lines or 1-3HZ. So nothing too fast. I use a
> control URB to tell the cp2103 device to toggle its GPIO state. My
> function like:
>
> static void cp2103_send_GPIO_packet(struct usb_serial_port *port, u8 mask,
> u8 latch){
> int i,ret_val;
> unsigned long flags;
> u8 pkt[USB_GPIO_PKT_SIZE]={0x40,0xff,0xe1,0x37,0x0f,0x00,0x00,0x00};
>
> spin_lock_bh(&port->lock);
> if (port->write_urb_busy) {
> spin_unlock_bh(&port->lock);
> dbg("%s - already writing", __FUNCTION__);
> return 0;
> }
> port->write_urb_busy = 1;
> spin_unlock_bh(&port->lock);
>
> /* place the latch and mask bytes in the correct place in the packet */
> pkt[4] = latch;
> pkt[5] = mask;
>
> if(port->write_urb->setup_packet == NULL){
> port->write_urb->setup_packet = kmalloc(sizeof(u8)*USB_GPIO_PKT_SIZE,
> GFP_KERNEL);
> memcpy(port->write_urb->setup_packet, pkt, USB_GPIO_PKT_SIZE);
>
> /* Fill our Control Packet */
> usb_fill_control_urb(port->write_urb, port->serial->dev,
> usb_sndctrlpipe(port->serial->dev, 0),
> port->write_urb->setup_packet,
> port->write_urb->transfer_buffer,
> 0, cp2103_send_GPIO_callback, port);
>
> ret_val = usb_submit_urb(port->write_urb, GFP_ATOMIC);
> if(ret_val){
> printk("[ERROR: usb_submit_urb:%i]\n",ret_val);
> }
> }else{
> printk("[ERROR: port->write_urb->setup_packet is NOT NULL\n");
> port->write_urb_busy=0;
> }
> }
>
> In kernel userland I have a loop that runs every 500ms at the moment
> toggling the state of the GPIO. I have verified that the loop is running
> fairly close to 500ms (within 10% no issues), and looked at debug code from
> kernel space and the ioctl function is being run at the same rate. The
> ioctl always returns success to the user application, but the LED flashes
> at a strange rate. It doesn't appear to toggle every ioctl call. If I
> call the ioctl function several times in a row suddenly it flashes every
> 500ms no problem.
>
> This leads me to my question. Is there a buffer that the control URB ends
> up sitting in that doesn't get flushed until a certain number of bytes are
> sent to the USB end point? If this is the case, is there an accepted
> method of fushing the URB to the USB endpoint?
It should be there when you get called back.
Do you have the docs for how this chip really works? If so, that might
help out as the driver was written by reverse-engineering the protocol,
so there might be bugs in the driver.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Flushing URBs for small control URBs
Andrew McKay wrote:
Pete Zaitcev wrote:
On Wed, 13 Feb 2008 13:31:54 -0600, Andrew McKay <[EMAIL PROTECTED]> wrote:
spin_lock_bh(&port->lock);
if (port->write_urb_busy) {
If you lock against callbacks and do not trigger tasklets yourself,
you must use spin_lock_irqsave (or spin_lock_irq if you are belong
to Oliver's denomination).
Hmm okay, I'll look into this.
I looked into why I used a spin_lock_bh. The cp2103 driver that I use doesn't
implement a write function, it just uses the usb_serial_generic_write function
in drivers/usb/serial/generic.c. I copied the method of locking from that code
because the control urb I'm sending uses the same write_urb struture as
usb_serial_generic_write. The kernel that I'm using is older (2.6.20.4). Looks
like this was a bug fix somewhere between 2.6.20.4 and the latest stable release.
I'll have to patch up the generic serial driver it looks like.
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: convert usb.h struct usb_device to kernel-doc
On Wed, 13 Feb 2008, Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > Convert struct usb_device to use kernel-doc notation. > Please especially check the @filelist and @usb_classdev descriptions. > > Fix a few other kernel-doc lines that should be all on one line but were on > multiple lines. > + * @rawdescriptors: waw descriptors for each config Typo. > + * @children: child devices - these can be either new devices (if this is a > + * hub device), or different instances of this same device. > + * Each instance needs its own set of data structures. What does "different instances of this same device" mean? Apparently This is a fossil comment; IMO it should be removed. Only hubs have children. > + * @delayed_work autosuspend: for delayed autosuspends Typo: the variable is just "autosuspend". "delayed_work" is part of the structure tag. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Flushing URBs for small control URBs
On Wed, 13 Feb 2008, Pete Zaitcev wrote: > On Wed, 13 Feb 2008 15:53:48 -0600, Andrew McKay <[EMAIL PROTECTED]> wrote: > > > Once the callback function has been called does this guarantee that the > > URB > > has already been sent to hardware? > > Yes (if the returned status was zero). > > > I'll definitely look into this usbmon app. I have timed things out and > > from the > > time I call usb_submit_urb until the callback is 1 jiffie or less. BTW, usbmon isn't an app -- it's a kernel module. The instructions for using it are in the kernel source file Documentation/usb/usbmon.txt. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Refactor EHCI shutdown functions and fix potential bugs.
This patch refactors some shutdown code so it can be shared between
ehci_stop() and ehci_shutdown().
This also fixes a couple potential bugs:
- ehci_shutdown() was not locking ehci->lock before halting the HC.
- ehci_shutdown() didn't disable the watchdog and IAA timers.
- ehci_stop() was resetting the host controller when it may have been
running, which the EHCI spec says "may result in undefined behavior".
ehci_stop() was calling port_power() to turn off the ports, which waited
20ms after applying the port change. The msleep was for the case where
the HC might take 20ms to turn the ports on; since we're shutting them
off, we can avoid the msleep and just use ehci_turn_off_ports().
ehci_stop() doesn't need to clear the intr_enable register or revert
ownership of the companion controllers to the BIOS, because the host
controller reset should have done that. There might be a buggy host
controller that doesn't follow the reset rules, but for now we assume
it's redundant code and remove it.
Signed-off-by: Sarah Sharp <[EMAIL PROTECTED]>
---
drivers/usb/host/ehci-hcd.c | 41 +
1 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 4caa6a8..b35285b 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -334,17 +334,13 @@ static void ehci_turn_off_all_ports(struct ehci_hcd *ehci)
&ehci->regs->port_status[port]);
}
-/* ehci_shutdown kick in for silicon on any bus (not just pci, etc).
- * This forcibly disables dma and IRQs, helping kexec and other cases
- * where the next system software may expect clean state.
+/*
+ * Halt HC, turn off all ports, and let the BIOS use the companion controllers.
+ * Should be called with ehci->lock held.
*/
-static void
-ehci_shutdown (struct usb_hcd *hcd)
+static void ehci_silence_controller(struct ehci_hcd *ehci)
{
- struct ehci_hcd *ehci;
-
- ehci = hcd_to_ehci (hcd);
- (void) ehci_halt (ehci);
+ ehci_halt(ehci);
ehci_turn_off_all_ports(ehci);
/* make BIOS/etc use companion controller during reboot */
@@ -354,6 +350,22 @@ ehci_shutdown (struct usb_hcd *hcd)
ehci_readl(ehci, &ehci->regs->configured_flag);
}
+/* ehci_shutdown kick in for silicon on any bus (not just pci, etc).
+ * This forcibly disables dma and IRQs, helping kexec and other cases
+ * where the next system software may expect clean state.
+ */
+static void ehci_shutdown(struct usb_hcd *hcd)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+
+ del_timer_sync(&ehci->watchdog);
+ del_timer_sync(&ehci->iaa_watchdog);
+
+ spin_lock_irq(&ehci->lock);
+ ehci_silence_controller(ehci);
+ spin_unlock_irq(&ehci->lock);
+}
+
static void ehci_port_power (struct ehci_hcd *ehci, int is_on)
{
unsigned port;
@@ -404,15 +416,15 @@ static void ehci_work (struct ehci_hcd *ehci)
timer_action (ehci, TIMER_IO_WATCHDOG);
}
+/*
+ * Called when the ehci_hcd module is removed.
+ */
static void ehci_stop (struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
ehci_dbg (ehci, "stop\n");
- /* Turn off port power on all root hub ports. */
- ehci_port_power (ehci, 0);
-
/* no more interrupts ... */
del_timer_sync (&ehci->watchdog);
del_timer_sync(&ehci->iaa_watchdog);
@@ -421,13 +433,10 @@ static void ehci_stop (struct usb_hcd *hcd)
if (HC_IS_RUNNING (hcd->state))
ehci_quiesce (ehci);
+ ehci_silence_controller(ehci);
ehci_reset (ehci);
- ehci_writel(ehci, 0, &ehci->regs->intr_enable);
spin_unlock_irq(&ehci->lock);
- /* let companion controllers work when we aren't */
- ehci_writel(ehci, 0, &ehci->regs->configured_flag);
-
remove_companion_file(ehci);
remove_debug_files (ehci);
--
1.5.3.4
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Flushing URBs for small control URBs
On Wed, 13 Feb 2008 15:53:48 -0600, Andrew McKay <[EMAIL PROTECTED]> wrote: > Once the callback function has been called does this guarantee that the URB > has already been sent to hardware? Yes (if the returned status was zero). > I'll definitely look into this usbmon app. I have timed things out and from > the > time I call usb_submit_urb until the callback is 1 jiffie or less. In this case you don't need usbmon for timing, but still have a look, it might clear the picture by giving a more complete view. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: OTG: Fix weirdnesses on enumerating partial otg devices
On Wed, Feb 13, 2008 at 01:36:00PM -0800, David Brownell wrote: > On Wednesday 13 February 2008, Felipe Balbi wrote: > > On Tue, Feb 12, 2008 at 12:32:34PM -0800, David Brownell wrote: > > > > > > Your proposal is to strike the "is_b_host" check. In terms of the > > > OTG (1.3) state machine, that removes a b_host --> b_peripheral > > > state transition. > > > > Not at all, we're just not doing transition right now. > > When *would* it happen then? And why not do it as soon as it's > known that the device on the other end of the cable is unsupported? Whenever we finnish using the bus we'd suspend it. This would sinalize a_peripheral switch back to a_host. Also, even though it's not on our TPL it doesn't mean we can't work with it. > > > > > BUT: notice it doesn't replace it with the ONLY other valid state > > > transition, b_host --> b_idle. In fact, that can not be initiated > > > by the B-device... > > > > > > So the current code *is* correct. > > > > > > ... deletia ... > > > > > > > We should at least try to enumerate a_peripheral, if it can't due to > > > > our power capabilities i.e. 100mA, we'll fall into overcurrent > > > > protection and we'll suspend the bus and disconnect, which would give > > > > a_device another change to enumerate us. > > > > > > > > This sound much better to me. > > > > > > You're overlooking something: this is the "!is_targeted(udev)" > > > case, so we have already enumerated the a_peripheral as much as > > > we can. There is *nothing* more we can do with it. Sitting > > > around in the b_host state would be utterly pointless. > > > > And you're overlooking something: tpl is not an enumeration blocker at > > all. The only blockers are drivers and power limits. > > The device has already been enumerated at this point. This is just > whether to set up communication with, and use, the device ... which > activity *IS* predicated on device support, "on the TPL" (as it says > in 6.8.1.4 of the spec for the A_HOST role, later reusing that language > where it describes the B_HOST role). > It only tell us to output a message to the user indicating it's not supported. Same for b_host. It never says we should end the session at that point. OTG Rev 1.3 is unclear about this. That's why I consulted Richard Pietre and asked him what would be the most sane way of handling hnp and he told me to implement it always trying to work with the device even though it's not tpl'ed. > > Imagine what happens on n810, we have 3 mass storage devices listed on > > its tpl: 770, n800 and itself. Besides that, we allow enumeration of any > > mass storage device as long as it draws less than 100mA. > > While it makes sense to me that an OTG device support things like > mass storage class devices, I still see that spec language saying > that classes can't be on the TPL ... and that only devices on the > TPL get communication beyond what's needed for enumeration. It doesn't say your last point. Besides, it says: "The Targeted Peripheral List shall not list supported USB Classes or similar devices." By "similar" we can understand several mass storage devices. It doesn't really matter on usb otg point of view whether we support mass storage device A or mass storage device B, both should work if they meet otg requirements (power consumption being the most significant issue). We can also see the TPL example on otg rev 1.3 is not listing "similar" devices. They are all different. Quoting from otg rev 1.3 Section 3.3: Vendor Model Speed TransportVIDPID Description 1. Logitech M-BJ58LS Int 0x046D 0xC00E USB Wheel Mouse 2. Yamaha YST-MS35D FS Isoch 0x0499 0x3002 USB Speakers 3. TEAC Corporation FD-05PUB FS Bulk 0x0644 0x USB Floppy Drive 4. Hewlett Packard D125XIFS Bulk 0x03F0 0x2311 All-In-One Printer/Scanner/Copier This sounds like another clue that we should be able to "try" to work with any mouse, any speekers, any floppy and any printer as long as they meet power requirements because we have support for them built into the otg device. > Regardless, that's a red herring. If you allow sane things like > arbitrary flash memory sticks to be used, you've effectively put > a device class on the TPL. But this discussion is about things > that are NOT on the TPL. No cuz I'm still notifying my user the device is unsupported even though it's not even a requirement, if the device meet otg constraints*(explained below). Which means it might or might not work. If it happen to work, that's fine, if it doesn't the user has been notified about that possibility. One other thing "Device is Not Supported" is just an example message. * In section 3.4 OTG says: (...) and the OTG device does not support the type of communitcation being requested by the user, then the OTG device shall provide messages to th
Re: Flushing URBs for small control URBs
Pete Zaitcev wrote:
On Wed, 13 Feb 2008 13:31:54 -0600, Andrew McKay <[EMAIL PROTECTED]> wrote:
spin_lock_bh(&port->lock);
if (port->write_urb_busy) {
If you lock against callbacks and do not trigger tasklets yourself,
you must use spin_lock_irqsave (or spin_lock_irq if you are belong
to Oliver's denomination).
Hmm okay, I'll look into this.
Don't overthink it.
Look at the traffic with usbmon, it provides you timestamps for
(S)ubmission and (C)allback events.
I don't completely understand the USB subsystem, so this may be a dumb question.
Once the callback function has been called does this guarantee that the URB
has already been sent to hardware? Or does it mean it's been copied into
another buffer somewhere waiting to sent out of the host controller?
I'll definitely look into this usbmon app. I have timed things out and from the
time I call usb_submit_urb until the callback is 1 jiffie or less. So worst
case 20ms in my kernel. It can't be causing the variations in timing that I'm
seeing.
I did manage to fix my weird flashing rate by keeping the devnode open in
userland. It appears opening and closing the device was causing my issues. I'm
looking into that now.
Thanks,
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: convert usb.h struct usb_device to kernel-doc
From: Randy Dunlap <[EMAIL PROTECTED]>
Convert struct usb_device to use kernel-doc notation.
Please especially check the @filelist and @usb_classdev descriptions.
Fix a few other kernel-doc lines that should be all on one line but were on
multiple lines.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
include/linux/usb.h | 177 +-
1 file changed, 108 insertions(+), 69 deletions(-)
--- linux-2625-rc1-kdoc.orig/include/linux/usb.h
+++ linux-2625-rc1-kdoc/include/linux/usb.h
@@ -342,102 +342,144 @@ struct usb_bus {
struct usb_tt;
-/*
+/**
* struct usb_device - kernel's representation of a USB device
+ * @devnum: device number; address on a USB bus
+ * @devpath: device ID string for use in messages (e.g., /port/...)
+ * @state: device state: configured, not attached, etc.
+ * @speed: device speed: high/full/low (or error)
+ * @tt: Transaction Translator info; used with low/full speed dev, highspeed
hub
+ * @ttport: device port on that tt hub
+ * @toggle: one bit for each endpoint, with ([0] = IN, [1] = OUT) endpoints
+ * @parent: our hub, unless we're the root
+ * @bus: bus we're part of
+ * @ep0: endpoint 0 data (default control pipe)
+ * @dev: generic device interface
+ * @descriptor: USB device descriptor
+ * @config: all of the device's configs
+ * @actconfig: the active configuration
+ * @ep_in: array of IN endpoints
+ * @ep_out: array of OUT endpoints
+ * @rawdescriptors: waw descriptors for each config
+ * @bus_mA: Current available from the bus
+ * @portnum: parent port number (origin 1)
+ * @level: number of USB hub ancestors
+ * @can_submit: URBs may be submitted
+ * @discon_suspended: disconnected while suspended
+ * @have_langid: whether string_langid is valid
+ * @authorized: policy has said we can use it;
+ * (user space) policy determines if we authorize this device to be
+ * used or not. By default, wired USB devices are authorized.
+ * WUSB devices are not, until we authorize them from user space.
+ * FIXME -- complete doc
+ * @wusb: device is Wireless USB
+ * @string_langid: language ID for strings
+ * @product: iProduct string, if present (static)
+ * @manufacturer: iManufacturer string, if present (static)
+ * @serial: iSerialNumber string, if present (static)
+ * @filelist: usbfs files that are open to this device
+ * @usb_classdev: USB class device that was created for usbfs device
+ * access from userspace
+ * @usbfs_dentry: usbfs dentry entry for the device
+ * @maxchild: number of ports if hub
+ * @children: child devices - these can be either new devices (if this is a
+ * hub device), or different instances of this same device.
+ * Each instance needs its own set of data structures.
+ * @pm_usage_cnt: usage counter for autosuspend
+ * @quirks: quirks of the whole device
+ * @urbnum: number of URBs submitted for the whole device
+ * @active_duration: total time device is not suspended
+ * @delayed_work autosuspend: for delayed autosuspends
+ * @pm_mutex: protects PM operations
+ * @last_busy: time of last use
+ * @autosuspend_delay: in jiffies
+ * @connect_time: time device was first connected
+ * @auto_pm: autosuspend/resume in progress
+ * @do_remote_wakeup: remote wakeup should be enabled
+ * @reset_resume: needs reset instead of resume
+ * @persist_enabled: USB_PERSIST enabled for this device
+ * @autosuspend_disabled: autosuspend disabled by the user
+ * @autoresume_disabled: autoresume disabled by the user
+ * @skip_sys_resume: skip the next system resume
*
- * FIXME: Write the kerneldoc!
- *
+ * Notes:
* Usbcore drivers should not set usbdev->state directly. Instead use
* usb_set_device_state().
- *
- * @authorized: (user space) policy determines if we authorize this
- * device to be used or not. By default, wired USB
- * devices are authorized. WUSB devices are not, until we
- * authorize them from user space. FIXME -- complete doc
*/
struct usb_device {
- int devnum; /* Address on USB bus */
- chardevpath [16]; /* Use in messages: /port/port/... */
- enum usb_device_state state; /* configured, not attached, etc */
- enum usb_device_speed speed; /* high/full/low (or error) */
+ int devnum;
+ chardevpath [16];
+ enum usb_device_state state;
+ enum usb_device_speed speed;
- struct usb_tt *tt;/* low/full speed dev, highspeed hub */
- int ttport; /* device port on that tt hub */
+ struct usb_tt *tt;
+ int ttport;
- unsigned int toggle[2]; /* one bit for each endpoint
-* ([0] = IN, [1] = OUT) */
+ unsigned int toggle[2];
- struct usb_device *parent; /* our hub, unless we're the root */
- struct usb_bus *bus;/* Bus we're part of */
+ struct usb_device *parent;
+
Re: Flushing URBs for small control URBs
On Wed, 13 Feb 2008 13:31:54 -0600, Andrew McKay <[EMAIL PROTECTED]> wrote:
>spin_lock_bh(&port->lock);
>if (port->write_urb_busy) {
If you lock against callbacks and do not trigger tasklets yourself,
you must use spin_lock_irqsave (or spin_lock_irq if you are belong
to Oliver's denomination).
> This leads me to my question. Is there a buffer that the control URB ends up
> sitting in that doesn't get flushed until a certain number of bytes are sent
> to
> the USB end point? If this is the case, is there an accepted method of
> fushing
> the URB to the USB endpoint?
Don't overthink it.
Look at the traffic with usbmon, it provides you timestamps for
(S)ubmission and (C)allback events.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: Prevent EHCI ITDs reusage while frame is active
ITDs can be detached from urbs, before the active frame elapses. Now those
ITDs are immediately recycled.
If the ITD is reused then, transactions based on its new usage can already
happen while the frame is still active, too early.
Patch takes care of those ITDs by moving them into a new ehci member list
cached_itd_list. ITDs resting in cached_itd_list are moved back into their
stream's free_list once scan_periodic() detects that the active frame has
elapsed.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
---
drivers/usb/host/ehci-hcd.c |2 +
drivers/usb/host/ehci-mem.c |1 +
drivers/usb/host/ehci-sched.c | 57 ++--
drivers/usb/host/ehci.h |5 +++
4 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 4caa6a8..b75db12 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -473,6 +473,7 @@ static int ehci_init(struct usb_hcd *hcd)
* periodic_size can shrink by USBCMD update if hcc_params allows.
*/
ehci->periodic_size = DEFAULT_I_TDPS;
+ INIT_LIST_HEAD(&ehci->cached_itd_list);
if ((retval = ehci_mem_init(ehci, GFP_KERNEL)) < 0)
return retval;
@@ -485,6 +486,7 @@ static int ehci_init(struct usb_hcd *hcd)
ehci->reclaim = NULL;
ehci->next_uframe = -1;
+ ehci->hw_frame = -1;
/*
* dedicate a qh for the async ring head, since we couldn't unlink
diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
index 0431397..10d5291 100644
--- a/drivers/usb/host/ehci-mem.c
+++ b/drivers/usb/host/ehci-mem.c
@@ -128,6 +128,7 @@ static inline void qh_put (struct ehci_qh *qh)
static void ehci_mem_cleanup (struct ehci_hcd *ehci)
{
+ free_cached_itd_list(ehci);
if (ehci->async)
qh_put (ehci->async);
ehci->async = NULL;
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 8a8e08a..f3afade 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1005,7 +1005,8 @@ iso_stream_put(struct ehci_hcd *ehci, struct
ehci_iso_stream *stream)
is_in = (stream->bEndpointAddress & USB_DIR_IN) ? 0x10 : 0;
stream->bEndpointAddress &= 0x0f;
- stream->ep->hcpriv = NULL;
+ if (stream->ep)
+ stream->ep->hcpriv = NULL;
if (stream->rescheduled) {
ehci_info (ehci, "ep%d%s-iso rescheduled "
@@ -1647,14 +1648,26 @@ itd_complete (
(stream->bEndpointAddress & USB_DIR_IN) ? "in" : "out");
}
iso_stream_put (ehci, stream);
- /* OK to recycle this ITD now that its completion callback ran. */
+
done:
usb_put_urb(urb);
itd->urb = NULL;
- itd->stream = NULL;
- list_move(&itd->itd_list, &stream->free_list);
- iso_stream_put(ehci, stream);
-
+ if (ehci->hw_frame != itd->frame || itd->index[7] != -1) {
+ /* OK to recycle this ITD now. */
+ itd->stream = NULL;
+ list_move(&itd->itd_list, &stream->free_list);
+ iso_stream_put(ehci, stream);
+ } else {
+ /* HW might still start transactions based on this ITD.
+ If its content changed that is. Move it to a safe place. */
+ list_move(&itd->itd_list, &ehci->cached_itd_list);
+ if (stream->refcount == 2) {
+ /* If iso_stream_put() would be called here, stream
+ would be freed. Prevent stream's reusage instead. */
+ stream->ep->hcpriv = NULL;
+ stream->ep = NULL;
+ }
+ }
return retval;
}
@@ -2100,10 +2113,24 @@ done:
/*-*/
+static void free_cached_itd_list(struct ehci_hcd *ehci)
+{
+ struct ehci_itd *itd, *n;
+
+ list_for_each_entry_safe(itd, n, &ehci->cached_itd_list, itd_list) {
+ struct ehci_iso_stream *stream = itd->stream;
+ itd->stream = NULL;
+ list_move(&itd->itd_list, &stream->free_list);
+ iso_stream_put(ehci, stream);
+ }
+}
+
+/*-*/
+
static void
scan_periodic (struct ehci_hcd *ehci)
{
- unsignedframe, clock, now_uframe, mod;
+ unsignedframe, hw_frame, clock, now_uframe, mod;
unsignedmodified;
mod = ehci->periodic_size << 3;
@@ -2114,10 +2141,17 @@ scan_periodic (struct ehci_hcd *ehci)
* Touches as few pages as possible: cache-friendly.
*/
now_uframe = ehci->next_uframe;
- if (HC_IS_RUNNING (ehci_to_hcd(ehci)->state))
+ if (HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
cloc
Re: [PATCH] USB: OTG: Fix weirdnesses on enumerating partial otg devices
On Wednesday 13 February 2008, Felipe Balbi wrote:
> On Tue, Feb 12, 2008 at 12:32:34PM -0800, David Brownell wrote:
> >
> > Your proposal is to strike the "is_b_host" check. In terms of the
> > OTG (1.3) state machine, that removes a b_host --> b_peripheral
> > state transition.
>
> Not at all, we're just not doing transition right now.
When *would* it happen then? And why not do it as soon as it's
known that the device on the other end of the cable is unsupported?
> > BUT: notice it doesn't replace it with the ONLY other valid state
> > transition, b_host --> b_idle. In fact, that can not be initiated
> > by the B-device...
> >
> > So the current code *is* correct.
> >
> > ... deletia ...
> >
> > > We should at least try to enumerate a_peripheral, if it can't due to
> > > our power capabilities i.e. 100mA, we'll fall into overcurrent
> > > protection and we'll suspend the bus and disconnect, which would give
> > > a_device another change to enumerate us.
> > >
> > > This sound much better to me.
> >
> > You're overlooking something: this is the "!is_targeted(udev)"
> > case, so we have already enumerated the a_peripheral as much as
> > we can. There is *nothing* more we can do with it. Sitting
> > around in the b_host state would be utterly pointless.
>
> And you're overlooking something: tpl is not an enumeration blocker at
> all. The only blockers are drivers and power limits.
The device has already been enumerated at this point. This is just
whether to set up communication with, and use, the device ... which
activity *IS* predicated on device support, "on the TPL" (as it says
in 6.8.1.4 of the spec for the A_HOST role, later reusing that language
where it describes the B_HOST role).
> Imagine what happens on n810, we have 3 mass storage devices listed on
> its tpl: 770, n800 and itself. Besides that, we allow enumeration of any
> mass storage device as long as it draws less than 100mA.
While it makes sense to me that an OTG device support things like
mass storage class devices, I still see that spec language saying
that classes can't be on the TPL ... and that only devices on the
TPL get communication beyond what's needed for enumeration.
Regardless, that's a red herring. If you allow sane things like
arbitrary flash memory sticks to be used, you've effectively put
a device class on the TPL. But this discussion is about things
that are NOT on the TPL.
> These tips I
> got from otg chairman himself and from OTG Clarification document, you
> can find it in compliance.usb.org.
Well, I'm glad at least one person there is talking sanely about
the TPL, but there is no such clarification that I can find.
I've observed USB-IF to be slow to address bugs in their specs,
maybe that's what's going on here. Bugs are often written into
specs as political compromises, and they can linger for various
reasons. (Including members with hidden agendas to block success,
and people who prefer to deny inconvenient realities.)
> So, what I'm trying to say is if
> a_device let us become host, we shold at least try to do, let's call it,
> full enumeration. Which means attaching any unlisted mass storage device
> should work.
Attaching works, sure. If you are willing to communicate with
that device, then it's on the Targeted Peripherals List (TPL),
so this code branch doesn't apply.
Put it this way: there is no *OTHER* mechanism for deciding not
to talk with a device; and that's the entire purpose of the TPL.
> > > 4. B-device become b_host, checks a_peripheral is not on its tpl, even
> > > though it has support for that device class
> >
> > If it supports a device class I'd say that should be included
> > in the TPL ("whitelist"). Though if it tries to do that, it's
> > an explicit violation of the OTG spec (sect 3.3):
>
> We can't support classes. What I'm trying to say is we have usb mass
> storage support enabled in kernel and we can handle _any_ mass storage
> devices as long as they meet otg requirements.
I think that detail of the OTG spec is stupid and misguided.
Of *course* it should be possible to support, for example,
devices that weren't shipped before your product's TPL was
defined. How ever you define the list of Targeted/supported
peripherals, that's got to be able to include classes and
similar mechanisms. That spec stupidity is one issue;
for the scope of this discussion I'll assume the TPL (which
has an algorithmic check) can pass things like flash sticks.
The other issue is what you call the part of your product
documentation which says what devices it can talk to. The
only term for such stuff in the OTG spec is "Targeted
Peripherals List". If you're assuming some other design
abstraction packages that notion, that doesn't match what
the Linux-USB code does.
If you wanted to *add* such an abstraction, you'd have to put
it everywhere the current whitelist is used ... better IMO to
just update the current whitelist/TPL code to handle classes.
Right
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
I'm glad this problem has been solved for good. Listening to music is such a nice thing :-) thanks everybody ! robert - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Flushing URBs for small control URBs
Hi
For a project I'm working on we had to add GPIO support to the cp2103 driver in
the 2.6.20.4 kernel. We are controlling a GPIO via ictl to flash an LED. We'd
like to hit something along the lines or 1-3HZ. So nothing too fast. I use a
control URB to tell the cp2103 device to toggle its GPIO state. My function like:
static void cp2103_send_GPIO_packet(struct usb_serial_port *port, u8 mask, u8
latch){
int i,ret_val;
unsigned long flags;
u8 pkt[USB_GPIO_PKT_SIZE]={0x40,0xff,0xe1,0x37,0x0f,0x00,0x00,0x00};
spin_lock_bh(&port->lock);
if (port->write_urb_busy) {
spin_unlock_bh(&port->lock);
dbg("%s - already writing", __FUNCTION__);
return 0;
}
port->write_urb_busy = 1;
spin_unlock_bh(&port->lock);
/* place the latch and mask bytes in the correct place in the packet */
pkt[4] = latch;
pkt[5] = mask;
if(port->write_urb->setup_packet == NULL){
port->write_urb->setup_packet = kmalloc(sizeof(u8)*USB_GPIO_PKT_SIZE,
GFP_KERNEL);
memcpy(port->write_urb->setup_packet, pkt, USB_GPIO_PKT_SIZE);
/* Fill our Control Packet */
usb_fill_control_urb(port->write_urb, port->serial->dev,
usb_sndctrlpipe(port->serial->dev, 0),
port->write_urb->setup_packet,
port->write_urb->transfer_buffer,
0, cp2103_send_GPIO_callback, port);
ret_val = usb_submit_urb(port->write_urb, GFP_ATOMIC);
if(ret_val){
printk("[ERROR: usb_submit_urb:%i]\n",ret_val);
}
}else{
printk("[ERROR: port->write_urb->setup_packet is NOT NULL\n");
port->write_urb_busy=0;
}
}
In kernel userland I have a loop that runs every 500ms at the moment toggling
the state of the GPIO. I have verified that the loop is running fairly close to
500ms (within 10% no issues), and looked at debug code from kernel space and the
ioctl function is being run at the same rate. The ioctl always returns success
to the user application, but the LED flashes at a strange rate. It doesn't
appear to toggle every ioctl call. If I call the ioctl function several times
in a row suddenly it flashes every 500ms no problem.
This leads me to my question. Is there a buffer that the control URB ends up
sitting in that doesn't get flushed until a certain number of bytes are sent to
the USB end point? If this is the case, is there an accepted method of fushing
the URB to the USB endpoint?
I'm not too familiar with the USB system of Linux at this point. Trying to
familiarize myself with it while trying to meet my deadlines of getting this
software functioning the way my bosses want.
Thanks
Andrew McKay
Iders Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
test
testing - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb device handled by ohci and not by ehci
On Wed, 13 Feb 2008 [EMAIL PROTECTED] wrote: > Dear list, > > I have problems with a usb device (mp3 player) which is handled by the > kernel modules in a wrong way. It is a usb 2.0 device (which behaves > as such on e.g. Mac OS X), but with the linux kernel (2.6.22-3 debian > kernel) I encounter only about 1MB/min of data transfer. > > A look into /proc/bus/usb/devices shows that the device is handled by > the ohci module instead of the ehci module. Can anybody explain to me > how to fix (debug) this problem? I am a bit lost with the usb modules, > which do not seem to have a debug option argument. You can start by looking at the output from dmesg. If that doesn't provide enough information you can enable debugging by turning on CONFIG_USB_DEBUG -- it's a configuration setting rather than a module parameter. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
usb device handled by ohci and not by ehci
Dear list, I have problems with a usb device (mp3 player) which is handled by the kernel modules in a wrong way. It is a usb 2.0 device (which behaves as such on e.g. Mac OS X), but with the linux kernel (2.6.22-3 debian kernel) I encounter only about 1MB/min of data transfer. A look into /proc/bus/usb/devices shows that the device is handled by the ohci module instead of the ehci module. Can anybody explain to me how to fix (debug) this problem? I am a bit lost with the usb modules, which do not seem to have a debug option argument. Best, Michael - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ONDA N501HS (aka ZTE MF330) flow control
Hi, I have an ONDA N501HS (namely a rebranded ZTE MF330) UMTS pc card. I am currently using this card with the sierra driver (as in current kernels). However I am noticing the following problem: - when I use the card for downloading from the internet, everything is fine; - when I use the card for uploading to the internet, after a few tens kB, the card freezes. Freezing goes as follows: the card provides 3 ports: ttyUSB0 to ttyUSB2. The port ttyUSB0 that is used for data stops working completely. It becomes impossible to talk to it, until the pc-card is extracted and put again in the pcmcia slot. The other ports keep working. I wonder if this might have something to do with flow control (or lack thereof) that causes the card to be flooded with data from the computer until it locks. I believe that flow control might be the issue, since if I use upload programs that let me decide the data rate and I pick a low enough rate everything goes just fine. I have also seen that the ZTE MF330 has just been moved from the sierra driver to the option driver. Is there any chance that this might fix my problem? If this is the case, having my distribution kernel source, once I have applied the patch, how can I rebuild _only_ the sierra and the option modules? Thanks, Sergio - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb-storage: don't clear-halt when Get-Max-LUN stalls
This patch (as1032) removes the Clear-Halt calls in
usb_stor_Bulk_max_lun(). Evidently some devices (such as the Oracom
MP3 player) really don't like to receive these requests when their
bulk endpoints aren't halted.
The only reason for adding them originally was to get an ancient
ZIP-100 drive to work. But since this device has only a single LUN,
we don't need to send it a Get-Max-LUN request at all. Adding an
unusual_devs entry for the ZIP-100 with the SINGLE_LUN flag set will
cause this step to be skipped.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
Index: usb-2.6/drivers/usb/storage/transport.c
===
--- usb-2.6.orig/drivers/usb/storage/transport.c
+++ usb-2.6/drivers/usb/storage/transport.c
@@ -879,17 +879,6 @@ int usb_stor_Bulk_max_lun(struct us_data
if (result > 0)
return us->iobuf[0];
- /*
-* Some devices (i.e. Iomega Zip100) need this -- apparently
-* the bulk pipes get STALLed when the GetMaxLUN request is
-* processed. This is, in theory, harmless to all other devices
-* (regardless of if they stall or not).
-*/
- if (result == -EPIPE) {
- usb_stor_clear_halt(us, us->recv_bulk_pipe);
- usb_stor_clear_halt(us, us->send_bulk_pipe);
- }
-
/*
* Some devices don't like GetMaxLUN. They may STALL the control
* pipe, they may return a zero-length result, they may do nothing at
Index: usb-2.6/drivers/usb/storage/unusual_devs.h
===
--- usb-2.6.orig/drivers/usb/storage/unusual_devs.h
+++ usb-2.6/drivers/usb/storage/unusual_devs.h
@@ -751,6 +751,18 @@ UNUSUAL_DEV( 0x0595, 0x4343, 0x, 0x
"Digital Camera EX-20 DSC",
US_SC_8070, US_PR_DEVICE, NULL, 0 ),
+/* Reported by Andre Welter <[EMAIL PROTECTED]>
+ * This antique device predates the release of the Bulk-only Transport
+ * spec, and if it gets a Get-Max-LUN then it requires the host to do a
+ * Clear-Halt on the bulk endpoints. The SINGLE_LUN flag will prevent
+ * us from sending the request.
+ */
+UNUSUAL_DEV( 0x059b, 0x0001, 0x0100, 0x0100,
+ "Iomega",
+ "ZIP 100",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_SINGLE_LUN ),
+
/* Reported by <[EMAIL PROTECTED]> */
UNUSUAL_DEV( 0x059f, 0x0643, 0x, 0x,
"LaCie",
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Handshaking on USB serial devices
Consider a USB-attached serial port that is set to do RTS/CTS (or DSR/DTR) handshaking: What stops the kernel sending more data to it when the remote end lowers CTS (or DTR)? - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: OTG: Fix weirdnesses on enumerating partial otg devices
On Tue, Feb 12, 2008 at 12:32:34PM -0800, David Brownell wrote:
> > > > > > Some devices claim
> > > > > > to be b_host even though they have an a_connector attached to it.
> > > > >
> > > > > Why not just fix that bug? Remember that's Linux code.
> > > >
> > > > The device claiming to be b_host is not linux based.
> > >
> > > Wrong ... the meaning of that flag is: *THIS* system is a
> > > Linux-USB OTG device which came up in B-peripheral role, and
> > > then through the magic of HNP morphed into the B-host role.
> >
> > Don't be sarcastic I won't even fall into what Jean Delvare told you.
>
> I see no sarcasm there. People seem to want different degrees
Ok, sorry here. Misunderstood the point of "magic"
> of handholding when being told they're wrong. First time gently,
> second time less so ...
>
> I think there are limits to how long you can realistically expect
> someone (in this case, me) to let that drag on.
>
> (You object to "magic"? Most LKML readers know squat about OTG,
> and that seemed like a succinct introduction to what it does.)
>
>
> > > Linux is acting as a host at that point. So either it's
> > > being the A-host, or the B-host. That flag says which. If
> > > the other device has the A-connector, yet we're the B-host,
> > > then right now it is acting as an A-peripheral. That's
> > > exactly what HNP is designed to do.
> >
> > True, but allowing hnp nowing we're b_host doesn't sound correct.
>
> Why not? The B-host can't proceed in that case. The mechanism
> for not-proceeding is inside this:
>
> if (!is_targeted(udev)) {
> if (udev->bus->b_hnp_enable || udev->bus->is_b_host) {
> err = usb_port_suspend(udev);
> if (err < 0)
> dev_dbg(&udev->dev, "HNP fail, %d\n", err);
> }
> err = -ENOTSUPP;
> goto fail;
> }
>
> Your proposal is to strike the "is_b_host" check. In terms of the
> OTG (1.3) state machine, that removes a b_host --> b_peripheral
> state transition.
Not at all, we're just not doing transition right now.
>
> BUT: notice it doesn't replace it with the ONLY other valid state
> transition, b_host --> b_idle. In fact, that can not be initiated
> by the B-device...
>
> So the current code *is* correct.
>
>
> > If
> > we're b_host it can get two scenarios we would get to fall into this
> > state:
> >
> > 1. We asked to become host; or
>
> This is always the case... the other side can enable HNP all
> it wants, but it won't proceed unless the b-peripheral does
> its side of the dance. (In terms of spec: b_bus_req must be
> true before HNP can proceed.)
>
>
> > 2. A_device allowed us become host because it can't handle us.
>
> We actually can't know why it started HNP; it may well have
> had other reasons. All we know is that the roles switched.
Got your point.
>
> Maybe it finished its initial task, and decided to give our
> side the opportunity to accomplish some tasks it couldn't
> know about in advance.
>
>
> > In both cases, HNP is quite useless happening again, don't you think?
>
> No. You have no way of knowing what the A-device may or may not
> do when it becomes host again. It's getting a chance to do
> more work, in conformance with what OTG is supposed to do.
>
>
> > We should at least try to enumerate a_peripheral, if it can't due to
> > our power capabilities i.e. 100mA, we'll fall into overcurrent
> > protection and we'll suspend the bus and disconnect, which would give
> > a_device another change to enumerate us.
> >
> > This sound much better to me.
>
> You're overlooking something: this is the "!is_targeted(udev)"
> case, so we have already enumerated the a_peripheral as much as
> we can. There is *nothing* more we can do with it. Sitting
> around in the b_host state would be utterly pointless.
And you're overlooking something: tpl is not an enumeration blocker at
all. The only blockers are drivers and power limits.
Imagine what happens on n810, we have 3 mass storage devices listed on
its tpl: 770, n800 and itself. Besides that, we allow enumeration of any
mass storage device as long as it draws less than 100mA. These tips I
got from otg chairman himself and from OTG Clarification document, you
can find it in compliance.usb.org. So, what I'm trying to say is if
a_device let us become host, we shold at least try to do, let's call it,
full enumeration. Which means attaching any unlisted mass storage device
should work.
> > > So it can happen again, to go back into the b_peripheral state.
> > > (And of course, we can't set the b_hnp_enable flag in a device
> > > which is in the a_peripheral state...)
> >
> > it shouldn't happen again at this point. If we're b_host, we should try to
> > enumerate a_peripheral. If it draws more than 100mA the session should
> > end, otherwise we'd fall into hnp loops until we start getting hub port
> > errors a
