| Message ID | 52090B43.9090000@codeaurora.org |
|---|---|
| State | New |
| Headers | show |
On Mon, Aug 12, 2013 at 09:20:19AM -0700, Stephen Boyd wrote: > On 08/12/13 09:03, Sören Brinkmann wrote: > > On Fri, Aug 09, 2013 at 10:27:57AM -0700, Stephen Boyd wrote: > >> On 08/09, Daniel Lezcano wrote: > >>> yes, but at least the broadcast mechanism should send an IPI to cpu0 to > >>> wake it up, no ? As Stephen stated this kind of configuration should has > >>> never been tested before so the tick broadcast code is not handling this > >>> case properly IMHO. > >>> > >> If you have a per-cpu tick device that isn't suffering from > >> FEAT_C3_STOP why wouldn't you use that for the tick versus a > >> per-cpu tick device that has FEAT_C3_STOP? It sounds like there > >> is a bug in the preference logic or you should boost the rating > >> of the arm global timer above the twd. Does this patch help? It > >> should make the arm global timer the tick device and whatever the > >> cadence timer you have into the broadcast device. > > I finally got to test your patch. Unfortunately, it makes the system > > hang even earlier: > > Sorry it had a bug depending on the registration order. Can you try this > one (tabs are probably spaces, sorry)? I will go read through this > thread to see if we already covered the registration order. What is the base for your patch? I based my GT enable patch on 3.11-rc3 and for consistency in our debugging, I didn't move it elsewhere since. Your patch doesn't apply cleanly on it. I see if I can work it out, just let me know if it depends on something not available in 3.11-rc3. Sören
On Mon, Aug 12, 2013 at 09:20:19AM -0700, Stephen Boyd wrote: > On 08/12/13 09:03, Sören Brinkmann wrote: > > On Fri, Aug 09, 2013 at 10:27:57AM -0700, Stephen Boyd wrote: > >> On 08/09, Daniel Lezcano wrote: > >>> yes, but at least the broadcast mechanism should send an IPI to cpu0 to > >>> wake it up, no ? As Stephen stated this kind of configuration should has > >>> never been tested before so the tick broadcast code is not handling this > >>> case properly IMHO. > >>> > >> If you have a per-cpu tick device that isn't suffering from > >> FEAT_C3_STOP why wouldn't you use that for the tick versus a > >> per-cpu tick device that has FEAT_C3_STOP? It sounds like there > >> is a bug in the preference logic or you should boost the rating > >> of the arm global timer above the twd. Does this patch help? It > >> should make the arm global timer the tick device and whatever the > >> cadence timer you have into the broadcast device. > > I finally got to test your patch. Unfortunately, it makes the system > > hang even earlier: > > Sorry it had a bug depending on the registration order. Can you try this > one (tabs are probably spaces, sorry)? I will go read through this > thread to see if we already covered the registration order. That did it! Booted straight into the system. The broadcast device is the TTC instead of GT, now. Tick Device: mode: 1 Broadcast device Clock Event Device: ttc_clockevent max_delta_ns: 1207932479 min_delta_ns: 18432 mult: 233015 shift: 32 mode: 1 next_event: 9223372036854775807 nsecs set_next_event: ttc_set_next_event set_mode: ttc_set_mode event_handler: tick_handle_oneshot_broadcast retries: 0 tick_broadcast_mask: 00000000 tick_broadcast_oneshot_mask: 00000000 Tick Device: mode: 1 Per CPU device: 0 Clock Event Device: arm_global_timer max_delta_ns: 12884902005 min_delta_ns: 1000 mult: 715827876 shift: 31 mode: 3 next_event: 24216749370 nsecs set_next_event: gt_clockevent_set_next_event set_mode: gt_clockevent_set_mode event_handler: hrtimer_interrupt retries: 0 Tick Device: mode: 1 Per CPU device: 1 Clock Event Device: arm_global_timer max_delta_ns: 12884902005 min_delta_ns: 1000 mult: 715827876 shift: 31 mode: 3 next_event: 24220000000 nsecs set_next_event: gt_clockevent_set_next_event set_mode: gt_clockevent_set_mode event_handler: hrtimer_interrupt retries: 0 # cat /proc/interrupts CPU0 CPU1 27: 1668 1640 GIC 27 gt 29: 0 0 GIC 29 twd 43: 0 0 GIC 43 ttc_clockevent 82: 536 0 GIC 82 xuartps IPI0: 0 0 CPU wakeup interrupts IPI1: 0 0 Timer broadcast interrupts IPI2: 1264 1322 Rescheduling interrupts IPI3: 0 0 Function call interrupts IPI4: 24 70 Single function call interrupts IPI5: 0 0 CPU stop interrupts Err: 0 Thanks, Sören
On 08/12/13 09:24, Sören Brinkmann wrote: > On Mon, Aug 12, 2013 at 09:20:19AM -0700, Stephen Boyd wrote: >> On 08/12/13 09:03, Sören Brinkmann wrote: >>> On Fri, Aug 09, 2013 at 10:27:57AM -0700, Stephen Boyd wrote: >>>> On 08/09, Daniel Lezcano wrote: >>>>> yes, but at least the broadcast mechanism should send an IPI to cpu0 to >>>>> wake it up, no ? As Stephen stated this kind of configuration should has >>>>> never been tested before so the tick broadcast code is not handling this >>>>> case properly IMHO. >>>>> >>>> If you have a per-cpu tick device that isn't suffering from >>>> FEAT_C3_STOP why wouldn't you use that for the tick versus a >>>> per-cpu tick device that has FEAT_C3_STOP? It sounds like there >>>> is a bug in the preference logic or you should boost the rating >>>> of the arm global timer above the twd. Does this patch help? It >>>> should make the arm global timer the tick device and whatever the >>>> cadence timer you have into the broadcast device. >>> I finally got to test your patch. Unfortunately, it makes the system >>> hang even earlier: >> Sorry it had a bug depending on the registration order. Can you try this >> one (tabs are probably spaces, sorry)? I will go read through this >> thread to see if we already covered the registration order. > What is the base for your patch? I based my GT enable patch on 3.11-rc3 > and for consistency in our debugging, I didn't move it elsewhere since. > Your patch doesn't apply cleanly on it. I see if I can work it out, just > let me know if it depends on something not available in 3.11-rc3. I applied this on 3.11-rc4. I don't think anything has changed there between rc3 and rc4. so you're probably running into the whitespace problem.
On Mon, Aug 12, 2013 at 09:40:52AM -0700, Stephen Boyd wrote: > On 08/12/13 09:24, Sören Brinkmann wrote: > > On Mon, Aug 12, 2013 at 09:20:19AM -0700, Stephen Boyd wrote: > >> On 08/12/13 09:03, Sören Brinkmann wrote: > >>> On Fri, Aug 09, 2013 at 10:27:57AM -0700, Stephen Boyd wrote: > >>>> On 08/09, Daniel Lezcano wrote: > >>>>> yes, but at least the broadcast mechanism should send an IPI to cpu0 to > >>>>> wake it up, no ? As Stephen stated this kind of configuration should has > >>>>> never been tested before so the tick broadcast code is not handling this > >>>>> case properly IMHO. > >>>>> > >>>> If you have a per-cpu tick device that isn't suffering from > >>>> FEAT_C3_STOP why wouldn't you use that for the tick versus a > >>>> per-cpu tick device that has FEAT_C3_STOP? It sounds like there > >>>> is a bug in the preference logic or you should boost the rating > >>>> of the arm global timer above the twd. Does this patch help? It > >>>> should make the arm global timer the tick device and whatever the > >>>> cadence timer you have into the broadcast device. > >>> I finally got to test your patch. Unfortunately, it makes the system > >>> hang even earlier: > >> Sorry it had a bug depending on the registration order. Can you try this > >> one (tabs are probably spaces, sorry)? I will go read through this > >> thread to see if we already covered the registration order. > > What is the base for your patch? I based my GT enable patch on 3.11-rc3 > > and for consistency in our debugging, I didn't move it elsewhere since. > > Your patch doesn't apply cleanly on it. I see if I can work it out, just > > let me know if it depends on something not available in 3.11-rc3. > > I applied this on 3.11-rc4. I don't think anything has changed there > between rc3 and rc4. so you're probably running into the whitespace problem. That or the scissors are my problem. I never worked with scissors and it looks kinda odd what happened when I am'ed the patch. Anyway, I just manually merged it in. Sören
On 08/12/2013 06:32 PM, Sören Brinkmann wrote: > On Mon, Aug 12, 2013 at 09:20:19AM -0700, Stephen Boyd wrote: >> On 08/12/13 09:03, Sören Brinkmann wrote: >>> On Fri, Aug 09, 2013 at 10:27:57AM -0700, Stephen Boyd wrote: >>>> On 08/09, Daniel Lezcano wrote: >>>>> yes, but at least the broadcast mechanism should send an IPI to cpu0 to >>>>> wake it up, no ? As Stephen stated this kind of configuration should has >>>>> never been tested before so the tick broadcast code is not handling this >>>>> case properly IMHO. >>>>> >>>> If you have a per-cpu tick device that isn't suffering from >>>> FEAT_C3_STOP why wouldn't you use that for the tick versus a >>>> per-cpu tick device that has FEAT_C3_STOP? It sounds like there >>>> is a bug in the preference logic or you should boost the rating >>>> of the arm global timer above the twd. Does this patch help? It >>>> should make the arm global timer the tick device and whatever the >>>> cadence timer you have into the broadcast device. >>> I finally got to test your patch. Unfortunately, it makes the system >>> hang even earlier: >> >> Sorry it had a bug depending on the registration order. Can you try this >> one (tabs are probably spaces, sorry)? I will go read through this >> thread to see if we already covered the registration order. > > That did it! Booted straight into the system. Good news :) > The broadcast device is > the TTC instead of GT, now. > > Tick Device: mode: 1 > Broadcast device > Clock Event Device: ttc_clockevent > max_delta_ns: 1207932479 > min_delta_ns: 18432 > mult: 233015 > shift: 32 > mode: 1 > next_event: 9223372036854775807 nsecs > set_next_event: ttc_set_next_event > set_mode: ttc_set_mode > event_handler: tick_handle_oneshot_broadcast > retries: 0 > > tick_broadcast_mask: 00000000 > tick_broadcast_oneshot_mask: 00000000 At the first glance, the timer broadcast usage is not set, right ? Can you try with the cpuidle flag even if it is not needed ? Thanks -- Daniel
On Mon, Aug 12, 2013 at 06:49:17PM +0200, Daniel Lezcano wrote: > On 08/12/2013 06:32 PM, Sören Brinkmann wrote: > > On Mon, Aug 12, 2013 at 09:20:19AM -0700, Stephen Boyd wrote: > >> On 08/12/13 09:03, Sören Brinkmann wrote: > >>> On Fri, Aug 09, 2013 at 10:27:57AM -0700, Stephen Boyd wrote: > >>>> On 08/09, Daniel Lezcano wrote: > >>>>> yes, but at least the broadcast mechanism should send an IPI to cpu0 to > >>>>> wake it up, no ? As Stephen stated this kind of configuration should has > >>>>> never been tested before so the tick broadcast code is not handling this > >>>>> case properly IMHO. > >>>>> > >>>> If you have a per-cpu tick device that isn't suffering from > >>>> FEAT_C3_STOP why wouldn't you use that for the tick versus a > >>>> per-cpu tick device that has FEAT_C3_STOP? It sounds like there > >>>> is a bug in the preference logic or you should boost the rating > >>>> of the arm global timer above the twd. Does this patch help? It > >>>> should make the arm global timer the tick device and whatever the > >>>> cadence timer you have into the broadcast device. > >>> I finally got to test your patch. Unfortunately, it makes the system > >>> hang even earlier: > >> > >> Sorry it had a bug depending on the registration order. Can you try this > >> one (tabs are probably spaces, sorry)? I will go read through this > >> thread to see if we already covered the registration order. > > > > That did it! Booted straight into the system. > > Good news :) > > > The broadcast device is > > the TTC instead of GT, now. > > > > Tick Device: mode: 1 > > Broadcast device > > Clock Event Device: ttc_clockevent > > max_delta_ns: 1207932479 > > min_delta_ns: 18432 > > mult: 233015 > > shift: 32 > > mode: 1 > > next_event: 9223372036854775807 nsecs > > set_next_event: ttc_set_next_event > > set_mode: ttc_set_mode > > event_handler: tick_handle_oneshot_broadcast > > retries: 0 > > > > tick_broadcast_mask: 00000000 > > tick_broadcast_oneshot_mask: 00000000 > > At the first glance, the timer broadcast usage is not set, right ? Can > you try with the cpuidle flag even if it is not needed ? It's actually present. I have a clean 3.11-rc3 and the only changes are my patch to enable the GT and Stephen's fix. The cpuidle stats show both idle states being used. Sören
On 08/12/2013 06:53 PM, Sören Brinkmann wrote: > On Mon, Aug 12, 2013 at 06:49:17PM +0200, Daniel Lezcano wrote: >> On 08/12/2013 06:32 PM, Sören Brinkmann wrote: >>> On Mon, Aug 12, 2013 at 09:20:19AM -0700, Stephen Boyd wrote: >>>> On 08/12/13 09:03, Sören Brinkmann wrote: >>>>> On Fri, Aug 09, 2013 at 10:27:57AM -0700, Stephen Boyd wrote: >>>>>> On 08/09, Daniel Lezcano wrote: >>>>>>> yes, but at least the broadcast mechanism should send an IPI to cpu0 to >>>>>>> wake it up, no ? As Stephen stated this kind of configuration should has >>>>>>> never been tested before so the tick broadcast code is not handling this >>>>>>> case properly IMHO. >>>>>>> >>>>>> If you have a per-cpu tick device that isn't suffering from >>>>>> FEAT_C3_STOP why wouldn't you use that for the tick versus a >>>>>> per-cpu tick device that has FEAT_C3_STOP? It sounds like there >>>>>> is a bug in the preference logic or you should boost the rating >>>>>> of the arm global timer above the twd. Does this patch help? It >>>>>> should make the arm global timer the tick device and whatever the >>>>>> cadence timer you have into the broadcast device. >>>>> I finally got to test your patch. Unfortunately, it makes the system >>>>> hang even earlier: >>>> >>>> Sorry it had a bug depending on the registration order. Can you try this >>>> one (tabs are probably spaces, sorry)? I will go read through this >>>> thread to see if we already covered the registration order. >>> >>> That did it! Booted straight into the system. >> >> Good news :) >> >>> The broadcast device is >>> the TTC instead of GT, now. >>> >>> Tick Device: mode: 1 >>> Broadcast device >>> Clock Event Device: ttc_clockevent >>> max_delta_ns: 1207932479 >>> min_delta_ns: 18432 >>> mult: 233015 >>> shift: 32 >>> mode: 1 >>> next_event: 9223372036854775807 nsecs >>> set_next_event: ttc_set_next_event >>> set_mode: ttc_set_mode >>> event_handler: tick_handle_oneshot_broadcast >>> retries: 0 >>> >>> tick_broadcast_mask: 00000000 >>> tick_broadcast_oneshot_mask: 00000000 >> >> At the first glance, the timer broadcast usage is not set, right ? Can >> you try with the cpuidle flag even if it is not needed ? > > It's actually present. I have a clean 3.11-rc3 and the only changes are > my patch to enable the GT and Stephen's fix. > The cpuidle stats show both idle states being used. Ah, right. The tick_broadcast_mask is not set because the arm global timer has not the CLOCK_EVT_FEAT_C3STOP feature flag set. Thanks -- Daniel
On Mon, Aug 12, 2013 at 07:02:39PM +0200, Daniel Lezcano wrote: > On 08/12/2013 06:53 PM, Sören Brinkmann wrote: > > On Mon, Aug 12, 2013 at 06:49:17PM +0200, Daniel Lezcano wrote: > >> On 08/12/2013 06:32 PM, Sören Brinkmann wrote: > >>> On Mon, Aug 12, 2013 at 09:20:19AM -0700, Stephen Boyd wrote: > >>>> On 08/12/13 09:03, Sören Brinkmann wrote: > >>>>> On Fri, Aug 09, 2013 at 10:27:57AM -0700, Stephen Boyd wrote: > >>>>>> On 08/09, Daniel Lezcano wrote: > >>>>>>> yes, but at least the broadcast mechanism should send an IPI to cpu0 to > >>>>>>> wake it up, no ? As Stephen stated this kind of configuration should has > >>>>>>> never been tested before so the tick broadcast code is not handling this > >>>>>>> case properly IMHO. > >>>>>>> > >>>>>> If you have a per-cpu tick device that isn't suffering from > >>>>>> FEAT_C3_STOP why wouldn't you use that for the tick versus a > >>>>>> per-cpu tick device that has FEAT_C3_STOP? It sounds like there > >>>>>> is a bug in the preference logic or you should boost the rating > >>>>>> of the arm global timer above the twd. Does this patch help? It > >>>>>> should make the arm global timer the tick device and whatever the > >>>>>> cadence timer you have into the broadcast device. > >>>>> I finally got to test your patch. Unfortunately, it makes the system > >>>>> hang even earlier: > >>>> > >>>> Sorry it had a bug depending on the registration order. Can you try this > >>>> one (tabs are probably spaces, sorry)? I will go read through this > >>>> thread to see if we already covered the registration order. > >>> > >>> That did it! Booted straight into the system. > >> > >> Good news :) > >> > >>> The broadcast device is > >>> the TTC instead of GT, now. > >>> > >>> Tick Device: mode: 1 > >>> Broadcast device > >>> Clock Event Device: ttc_clockevent > >>> max_delta_ns: 1207932479 > >>> min_delta_ns: 18432 > >>> mult: 233015 > >>> shift: 32 > >>> mode: 1 > >>> next_event: 9223372036854775807 nsecs > >>> set_next_event: ttc_set_next_event > >>> set_mode: ttc_set_mode > >>> event_handler: tick_handle_oneshot_broadcast > >>> retries: 0 > >>> > >>> tick_broadcast_mask: 00000000 > >>> tick_broadcast_oneshot_mask: 00000000 > >> > >> At the first glance, the timer broadcast usage is not set, right ? Can > >> you try with the cpuidle flag even if it is not needed ? > > > > It's actually present. I have a clean 3.11-rc3 and the only changes are > > my patch to enable the GT and Stephen's fix. > > The cpuidle stats show both idle states being used. > > Ah, right. The tick_broadcast_mask is not set because the arm global > timer has not the CLOCK_EVT_FEAT_C3STOP feature flag set. Just to check in. Do you want any additional testing done? Or can I expect Stephens fix to get merged, so Zynq can use the GT? Thanks, Sören
On 08/16/13 10:28, Sören Brinkmann wrote: > On Mon, Aug 12, 2013 at 07:02:39PM +0200, Daniel Lezcano wrote: >> On 08/12/2013 06:53 PM, Sören Brinkmann wrote: >>> It's actually present. I have a clean 3.11-rc3 and the only changes are >>> my patch to enable the GT and Stephen's fix. >>> The cpuidle stats show both idle states being used. >> Ah, right. The tick_broadcast_mask is not set because the arm global >> timer has not the CLOCK_EVT_FEAT_C3STOP feature flag set. > Just to check in. Do you want any additional testing done? Or can I > expect Stephens fix to get merged, so Zynq can use the GT? > I was curious, can you use just the first hunk of the patch that applied to tick-broadcast.c to fix the problem? I think the answer is yes.
Hi Stephen, On Mon, Aug 19, 2013 at 04:00:36PM -0700, Stephen Boyd wrote: > On 08/16/13 10:28, Sören Brinkmann wrote: > > On Mon, Aug 12, 2013 at 07:02:39PM +0200, Daniel Lezcano wrote: > >> On 08/12/2013 06:53 PM, Sören Brinkmann wrote: > >>> It's actually present. I have a clean 3.11-rc3 and the only changes are > >>> my patch to enable the GT and Stephen's fix. > >>> The cpuidle stats show both idle states being used. > >> Ah, right. The tick_broadcast_mask is not set because the arm global > >> timer has not the CLOCK_EVT_FEAT_C3STOP feature flag set. > > Just to check in. Do you want any additional testing done? Or can I > > expect Stephens fix to get merged, so Zynq can use the GT? > > > > I was curious, can you use just the first hunk of the patch that applied > to tick-broadcast.c to fix the problem? I think the answer is yes. Yes, that seems to be enough. # cat /proc/interrupts CPU0 CPU1 27: 14 1 GIC 27 gt 29: 664 759 GIC 29 twd 43: 725 0 GIC 43 ttc_clockevent 82: 214 0 GIC 82 xuartps IPI0: 0 0 CPU wakeup interrupts IPI1: 0 58 Timer broadcast interrupts IPI2: 1224 1120 Rescheduling interrupts IPI3: 0 0 Function call interrupts IPI4: 44 50 Single function call interrupts IPI5: 0 0 CPU stop interrupts Err: 0 Timer list: Tick Device: mode: 1 Broadcast device Clock Event Device: ttc_clockevent max_delta_ns: 1207932479 min_delta_ns: 18432 mult: 233015 shift: 32 mode: 3 next_event: 60080000000 nsecs set_next_event: ttc_set_next_event set_mode: ttc_set_mode event_handler: tick_handle_oneshot_broadcast retries: 0 tick_broadcast_mask: 00000003 tick_broadcast_oneshot_mask: 00000000 Tick Device: mode: 1 Per CPU device: 0 Clock Event Device: local_timer max_delta_ns: 12884902005 min_delta_ns: 1000 mult: 715827876 shift: 31 mode: 3 next_event: 59075238755 nsecs set_next_event: twd_set_next_event set_mode: twd_set_mode event_handler: hrtimer_interrupt retries: 0 Tick Device: mode: 1 Per CPU device: 1 Clock Event Device: local_timer max_delta_ns: 12884902005 min_delta_ns: 1000 mult: 715827876 shift: 31 mode: 3 next_event: 59080000000 nsecs set_next_event: twd_set_next_event set_mode: twd_set_mode event_handler: hrtimer_interrupt retries: 0 Sören
On 08/19, S??ren Brinkmann wrote: > Hi Stephen, > > On Mon, Aug 19, 2013 at 04:00:36PM -0700, Stephen Boyd wrote: > > On 08/16/13 10:28, S??ren Brinkmann wrote: > > > On Mon, Aug 12, 2013 at 07:02:39PM +0200, Daniel Lezcano wrote: > > >> On 08/12/2013 06:53 PM, S??ren Brinkmann wrote: > > >>> It's actually present. I have a clean 3.11-rc3 and the only changes are > > >>> my patch to enable the GT and Stephen's fix. > > >>> The cpuidle stats show both idle states being used. > > >> Ah, right. The tick_broadcast_mask is not set because the arm global > > >> timer has not the CLOCK_EVT_FEAT_C3STOP feature flag set. > > > Just to check in. Do you want any additional testing done? Or can I > > > expect Stephens fix to get merged, so Zynq can use the GT? > > > > > > > I was curious, can you use just the first hunk of the patch that applied > > to tick-broadcast.c to fix the problem? I think the answer is yes. > > Yes, that seems to be enough. > Great thank you. I will split the patch into two pieces. That way we can discuss the merit of always using a timer that doesn't suffer from FEAT_C3_STOP over a timer that does.
On 08/20/2013 02:57 AM, Stephen Boyd wrote: > On 08/19, S??ren Brinkmann wrote: >> Hi Stephen, >> >> On Mon, Aug 19, 2013 at 04:00:36PM -0700, Stephen Boyd wrote: >>> On 08/16/13 10:28, S??ren Brinkmann wrote: >>>> On Mon, Aug 12, 2013 at 07:02:39PM +0200, Daniel Lezcano wrote: >>>>> On 08/12/2013 06:53 PM, S??ren Brinkmann wrote: >>>>>> It's actually present. I have a clean 3.11-rc3 and the only changes are >>>>>> my patch to enable the GT and Stephen's fix. >>>>>> The cpuidle stats show both idle states being used. >>>>> Ah, right. The tick_broadcast_mask is not set because the arm global >>>>> timer has not the CLOCK_EVT_FEAT_C3STOP feature flag set. >>>> Just to check in. Do you want any additional testing done? Or can I >>>> expect Stephens fix to get merged, so Zynq can use the GT? >>>> >>> >>> I was curious, can you use just the first hunk of the patch that applied >>> to tick-broadcast.c to fix the problem? I think the answer is yes. >> >> Yes, that seems to be enough. >> > > Great thank you. I will split the patch into two pieces. That way > we can discuss the merit of always using a timer that doesn't > suffer from FEAT_C3_STOP over a timer that does. Yes, that sounds a good idea. -- Daniel
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c index 218bcb5..d3539e5 100644 --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@ -77,6 +77,9 @@ static bool tick_check_broadcast_device(struct clock_event_device *curdev, !(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) return false; + if (cpumask_equal(newdev->cpumask, cpumask_of(smp_processor_id()))) + return false; + return !curdev || newdev->rating > curdev->rating; } diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index 64522ec..dd08f3b 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -244,12 +244,22 @@ static bool tick_check_preferred(struct clock_event_device *curdev, return false; } + if (!curdev) + return true; + + /* Always prefer a tick device that doesn't suffer from FEAT_C3STOP */ + if (!(newdev->features & CLOCK_EVT_FEAT_C3STOP) && + (curdev->features & CLOCK_EVT_FEAT_C3STOP)) + return true; + if ((newdev->features & CLOCK_EVT_FEAT_C3STOP) && + !(curdev->features & CLOCK_EVT_FEAT_C3STOP)) + return false; + /* * Use the higher rated one, but prefer a CPU local device with a lower * rating than a non-CPU local device */ - return !curdev || - newdev->rating > curdev->rating || + return newdev->rating > curdev->rating || !cpumask_equal(curdev->cpumask, newdev->cpumask); }