On Mon, Aug 28, 2017 at 11:22:48AM +0300, Matwey V. Kornilov wrote:
> Hi all,
> 
> I have an issue with the following patch:
> c6dce2626606 ("USB: serial: ftdi_sio: fix extreme low-latency setting")
> 
> I really need sub 16-ms latency for my peripheral and while I have no
> problems with idea of setting ASYNC_LOW_LATENCY I would like point out
> that it doesn't work as expected and probably need to be fixed.
> 
> My user space code snipped is simple enough
> 
>     if (ioctl(fd, TIOCGSERIAL, &old_serial) == 0) {
>         struct serial_struct new_serial = old_serial;
>         new_serial.flags |= ASYNC_LOW_LATENCY;
> 
>         if (ioctl(fd, TIOCSSERIAL, &new_serial) < 0) {
>             return -1;
>         }
>     }
> 
> My hardware is
> 
> 0403:6001 Future Technology Devices International, Ltd FT232
> USB-Serial (UART) IC
> 
> However, currently I see that
> 
> 1) Application of ASYNC LOW_LATENCY is not taken immediately. That is
> what I see from incoming data which arrives with considerable delays
> after I TIOCSSERIAL. I suppose that latency timer is applied after the
> end of currently running period. I.e I need to wait ~16ms and only
> after then 1ms latency started. 16ms is quite considerable time for
> nowadays user-space application.

But this is USB, you have to wait for a time for stuff like this to get
out to the device.  You just do it once at open() time and you should be
fine, right?

And low-latency with a USB device?  You know you have no guarantee at
all from the hardware that this will happen, you are playing with fire
here...

> 2) There is no generic reliable user-space way to wait until latency
> settings are actually applied. I haven't find the way to determine
> from user-space that it is ftdi_sio-driven tty-device and I need to
> apply msleep-based quirks.

Why not always just do this at open() time and you should be fine?

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

Reply via email to