public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: santosh.shilimkar@ti•com (Santosh Shilimkar)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
Date: Thu, 15 May 2014 13:54:35 -0400	[thread overview]
Message-ID: <5374FF5B.8050702@ti.com> (raw)
In-Reply-To: <5374FE61.50901@linaro.org>

On Thursday 15 May 2014 01:50 PM, Daniel Lezcano wrote:
> On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:
>> Daniel,
>>
>> On Wednesday 14 May 2014 05:18 PM, Santosh Shilimkar wrote:
>>> On Wednesday 14 May 2014 04:02 PM, Daniel Lezcano wrote:
>>>> On 05/14/2014 09:50 PM, Santosh Shilimkar wrote:
>>>>> On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:
>>>>>> On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:
>>>>>>> On OMAP4 panda board, there have been several bug reports about boot
>>>>>>> hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
>>>>>>> is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
>>>>>>> use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
>>>>>>> code for right reasons but on OMAP4 which suffers from a nasty ROM code
>>>>>>> bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
>>>>>>> we loose interrupts which leads to issues like lock-up, hangs etc.
>>>>>>>
>>>>>>> Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
>>>>>>> flag} to avoid the issue. With this change, OMAP4 panda boards, the mentioned
>>>>>>> issues are getting fixed. We no longer loose interrupts which was the cause
>>>>>>> of the regression.
>>>>>>>
>>>>>>> Cc: Roger Quadros <rogerq@ti•com>
>>>>>>> Cc: Kevin Hilman <khilman@linaro•org>
>>>>>>> Cc: Tony Lindgren <tony@atomide•com>
>>>>>>> Cc: Daniel Lezcano <daniel.lezcano@linaro•org>
>>>>>>> Reported-tested-by: Roger Quadros <rogerq@ti•com>
>>>>>>> Reported-tested-by: Kevin Hilman <khilman@linaro•org>
>>>>>>> Tested-by: Tony Lindgren <tony@atomide•com>
>>>>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti•com>
>>>>>>> ---
>>>>
>>>> [ ... ]
>>>>
>>>>>>>
>>>>>>> +    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
>>>>>>> +
>>>>>>>         /*
>>>>>>>          * Call idle CPU PM enter notifier chain so that
>>>>>>>          * VFP and per CPU interrupt context is saved.
>>>>>>> @@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
>>>>>>>         if (dev->cpu == 0 && mpuss_can_lose_context)
>>>>>>>             cpu_cluster_pm_exit();
>>>>>>>
>>>>>>> +    clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
>>>>
>>>> [ ... ]
>>>>
>>>>>>
>>>>>> Shouldn't the broadcast timer to be setup with CLOCK_EVT_NOTIFY_BROADCAST_ON also ?
>>>>>>
>>>>> Which is already taken care by __cpuidle_register_driver(). Note that setup code
>>>>> is still used from generic code...
>>>>
>>>> Nope, if the flag CPUIDLE_FLAG_TIMER_STOP is not set, the cpuidle framework won't setup the timer.
>>>>
>>> I see. I assumed it was taken care. So we might have setup the timer too.
>>>
>>>> static void __cpuidle_driver_init(struct cpuidle_driver *drv)
>>>> {
>>>>
>>>>      ...
>>>>
>>>>      for (i = drv->state_count - 1; i >= 0 ; i--) {
>>>>          if (drv->states[i].flags & CPUIDLE_FLAG_TIMER_STOP) {
>>> May be you should start the bc timer in case 'CPUIDLE_FLAG_TIMER_STOP'
>>> or 'CPUIDLE_FLAG_COUPLED'
>>>>              drv->bctimer = 1;
>>>>              break;
>>>>          }
>>>>      }
>>>>
>>>>      ...
>>>>
>>>> }
>>>>
>>>> static int __cpuidle_register_driver(struct cpuidle_driver *drv)
>>>> {
>>>>      ...
>>>>
>>>>      if (drv->bctimer)
>>>>          on_each_cpu_mask(drv->cpumask,
>>>>          cpuidle_setup_broadcast_timer,
>>>>           (void *)CLOCK_EVT_NOTIFY_BROADCAST_ON, 1);
>>>>
>>>>      ...
>>>> }
>>>>
>>>> So the broadcast timer does not operate with this revert. Moreover, I am not sure reverting this patch is the right solution.
>>>>
>>> With above mentioned change, it should work. Other alternatives is OMAP4 driver does
>>> its won registration where it can start the timer. The way it was before the
>>> consolidation.
>>>
>>> Ofcourse if you have better fix, then great.
>>>
>> What is your suggestion. We *must* fix the regression asap. I think
>> $subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
>> seems a good way forward.
>>
>> Do let me know.
> 
> Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the panda ES to hang.
> 
The hang is definitely due to the bctimer not started. As I said, I assumed it was and
then you corrected saying it is under the flag.

> I am not convinced the culprit is this code you are trying to revert.
> 
fair enough. Thats why I said if you have an alternative fix thats great.

> I will try to reproduce the bug on my board.
> 
Sure...

  reply	other threads:[~2014-05-15 17:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 14:39 [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled Santosh Shilimkar
2014-05-14 15:22 ` Tony Lindgren
2014-05-14 19:44 ` Daniel Lezcano
2014-05-14 19:50   ` Santosh Shilimkar
2014-05-14 20:02     ` Daniel Lezcano
2014-05-14 20:56       ` Tony Lindgren
2014-05-14 23:31         ` Tony Lindgren
2014-05-16  0:13           ` Tony Lindgren
2014-05-16  0:40             ` Tony Lindgren
2014-05-14 21:18       ` Santosh Shilimkar
2014-05-15 17:03         ` Santosh Shilimkar
2014-05-15 17:50           ` Daniel Lezcano
2014-05-15 17:54             ` Santosh Shilimkar [this message]
2014-05-15 18:29               ` Santosh Shilimkar
2014-05-16  0:33                 ` Alex Shi
2014-05-16 13:43                 ` Santosh Shilimkar
2014-05-16 21:29                   ` Tony Lindgren
2014-05-19 16:45                     ` Daniel Lezcano
2014-05-19 17:23                       ` Tony Lindgren
2014-05-19 17:34                         ` Santosh Shilimkar
2014-05-19 17:51                           ` Tony Lindgren
2014-05-19 18:06                             ` Daniel Lezcano
2014-05-19 19:36                               ` Tony Lindgren
2014-05-19 19:45                                 ` Daniel Lezcano
2014-05-19 21:18                                   ` Tobias Jakobi
2014-05-19 22:42                                     ` Tony Lindgren
2014-05-23 14:44                                     ` Tony Lindgren
2014-05-23 18:32                                       ` Tony Lindgren
     [not found]                                         ` <CAKnoXLxj42veWCbRjX98iT3FNAb92J4yR+UAL716JFSOb=pcrQ@mail.gmail.com>
2014-05-27 20:34                                           ` Tony Lindgren
2014-05-27 21:03                                             ` Santosh Shilimkar
2014-05-27 21:06                                               ` Daniel Lezcano
2014-05-19 20:00                                 ` Santosh Shilimkar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5374FF5B.8050702@ti.com \
    --to=santosh.shilimkar@ti$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox