| Message ID | 20151002180255.GK12338@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Fri, Oct 02, 2015 at 11:02:55AM -0700, Stephen Boyd wrote: > On 10/02, Mason wrote: > > [ Adding original reporter ] > > > > On 02/10/2015 11:52, Mason wrote: > > > > > [ take 1 was sent on 2015-03-26 ] > > > > > > Hello everyone, > > > > > > In http://thread.gmane.org/gmane.linux.ports.arm.kernel/389931/focus=392348 > > > Stephen Boyd wrote: > > > > > >> I don't see any problem with the TWD dropping the dependency on SMP. > > >> The code should work the same on a UP configuration [...] > > > > > > And Arnd recently said: > > > > > >> I think this has come up before and should be fixed. Could you > > >> send a patch that allows using TWD in uniprocessor configurations? > > > > > > Basically, this means reverting Shawn Guo's 904464b91eca patch. > > > and removing "depends on SMP" for HAVE_ARM_TWD. > > > > > > However, Shawn's patch fixed an issue, therefore it seems likely > > > that simply reverting is not the proper solution? > > > > > > What should I do? > > > > For reference, the warning used to be: > > > > ------------[ cut here ]------------ > > WARNING: at arch/arm/kernel/smp_twd.c:345 > > twd_local_timer_of_register+0x7c/0x90() > > twd_local_timer_of_register failed (-6) > > Modules linked in: > > Backtrace: > > [<80011f14>] (dump_backtrace+0x0/0x10c) from [<8044dd30>] > > (dump_stack+0x18/0x1c) > > r7:805e9f58 r6:805ba84c r5:80539331 r4:00000159 > > [<8044dd18>] (dump_stack+0x0/0x1c) from [<80020fbc>] > > (warn_slowpath_common+0x54/0x6c) > > [<80020f68>] (warn_slowpath_common+0x0/0x6c) from [<80021078>] > > (warn_slowpath_fmt+0x38/0x40) > > r9:412fc09a r8:8fffffff r7:ffffffff r6:00000001 r5:80633b8c > > r4:80b32da8 > > [<80021040>] (warn_slowpath_fmt+0x0/0x40) from [<805ba84] > > (twd_local_timer_of_register+0x7c/0x90) > > r3:fffffffa r2:8053934b > > [<805ba7d0>] (twd_local_timer_of_register+0x0/0x90) from [<805c0bec>] > > (imx6q_timer_init+0x18/0x4c) > > r5:80633800 r4:8053b701 > > [<805c0bd4>] (imx6q_timer_init+0x0/0x4c) from [<805ba4e8>] > > (time_init+0x28/0x38) > > r5:80633800 r4:805dc0f4 > > [<805ba4c0>] (time_init+0x0/0x38) from [<805b6854>] > > (start_kernel+0x1a0/0x310) > > [<805b66b4>] (start_kernel+0x0/0x310) from [<10008044>] (0x10008044) > > r8:1000406a r7:805f3f8c r6:805dc0c4 r5:805f0518 r4:10c5387d > > ---[ end trace 1b75b31a2719ed1c ]--- > > > > > > I cannot reproduce on v4.2 + my platform... > > The warning has been removed in commit 5028090d1da1 (ARM: 8434/1: > Revert "7655/1: smp_twd: make twd_local_timer_of_register() no-op > for nosmp", 2015-09-14) sitting in linux-next. Oddly, that commit > doesn't remove the depends on SMP for the Kconfig. So it seems > that we can apply this patch and everyone is happy? We could also > drop the "if SMP" part of most of the platform selects if anyone > actually cares. heh, sorry about that. I forgot omap2plus_defconfig enables everything. I could refresh that patch if Russell is still okay taking a newer version of it. Russell ?
On 02/10/2015 20:02, Stephen Boyd wrote: > On 10/02, Mason wrote: >> [ Adding original reporter ] >> >> On 02/10/2015 11:52, Mason wrote: >> >>> [ take 1 was sent on 2015-03-26 ] >>> >>> Hello everyone, >>> >>> In http://thread.gmane.org/gmane.linux.ports.arm.kernel/389931/focus=392348 >>> Stephen Boyd wrote: >>> >>>> I don't see any problem with the TWD dropping the dependency on SMP. >>>> The code should work the same on a UP configuration [...] >>> >>> And Arnd recently said: >>> >>>> I think this has come up before and should be fixed. Could you >>>> send a patch that allows using TWD in uniprocessor configurations? >>> >>> Basically, this means reverting Shawn Guo's 904464b91eca patch. >>> and removing "depends on SMP" for HAVE_ARM_TWD. >>> >>> However, Shawn's patch fixed an issue, therefore it seems likely >>> that simply reverting is not the proper solution? >>> >>> What should I do? >> >> For reference, the warning used to be: >> >> ------------[ cut here ]------------ >> WARNING: at arch/arm/kernel/smp_twd.c:345 >> twd_local_timer_of_register+0x7c/0x90() >> twd_local_timer_of_register failed (-6) >> Modules linked in: >> Backtrace: >> [<80011f14>] (dump_backtrace+0x0/0x10c) from [<8044dd30>] >> (dump_stack+0x18/0x1c) >> r7:805e9f58 r6:805ba84c r5:80539331 r4:00000159 >> [<8044dd18>] (dump_stack+0x0/0x1c) from [<80020fbc>] >> (warn_slowpath_common+0x54/0x6c) >> [<80020f68>] (warn_slowpath_common+0x0/0x6c) from [<80021078>] >> (warn_slowpath_fmt+0x38/0x40) >> r9:412fc09a r8:8fffffff r7:ffffffff r6:00000001 r5:80633b8c >> r4:80b32da8 >> [<80021040>] (warn_slowpath_fmt+0x0/0x40) from [<805ba84] >> (twd_local_timer_of_register+0x7c/0x90) >> r3:fffffffa r2:8053934b >> [<805ba7d0>] (twd_local_timer_of_register+0x0/0x90) from [<805c0bec>] >> (imx6q_timer_init+0x18/0x4c) >> r5:80633800 r4:8053b701 >> [<805c0bd4>] (imx6q_timer_init+0x0/0x4c) from [<805ba4e8>] >> (time_init+0x28/0x38) >> r5:80633800 r4:805dc0f4 >> [<805ba4c0>] (time_init+0x0/0x38) from [<805b6854>] >> (start_kernel+0x1a0/0x310) >> [<805b66b4>] (start_kernel+0x0/0x310) from [<10008044>] (0x10008044) >> r8:1000406a r7:805f3f8c r6:805dc0c4 r5:805f0518 r4:10c5387d >> ---[ end trace 1b75b31a2719ed1c ]--- >> >> >> I cannot reproduce on v4.2 + my platform... > > The warning has been removed in commit 5028090d1da1 (ARM: 8434/1: > Revert "7655/1: smp_twd: make twd_local_timer_of_register() no-op > for nosmp", 2015-09-14) sitting in linux-next. Does that mean it will automatically make it into v4.3? > Oddly, that commit doesn't remove the depends on SMP for the Kconfig. Perhaps because the commit is just a revert, and the depends statement has been here since the beginning (f32f4ce257452) > So it seems that we can apply this patch and everyone is happy? > We could also drop the "if SMP" part of most of the platform > selects if anyone actually cares. My port requires the TWD to function. So I'm using select HAVE_ARM_TWD (no "if SMP") to have it work even on MULTIPLATFORM UP configs. > ---8<---- > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 369791fb619c..be64d9d604c3 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1389,7 +1389,6 @@ config HAVE_ARM_ARCH_TIMER > > config HAVE_ARM_TWD > bool > - depends on SMP > select CLKSRC_OF if OF > help > This options enables support for the ARM timer and watchdog unit Regards.
On Fri, Oct 02, 2015 at 01:48:27PM -0500, Felipe Balbi wrote: > heh, sorry about that. I forgot omap2plus_defconfig enables everything. > I could refresh that patch if Russell is still okay taking a newer > version of it. Russell ? Ok.
On Fri, Oct 02, 2015 at 07:55:33PM +0100, Russell King - ARM Linux wrote: > On Fri, Oct 02, 2015 at 01:48:27PM -0500, Felipe Balbi wrote: > > heh, sorry about that. I forgot omap2plus_defconfig enables everything. > > I could refresh that patch if Russell is still okay taking a newer > > version of it. Russell ? > > Ok. thanks, patch coming shortly. If anybody is against refreshing original patch, let me know now :-)
On 10/02, Mason wrote: > On 02/10/2015 20:02, Stephen Boyd wrote: > > On 10/02, Mason wrote: > >> > >> > >> I cannot reproduce on v4.2 + my platform... > > > > The warning has been removed in commit 5028090d1da1 (ARM: 8434/1: > > Revert "7655/1: smp_twd: make twd_local_timer_of_register() no-op > > for nosmp", 2015-09-14) sitting in linux-next. > > Does that mean it will automatically make it into v4.3? No. It will most likely be in v4.4 > > So it seems that we can apply this patch and everyone is happy? > > We could also drop the "if SMP" part of most of the platform > > selects if anyone actually cares. > > My port requires the TWD to function. So I'm using > select HAVE_ARM_TWD (no "if SMP") to have it work > even on MULTIPLATFORM UP configs. So you probably get some Kconfig warning about unmet dependencies.
Mason <slash.tmp@free.fr> writes: > My port requires the TWD to function. So I'm using > select HAVE_ARM_TWD (no "if SMP") to have it work > even on MULTIPLATFORM UP configs. You could just let it use another timer in the non-smp case if you didn't have that weird aversion towards using my code.
On Sat, 3 Oct 2015 00:34:02 +0100 Måns Rullgård <mans@mansr.com> wrote: > Mason <slash.tmp@free.fr> writes: > > > My port requires the TWD to function. So I'm using > > select HAVE_ARM_TWD (no "if SMP") to have it work > > even on MULTIPLATFORM UP configs. > > You could just let it use another timer in the non-smp case if you > didn't have that weird aversion towards using my code. I have no idea what your code does, but using the timer that is integrated into the core (just like on any other A9 implementation) feels like the right thing to do, unless the HW is too broken to use TWD. Another timer is a nice thing to have (it probably comes in handy for suspend/resume, and it may have a much better resolution), but this seems like icing on the cake at this point. Let's see the cake first. Thanks, M.
On 03/10/2015 11:32, Marc Zyngier wrote: > On Sat, 3 Oct 2015 00:34:02 +0100 > Måns Rullgård wrote: >> Mason writes: >> >>> My port requires the TWD to function. So I'm using >>> select HAVE_ARM_TWD (no "if SMP") to have it work >>> even on MULTIPLATFORM UP configs. >> >> You could just let it use another timer in the non-smp case if you >> didn't have that weird aversion towards using my code. > > I have no idea what your code does, but using the timer that is > integrated into the core (just like on any other A9 implementation) > feels like the right thing to do, unless the HW is too broken to use > TWD. > > Another timer is a nice thing to have (it probably comes in handy for > suspend/resume, and it may have a much better resolution), but this > seems like icing on the cake at this point. Let's see the cake first. Marc, I have a quick question for you :-) As I stated several months ago, my goal is to produce the simplest port possible, which is why I chose the TWD instead of platform timers. At one point, I was also considering the global timer. (I have a Cortex A9 MPCore.) But as far as I could tell, the code for the global timer does not handle CPU frequency changes (while smp_twd.c does), is that correct? AFAIU, TWD timers and global timer "tick" at the frequency of PERIPHCLK (which is CPUCLK/2 in my implementation). Therefore, code needs to be specifically written to handle cpufreq events. Is that a correct understanding? As for you comment about resolution, nominal PERIPHCLK is 600 MHz. Hard to beat that kind of resolution, I think. Have a nice week end. Regards.
On Sat, 3 Oct 2015 11:49:41 +0200 Mason <slash.tmp@free.fr> wrote: > On 03/10/2015 11:32, Marc Zyngier wrote: > > On Sat, 3 Oct 2015 00:34:02 +0100 > > Måns Rullgård wrote: > >> Mason writes: > >> > >>> My port requires the TWD to function. So I'm using > >>> select HAVE_ARM_TWD (no "if SMP") to have it work > >>> even on MULTIPLATFORM UP configs. > >> > >> You could just let it use another timer in the non-smp case if you > >> didn't have that weird aversion towards using my code. > > > > I have no idea what your code does, but using the timer that is > > integrated into the core (just like on any other A9 implementation) > > feels like the right thing to do, unless the HW is too broken to use > > TWD. > > > > Another timer is a nice thing to have (it probably comes in handy for > > suspend/resume, and it may have a much better resolution), but this > > seems like icing on the cake at this point. Let's see the cake first. > > Marc, > > I have a quick question for you :-) > > As I stated several months ago, my goal is to produce the simplest > port possible, which is why I chose the TWD instead of platform > timers. At one point, I was also considering the global timer. > (I have a Cortex A9 MPCore.) But as far as I could tell, the > code for the global timer does not handle CPU frequency changes > (while smp_twd.c does), is that correct? Indeed, I cannot see any code that does that in the GT driver. But if you have an A9 MP, you probably want to stick to TWD, which gives you a per-cpu timer instead of a global timer that will require IPIs to other CPUs. > AFAIU, TWD timers and global timer "tick" at the frequency of > PERIPHCLK (which is CPUCLK/2 in my implementation). Therefore, > code needs to be specifically written to handle cpufreq events. > Is that a correct understanding? I don't have the A9 TRM handy (nor the desire to read it on a sunny Saturday morning), so I can't really tell. But yes, this is likely to require some clock change handling. M.
On Sat, 2015-10-03 at 11:12AM +0100, Marc Zyngier wrote: > On Sat, 3 Oct 2015 11:49:41 +0200 > Mason <slash.tmp@free.fr> wrote: > > > On 03/10/2015 11:32, Marc Zyngier wrote: > > > On Sat, 3 Oct 2015 00:34:02 +0100 > > > Måns Rullgård wrote: > > >> Mason writes: > > >> > > >>> My port requires the TWD to function. So I'm using > > >>> select HAVE_ARM_TWD (no "if SMP") to have it work > > >>> even on MULTIPLATFORM UP configs. > > >> > > >> You could just let it use another timer in the non-smp case if you > > >> didn't have that weird aversion towards using my code. > > > > > > I have no idea what your code does, but using the timer that is > > > integrated into the core (just like on any other A9 implementation) > > > feels like the right thing to do, unless the HW is too broken to use > > > TWD. > > > > > > Another timer is a nice thing to have (it probably comes in handy for > > > suspend/resume, and it may have a much better resolution), but this > > > seems like icing on the cake at this point. Let's see the cake first. > > > > Marc, > > > > I have a quick question for you :-) > > > > As I stated several months ago, my goal is to produce the simplest > > port possible, which is why I chose the TWD instead of platform > > timers. At one point, I was also considering the global timer. > > (I have a Cortex A9 MPCore.) But as far as I could tell, the > > code for the global timer does not handle CPU frequency changes > > (while smp_twd.c does), is that correct? > > Indeed, I cannot see any code that does that in the GT driver. But if > you have an A9 MP, you probably want to stick to TWD, which gives you a > per-cpu timer instead of a global timer that will require IPIs to other > CPUs. I think the TWD only provides a clock_event device. Clocksource and schedclock would have to be provided by something else. > > > AFAIU, TWD timers and global timer "tick" at the frequency of > > PERIPHCLK (which is CPUCLK/2 in my implementation). Therefore, > > code needs to be specifically written to handle cpufreq events. > > Is that a correct understanding? > > I don't have the A9 TRM handy (nor the desire to read it on a > sunny Saturday morning), so I can't really tell. But yes, this is > likely to require some clock change handling. I looked at that once. IIRC, the problems are schedclock and clocksource. Other than a clockevent device which can be adjusted for frequency changes, there is (at least was) no such mechanism for clocksources and schedclock. Those are required to run at a stable frequency at all times (https://www.kernel.org/doc/Documentation/timers/timekeeping.txt). On Zynq I had the same problem and created a construct of notifiers for our clocksource to deal with this problem (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/clocksource/cadence_ttc_timer.c) I never really liked that "solution" much, though. That approach would probably not work with the GT because, last time I checked, it runs at the maximum frequency possible, i.e. dividers at the minimum (as a timer should), which means, if cpufreq throttles your CPU speed down, you'd have to decrease the clock dividers which isn't possible anymore (I could do that on the TTC because we have to run it a at very low speeds with high dividers to avoid constantly overflowing the 16-bit counter). Sören
On 05/10/2015 07:46, Sören Brinkmann wrote: > On Sat, 2015-10-03 at 11:12AM +0100, Marc Zyngier wrote: >> On Sat, 3 Oct 2015 11:49:41 +0200 >> Mason <slash.tmp@free.fr> wrote: >> >>> On 03/10/2015 11:32, Marc Zyngier wrote: >>>> On Sat, 3 Oct 2015 00:34:02 +0100 >>>> Måns Rullgård wrote: >>>>> Mason writes: >>>>> >>>>>> My port requires the TWD to function. So I'm using >>>>>> select HAVE_ARM_TWD (no "if SMP") to have it work >>>>>> even on MULTIPLATFORM UP configs. >>>>> >>>>> You could just let it use another timer in the non-smp case if you >>>>> didn't have that weird aversion towards using my code. >>>> >>>> I have no idea what your code does, but using the timer that is >>>> integrated into the core (just like on any other A9 implementation) >>>> feels like the right thing to do, unless the HW is too broken to use >>>> TWD. >>>> >>>> Another timer is a nice thing to have (it probably comes in handy for >>>> suspend/resume, and it may have a much better resolution), but this >>>> seems like icing on the cake at this point. Let's see the cake first. >>> >>> I have a quick question for you :-) >>> >>> As I stated several months ago, my goal is to produce the simplest >>> port possible, which is why I chose the TWD instead of platform >>> timers. At one point, I was also considering the global timer. >>> (I have a Cortex A9 MPCore.) But as far as I could tell, the >>> code for the global timer does not handle CPU frequency changes >>> (while smp_twd.c does), is that correct? >> >> Indeed, I cannot see any code that does that in the GT driver. But if >> you have an A9 MP, you probably want to stick to TWD, which gives you a >> per-cpu timer instead of a global timer that will require IPIs to other >> CPUs. > > I think the TWD only provides a clock_event device. Clocksource and > schedclock would have to be provided by something else. That is correct AFAIU. But my platform provides a simple 32-bit 27 MHz tick counter, which makes it trivial to implement clock source, sched clock and delay timer. http://article.gmane.org/gmane.linux.kernel/2049558 I have identified two problems with using the TWD in Linux: 1) the TWD is only available on SMP kernels => that issue seems close to being resolved 2) I was told that some platforms "turn off" the TWD block in low-power modes (like during WFI), and therefore must be marked as unreliable in "C3" (FEAT_C3STOP). I have a patch to selectively not mark the TWD as unreliable. (I will make a formal submission today.) >>> AFAIU, TWD timers and global timer "tick" at the frequency of >>> PERIPHCLK (which is CPUCLK/2 in my implementation). Therefore, >>> code needs to be specifically written to handle cpufreq events. >>> Is that a correct understanding? >> >> I don't have the A9 TRM handy (nor the desire to read it on a >> sunny Saturday morning), so I can't really tell. But yes, this is >> likely to require some clock change handling. > > I looked at that once. IIRC, the problems are schedclock and clocksource. > Other than a clockevent device which can be adjusted for frequency > changes, there is (at least was) no such mechanism for clocksources and > schedclock. Those are required to run at a stable frequency at all times > (https://www.kernel.org/doc/Documentation/timers/timekeeping.txt). > > On Zynq I had the same problem and created a construct of notifiers for > our clocksource to deal with this problem > (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/clocksource/cadence_ttc_timer.c) > I never really liked that "solution" much, though. > > That approach would probably not work with the GT because, last time I > checked, it runs at the maximum frequency possible, i.e. dividers at the > minimum (as a timer should), which means, if cpufreq throttles your CPU > speed down, you'd have to decrease the clock dividers which isn't > possible anymore (I could do that on the TTC because we have to run it > a at very low speeds with high dividers to avoid constantly overflowing > the 16-bit counter). Thanks for sharing your analysis. Regards.
On Mon, Oct 5, 2015 at 9:38 AM, Mason <slash.tmp@free.fr> wrote: > 2) I was told that some platforms "turn off" the TWD block in > low-power modes (like during WFI), and therefore must be marked > as unreliable in "C3" (FEAT_C3STOP). > > I have a patch to selectively not mark the TWD as unreliable. > (I will make a formal submission today.) This sounds like something that should be done with a device tree bool. Don't forget to patch Documentation/devicetree/bindings/arm/twd.txt Yours, Linus Walleij
Hi, On Sun, Oct 04, 2015 at 10:46:52PM -0700, Sören Brinkmann wrote: > On Sat, 2015-10-03 at 11:12AM +0100, Marc Zyngier wrote: > > Indeed, I cannot see any code that does that in the GT driver. But if > > you have an A9 MP, you probably want to stick to TWD, which gives you a > > per-cpu timer instead of a global timer that will require IPIs to other > > CPUs. > > I think the TWD only provides a clock_event device. Clocksource and > schedclock would have to be provided by something else. If no clocksource, sched clock is provided, default jiffies based ones would be sufficient for single core, no ?, though not a preferred one. Regards afzal > I looked at that once. IIRC, the problems are schedclock and clocksource. > Other than a clockevent device which can be adjusted for frequency > changes, there is (at least was) no such mechanism for clocksources and > schedclock. Those are required to run at a stable frequency at all times
On Mon, 2015-10-05 at 05:19PM +0530, Afzal Mohammed wrote: > Hi, > > On Sun, Oct 04, 2015 at 10:46:52PM -0700, Sören Brinkmann wrote: > > On Sat, 2015-10-03 at 11:12AM +0100, Marc Zyngier wrote: > > > > Indeed, I cannot see any code that does that in the GT driver. But if > > > you have an A9 MP, you probably want to stick to TWD, which gives you a > > > per-cpu timer instead of a global timer that will require IPIs to other > > > CPUs. > > > > I think the TWD only provides a clock_event device. Clocksource and > > schedclock would have to be provided by something else. > > If no clocksource, sched clock is provided, default jiffies based ones > would be sufficient for single core, no ?, though not a preferred one. Yes that is correct. My point was more, that twd+cpufreq is a rather easy case since it doesn't provide a clocksource/schedclock. A driver that provides those needs quite some more work if it depends on the CPU frequency and needs to be usable with cpufreq. Sören
On Mon, Oct 05, 2015 at 08:13:03AM -0700, Sören Brinkmann wrote: > On Mon, 2015-10-05 at 05:19PM +0530, Afzal Mohammed wrote: > > Hi, > > > > On Sun, Oct 04, 2015 at 10:46:52PM -0700, Sören Brinkmann wrote: > > > On Sat, 2015-10-03 at 11:12AM +0100, Marc Zyngier wrote: > > > > > > Indeed, I cannot see any code that does that in the GT driver. But if > > > > you have an A9 MP, you probably want to stick to TWD, which gives you a > > > > per-cpu timer instead of a global timer that will require IPIs to other > > > > CPUs. > > > > > > I think the TWD only provides a clock_event device. Clocksource and > > > schedclock would have to be provided by something else. > > > > If no clocksource, sched clock is provided, default jiffies based ones > > would be sufficient for single core, no ?, though not a preferred one. > > Yes that is correct. My point was more, that twd+cpufreq is a rather > easy case since it doesn't provide a clocksource/schedclock. A driver > that provides those needs quite some more work if it depends on the CPU > frequency and needs to be usable with cpufreq. _And_ you need to take the decision that you don't care about time keeping accuracy - because each and every time you change the clocksource's frequency, you will never be able to know exactly when the frequency change took effect in comparison with the counter value. You could do a very tight "read counter before, write clock rate, read counter after" and use that to calculate the number of timer ticks at the old rate, and re-set the timing parameters with the new initial counter value after the change, but even that's not perfect as you don't actually know when the write hits the hardware compared to the reads.
On 02/10/2015 20:02, Stephen Boyd wrote: > The warning has been removed in commit 5028090d1da1 (ARM: 8434/1: > Revert "7655/1: smp_twd: make twd_local_timer_of_register() no-op > for nosmp", 2015-09-14) sitting in linux-next. Oddly, that commit > doesn't remove the depends on SMP for the Kconfig. So it seems > that we can apply this patch and everyone is happy? We could also > drop the "if SMP" part of most of the platform selects if anyone > actually cares. > > ---8<---- > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 369791fb619c..be64d9d604c3 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1389,7 +1389,6 @@ config HAVE_ARM_ARCH_TIMER > > config HAVE_ARM_TWD > bool > - depends on SMP > select CLKSRC_OF if OF > help > This options enables support for the ARM timer and watchdog unit Hello Stephen, Should I make a formal submission for the above patch to be accepted? (Did you see my "twd: Don't set CLOCK_EVT_FEAT_C3STOP unconditionally" patch? What should I do now for it to be accepted?) Regards.
On 10/06, Mason wrote: > On 02/10/2015 20:02, Stephen Boyd wrote: > > > The warning has been removed in commit 5028090d1da1 (ARM: 8434/1: > > Revert "7655/1: smp_twd: make twd_local_timer_of_register() no-op > > for nosmp", 2015-09-14) sitting in linux-next. Oddly, that commit > > doesn't remove the depends on SMP for the Kconfig. So it seems > > that we can apply this patch and everyone is happy? We could also > > drop the "if SMP" part of most of the platform selects if anyone > > actually cares. > > > > ---8<---- > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 369791fb619c..be64d9d604c3 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -1389,7 +1389,6 @@ config HAVE_ARM_ARCH_TIMER > > > > config HAVE_ARM_TWD > > bool > > - depends on SMP > > select CLKSRC_OF if OF > > help > > This options enables support for the ARM timer and watchdog unit > > Hello Stephen, > > Should I make a formal submission for the above patch to be accepted? No. I believe Felipe is going to update commit 5028090d1da1 to remove the depends on. > > (Did you see my "twd: Don't set CLOCK_EVT_FEAT_C3STOP unconditionally" > patch? What should I do now for it to be accepted?) > Assuming you sent it to the correct maintainer from the MAINTAINERS file, I would expect them to apply it directly.
Stephen Boyd <sboyd@codeaurora.org> writes: > On 10/06, Mason wrote: >> On 02/10/2015 20:02, Stephen Boyd wrote: >> >> > The warning has been removed in commit 5028090d1da1 (ARM: 8434/1: >> > Revert "7655/1: smp_twd: make twd_local_timer_of_register() no-op >> > for nosmp", 2015-09-14) sitting in linux-next. Oddly, that commit >> > doesn't remove the depends on SMP for the Kconfig. So it seems >> > that we can apply this patch and everyone is happy? We could also >> > drop the "if SMP" part of most of the platform selects if anyone >> > actually cares. >> > >> > ---8<---- >> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> > index 369791fb619c..be64d9d604c3 100644 >> > --- a/arch/arm/Kconfig >> > +++ b/arch/arm/Kconfig >> > @@ -1389,7 +1389,6 @@ config HAVE_ARM_ARCH_TIMER >> > >> > config HAVE_ARM_TWD >> > bool >> > - depends on SMP >> > select CLKSRC_OF if OF >> > help >> > This options enables support for the ARM timer and watchdog unit >> >> Hello Stephen, >> >> Should I make a formal submission for the above patch to be accepted? > > No. I believe Felipe is going to update commit 5028090d1da1 to > remove the depends on. Already did it. Should be in next shortly.
Stephen Boyd wrote: > Mason wrote: > >> Did you see my "twd: Don't set CLOCK_EVT_FEAT_C3STOP unconditionally" >> patch? What should I do now for it to be accepted? > > Assuming you sent it to the correct maintainer from the > MAINTAINERS file, I would expect them to apply it directly. <confused> The patch touches arch/arm/kernel/smp_twd.c I do not see any entry for arch/arm/kernel in MAINTAINERS. This means I should fall back to the generic arch/arm entry, right? ARM PORT M: Russell King <linux@arm.linux.org.uk> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) W: http://www.arm.linux.org.uk/ S: Maintained F: arch/arm/ AFAIU, there is a separate process for submitting patches for arch/arm: http://www.arm.linux.org.uk/developer/patches/ Russell, Mark Rutland wrote: "Otherwise this looks ok." Does that mean I should now submit via the web form? Regards.
Hi, Mason <slash.tmp@free.fr> writes: > Stephen Boyd wrote: > >> Mason wrote: >> >>> Did you see my "twd: Don't set CLOCK_EVT_FEAT_C3STOP unconditionally" >>> patch? What should I do now for it to be accepted? >> >> Assuming you sent it to the correct maintainer from the >> MAINTAINERS file, I would expect them to apply it directly. > > <confused> > > The patch touches arch/arm/kernel/smp_twd.c > I do not see any entry for arch/arm/kernel in MAINTAINERS. > This means I should fall back to the generic arch/arm entry, right? > > ARM PORT > M: Russell King <linux@arm.linux.org.uk> > L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) > W: http://www.arm.linux.org.uk/ > S: Maintained > F: arch/arm/ > > AFAIU, there is a separate process for submitting patches for arch/arm: > http://www.arm.linux.org.uk/developer/patches/ > > Russell, Mark Rutland wrote: "Otherwise this looks ok." > Does that mean I should now submit via the web form? Mason, please have a read at Russell's patch info [1]. You don't even need to use the web form. [1] http://www.arm.linux.org.uk/developer/patches/info.php
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 369791fb619c..be64d9d604c3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1389,7 +1389,6 @@ config HAVE_ARM_ARCH_TIMER config HAVE_ARM_TWD bool - depends on SMP select CLKSRC_OF if OF help This options enables support for the ARM timer and watchdog unit