From: Jon Hunter <jon-hunter@ti.com>
To: Franky Lin <frankyl@broadcom.com>
Cc: Kevin Hilman <khilman@ti.com>,
b-cousson@ti.com, tony@atomide.com,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
grant.likely@secretlab.ca, santosh.shilimkar@ti.com,
linux-omap@vger.kernel.org, tarun.kanti@ti.com,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: Panda ES board hang when using GPIO as interrupt
Date: Thu, 28 Jun 2012 17:59:09 -0500 [thread overview]
Message-ID: <4FECE1BD.80906@ti.com> (raw)
In-Reply-To: <4FECE067.7000809@broadcom.com>
On 06/28/2012 05:53 PM, Franky Lin wrote:
> On 06/28/2012 02:55 PM, Jon Hunter wrote:
>> Ok. Any way to manually reset the wlan module to deactivate the gpio
>> when it is hung? I am wondering if the gpio is deactivated if the board
>> comes back to life, indicating it is stuck in the interrupt somewhere.
>
> The only way I can think of is removing the module manually. But it
> didn't bring the board back to live.
>
>> Well, at least that is consistent with what I see, but also perplexing
>> that it takes sometime to fail. Can you try the following as a debug
>> patch to see if it is in the context restore that is the problem. From
>> your testing and bisect, the only possible difference in the current
>> kernel is that it could perform the context restore when acquiring the
>> gpio.
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index c4ed172..a2401bd 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -1341,6 +1341,8 @@ void omap2_gpio_resume_after_idle(void)
>> #if defined(CONFIG_PM_RUNTIME)
>> static void omap_gpio_restore_context(struct gpio_bank *bank)
>> {
>> + return;
>> +
>> __raw_writel(bank->context.wake_en,
>> bank->base + bank->regs->wkup_en);
>> __raw_writel(bank->context.ctrl, bank->base + bank->regs->ctrl);
>>
>
> This one works! It can run more than 20 mins.
Great! I need to dig into the context restore some more.
> I found one interesting thing. When I added the print info to see when
> runtime_suspend/resume get called, it seems like the suspend/resume is
> unbalance during boot. Resume got called more than suspend. So I hack
> the code to make sure suspend and resume are called in pair. A resume
> without suspend will do nothing and return immediately. This also makes
> the hang vanish.
I am not 100% sure I follow. On boot I would expect to see a
resume/suspend due to the probe on the irq bank and then I would expect
to see another resume from the acquisition of the gpio, however, I would
not expect a suspend until the gpio is freed, which I don't believe you
are doing.
Can you share your hack? Just paste the diff? This may help me
understand more.
Thanks
Jon
WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jon-hunter@ti.com>
To: Franky Lin <frankyl@broadcom.com>
Cc: Kevin Hilman <khilman@ti.com>, <b-cousson@ti.com>,
<tony@atomide.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
<grant.likely@secretlab.ca>, <santosh.shilimkar@ti.com>,
<linux-omap@vger.kernel.org>, <tarun.kanti@ti.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: Panda ES board hang when using GPIO as interrupt
Date: Thu, 28 Jun 2012 17:59:09 -0500 [thread overview]
Message-ID: <4FECE1BD.80906@ti.com> (raw)
In-Reply-To: <4FECE067.7000809@broadcom.com>
On 06/28/2012 05:53 PM, Franky Lin wrote:
> On 06/28/2012 02:55 PM, Jon Hunter wrote:
>> Ok. Any way to manually reset the wlan module to deactivate the gpio
>> when it is hung? I am wondering if the gpio is deactivated if the board
>> comes back to life, indicating it is stuck in the interrupt somewhere.
>
> The only way I can think of is removing the module manually. But it
> didn't bring the board back to live.
>
>> Well, at least that is consistent with what I see, but also perplexing
>> that it takes sometime to fail. Can you try the following as a debug
>> patch to see if it is in the context restore that is the problem. From
>> your testing and bisect, the only possible difference in the current
>> kernel is that it could perform the context restore when acquiring the
>> gpio.
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index c4ed172..a2401bd 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -1341,6 +1341,8 @@ void omap2_gpio_resume_after_idle(void)
>> #if defined(CONFIG_PM_RUNTIME)
>> static void omap_gpio_restore_context(struct gpio_bank *bank)
>> {
>> + return;
>> +
>> __raw_writel(bank->context.wake_en,
>> bank->base + bank->regs->wkup_en);
>> __raw_writel(bank->context.ctrl, bank->base + bank->regs->ctrl);
>>
>
> This one works! It can run more than 20 mins.
Great! I need to dig into the context restore some more.
> I found one interesting thing. When I added the print info to see when
> runtime_suspend/resume get called, it seems like the suspend/resume is
> unbalance during boot. Resume got called more than suspend. So I hack
> the code to make sure suspend and resume are called in pair. A resume
> without suspend will do nothing and return immediately. This also makes
> the hang vanish.
I am not 100% sure I follow. On boot I would expect to see a
resume/suspend due to the probe on the irq bank and then I would expect
to see another resume from the acquisition of the gpio, however, I would
not expect a suspend until the gpio is freed, which I don't believe you
are doing.
Can you share your hack? Just paste the diff? This may help me
understand more.
Thanks
Jon
WARNING: multiple messages have this Message-ID (diff)
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: Panda ES board hang when using GPIO as interrupt
Date: Thu, 28 Jun 2012 17:59:09 -0500 [thread overview]
Message-ID: <4FECE1BD.80906@ti.com> (raw)
In-Reply-To: <4FECE067.7000809@broadcom.com>
On 06/28/2012 05:53 PM, Franky Lin wrote:
> On 06/28/2012 02:55 PM, Jon Hunter wrote:
>> Ok. Any way to manually reset the wlan module to deactivate the gpio
>> when it is hung? I am wondering if the gpio is deactivated if the board
>> comes back to life, indicating it is stuck in the interrupt somewhere.
>
> The only way I can think of is removing the module manually. But it
> didn't bring the board back to live.
>
>> Well, at least that is consistent with what I see, but also perplexing
>> that it takes sometime to fail. Can you try the following as a debug
>> patch to see if it is in the context restore that is the problem. From
>> your testing and bisect, the only possible difference in the current
>> kernel is that it could perform the context restore when acquiring the
>> gpio.
>>
>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> index c4ed172..a2401bd 100644
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -1341,6 +1341,8 @@ void omap2_gpio_resume_after_idle(void)
>> #if defined(CONFIG_PM_RUNTIME)
>> static void omap_gpio_restore_context(struct gpio_bank *bank)
>> {
>> + return;
>> +
>> __raw_writel(bank->context.wake_en,
>> bank->base + bank->regs->wkup_en);
>> __raw_writel(bank->context.ctrl, bank->base + bank->regs->ctrl);
>>
>
> This one works! It can run more than 20 mins.
Great! I need to dig into the context restore some more.
> I found one interesting thing. When I added the print info to see when
> runtime_suspend/resume get called, it seems like the suspend/resume is
> unbalance during boot. Resume got called more than suspend. So I hack
> the code to make sure suspend and resume are called in pair. A resume
> without suspend will do nothing and return immediately. This also makes
> the hang vanish.
I am not 100% sure I follow. On boot I would expect to see a
resume/suspend due to the probe on the irq bank and then I would expect
to see another resume from the acquisition of the gpio, however, I would
not expect a suspend until the gpio is freed, which I don't believe you
are doing.
Can you share your hack? Just paste the diff? This may help me
understand more.
Thanks
Jon
next prev parent reply other threads:[~2012-06-28 22:59 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-25 20:52 Panda ES board hang when using GPIO as interrupt Franky Lin
2012-06-25 20:52 ` Franky Lin
2012-06-25 20:52 ` Franky Lin
2012-06-26 7:21 ` DebBarma, Tarun Kanti
2012-06-26 7:21 ` DebBarma, Tarun Kanti
[not found] ` <CAC83ZvL2ozQD1DYmtKeFa1PB1pZ1JmBUKFWmDWnbJOCDL3sKNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-06-26 18:20 ` Franky Lin
2012-06-26 18:20 ` Franky Lin
2012-06-26 18:20 ` Franky Lin
2012-06-27 13:29 ` DebBarma, Tarun Kanti
2012-06-27 13:29 ` DebBarma, Tarun Kanti
[not found] ` <4FE8CF77.5080400-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2012-06-27 3:37 ` Kevin Hilman
2012-06-27 3:37 ` Kevin Hilman
2012-06-27 3:37 ` Kevin Hilman
[not found] ` <87txxxs9we.fsf-l0cyMroinI0@public.gmane.org>
2012-06-28 0:41 ` Franky Lin
2012-06-28 0:41 ` Franky Lin
2012-06-28 0:41 ` Franky Lin
2012-06-28 15:42 ` Jon Hunter
2012-06-28 15:42 ` Jon Hunter
2012-06-28 15:42 ` Jon Hunter
2012-06-28 21:24 ` Franky Lin
2012-06-28 21:24 ` Franky Lin
[not found] ` <4FECCB91.7090609-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2012-06-28 21:55 ` Jon Hunter
2012-06-28 21:55 ` Jon Hunter
2012-06-28 21:55 ` Jon Hunter
[not found] ` <4FECD2E5.1060603-l0cyMroinI0@public.gmane.org>
2012-06-28 22:53 ` Franky Lin
2012-06-28 22:53 ` Franky Lin
2012-06-28 22:53 ` Franky Lin
2012-06-28 22:59 ` Jon Hunter [this message]
2012-06-28 22:59 ` Jon Hunter
2012-06-28 22:59 ` Jon Hunter
2012-06-28 23:10 ` Franky Lin
2012-06-28 23:10 ` Franky Lin
[not found] ` <4FECE45E.6040506-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2012-06-28 23:28 ` Jon Hunter
2012-06-28 23:28 ` Jon Hunter
2012-06-28 23:28 ` Jon Hunter
2012-06-28 23:35 ` Jon Hunter
2012-06-28 23:35 ` Jon Hunter
2012-06-28 23:35 ` Jon Hunter
2012-06-28 23:54 ` Jon Hunter
2012-06-28 23:54 ` Jon Hunter
2012-06-28 23:54 ` Jon Hunter
2012-06-29 0:59 ` Franky Lin
2012-06-29 0:59 ` Franky Lin
2012-06-29 4:07 ` DebBarma, Tarun Kanti
2012-06-29 4:07 ` DebBarma, Tarun Kanti
2012-06-29 4:07 ` DebBarma, Tarun Kanti
[not found] ` <CAC83ZvJJw-7Xt4Ey4_OT70D6MGHEfwURYVuj5wYTLe5oYiMuRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-06-29 15:53 ` Jon Hunter
2012-06-29 15:53 ` Jon Hunter
2012-06-29 15:53 ` Jon Hunter
2012-06-27 23:43 ` Jon Hunter
2012-06-27 23:43 ` Jon Hunter
2012-06-27 23:43 ` Jon Hunter
2012-06-28 1:03 ` Franky Lin
2012-06-28 1:03 ` Franky Lin
[not found] ` <4FEBAD7A.5050505-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2012-06-28 15:37 ` Jon Hunter
2012-06-28 15:37 ` Jon Hunter
2012-06-28 15:37 ` Jon Hunter
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=4FECE1BD.80906@ti.com \
--to=jon-hunter@ti.com \
--cc=b-cousson@ti.com \
--cc=frankyl@broadcom.com \
--cc=grant.likely@secretlab.ca \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=santosh.shilimkar@ti.com \
--cc=tarun.kanti@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.