diff mbox

arm: kernel: utilize hrtimer based broadcast

Message ID 1437124312-44700-1-git-send-email-b18965@freescale.com (mailing list archive)
State New, archived
Headers show

Commit Message

Alison Wang July 17, 2015, 9:11 a.m. UTC
Hrtimer based broadcast is used on ARM platform. It can be
registered as the tick broadcast device in the absence of
a real external clock device.

Signed-off-by: Alison Wang <alison.wang@freescale.com>
---
 arch/arm/kernel/time.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Alison Wang Oct. 27, 2015, 2:58 a.m. UTC | #1
Hi, Mark,

	Could you comment this patch? It is based on your suggestion in https://patchwork.kernel.org/patch/6764231/ .

	Thanks.

Best Regards,
Alison Wang

> -----Original Message-----
> From: Alison Wang [mailto:b18965@freescale.com]
> Sent: Friday, July 17, 2015 5:12 PM
> To: mark.rutland@arm.com; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org
> Cc: Wang Huan-B18965
> Subject: [PATCH] arm: kernel: utilize hrtimer based broadcast
> 
> Hrtimer based broadcast is used on ARM platform. It can be registered as
> the tick broadcast device in the absence of a real external clock device.
> 
> Signed-off-by: Alison Wang <alison.wang@freescale.com>
> ---
>  arch/arm/kernel/time.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index
> a66e37e..a9bc73c 100644
> --- a/arch/arm/kernel/time.c
> +++ b/arch/arm/kernel/time.c
> @@ -12,6 +12,7 @@
>   *  reading the RTC at bootup, etc...
>   */
>  #include <linux/clk-provider.h>
> +#include <linux/clockchips.h>
>  #include <linux/clocksource.h>
>  #include <linux/errno.h>
>  #include <linux/export.h>
> @@ -121,5 +122,7 @@ void __init time_init(void)
>  		of_clk_init(NULL);
>  #endif
>  		clocksource_of_init();
> +
> +		tick_setup_hrtimer_broadcast();
>  	}
>  }
> --
> 2.1.0.27.g96db324
Mark Rutland Oct. 27, 2015, 8:18 a.m. UTC | #2
On Fri, Jul 17, 2015 at 10:11:52AM +0100, Alison Wang wrote:
> Hrtimer based broadcast is used on ARM platform. It can be
> registered as the tick broadcast device in the absence of
> a real external clock device.
> 
> Signed-off-by: Alison Wang <alison.wang@freescale.com>

This looks sensible to me. FWIW:

Acked-by: Mark Rutland <mark.rutland@arm.com>

Thanks,
Mark.

> ---
>  arch/arm/kernel/time.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
> index a66e37e..a9bc73c 100644
> --- a/arch/arm/kernel/time.c
> +++ b/arch/arm/kernel/time.c
> @@ -12,6 +12,7 @@
>   *  reading the RTC at bootup, etc...
>   */
>  #include <linux/clk-provider.h>
> +#include <linux/clockchips.h>
>  #include <linux/clocksource.h>
>  #include <linux/errno.h>
>  #include <linux/export.h>
> @@ -121,5 +122,7 @@ void __init time_init(void)
>  		of_clk_init(NULL);
>  #endif
>  		clocksource_of_init();
> +
> +		tick_setup_hrtimer_broadcast();
>  	}
>  }
> -- 
> 2.1.0.27.g96db324
>
Alison Wang Nov. 6, 2015, 6:35 a.m. UTC | #3
Hi,

	Could you help to review this patch?

	Thanks.


Best Regards,
Alison Wang

