USB synchronous control transfers (for usb-to-serial)

[Piet Skiet]

On Tue, Aug 31, 2010 at 9:47 AM, Hans Petter Selasky <hselasky at 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 <hselasky at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uslcom.patch
Type: application/octet-stream
Size: 3594 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20100903/ac018b14/uslcom.obj