Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs

[Gerlando Falauto]

Hi Stephan,

On 11/11/2013 07:53 PM, Stephen Warren wrote:
> On 11/11/2013 11:28 AM, Gerlando Falauto wrote:
> > Hi everyone,
> >
> > [jumping in on an old discussion]
> >
> > On 09/09/2013 06:19 PM, Mark Brown wrote:
> > > On Wed, Sep 04, 2013 at 02:16:36PM -0600, Stephen Warren wrote:
> > > > On 09/04/2013 03:05 AM, Lars Poeschel wrote:
> > >
> > > > > The driver that tries to use the GPIO requested by this patch before
> > > > > HAS to
> > > > > fail. This is exactly the intention of this patch. We don't want the
> > > > > GPIO to
> > > > > be requested any more, if it is used as an interrupt pin.
> > >
> > > > That will break existing drivers. There are drivers that request the
> > > > same GPIO and IRQ. IIRC, the SDHCI CD (Card Detect) GPIO is requested
> > > > that way.
> > >
> > > Yes, plus input devices and audio jack detection among others.  This
> > > pattern is very common if the GPIO is actually being used as a GPIO, an
> > > edge triggered interrupt is used to flag when something happens and the
> > > state is determined by reading the GPIO state (often with some
> > > debounce).
> >
> > I actually came across this thread while looking for an answer to the
> > following (apparently trivial) question:
> >
> > If you were to write a new driver & binding, what would be, in general,
> > the recommended DT binding for a cascade interrupt controller (or any
> > other peripheral, for that matter), which is connected through a GPIO
> > (to be used as IRQ)?
> >
> > a) Through gpios = <&gpio0 N>
> > b) through interrupt-parent = <&gpio0> & interrupts <N
> > IRQ_TYPE_LEVEL_LOW>, or
> > c) both?
>
> (b) alone.
>
>  From the perspective of the child interrupt controller, its output is
> purely an interrupt. The fact that the parent interrupt controller could
> use that pin as a GPIO in some other context (e.g. on a different board)
> isn't something that the child interrupt controller should know/care about.

Thanks for your answer. So it should be the parent driver to proactively 
configure the GPIO as input, active high etc..., when an IRQ for its 
GPIOs is requested, right?

Moving to a different target (actually Mark's original point), i.e. a 
generic device which is connected through a GPIO, using the IRQ to 
trigger an event, what would be the recommended way?

Thanks again!
Gerlando
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/