Hello knowledgeable people,
I have a question regarding tcdrain() and kernel driver
drivers/usb/serial/ftdi_sio.c (for a family of USB-to-UART converter
chips from FTDI). I'm using an FT232RL and kernel 2.6.38-16. (The driver
code does not seem to have changed much between that version and 3.6.)
My goal is to make sure all TX data has been sent over the wire in
application code. This is what function tcdrain() is for according to
the manual page and serial programming guides. It doesn't seem to do
anything for the FT232RL chip, however.
I found the following when digging around:
- tcdrain() is implemented in libc and translated into ioctl TCSBRK with
value 1. In Linux, this is apparently defined as "wait until drained"
without sending an actual break over the UART.
- I would expect this ioctl to arrive in function ftdi_ioctl() of the
driver, but it doesn't. (I included a printk showing every ioctl it
receives.)
- It seems like the hardware can return whether its TX buffer is empty.
This is stored in field transmit_empty of struct ftdi_private and can be
retrieved by application code by doing ioctl TIOCSERGETLSR. I found an
old thread in this mailing list ("support for TIOCSERGETLSR in
ftdi_sio", posted December 10, 2010), which seems to be the origin of
this addition. Several other drivers under drivers/usb/serial seem to
implement the same ioctl: io_edgeport.c, mos7720.c and mos7840.c.
My questions are:
- Can anyone confirm that the state of the chip's TX buffer (at least
whether it is empty) can be retrieved from the chip? There is no
publicly available datasheet about this kind of hardware details.
- Is tcdrain() supposed to ensure that all TX data has been sent for any
serial device? If so, why is it not implemented for this device?
- Or has ioctl TIOCSERGETLSR perhaps become the standard to do this for
USB UART devices?
Thank you in advance for your help.
Kind regards,
Jarkko Huijts
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
