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
