Messages in this thread | | | Subject | Re: [PATCH v1] iopoll: Tweak readx_poll_timeout sleep range | From | Marc Gonzalez <> | Date | Thu, 13 Jun 2019 18:04:41 +0200 |
| |
On 13/06/2019 14:42, Arnd Bergmann wrote:
> On Thu, Jun 13, 2019 at 2:16 PM Marc Gonzalez wrote: > >> Chopping max delay in 4 seems excessive. Let's just cut it in half. >> >> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr> >> --- >> When max_us=100, old_min was 26 us; new_min would be 50 us >> Was there a good reason for the 1/4th? >> Is new_min=0 a problem? (for max=1) > > You normally want a large enough range between min and max. I don't > see anything wrong with a factor of four.
Hmmm, I expect the typical use-case to be: "HW manual states operation X completes in 100 µs. Let's call usleep_range(100, foo); before hitting the reg."
And foo needs to be a "reasonable" value: big enough to be able to merge several requests, low enough not to wait too long after the HW is ready.
In this case, I'd say usleep_range(100, 200); makes sense.
Come to think of it, I'm not sure min=26 (or min=50) makes sense... Why wait *less* than what the user specified?
>> @@ -47,7 +47,7 @@ >> break; \ >> } \ >> if (__sleep_us) \ >> - usleep_range((__sleep_us >> 2) + 1, __sleep_us); \ >> + usleep_range(__sleep_us / 2, __sleep_us); \ >> } \ > > You are also missing the '+1' now, so this breaks with __sleep_us=1.
It was on purpose.
usleep_range(0, 1); is not well-defined? (I tried looking at the source, got lost down the rabbit hole.)
Regards.
| |