Hi all,
I've just realized what is the reason for such long delays (~250ms)
between setting ASYNC_LOW_LATENCY and starting receiving incoming
data. Setting ASYNC_LOW_LATENCY leads to setting FTDI latency timer
limit which is expressed in ms and allowed to be between 1ms and
255ms. Current default timer limit is 16ms, ASYNC_LOW_LATENCY writes
the limit to be 1ms (old default). And I feel that we cannot just
write the timer limit while timer itself is running. It looks like
there is 8-bit counter register in FT232, which is incremented by 1ms
clocks until limit is reached, then the data transfer is enforced.
Then, imagine that at the some specific time moment the counter is
lower that 16 and greater than 1 (Obviously, It happens with high
probability), say it is 8. Imagine, that PC issues
FTDI_SIO_SET_LATENCY_TIMER to set new limit to be 1ms at this moment.
Then, the criteria (counter == limit) happens only when counter will
overflow over 255 and happens to be 1 again. This explains observed
~250ms timeouts.
But I agree that increment counter is not obvious option for hardware.
If I had developed FT232, I would have made decrement counter,
counting downwards from the limit to zero. In this case I would have
really seen ~16 ms timeouts, but when measured, they appeared to be
larger than I expected in the first mail.
Nevertheless, 250ms is huge delay, it is enough to even run setserial
/dev/ttyUSB0 low_latency, then start new application process which
happens to fail with timeout due to missed input. It must be handled
inside the driver.
2017-08-28 12:32 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@xxxxxxxxx>:
> 2017-08-28 11:22 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@xxxxxxxxx>:
>> 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.
>
> Well, from what I see from experiments with usbmon, the transition
> time is ~250ms.
> FTDI starts sending first BULK IN 250ms after TIOCSSERIAL (and then
> repeat every 1ms). I am sure that there is incoming data in FTDI's
> internal buffer all this time. Such delay is long enough.
>
>> 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.
>>
>> So, my suggestion is that TIOCSSERIAL must block until latency
>> settings are actually applied which can be checked internally in the
>> driver.
>>
>> --
>> With best regards,
>> Matwey V. Kornilov
>
>
>
> --
> With best regards,
> Matwey V. Kornilov
--
With best regards,
Matwey V. Kornilov
--
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
