[PATCH linux dev-4.18] clocksource/drivers/fttmr010: Fix set_next_event handler

[Joel Stanley]

On Mon, 15 Oct 2018 at 14:27, Tao Ren <taoren at fb.com> wrote:
>
> On 10/14/18, 8:47 PM, "Tao Ren" <taoren at fb.com> wrote:
>
> > Currently, the aspeed MATCH1 register is updated to <current_count -
> > cycles> in set_next_event handler, with the assumption that COUNT
> > register value is preserved when the timer is disabled and it continues
> > decrementing after the timer is enabled. But the assumption is wrong:
> > RELOAD register is loaded into COUNT register when the aspeed timer is
> > enabled, which means the next event may be delayed because timer
> > interrupt won't be generated until <0xFFFFFFFF - current_count +
> > cycles>.
> >
> > The problem can be fixed by updating RELOAD register to <cycles>, and
> > COUNT register will be re-loaded when the timer is enabled and interrupt
> > is generated when COUNT register overflows.
> >
> > The test result on Facebook Backpack-CMM BMC hardware (AST2500) shows
> > the issue is fixed: without the patch, usleep(100) suspends the process
> > for several milliseconds (and sometimes even over 40 milliseconds);
> > after applying the fix, usleep(100) takes averagely 240 microseconds to
> > return under the same workload level.
> >
> > Signed-off-by: Tao Ren <taoren at fb.com>
> > Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> > Tested-by: Lei YU <mine260309 at gmail.com>
> > Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>
> Hi Joel / Andrew,
>
> The patch is included in v4.19-rc6 (commit 4451d3f59f2a), so you could either apply the patch to dev-4.18 now, or it can also be included when kernel is upgraded to 4.19.

This patch was included in stable, so when openbmc moved to 4.18.16 we
got it for "free".

Thanks for submitting the fix upstream. This saves a everyone from
duplicated effort.

Cheers,

Joel