From: Preeti U Murthy <hidden> Date: 2014-12-08 06:55:57
Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
hrtimer based broadcast mode for those platforms in which local timers stop
when CPUs enter deep idle states. The commit expected the platforms to
register for this mode explicitly when they lacked a better external device
to wake up CPUs in deep idle. Given that more platforms are beginning to use
this mode, we can avoid the call to set it up on every platform that requires
it, by registering for the hrtimer based broadcast mode in the core code if
no better broadcast device is available.
This commit also helps detect cases where the platform fails to register for
a broadcast device but invokes the help of one when entering deep idle states.
Currently we do not handle this situation at all and call the broadcast clock
device without checking for its existence. This patch will handle such buggy
cases properly.
Signed-off-by: Preeti U Murthy <redacted>
---
Changes from V1: https://lkml.org/lkml/2014/12/5/261
1.Moved registering the hrtimer based broadcast from timekeeping code
to an early_initcall.
arch/arm64/kernel/time.c | 2 --
arch/powerpc/kernel/time.c | 1 -
include/linux/clockchips.h | 6 +++---
kernel/time/tick-broadcast-hrtimer.c | 4 +++-
4 files changed, 6 insertions(+), 7 deletions(-)
From: Mark Rutland <mark.rutland@arm.com> Date: 2014-12-08 10:48:39
Hi Preeti,
On Mon, Dec 08, 2014 at 06:55:43AM +0000, Preeti U Murthy wrote:
Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
hrtimer based broadcast mode for those platforms in which local timers stop
when CPUs enter deep idle states. The commit expected the platforms to
register for this mode explicitly when they lacked a better external device
to wake up CPUs in deep idle. Given that more platforms are beginning to use
this mode, we can avoid the call to set it up on every platform that requires
it, by registering for the hrtimer based broadcast mode in the core code if
no better broadcast device is available.
This commit also helps detect cases where the platform fails to register for
a broadcast device but invokes the help of one when entering deep idle states.
Currently we do not handle this situation at all and call the broadcast clock
device without checking for its existence. This patch will handle such buggy
cases properly.
Signed-off-by: Preeti U Murthy <redacted>
I've just given this a go on an arm64 platform (Juno) without any
system-wide clock_event_devices registered, and everything works well
with CPUs entering and exiting idle states where the cpu-local timers
lose state. So:
Tested-by: Mark Rutland <mark.rutland@arm.com>
One minor thing I noticed when testing was that
/sys/devices/system/clockevents/broadcast/name contained "(null)",
because we never set the name field on the clock_event_device. It's
always been that way, but now might be a good time to change that to
something like "broadcast_hrtimer".
[...]
With the initcall moved to the driver we have no external users of
tick_setup_hrtimer_broadcast, so I think we can remove the prototype
entirely from clockchips.h...
From: Preeti U Murthy <hidden> Date: 2014-12-08 12:03:19
On 12/08/2014 04:18 PM, Mark Rutland wrote:
Hi Preeti,
On Mon, Dec 08, 2014 at 06:55:43AM +0000, Preeti U Murthy wrote:
quoted
Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
hrtimer based broadcast mode for those platforms in which local timers stop
when CPUs enter deep idle states. The commit expected the platforms to
register for this mode explicitly when they lacked a better external device
to wake up CPUs in deep idle. Given that more platforms are beginning to use
this mode, we can avoid the call to set it up on every platform that requires
it, by registering for the hrtimer based broadcast mode in the core code if
no better broadcast device is available.
This commit also helps detect cases where the platform fails to register for
a broadcast device but invokes the help of one when entering deep idle states.
Currently we do not handle this situation at all and call the broadcast clock
device without checking for its existence. This patch will handle such buggy
cases properly.
Signed-off-by: Preeti U Murthy <redacted>
I've just given this a go on an arm64 platform (Juno) without any
system-wide clock_event_devices registered, and everything works well
with CPUs entering and exiting idle states where the cpu-local timers
lose state. So:
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks!
One minor thing I noticed when testing was that
/sys/devices/system/clockevents/broadcast/name contained "(null)",
because we never set the name field on the clock_event_device. It's
always been that way, but now might be a good time to change that to
something like "broadcast_hrtimer".
You mean /sys/devices/system/clockevents/broadcast/current_device right?
With the initcall moved to the driver we have no external users of
tick_setup_hrtimer_broadcast, so I think we can remove the prototype
entirely from clockchips.h...
From: Mark Rutland <mark.rutland@arm.com> Date: 2014-12-08 12:12:26
On Mon, Dec 08, 2014 at 12:02:55PM +0000, Preeti U Murthy wrote:
On 12/08/2014 04:18 PM, Mark Rutland wrote:
quoted
Hi Preeti,
On Mon, Dec 08, 2014 at 06:55:43AM +0000, Preeti U Murthy wrote:
quoted
Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
hrtimer based broadcast mode for those platforms in which local timers stop
when CPUs enter deep idle states. The commit expected the platforms to
register for this mode explicitly when they lacked a better external device
to wake up CPUs in deep idle. Given that more platforms are beginning to use
this mode, we can avoid the call to set it up on every platform that requires
it, by registering for the hrtimer based broadcast mode in the core code if
no better broadcast device is available.
This commit also helps detect cases where the platform fails to register for
a broadcast device but invokes the help of one when entering deep idle states.
Currently we do not handle this situation at all and call the broadcast clock
device without checking for its existence. This patch will handle such buggy
cases properly.
Signed-off-by: Preeti U Murthy <redacted>
I've just given this a go on an arm64 platform (Juno) without any
system-wide clock_event_devices registered, and everything works well
with CPUs entering and exiting idle states where the cpu-local timers
lose state. So:
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks!
quoted
One minor thing I noticed when testing was that
/sys/devices/system/clockevents/broadcast/name contained "(null)",
because we never set the name field on the clock_event_device. It's
always been that way, but now might be a good time to change that to
something like "broadcast_hrtimer".
You mean /sys/devices/system/clockevents/broadcast/current_device right?
With the initcall moved to the driver we have no external users of
tick_setup_hrtimer_broadcast, so I think we can remove the prototype
entirely from clockchips.h...