> On Fri, Jul 17, 2015 at 10:11:52AM +0100, Alison Wang wrote:
> > Hrtimer based broadcast is used on ARM platform. It can be registered
> > as the tick broadcast device in the absence of a real external clock;
> > device.
> >
> > Signed-off-by: Alison Wang <alison.wang@freescale.com>
> 
> This looks sensible to me. FWIW:
> 
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> 
> Thanks,
> Mark.
> 
> > ---
> >  arch/arm/kernel/time.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index
> > a66e37e..a9bc73c 100644
> > --- a/arch/arm/kernel/time.c
> > +++ b/arch/arm/kernel/time.c
> > @@ -12,6 +12,7 @@
> >   *  reading the RTC at bootup, etc...
> >   */
> >  #include <linux/clk-provider.h>
> > +#include <linux/clockchips.h>
> >  #include <linux/clocksource.h>
> >  #include <linux/errno.h>
> >  #include <linux/export.h>
> > @@ -121,5 +122,7 @@ void __init time_init(void)
> >  		of_clk_init(NULL);
> >  #endif
> >  		clocksource_of_init();
> > +
> > +		tick_setup_hrtimer_broadcast();
> >  	}
> >  }
> > --
> > 2.1.0.27.g96db324
> >
Alison Wang Dec. 28, 2015, 7:18 a.m. UTC | #4
Hi, Arnd,

	Could you help to review the following patch? Thanks.


Best Regards,
Alison Wang

> On Fri, Jul 17, 2015 at 10:11:52AM +0100, Alison Wang wrote:
> > Hrtimer based broadcast is used on ARM platform. It can be registered
> > as the tick broadcast device in the absence of a real external clock
> > device.
> >
> > Signed-off-by: Alison Wang <alison.wang@freescale.com>
> 
> This looks sensible to me. FWIW:
> 
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> 
> Thanks,
> Mark.
> 
> > ---
> >  arch/arm/kernel/time.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index
> > a66e37e..a9bc73c 100644
> > --- a/arch/arm/kernel/time.c
> > +++ b/arch/arm/kernel/time.c
> > @@ -12,6 +12,7 @@
> >   *  reading the RTC at bootup, etc...
> >   */
> >  #include <linux/clk-provider.h>
> > +#include <linux/clockchips.h>
> >  #include <linux/clocksource.h>
> >  #include <linux/errno.h>
> >  #include <linux/export.h>
> > @@ -121,5 +122,7 @@ void __init time_init(void)
> >  		of_clk_init(NULL);
> >  #endif
> >  		clocksource_of_init();
> > +
> > +		tick_setup_hrtimer_broadcast();
> >  	}
> >  }
> > --
> > 2.1.0.27.g96db324
> >
Arnd Bergmann Dec. 28, 2015, 11:54 a.m. UTC | #5
On Monday 28 December 2015 07:18:58 Huan Wang wrote:
> Hi, Arnd,
> 
> 	Could you help to review the following patch? Thanks.
> 

Hi Alison,

I'm sorry but I understand very little of this particular area of the kernel.

I've added Daniel Lezcano, John Stultz and Thomas Gleixner to Cc, they all
know this much better than I do and one of them should be able to comment after
their Christmas break.

	Arnd

> > On Fri, Jul 17, 2015 at 10:11:52AM +0100, Alison Wang wrote:
> > > Hrtimer based broadcast is used on ARM platform. It can be registered
> > > as the tick broadcast device in the absence of a real external clock
> > > device.
> > >
> > > Signed-off-by: Alison Wang <alison.wang@freescale.com>
> > 
> > This looks sensible to me. FWIW:
> > 
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > 
> > Thanks,
> > Mark.
> > 
> > > ---
> > >  arch/arm/kernel/time.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index
> > > a66e37e..a9bc73c 100644
> > > --- a/arch/arm/kernel/time.c
> > > +++ b/arch/arm/kernel/time.c
> > > @@ -12,6 +12,7 @@
> > >   *  reading the RTC at bootup, etc...
> > >   */
> > >  #include <linux/clk-provider.h>
> > > +#include <linux/clockchips.h>
> > >  #include <linux/clocksource.h>
> > >  #include <linux/errno.h>
> > >  #include <linux/export.h>
> > > @@ -121,5 +122,7 @@ void __init time_init(void)
> > >  		of_clk_init(NULL);
> > >  #endif
> > >  		clocksource_of_init();
> > > +
> > > +		tick_setup_hrtimer_broadcast();
> > >  	}
> > >  }
Thomas Gleixner Dec. 29, 2015, 1:54 p.m. UTC | #6
On Mon, 28 Dec 2015, Arnd Bergmann wrote:

