[PATCH 4/9] pinctrl: meson: allow gpio to request irq
khilman at baylibre.com
Wed Oct 26 08:50:06 PDT 2016
Linus Walleij <linus.walleij at linaro.org> writes:
> On Wed, Oct 26, 2016 at 4:22 PM, Jerome Brunet <jbrunet at baylibre.com> wrote:
>> On Tue, 2016-10-25 at 20:20 +0200, Linus Walleij wrote:
>>> However the semantic is such, that it is not necessary to call
>>> before using an IRQ: the irqchip and gpiochip abstractions should be
>> They are orthogonal. You can request an irq from the irqchip controller
>> without the gpiochip, like any other irq controller.
> OK good, sorry if I'm stating the obvious.
>> irq_create_mapping (and irq_create_fwspec_mapping) internally calls
>> irq_find_mapping. So if the mapping already exist (the irq is already
>> used before calling to_irq), the existing mapping will be returned. The
>> mapping will be actually created only if needed. It seems to be in line
>> with your explanation, no ?
> Yes, but you want to call irq_create_mapping() in slowpath (irq setup)
> and irq_find_mapping() in fastpath (irq handler). Else the first IRQ
> may result in unwelcomed surprises.
>> There is really a *lot* of gpio drivers which use irq_create_mapping in
>> the to_irq callback, are these all wrong ?
> Yes they are all wrong. They should all be using irq_find_mapping().
So, dumb question from someone trying (but having a hard time) to follow
and understand the rationale...
If it's wrong enough to completely reject, why are changes still being
merged that are doing it so wrong? (e.g. like this one, just merged
 0eb9f683336d pinctrl: Add IRQ support to STM32 gpios
More information about the linux-amlogic