[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fd5d4df5-c27c-8328-2d9b-f56c0a8a4d32@arm.com>
Date: Tue, 12 Feb 2019 11:35:06 +0000
From: Marc Zyngier <marc.zyngier@....com>
To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc: Bartosz Golaszewski <bgolaszewski@...libre.com>,
Bartosz Golaszewski <brgl@...ev.pl>,
Linus Walleij <linus.walleij@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-gpio <linux-gpio@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/9] irq/irq_sim: provide irq_sim_fire_type()
On 12/02/2019 11:05, Uwe Kleine-König wrote:
> On Tue, Feb 12, 2019 at 10:27:54AM +0000, Marc Zyngier wrote:
>> On 12/02/2019 09:19, Bartosz Golaszewski wrote:
>>> When userspace wants to monitor GPIO line interrupts, the GPIO
>>> framework requests a threaded interrupt with IRQF_TRIGGER_FALLING,
>>> IRQF_TRIGGER_RISING or both. The testing module tries to act like real
>>> hardware and so if we pass only one of the *_TRIGGER_* flags, we want
>>> the simulated interrupt of corresponding type to be fired.
>>
>> Well, that's not how HW works.
>
> I cannot follow. I agree with Bartosz here. If you configure your SoC's
> irq-controller to only fire on a raising edge, you don't get an event
> when the line falls.
I was a bit quick here. It is more the fact that level gets treated as
"just another type of edge" that really irritated me (yes, I've wasted
way too much time implementing interrupt controllers).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists