[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z4bcXx9LjmHQ0EuP@google.com>
Date: Tue, 14 Jan 2025 13:51:27 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Aaro Koskinen <aaro.koskinen@....fi>, Helge Deller <deller@....de>,
Janusz Krzysztofik <jmkrzyszt@...il.com>,
Tony Lindgren <tony@...mide.com>, linux-fbdev@...r.kernel.org,
linux-omap@...r.kernel.org, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] Input: ads7846 - fix up the pendown GPIO setup on
Nokia 770
On Tue, Jan 14, 2025 at 01:28:32PM +0100, Linus Walleij wrote:
> On Mon, Jan 6, 2025 at 8:02 AM Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> > On Thu, Jan 02, 2025 at 10:32:00PM +0100, Linus Walleij wrote:
> > > On Thu, Jan 2, 2025 at 7:20 PM Aaro Koskinen <aaro.koskinen@....fi> wrote:
> > >
> > > > 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@....fi>
> > >
> > > Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
> >
> > 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
Powered by blists - more mailing lists