linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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.

      reply	other threads:[~2014-12-08 12:12 UTC|newest]

Thread overview: 4+ 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 10:48 ` Mark Rutland
2014-12-08 12:02   ` Preeti U Murthy
2014-12-08 12:11     ` Mark Rutland [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).