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
