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 <[email protected]>
---
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
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 <[email protected]>
>
> This looks sensible to me. FWIW:
>
> Acked-by: Mark Rutland <[email protected]>
>
> 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
> >
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 <[email protected]>
>
> This looks sensible to me. FWIW:
>
> Acked-by: Mark Rutland <[email protected]>
>
> 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
> >
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 <[email protected]>
> >
> > This looks sensible to me. FWIW:
> >
> > Acked-by: Mark Rutland <[email protected]>
> >
> > 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();
> > > }
> > > }
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 <[email protected]>
> > >
> > > This looks sensible to me. FWIW:
> > >
> > > Acked-by: Mark Rutland <[email protected]>
> > >
> > > 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();
> > > > }
> > > > }
>
>
>
On Tue, Jan 5, 2016 at 3:46 AM Thomas Gleixner <[email protected]> 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
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
From 1585560690256904713@xxx Fri Dec 01 06:08:27 +0000 2017
X-GM-THRID: 1585560690256904713
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread