On Tue, Oct 09, 2012 at 12:21:56PM +0200, Jarkko Huijts wrote: > On Thu, 2012-10-04 at 15:25 -0700, Greg KH wrote: > > > - 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, > > Hello Greg, > > You helped by confirming that it is indeed missing. I have figured out a > solution that at least works for my FT232RL chip. > > The solution: Add a chars_in_buffer() function that checks both the > software buffer and the hardware buffer. This function is called when > tcdrain() or close() is called in an application. > > The amount of data in the hardware buffer cannot be retrieved, but (as > suggested by ftdi_tiocmget()) all devices, except the original SIO, can > indicate whether the hardware buffer is empty. All newer devices return > 2 bytes when reading register GET_MODEM_STATUS, the second being the > line status, which contains bit FTDI_RS_TEMT (TX empty, already defined > in the header file). If the hardware buffer is not empty, let the > function at least return 1. > > I have attached the code for the function. > - The symbol for function usb_serial_generic_chars_in_buffer() is not > exported, so I had to copy the code. > - I'm not sure whether the kmalloc is really needed and whether no other > locking is necessary. > - As mentioned, this works for my FT232RL. The function is called many > times when doing tcdrain() or close(). At first it returns something > like 3000 (characters in the software buffer). In the end it returns 1 > for a while (software buffer empty, hardware buffer not yet empty). > > I have e-mailed FTDI's support to ask whether the assumptions described > above are true and whether there is no register to read the actual > amount of data in the hardware buffer(s). Their website states you need > to sign an NDA to get the register descriptions, but with some luck that > isn't needed.
Your function looks good, care to add it to the file and create a patch so that I can apply it properly to the kernel tree? Take a look at the file Documentation/SubmittingPatches for how to do this, and if you have any problems, or need me to do it, please let me know. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
