Date: Tue, 31 Aug 2010 09:47:07 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Piet Skiet <tuksgig@gmail.com> Cc: freebsd-usb@freebsd.org Subject: Re: USB synchronous control transfers (for usb-to-serial) Message-ID: <201008310947.07460.hselasky@c2i.net> In-Reply-To: <AANLkTinuHO1-23K6BW%2Bta3xZ4a6ObKzPyRd6=xAmE0S2@mail.gmail.com> References: <AANLkTinr3KbWOqgQoKVvF84H2c02fHh9SQRDeUkSRn4B@mail.gmail.com> <201008302113.33960.hselasky@c2i.net> <AANLkTinuHO1-23K6BW%2Bta3xZ4a6ObKzPyRd6=xAmE0S2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 31 August 2010 09:39:46 Piet Skiet wrote: > On Mon, Aug 30, 2010 at 9:13 PM, Hans Petter Selasky <hselasky@c2i.net> wrote: > > On Monday 30 August 2010 14:41:56 Piet Skiet wrote: > >> On Mon, Aug 30, 2010 at 10:51 AM, Piet Skiet <tuksgig@gmail.com> wrote: > >> > Hi, > >> > > >> > Can anyone clarify how to go about doing a synchronous usb control > >> > transfer, similar to Linux's usb_control_msg? I want to implement the > >> > TIOCMGET ioctl on a usb-to-serial converter. The Linux driver uses > >> > synchronous control messages to read DCE and CTS serial pin status, > >> > and I want to do something similar in FreeBSD. The usbdi(9) manpage > >> > talks about control transfers using usbd_transfer_submit, but they're > >> > not synchronous. What about using usbd_transfer_drain? Is there an > >> > example driver showing setting up and doing control transfers? > >> > > >> > The ucom driver seems to only implement TIOCSBRK and TIOCCBRK iotcls > >> > at the moment. > >> > > >> > Thanks > >> > >> Scanning through the ucom code, it seems to me that the > >> usbd_do_request_proc has somehting to do with blocking control > >> transfers. Am I on the right track here? > > > > Yes, this is correct. You have to re-format the do request information a > > little bit compared with Linux. This function is supposed to be called > > from a UCOM callback. Please also check recent changes in USB P4: > > > > http://p4web.freebsd.org/@md=d&cd=//depot/projects/usb/src/sys/dev/usb/co > > ntroller/&cdf=//depot/projects/usb/src/sys/dev/usb/serial/usb_serial.c&c= > > LJN@//depot/projects/usb/src/sys/dev/usb/serial/usb_serial.c?ac=22 > > > > --HPS > > OK, but I'm still a bit confused. I'm not sure in which callback to > put the usb_do_request. For instance, the driver that I'm interested > in is the uslcom.c driver for the cp210x usb-to-serial converter. It > has two usb_config structs defined of type UE_BULK for read and write > transfers. Do I need to add a third usb_config struct for UE_CONTROL? > Should the usb_do_request then be called from the UE_CONTROL callback? Hi, The usb_config's are for asynchronous operation. The usbd_do_request_proc() function is synchronous. I.E. it completes when it returns. The reason we have this variant is to allow smooth exit and entry of the mutex which is locked when you get callbacks from UCOM. All UCOM callbacks are pre-locked, and if you don't exit the lock the kernel will complain. > The plan is to add a .ucom_ioctl to the uslcom.c driver and implement > the TIOCMGET directly in the driver ioctl using synchronous usb > transfers. I've already tested the .ucom_ioctl override and it works, > now I just need to figure out how to do the usb transfers. > > BTW, the FTDI driver (uftdi.c) does things differently. It updates the > msr (modem status register?) in the bulk read callback and then calls > ucom_status_change to update any changes to ucom. The FTDI driver uses another mechanism to transfer that information. Probably what you want to do is to add a timer/watchdog to poll that information regularly. Then you can use a single asynchronous control transfer, and set the interval of the transfer to 250ms, for example, so that you don't need to allocate a separate timer to do this. Or maybe 100ms is better. You need to test this. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008310947.07460.hselasky>