On Tue, Oct 02, 2012 at 05:56:30PM +0200, Jarkko Huijts wrote:
> 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.)
No, the break callback in the ftdi driver should be called instead (the
ftdi_break_ctl() function).
> - 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.
I don't have the datasheet, so I can't answer this for you, sorry.
> - 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?
No one has implemented it to do so. Other usb-serial drivers have
implemented this functionality, just not this one. Perhaps because no
one has noticed before, or maybe the chip really can't do it.
Without the specs for the device itself, I can't really tell for sure.
If you do get ahold of the specs, let me know, and I'll be glad to work
to add this support to the driver, as I agree, it is something that
would be useful to a lot of people.
Sorry I can't be of more help,
greg k-h
--
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