> On Monday 28 December 2015 07:18:58 Huan Wang wrote:
> > Hi, Arnd,
> > 
> > 	Could you help to review the following patch? Thanks.
> > 
> 
> Hi Alison,
> 
> I'm sorry but I understand very little of this particular area of the kernel.
> 
> I've added Daniel Lezcano, John Stultz and Thomas Gleixner to Cc, they all
> know this much better than I do and one of them should be able to comment after
> their Christmas break.

I have no real opinion about that patch. It does no harm to unconditionally
setup the hrtimer based broadcast even if it's never used.

Up to the arch maintainer to decide. 

Thanks,

	tglx
 
> > > On Fri, Jul 17, 2015 at 10:11:52AM +0100, Alison Wang wrote:
> > > > Hrtimer based broadcast is used on ARM platform. It can be registered
> > > > as the tick broadcast device in the absence of a real external clock
> > > > device.
> > > >
> > > > Signed-off-by: Alison Wang <alison.wang@freescale.com>
> > > 
> > > This looks sensible to me. FWIW:
> > > 
> > > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > > 
> > > Thanks,
> > > Mark.
> > > 
> > > > ---
> > > >  arch/arm/kernel/time.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c index
> > > > a66e37e..a9bc73c 100644
> > > > --- a/arch/arm/kernel/time.c
> > > > +++ b/arch/arm/kernel/time.c
> > > > @@ -12,6 +12,7 @@
> > > >   *  reading the RTC at bootup, etc...
> > > >   */
> > > >  #include <linux/clk-provider.h>
> > > > +#include <linux/clockchips.h>
> > > >  #include <linux/clocksource.h>
> > > >  #include <linux/errno.h>
> > > >  #include <linux/export.h>
> > > > @@ -121,5 +122,7 @@ void __init time_init(void)
> > > >  		of_clk_init(NULL);
> > > >  #endif
> > > >  		clocksource_of_init();
> > > > +
> > > > +		tick_setup_hrtimer_broadcast();
> > > >  	}
> > > >  }
> 
> 
>
Russell King - ARM Linux Jan. 2, 2016, 10:29 a.m. UTC | #7
On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote:
> On Mon, 28 Dec 2015, Arnd Bergmann wrote:
> 
> > On Monday 28 December 2015 07:18:58 Huan Wang wrote:
> > > Hi, Arnd,
> > > 
> > > 	Could you help to review the following patch? Thanks.
> > > 
> > 
> > Hi Alison,
> > 
> > I'm sorry but I understand very little of this particular area of the kernel.
> > 
> > I've added Daniel Lezcano, John Stultz and Thomas Gleixner to Cc, they all
> > know this much better than I do and one of them should be able to comment after
> > their Christmas break.
> 
> I have no real opinion about that patch. It does no harm to unconditionally
> setup the hrtimer based broadcast even if it's never used.
> 
> Up to the arch maintainer to decide. 

That's really not fair to keep shovelling these kinds of decisions onto
architecture maintainers without any kind of explanation about how an
architecture maintainer should make such a decision.

Do I roll a 6-face dice, and if it gives an odd number, I apply this
patch, otherwise I reject it?

Is there a technical basis for making the decision?  If so, please
explain what the technical arguments are against having or not having
this change.

Thanks.
Thomas Gleixner Jan. 5, 2016, 9:42 a.m. UTC | #8
On Sat, 2 Jan 2016, Russell King - ARM Linux wrote:
> On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote:
> > I have no real opinion about that patch. It does no harm to unconditionally
> > setup the hrtimer based broadcast even if it's never used.
> > 
> > Up to the arch maintainer to decide. 
> 
> That's really not fair to keep shovelling these kinds of decisions onto
> architecture maintainers without any kind of explanation about how an
> architecture maintainer should make such a decision.
> 
> Do I roll a 6-face dice, and if it gives an odd number, I apply this
> patch, otherwise I reject it?
> 
> Is there a technical basis for making the decision?  If so, please
> explain what the technical arguments are against having or not having
> this change.

