Re: USB device driver question: timeout() and usbd_do_request()
On Sun, May 02, 2004 at 10:38:42AM -0400, Rita Lin wrote: Hello, I'm writing a USB driver for a device that does not have any interrupt. It only has Bulk-in and Bulk-out. A periodic polling status from default pipe is required to have a smooth data transfer. I used timeout() routine to call usbd_do_request() for polling. I thought maybe timeout() is called under interrupt context, since usbd_do_request() access system I/O, it crashes. However, by adding this timeout() in ucomstart(), it didn't crash until the third call to timeout(). Removing usbd_do_request() allows the timeout() to work without any problem. From the USB analyzer, I could see that even if the system crashed, a request was sent to the USB device correctly. There are two crashdump messages printed out to the screen, I could only catch the second one. The first one scrolled off the screen too fast. By counting the byte and the instruction pointer, the routine crashed in acquire_lock(). I 'greped' the kernel source code, didn't see this routine. I know I'm missing some important FreeBSD concept since I'm new to it, by reading related document did not reveal anything that might help me. If usbd_do_request() should never be used in timeout() as a callback routine, what other options do I have, to implement a status-polling scheme? You can't use usbd_do_request in timeout as it requires memory allocation, etc... But I don't understand the whole issue you have. Just schedule a request and wait for the device to ack. The Host controller does the polling for you as long as the request is queued and the timeout value supplied with the request did not time out. That has nothing to do with FreeBSD - it's how things work with USB in general. PS: please break lines -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB device driver question: timeout() and usbd_do_request()
But I don't understand the whole issue you have. Just schedule a request and wait for the device to ack. The Host controller does the polling for you as long as the request is queued and the timeout value supplied with the request did not time out. That has nothing to do with FreeBSD - it's how things work with USB in general. I needed a task or a timer that periodicaly polls the modem status from the USB device. I think you meant the timeout value inside the usbd_do_request(). I needed something that periodically calls usbd_do_request(). The mention of FreeBSD device polling was something I found on the Web. The FreeBSD allows network driver to do polling instead of interrupt. The implementation requires the first interrupt from the device in order to register the callback for the polling. When I first saw the device polling support in FreeBSD, I thought I could call usbd_do_request() in the callback routine. I was wrong. Mike Silbersack suggested the use of kthread. I added it today, tested it out, and it works. Thanks, Mike! By the way, for people who are writing USB drivers that uses ucom support, you do not need to modify ucom.c to support multiple ports. By doing a trick in declaring xxx_softc, I was able to create 4 ucom ports with one single physical device. Rita -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB device driver question: timeout() and usbd_do_request()
On Mon, May 03, 2004 at 04:37:22PM -0400, Rita Lin wrote: But I don't understand the whole issue you have. Just schedule a request and wait for the device to ack. The Host controller does the polling for you as long as the request is queued and the timeout value supplied with the request did not time out. That has nothing to do with FreeBSD - it's how things work with USB in general. I needed a task or a timer that periodicaly polls the modem status from the USB device. I think you meant the timeout value inside the usbd_do_request(). I needed something that periodically calls usbd_do_request(). Igh - that sounds like a very bad device design then. There would have been lots a ways to do in a clean way without additional pipes - such as transfering 0 sized packets to trigger a status inquiry or by adding status bytes in each packet. For what purpose do you need to poll the status in case for this device? The mention of FreeBSD device polling was something I found on the Web. The FreeBSD allows network driver to do polling instead of interrupt. The implementation requires the first interrupt from the device in order to register the callback for the polling. When I first saw the device polling support in FreeBSD, I thought I could call usbd_do_request() in the callback routine. I was wrong. Yes - that's for IO or memory accessable devices - basicly to avoid interrupt overhead I think. Mike Silbersack suggested the use of kthread. I added it today, tested it out, and it works. Thanks, Mike! By the way, for people who are writing USB drivers that uses ucom support, you do not need to modify ucom.c to support multiple ports. By doing a trick in declaring xxx_softc, I was able to create 4 ucom ports with one single physical device. Yes that's possible as long a you have separate pipes for each channel. But if you have separate pipes for each channel then the device could use separate USB interfaces as well so you can attach seprate instances of your driver as well without doing special handling. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB device driver question: timeout() and usbd_do_request()
Igh - that sounds like a very bad device design then. There would have been lots a ways to do in a clean way without additional pipes - such as transfering 0 sized packets to trigger a status inquiry or by adding status bytes in each packet. For what purpose do you need to poll the status in case for this device? I would not say it's a very bad device design. However, I do agree with you that there are numerous way to implement it. Most devices generate interrupts when there is a modem status change. This particular device does not support interrupts. Yes that's possible as long a you have separate pipes for each channel. But if you have separate pipes for each channel then the device could use separate USB interfaces as well so you can attach seprate instances of your driver as well without doing special handling. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] That is correct provided that xxx_softc is handled correctly, otherwise, you will end up handling wrong ucom_softc each time when driver specific routines are called. I didn't do any special handling in my driver methods. As I mentioned earlier, I only did a trick in declaring the xxx_softc. ucom_attach() attaches one instance of my driver. I made this comment because I saw some earlier posts about ucom needed modification to support multiple ports. Rita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB device driver question: timeout() and usbd_do_request()
That is what I call a bad design. You waste resources because the device designer did not take the features he had available. Okay, I guess so. There are also other minor things that I don't understand why the device is implemented the way it is. Since I don't make it, and I don't work for the company that makes it, it's beyond me. If this is a device level driver yes. But I still think that a device with multiple ports and separate pipes per port should also offer multiple USB interfaces. Are you talking about USB interfaces at software layer or physical layer? I think I'm confused here. If it's software layer, yes, the device offers multiple USB interfaces. Each interface has its own pipes. But, of course, the default pipe is shared. Rita ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB device driver question: timeout() and usbd_do_request()
On Mon, May 03, 2004 at 06:48:14PM -0400, Rita Lin wrote: That is what I call a bad design. You waste resources because the device designer did not take the features he had available. Okay, I guess so. There are also other minor things that I don't understand why the device is implemented the way it is. Since I don't make it, and I don't work for the company that makes it, it's beyond me. Obviously. I also understand that a vendor can't use an interrupt pipe for this case as USB hardware is usually limited in number and type of pipes it can handle, but USB offers much more. It's also not absolutely clear to me why you are interested in regular status information at all? If this is a device level driver yes. But I still think that a device with multiple ports and separate pipes per port should also offer multiple USB interfaces. Are you talking about USB interfaces at software layer or physical layer? I think I'm confused here. If it's software layer, yes, the device offers multiple USB interfaces. Each interface has its own pipes. But, of course, the default pipe is shared. That's what I mean - so the vendor intendend use is to attach at interface level, which means each port has it's completely own instance of driver (and also a softc on it's own) - no difference for ucom comparing to completely different devices. If you instead take the whole device at once you can't use the same driver to work with other variants of the same protocol. Maybe the vendor also has a device plus a printer interface in the future. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB device driver question: timeout() and usbd_do_request()
On Mon, May 03, 2004 at 05:36:47PM -0400, Rita Lin wrote: Igh - that sounds like a very bad device design then. There would have been lots a ways to do in a clean way without additional pipes - such as transfering 0 sized packets to trigger a status inquiry or by adding status bytes in each packet. For what purpose do you need to poll the status in case for this device? I would not say it's a very bad device design. However, I do agree with you that there are numerous way to implement it. Most devices generate interrupts when there is a modem status change. This particular device does not support interrupts. That is what I call a bad design. You waste resources because the device designer did not take the features he had available. Yes that's possible as long a you have separate pipes for each channel. But if you have separate pipes for each channel then the device could use separate USB interfaces as well so you can attach seprate instances of your driver as well without doing special handling. That is correct provided that xxx_softc is handled correctly, otherwise, you will end up handling wrong ucom_softc each time when driver specific routines are called. I didn't do any special handling in my driver methods. As I mentioned earlier, I only did a trick in declaring the xxx_softc. ucom_attach() attaches one instance of my driver. I made this comment because I saw some earlier posts about ucom needed modification to support multiple ports. If this is a device level driver yes. But I still think that a device with multiple ports and separate pipes per port should also offer multiple USB interfaces. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
