All of lore.kernel.org
 help / color / mirror / Atom feed
From: adharmap@codeaurora.org (Abhijeet Dharmapurikar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] GIC: Assign correct flow handler type in set_type callback
Date: Sat, 01 Jan 2011 22:26:58 -0800	[thread overview]
Message-ID: <4D201AB2.7050805@codeaurora.org> (raw)
In-Reply-To: <4D1DB2DD.3020701@codeaurora.org>

On 12/31/2010 02:39 AM, Abhijeet Dharmapurikar wrote:
> On 12/29/2010 10:27 PM, Rabin Vincent wrote:
>> On Thu, Dec 30, 2010 at 10:59 AM, Abhijeet Dharmapurikar
>> <adharmap@codeaurora.org> wrote:
>>> There are some interrupts that are true edge triggered in nature. If not
>>> marked IRQ_PENDING, when disabled, they will be lost.
>>>
>>> Use the set_type callback to assign the correct flow type handler for
>>> shared peripheral interrupts.
>>>
>>> Signed-off-by: Abhijeet Dharmapurikar<adharmap@codeaurora.org>
>>> ---
>>> This came to light when a edge triggered interrupt was supposed to
>>> wakeup the
>>> sytem. The flow handler was set to the default handle_level_irq. On
>>> the resume
>>> path the flow handler was invoked right after the I bit was cleared
>>> but before
>>> each individual interrupts were enabled. This made the
>>> handle_level_irq ignore
>>
>> Why does the flow handler hit when the interrupt is disabled? Have you
>> set
>> IRQF_NOSUSPEND on this interrupt?
>>
> Since GIC doesnt have disable callback it implements lazy disabling. The
> interrupt is only marked IRQ_DISABLED in the descriptor but is not
> masked in the GIC. Hence the interrupt flow handler is hit.
>
> Now that I re-read the code setting IRQF_NO_SUSPEND would fix the issue.

Let me correct myself, IRQF_NO_SUSPEND isnt exactly what I want to do. 
If an interrupt triggers after suspend_device_irqs() is run and before 
the I bit is set in arch_suspend_disable_irqs() the system will handle 
the interrupt but will not abort suspend - check_wakeup_irqs() will 
return 0.

IMO, using handle_edge_irq() for an edge triggered wakeup interrupt 
would be the right way to address the issue.

WARNING: multiple messages have this Message-ID (diff)
From: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
To: Rabin Vincent <rabin@rab.in>
Cc: Daniel Walker <dwalker@codeaurora.org>,
	Russell King <linux@arm.linux.org.uk>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Chao Xie <chao.xie@marvell.com>,
	tglx@linutronix.de
Subject: Re: [PATCH] GIC: Assign correct flow handler type in set_type callback
Date: Sat, 01 Jan 2011 22:26:58 -0800	[thread overview]
Message-ID: <4D201AB2.7050805@codeaurora.org> (raw)
In-Reply-To: <4D1DB2DD.3020701@codeaurora.org>

On 12/31/2010 02:39 AM, Abhijeet Dharmapurikar wrote:
> On 12/29/2010 10:27 PM, Rabin Vincent wrote:
>> On Thu, Dec 30, 2010 at 10:59 AM, Abhijeet Dharmapurikar
>> <adharmap@codeaurora.org> wrote:
>>> There are some interrupts that are true edge triggered in nature. If not
>>> marked IRQ_PENDING, when disabled, they will be lost.
>>>
>>> Use the set_type callback to assign the correct flow type handler for
>>> shared peripheral interrupts.
>>>
>>> Signed-off-by: Abhijeet Dharmapurikar<adharmap@codeaurora.org>
>>> ---
>>> This came to light when a edge triggered interrupt was supposed to
>>> wakeup the
>>> sytem. The flow handler was set to the default handle_level_irq. On
>>> the resume
>>> path the flow handler was invoked right after the I bit was cleared
>>> but before
>>> each individual interrupts were enabled. This made the
>>> handle_level_irq ignore
>>
>> Why does the flow handler hit when the interrupt is disabled? Have you
>> set
>> IRQF_NOSUSPEND on this interrupt?
>>
> Since GIC doesnt have disable callback it implements lazy disabling. The
> interrupt is only marked IRQ_DISABLED in the descriptor but is not
> masked in the GIC. Hence the interrupt flow handler is hit.
>
> Now that I re-read the code setting IRQF_NO_SUSPEND would fix the issue.

Let me correct myself, IRQF_NO_SUSPEND isnt exactly what I want to do. 
If an interrupt triggers after suspend_device_irqs() is run and before 
the I bit is set in arch_suspend_disable_irqs() the system will handle 
the interrupt but will not abort suspend - check_wakeup_irqs() will 
return 0.

IMO, using handle_edge_irq() for an edge triggered wakeup interrupt 
would be the right way to address the issue.


  reply	other threads:[~2011-01-02  6:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-30  5:29 [PATCH] GIC: Assign correct flow handler type in set_type callback Abhijeet Dharmapurikar
2010-12-30  5:29 ` Abhijeet Dharmapurikar
2010-12-30  6:27 ` Rabin Vincent
2010-12-30  6:27   ` Rabin Vincent
2010-12-31 10:39   ` Abhijeet Dharmapurikar
2010-12-31 10:39     ` Abhijeet Dharmapurikar
2011-01-02  6:26     ` Abhijeet Dharmapurikar [this message]
2011-01-02  6:26       ` Abhijeet Dharmapurikar

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=4D201AB2.7050805@codeaurora.org \
    --to=adharmap@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.