Re: RFC: Extension to External Interrupt API


Maureen Helm
 

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Monday, September 19, 2016 3:31 PM
To: Iván Briano <ivan.briano(a)intel.com>
Cc: vinayak.kariappa.chettimada(a)nordicsemi.no; Boie, Andrew P
<andrew.p.boie(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: RFC: Extension to External Interrupt API

On Mon, Sep 19, 2016 at 04:34:07PM -0300, Iván Briano wrote:
On Mon, 19 Sep 2016 19:07:12 +0000, Boie, Andrew P wrote:
On Fri, 2016-09-16 at 04:52 +0000, Vinayak Kariappa Chettimada wrote:
Hi,

Welcome your valuable comments on the proposed extension to
External Interrupt API.

*irq_enable_keep*
https://gerrit.zephyrproject.org/r/#/c/4676/1
https://gerrit.zephyrproject.org/r/#/c/4677/1
Originally Vinayak sent a patch to change ARM's irq_enable() not to
unpend any pending interrupts when enabling the channel. It was -1
as we didn't want to change the semantics of the kernel API to
preserve compatibility.

However, on further inspection of other arches, this behavior seems
to be peculiar to ARM.

On x86, for example, enabling an IRQ in the IOAPIC or MVIC just
clears the IOAPIC_INT_MASK (bit 16) in the appropriate IOREDTBL
entry. It doesn't clear pending interrupts on that line. Indeed, if
it did, the rate-limiting in the IPM console driver wouldn't work.

On ARC, similarly it puts the IRQ line into the _ARC_V2_IRQ_SELECT
register, and then writes to the _ARC_V2_IRQ_ENABLE register to
enable/disable it. I don't see anything in the datasheet that
un-pends any pending interrupts.

I think at this point we could consider ARM's behavior of clearing
pending interrupts on irq_enable() a bug and we should change it,
making irq_enable_keep() unnecessary. Does this sound good to
everyone?

Sounds reasonable to me.
Put like that, it's probably the right thing to do.
Sounds ok to me. Thanks for digging into the other arches Andrew.

Join devel@lists.zephyrproject.org to automatically receive all group messages.