The hrtimer based broadcast device is used when you have per cpu timers which
stop in deeper power states, but you have no other timer hardware on the chip
which can backup the per cpu timer in deep power states. The trick is that it
emulates a timer hardware via a hrtimer and then tells the cpu idle code not
to go into deep power states on the cpu which owns that hrtimer. All other
cpus can go as deep as they want and still get woken up.

The only downside of adding this unconditionally is extra code in case that it
is not needed on a particular platform.

Hope that helps.

     tglx
Alison Wang Dec. 1, 2017, 3:33 a.m. UTC | #9
Hi, Russell,

> On Sat, 2 Jan 2016, Russell King - ARM Linux wrote:
> > On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote:
> > > I have no real opinion about that patch. It does no harm to
> > > unconditionally setup the hrtimer based broadcast even if it's never
> used.
> > >
> > > Up to the arch maintainer to decide.
> >
> > That's really not fair to keep shovelling these kinds of decisions
> > onto architecture maintainers without any kind of explanation about
> > how an architecture maintainer should make such a decision.
> >
> > Do I roll a 6-face dice, and if it gives an odd number, I apply this
> > patch, otherwise I reject it?
> >
> > Is there a technical basis for making the decision?  If so, please
> > explain what the technical arguments are against having or not having
> > this change.
> 
> The hrtimer based broadcast device is used when you have per cpu timers
> which stop in deeper power states, but you have no other timer hardware on
> the chip which can backup the per cpu timer in deep power states. The
> trick is that it emulates a timer hardware via a hrtimer and then tells
> the cpu idle code not to go into deep power states on the cpu which owns
> that hrtimer. All other cpus can go as deep as they want and still get
> woken up.
> 
> The only downside of adding this unconditionally is extra code in case
> that it is not needed on a particular platform.
> 
> Hope that helps.
> 
[Alison Wang] What's your opinion about this explanation? Is this patch acceptable?

Best Regards,
Alison Wang
Yang Li April 3, 2019, 2:36 a.m. UTC | #10
On Tue, Jan 5, 2016 at 3:46 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Sat, 2 Jan 2016, Russell King - ARM Linux wrote:
> > On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote:
> > > I have no real opinion about that patch. It does no harm to unconditionally
> > > setup the hrtimer based broadcast even if it's never used.
> > >
> > > Up to the arch maintainer to decide.
> >
> > That's really not fair to keep shovelling these kinds of decisions onto
> > architecture maintainers without any kind of explanation about how an
> > architecture maintainer should make such a decision.
> >
> > Do I roll a 6-face dice, and if it gives an odd number, I apply this
> > patch, otherwise I reject it?
> >
> > Is there a technical basis for making the decision?  If so, please
> > explain what the technical arguments are against having or not having
> > this change.
>
> The hrtimer based broadcast device is used when you have per cpu timers which
> stop in deeper power states, but you have no other timer hardware on the chip
> which can backup the per cpu timer in deep power states. The trick is that it
> emulates a timer hardware via a hrtimer and then tells the cpu idle code not
> to go into deep power states on the cpu which owns that hrtimer. All other
> cpus can go as deep as they want and still get woken up.
>
> The only downside of adding this unconditionally is extra code in case that it
> is not needed on a particular platform.
>
> Hope that helps.

Hi Russell,

This has been pending for so long time.  I assume this is an ack from
Thomas.  And given the same thing has been added for arm64 and powerpc
architecture, can you also merge this for ARM?


Regards,
Leo
diff mbox

Patch

diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index a66e37e..a9bc73c 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -12,6 +12,7 @@ 
  *  reading the RTC at bootup, etc...
  */
 #include <linux/clk-provider.h>
+#include <linux/clockchips.h>
 #include <linux/clocksource.h>
 #include <linux/errno.h>
 #include <linux/export.h>
@@ -121,5 +122,7 @@  void __init time_init(void)
 		of_clk_init(NULL);
 #endif
 		clocksource_of_init();
+
+		tick_setup_hrtimer_broadcast();
 	}
 }