From: Mark Rutland <mark.rutland@arm.com>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"fweisbec@gmail.com" <fweisbec@gmail.com>,
"rafael.j.wysocki@intel.com" <rafael.j.wysocki@intel.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jingchang.lu@freescale.com" <jingchang.lu@freescale.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"shawn.guo@linaro.org" <shawn.guo@linaro.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V2] tick-broadcast: Register for hrtimer based broadcast as the fallback broadcast mode
Date: Mon, 8 Dec 2014 12:11:10 +0000 [thread overview]
Message-ID: <20141208121110.GC21680@leverpostej> (raw)
In-Reply-To: <5485936F.20901@linux.vnet.ibm.com>
On Mon, Dec 08, 2014 at 12:02:55PM +0000, Preeti U Murthy wrote:
> 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:
> >> 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 <preeti@linux.vnet.ibm.com>
> >
> > 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?
Whoops, yes I did.
> > [...]
> >
> >> diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
> >> index 2e4cb67..91754b0 100644
> >> --- a/include/linux/clockchips.h
> >> +++ b/include/linux/clockchips.h
> >> @@ -187,11 +187,11 @@ extern int tick_receive_broadcast(void);
> >> #endif
> >>
> >> #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) && defined(CONFIG_TICK_ONESHOT)
> >> -extern void tick_setup_hrtimer_broadcast(void);
> >> +extern int __init tick_setup_hrtimer_broadcast(void);
> >> extern int tick_check_broadcast_expired(void);
> >> #else
> >> static inline int tick_check_broadcast_expired(void) { return 0; }
> >> -static inline void tick_setup_hrtimer_broadcast(void) {};
> >> +static inline int __init tick_setup_hrtimer_broadcast(void) { return 0; }
> >> #endif
> >>
> >> #ifdef CONFIG_GENERIC_CLOCKEVENTS
> >> @@ -207,7 +207,7 @@ static inline void clockevents_resume(void) {}
> >>
> >> static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
> >> static inline int tick_check_broadcast_expired(void) { return 0; }
> >> -static inline void tick_setup_hrtimer_broadcast(void) {};
> >> +static inline int __init tick_setup_hrtimer_broadcast(void) { return 0; }
> >
> > 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...
> >
> >> #endif
> >>
> >> diff --git a/kernel/time/tick-broadcast-hrtimer.c b/kernel/time/tick-broadcast-hrtimer.c
> >> index eb682d5..5c35995 100644
> >> --- a/kernel/time/tick-broadcast-hrtimer.c
> >> +++ b/kernel/time/tick-broadcast-hrtimer.c
> >> @@ -98,9 +98,11 @@ static enum hrtimer_restart bc_handler(struct hrtimer *t)
> >> return HRTIMER_RESTART;
> >> }
> >>
> >> -void tick_setup_hrtimer_broadcast(void)
> >> +int __init tick_setup_hrtimer_broadcast(void)
> >
> > ...and make it static here.
>
> Yep will do. Sorry I overlooked this.
>
> >
> >> {
> >> hrtimer_init(&bctimer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
> >> bctimer.function = bc_handler;
> >> clockevents_register_device(&ce_broadcast_hrtimer);
> >> + return 0;
> >> }
> >> +early_initcall(tick_setup_hrtimer_broadcast);
> >
> > Otherwise this looks good to me, thanks for putting this together!
>
> Thanks a lot for the review! Will send out the patch with the above
> corrections.
Cheers!
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2] tick-broadcast: Register for hrtimer based broadcast as the fallback broadcast mode
Date: Mon, 8 Dec 2014 12:11:10 +0000 [thread overview]
Message-ID: <20141208121110.GC21680@leverpostej> (raw)
In-Reply-To: <5485936F.20901@linux.vnet.ibm.com>
On Mon, Dec 08, 2014 at 12:02:55PM +0000, Preeti U Murthy wrote:
> 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:
> >> 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 <preeti@linux.vnet.ibm.com>
> >
> > 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?
Whoops, yes I did.
> > [...]
> >
> >> diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
> >> index 2e4cb67..91754b0 100644
> >> --- a/include/linux/clockchips.h
> >> +++ b/include/linux/clockchips.h
> >> @@ -187,11 +187,11 @@ extern int tick_receive_broadcast(void);
> >> #endif
> >>
> >> #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) && defined(CONFIG_TICK_ONESHOT)
> >> -extern void tick_setup_hrtimer_broadcast(void);
> >> +extern int __init tick_setup_hrtimer_broadcast(void);
> >> extern int tick_check_broadcast_expired(void);
> >> #else
> >> static inline int tick_check_broadcast_expired(void) { return 0; }
> >> -static inline void tick_setup_hrtimer_broadcast(void) {};
> >> +static inline int __init tick_setup_hrtimer_broadcast(void) { return 0; }
> >> #endif
> >>
> >> #ifdef CONFIG_GENERIC_CLOCKEVENTS
> >> @@ -207,7 +207,7 @@ static inline void clockevents_resume(void) {}
> >>
> >> static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
> >> static inline int tick_check_broadcast_expired(void) { return 0; }
> >> -static inline void tick_setup_hrtimer_broadcast(void) {};
> >> +static inline int __init tick_setup_hrtimer_broadcast(void) { return 0; }
> >
> > 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...
> >
> >> #endif
> >>
> >> diff --git a/kernel/time/tick-broadcast-hrtimer.c b/kernel/time/tick-broadcast-hrtimer.c
> >> index eb682d5..5c35995 100644
> >> --- a/kernel/time/tick-broadcast-hrtimer.c
> >> +++ b/kernel/time/tick-broadcast-hrtimer.c
> >> @@ -98,9 +98,11 @@ static enum hrtimer_restart bc_handler(struct hrtimer *t)
> >> return HRTIMER_RESTART;
> >> }
> >>
> >> -void tick_setup_hrtimer_broadcast(void)
> >> +int __init tick_setup_hrtimer_broadcast(void)
> >
> > ...and make it static here.
>
> Yep will do. Sorry I overlooked this.
>
> >
> >> {
> >> hrtimer_init(&bctimer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
> >> bctimer.function = bc_handler;
> >> clockevents_register_device(&ce_broadcast_hrtimer);
> >> + return 0;
> >> }
> >> +early_initcall(tick_setup_hrtimer_broadcast);
> >
> > Otherwise this looks good to me, thanks for putting this together!
>
> Thanks a lot for the review! Will send out the patch with the above
> corrections.
Cheers!
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"rafael.j.wysocki@intel.com" <rafael.j.wysocki@intel.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jingchang.lu@freescale.com" <jingchang.lu@freescale.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"fweisbec@gmail.com" <fweisbec@gmail.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"shawn.guo@linaro.org" <shawn.guo@linaro.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH V2] tick-broadcast: Register for hrtimer based broadcast as the fallback broadcast mode
Date: Mon, 8 Dec 2014 12:11:10 +0000 [thread overview]
Message-ID: <20141208121110.GC21680@leverpostej> (raw)
In-Reply-To: <5485936F.20901@linux.vnet.ibm.com>
On Mon, Dec 08, 2014 at 12:02:55PM +0000, Preeti U Murthy wrote:
> 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:
> >> 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 <preeti@linux.vnet.ibm.com>
> >
> > 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?
Whoops, yes I did.
> > [...]
> >
> >> diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
> >> index 2e4cb67..91754b0 100644
> >> --- a/include/linux/clockchips.h
> >> +++ b/include/linux/clockchips.h
> >> @@ -187,11 +187,11 @@ extern int tick_receive_broadcast(void);
> >> #endif
> >>
> >> #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) && defined(CONFIG_TICK_ONESHOT)
> >> -extern void tick_setup_hrtimer_broadcast(void);
> >> +extern int __init tick_setup_hrtimer_broadcast(void);
> >> extern int tick_check_broadcast_expired(void);
> >> #else
> >> static inline int tick_check_broadcast_expired(void) { return 0; }
> >> -static inline void tick_setup_hrtimer_broadcast(void) {};
> >> +static inline int __init tick_setup_hrtimer_broadcast(void) { return 0; }
> >> #endif
> >>
> >> #ifdef CONFIG_GENERIC_CLOCKEVENTS
> >> @@ -207,7 +207,7 @@ static inline void clockevents_resume(void) {}
> >>
> >> static inline int clockevents_notify(unsigned long reason, void *arg) { return 0; }
> >> static inline int tick_check_broadcast_expired(void) { return 0; }
> >> -static inline void tick_setup_hrtimer_broadcast(void) {};
> >> +static inline int __init tick_setup_hrtimer_broadcast(void) { return 0; }
> >
> > 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...
> >
> >> #endif
> >>
> >> diff --git a/kernel/time/tick-broadcast-hrtimer.c b/kernel/time/tick-broadcast-hrtimer.c
> >> index eb682d5..5c35995 100644
> >> --- a/kernel/time/tick-broadcast-hrtimer.c
> >> +++ b/kernel/time/tick-broadcast-hrtimer.c
> >> @@ -98,9 +98,11 @@ static enum hrtimer_restart bc_handler(struct hrtimer *t)
> >> return HRTIMER_RESTART;
> >> }
> >>
> >> -void tick_setup_hrtimer_broadcast(void)
> >> +int __init tick_setup_hrtimer_broadcast(void)
> >
> > ...and make it static here.
>
> Yep will do. Sorry I overlooked this.
>
> >
> >> {
> >> hrtimer_init(&bctimer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
> >> bctimer.function = bc_handler;
> >> clockevents_register_device(&ce_broadcast_hrtimer);
> >> + return 0;
> >> }
> >> +early_initcall(tick_setup_hrtimer_broadcast);
> >
> > Otherwise this looks good to me, thanks for putting this together!
>
> Thanks a lot for the review! Will send out the patch with the above
> corrections.
Cheers!
Thanks,
Mark.
next prev parent reply other threads:[~2014-12-08 12:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-08 6:55 [PATCH V2] tick-broadcast: Register for hrtimer based broadcast as the fallback broadcast mode Preeti U Murthy
2014-12-08 6:55 ` Preeti U Murthy
2014-12-08 6:55 ` Preeti U Murthy
2014-12-08 10:48 ` Mark Rutland
2014-12-08 10:48 ` Mark Rutland
2014-12-08 10:48 ` Mark Rutland
2014-12-08 12:02 ` Preeti U Murthy
2014-12-08 12:02 ` Preeti U Murthy
2014-12-08 12:02 ` Preeti U Murthy
2014-12-08 12:11 ` Mark Rutland [this message]
2014-12-08 12:11 ` Mark Rutland
2014-12-08 12:11 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141208121110.GC21680@leverpostej \
--to=mark.rutland@arm.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=Will.Deacon@arm.com \
--cc=fweisbec@gmail.com \
--cc=jingchang.lu@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=peterz@infradead.org \
--cc=preeti@linux.vnet.ibm.com \
--cc=rafael.j.wysocki@intel.com \
--cc=shawn.guo@linaro.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.