[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkda5QuuEJhMwSjJb-pqkKQsn6YpCysDLTx17__meZC52XQ@mail.gmail.com>
Date: Fri, 5 Jul 2019 23:46:02 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Michael.Wu@...ics.com
Cc: Bartosz Golaszewski <bgolaszewski@...libre.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
mvp.kutali@...il.com
Subject: Re: [PATCH] gpiolib: fix incorrect IRQ requesting of an active-low lineevent
On Fri, Jul 5, 2019 at 12:35 PM <Michael.Wu@...ics.com> wrote:
> For example, there is a button which drives level to be low when it is pushed, and drivers level to be high when it is released.
> We want to catch the event when the button is pushed.
>
> In user space we configure a line event with the following code:
>
> req.handleflags = GPIOHANDLE_REQUEST_INPUT;
> req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
But *THIS* is the case that should have
GPIOHANDLE_REQUEST_ACTIVE_LOW, because you push
the button to activate it (it is inactive when not pushed).
Also this should have GPIOEVENT_REQUEST_RISING_EDGE.
> Run the same logic on another board which the polarity of the button is inverted. The button drives level to be high when it is pushed.
> For the inverted level case, we have to add flag GPIOHANDLE_REQUEST_ACTIVE_LOW:
>
> req.handleflags = GPIOHANDLE_REQUEST_INPUT | GPIOHANDLE_REQUEST_ACTIVE_LOW;
> req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
This one should not be active low.
And also have GPIOEVENT_REQUEST_RISING_EDGE.
However I agree that the semantic should change as in the
patch, it makes most logical sense.
The reason it looks as it does is because GPIO line values
and interrupts are two separate subsystems inside the kernel
with their own flags (as you've seen).
But you are right, userspace has no idea about that and should
not have to care.
Yours,
Linus Walleij
Powered by blists - more mailing lists