Message ID | 1437124312-44700-1-git-send-email-b18965@freescale.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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
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 >
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 > >
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 > >
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(); > > > } > > > }
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(); > > > > } > > > > } > > >
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.
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
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
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 --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(); } }
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(+)