On Tue, Aug 31, 2010 at 9:47 AM, Hans Petter Selasky <hsela...@c2i.net> wrote: > On Tuesday 31 August 2010 09:39:46 Piet Skiet wrote: >> On Mon, Aug 30, 2010 at 9:13 PM, Hans Petter Selasky <hsela...@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 <tuks...@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 >
Hi, Attached is the patch adding a 250ms polling control transfer to update the port status flags. I've also added CRTSCTS hardware flow control. I did some tests with minicom and with gtkterm. Minicom works perfectly, but gtkterm has problems at baud 115200 and also with hardware flow control. I also testes the Prolific driver (uplcom) with minicom and gtkterm, and gtkterm has the same problems at 115200 baud, so I'm assuming it's a gtkterm bug (not maintained anymore). BTW, do the usb-to-serial drivers need the force_short_xfer usb transfer flag? gtkterm seems to work slightly better without the flag... Anyway, thanks for the help so far
Description: Binary data
_______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"