On Tue, Jan 14, 2025 at 01:28:32PM +0100, Linus Walleij wrote:
On Mon, Jan 6, 2025 at 8:02 AM Dmitry Torokhov
[off-list ref] wrote:
quoted
On Thu, Jan 02, 2025 at 10:32:00PM +0100, Linus Walleij wrote:
quoted
On Thu, Jan 2, 2025 at 7:20 PM Aaro Koskinen [off-list ref] wrote:
quoted
The GPIO is set up as an IRQ, so request it as non-exclusive. Otherwise the
probe fails on Nokia 770 with:
ads7846 spi2.0: failed to request pendown GPIO
ads7846: probe of spi2.0 failed with error -16
Also the polarity is wrong. Fix it.
Fixes: 767d83361aaa ("Input: ads7846 - Convert to use software nodes")
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reviewed-by: Linus Walleij <redacted>
Do we need to have this knowledge in the driver or can it be handled
in GPIO subsystem or affected board support? Requesting a GPIO with "in"
direction when it is also an interrupt source should be pretty common.
Hm I don't know exactly the question here but I try to answer
anyway :)
The patch makes the boardfile describe the polarity but the
boardfile (or device tree) cannot define directions, consumers
must specify this. The main reason is that actual users exist that
switch the direction of GPIOs at runtime so this has been designed
as a (runtime) consumer duty.
As for GPIOD_FLAGS_BIT_NONEXCLUSIVE, this enables the
GPIO subsystem to read the GPIO while the irqchip subsystem
can also handle the same GPIO line as an interrupt source, so
it's not exclusive to either subsystem.
But isn't this something that should work by default, without specifying
any additional flags? I understand that using GPIO as an interrupt
source and at the same time as an output line is not possible (without
reconfiguration "on the fly"), but reading state if an input GPIO line
that is also an interrupt should be OK? I am pretty sure there are
systems/boards/arches that allow this.
This is my objection - we have to add a flag to a driver that is used on
multiple systems to tweak behavior of one particular board.
Thanks.
--
Dmitry