From: Anton Blanchard <hidden> Date: 2018-10-01 23:05:51
We currently cap the decrementer clockevent at 4 seconds, even on systems
with large decrementer support. Fix this by converting the code to use
clockevents_register_device() which calculates the upper bound based on
the max_delta passed in.
Signed-off-by: Anton Blanchard <redacted>
---
arch/powerpc/kernel/time.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
From: Anton Blanchard <hidden> Date: 2018-10-01 23:08:05
If CONFIG_PPC_WATCHDOG is enabled we always cap the decrementer to
0x7fffffff:
if (IS_ENABLED(CONFIG_PPC_WATCHDOG))
set_dec(0x7fffffff);
else
set_dec(decrementer_max);
If there are no future events, we don't reprogram the decrementer
after this and we end up with 0x7fffffff even on a large decrementer
capable system.
As suggested by Nick, add a set_state_oneshot_stopped callback
so we program the decrementer with decrementer_max if there are
no future events.
Signed-off-by: Anton Blanchard <redacted>
---
arch/powerpc/kernel/time.c | 1 +
1 file changed, 1 insertion(+)
From: Michael Ellerman <hidden> Date: 2018-10-11 08:42:53
On Mon, 2018-10-01 at 23:01:04 UTC, Anton Blanchard wrote:
We currently cap the decrementer clockevent at 4 seconds, even on systems
with large decrementer support. Fix this by converting the code to use
clockevents_register_device() which calculates the upper bound based on
the max_delta passed in.
Signed-off-by: Anton Blanchard <redacted>
This broke KVM PR :)
Because we no longer set the mult/shift in decrementer_clockevent, which
is used in kvmppc_emulate_dec().
The patch below fixes it, though it'd be nice to come up with something
cleaner eventually.
cheers
@@ -1036,6 +1036,9 @@ static void __init set_decrementer_max(void)staticvoid__initinit_decrementer_clockevent(void){register_decrementer_clockevent(smp_processor_id());++/* Set values for KVM, see kvm_emulate_dec() */+decrementer_clockevent=*dec;}voidsecondary_cpu_time_init(void)