Re: Should irq_enable/disable be flagging/unflagging gpio lines used as irq?

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Nov 20, 2017 at 11:48 PM, Davide Hug <d@xxxxxxxxxx> wrote:

> I'm really sorry that I come back to this only now.

Business as usual. We are all creative people with lots to do, do
not worry.

> Do I understand this correctly? Some GPIO drivers can be slow and sleep, and
> .irq_enable/disable can be called from places where this is not acceptable.

That is the essence of it I guess.

> (I see that only gpio/gpio-pcf857x implements .irq_enable/disable and has
> .can_sleep=true)

The crucial thing is  that PCF857x is an I2C expander GPIO chip.

I2C traffic is blocking, so cannot be called in IRQ context.

As long as the .irq_enable/.irq_disable callbacks does not
start to issue something blocking, like I2C traffic, e.g. reading
and writing registers in the chip, all is fine.

>> Maybe we should do it in .irq_enable()/.irq_disable() in case
>> the .can_sleep bool on the gpiochip is not set, simply?
>> This way the irqchip should be able to lock/unlock the GPIO
>> lines dynamically.
>
> So, before a driver relays on locking/unlocking a GPIO line dynamically, the
> driver would have to make sure that the GPIO has not .can_sleep=true. Right?

Something like that. I suspect you know it better than me
by now, I am rusty all the time on details.

I also changed the accessor gpiod_set/get_raw_value() so these
will work even if the line is used for IRQ. These are really violent
accessors, but they have their place.

Please check if that is something that would help your
usecase before venturing to deep into the infrastructure.

> With a default .irq_enable/disable implementation in gpiolib (something as in
> the patch below) the GPIO driver implementing their own .irq_enable/disable
> would have to be fixed, right?

Yeah. But I don't know if the solution is very good, because
it duct-tapes on a solution that will only work if the gpiochip is
non-sleeping. The driver will simply fail randomly on
sleeping cpiochips which is not what we want, we want GPIOs
and their IRQs to uniformly behave the same no matter
which GPIO driver and consumer combo we make.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html