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

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Sat, Aug 26, 2017 at 12:45 AM, Davide Hug <d@xxxxxxxxxx> wrote:
> On Tue, 1 Aug 2017 09:37:12 +0200
> Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
>> I'm not so sure about that. You might be the only one with the right hardware
>> to fix the problem. Also it is never our intention to discourage anyone to
>> hack on the kernel.
>
> You are right. I shouldn't give up that quickly.
>
> I have tried a few things and I would like to ask if one of these is an appropriate approach.
> Sorry this is long! If there is a better place for me to ask these, please point me there.
>
> My main question is if "timer based polling" is the way to go, is my
> approach with timers below (3.) appropriate?

...
> 1. Naive approach: just `msleep` long enough.

This is wrong atleastm since msleep() has no guarantees for the
time it sleeps, it's "this amount or more".

> 2. Naive polling: `msleep` repeatedly in a loop and check for the data line to be low each time.

Same problem.

> 3. Polling with timer: use a timer for polling and `wait_event_timeout` to wait for the polling to succeed.

This seems reasonable.

> 4. Fix the irq problem in the current driver by calling `devm_request_irq` and
> `devm_free_irq` instead of just using `disable_irq_nosync` and `enable_irq`,
> to prevent setting as output a gpio requested as irq.

This makes me feel there is something that needs to be fixed.

If IRQs are available we should always try to use them somehow.
I don't remember the discussuin fully, but I guess the timer in (3)
is started in response to an IRQ? That should work fine.

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