Messages in this thread | | | From | Linus Walleij <> | Date | Tue, 1 Mar 2022 13:21:57 +0100 | Subject | Re: Question on expiring HRtimer in-kernel |
| |
Sorry for top posting, the helpful autocomplete in gmail think Rohm Europe is better to address than linux-pm@vger...
On Tue, Mar 1, 2022 at 1:19 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > I have a problem with a premature expiring HRtimer. > > The HRtimer hrtimer_set_expires_range() is used in two places in > the upstream kernel: > kernel/futex/core.c > drivers/power/supply/ab8500_chargalg.c > > Now I am testing the code in the latter, and it has seen some > bitrot since merged in 2012. Maybe it was correct at one point. > The timer is started like this: > > hrtimer_init(&di->safety_timer, CLOCK_REALTIME, HRTIMER_MODE_ABS); > (...) > hrtimer_set_expires_range(&di->safety_timer, > ktime_set(timer_expiration * ONE_HOUR_IN_SECONDS, 0), > ktime_set(FIVE_MINUTES_IN_SECONDS, 0)); > hrtimer_start_expires(&di->safety_timer, HRTIMER_MODE_REL); > > What the author wanted to achieve is a very definitive callback in one > hour relative to now +/- 5 min, and that is one hour later in the > physical world, > as this deals with battery charging. > > However sometimes this fires almost immediately rather than in an hour. > > My first thought is to pass HRTIMER_MODE_REL also to init as > hrtimer_set_expires_range() could make things happen immediately > if we have ABS set, but this is all just intuitive. > > Any hints? Better ways to create a definitive event in one hour? > > Yours, > Linus Walleij
| |