- RFC: Extension to External Interrupt API
Re: RFC: Extension to External Interrupt API
toggle quoted messageShow quoted text
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
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:everyone?
On Fri, 2016-09-16 at 04:52 +0000, Vinayak Kariappa Chettimada wrote:
Hi,Originally Vinayak sent a patch to change ARM's irq_enable() not to
Welcome your valuable comments on the proposed extension to
External Interrupt API.
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
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
Put like that, it's probably the right thing to do.
Sounds reasonable to me.
Sounds ok to me. Thanks for digging into the other arches Andrew.
Join email@example.com to automatically receive all group messages.