On Wed, Sep 19, 2018 at 3:13 PM Tao Ren <tao...@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 <tao...@fb.com>
Actually this is much more intuitive too, it is the typical way to handle a down-counting timer. Good catch! Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Sorry for any cargo-cult programming on my part :/ Would be nice to get a nod from the AST2400 users that this works for them too, so included them in the To: field. I can't test it on up-counting hardware right now but I convinced myself it is handled just like before so it shouldn't be an issue. It actually would make kind of sense to restart the up-counting timer from zero and set match to whatever value is passed in as well, so I might send a patch for this. It's no regression though so no hurry with that. Yours, Linus Walleij
