summaryrefslogtreecommitdiffstats
path: root/drivers/phy
diff options
context:
space:
mode:
authorTao Ren <taoren@fb.com>2018-09-19 15:13:31 -0700
committerDaniel Lezcano <daniel.lezcano@linaro.org>2018-09-24 06:13:31 +0200
commit4451d3f59f2a6f95e5d205c2d04ea072955d080d (patch)
tree7ff03084e4fd99f675497adfbc66fb67ba335ac7 /drivers/phy
parent3b7d96a0dbb6b630878597a1838fc39f808b761b (diff)
downloadlinux-4451d3f59f2a6f95e5d205c2d04ea072955d080d.tar.bz2
clocksource/drivers/fttmr010: Fix set_next_event handler
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@fb.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Lei YU <mine260309@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Diffstat (limited to 'drivers/phy')
0 files changed, 0 insertions, 0 deletions