On Fri, Aug 14, 2020 at 12:42 PM Crt Mori <cmo@xxxxxxxxxxx> wrote: > On Fri, 14 Aug 2020 at 11:32, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > On Fri, Aug 14, 2020 at 10:33 AM Crt Mori <cmo@xxxxxxxxxxx> wrote: > > > On Thu, 13 Aug 2020 at 21:41, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > > > On Thu, Aug 13, 2020 at 4:04 PM Crt Mori <cmo@xxxxxxxxxxx> wrote: > > > > > On Thu, 13 Aug 2020 at 13:24, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: ... > > > > > usleep_range(10000, 11000); Above for 4 attempts is up to 44000us. With iopoll.h case we may set delay_us = 18000 (the result range will be 4500, 18000) timeout_us = 72000 (this will give up to 16 attempts to read) > I tested on Beaglebone with the 100 * 10000 as timeout_us and I always > got the -ETIMEDOUT error. I also tested in the other case where > delay_us is 250000 and then timeout_us would be 4*250000 and I have > also received -ETIMEDOUT as a response. I don't see how delay_us should be bigger than 20ms (20000). > I can prepare a patch with the iopoll.h API and maybe you will spot > the mistake, as after rechecking timeout_us is indeed 64bit and is > only used in the time comparison operations and not with timers. Perhaps above will clarify. -- With Best Regards, Andy Shevchenko
