Re: Using a GPIO as an interrupt line

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Tue, Nov 19, 2019 at 11:46:21AM +0100, Marc Gonzalez wrote:
> On 19/11/2019 10:57, Russell King - ARM Linux admin wrote:
> 
> > On Tue, Nov 19, 2019 at 10:28:15AM +0100, Marc Gonzalez wrote:
> > 
> >> The board I'm working on provides a TCA9539 I/O expander.
> >> Or, as the datasheet(*) calls it, a "Low Voltage 16-Bit I2C and
> >> SMBus Low-Power I/O Expander with Interrupt Output, Reset Pin,
> >> and Configuration Registers"
> >>
> >> (*) http://www.ti.com/lit/ds/symlink/tca9539.pdf
> >>
> >> The binding is documented in Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> >>
> >> I have some doubts about the interrupt output, described as:
> >>
> >> Optional properties:
> >>  - interrupts: interrupt specifier for the device's interrupt output.
> >>
> >> In my board's DT, the I/O expander is described as:
> >>
> >> 	exp1: gpio@74 {
> >> 		compatible = "ti,tca9539";
> >> 		reg = <0x74>;
> >> 		gpio-controller;
> >> 		#gpio-cells = <2>;
> >> 		reset-gpios = <&tlmm 96 GPIO_ACTIVE_LOW>;
> >> 		pinctrl-names = "default";
> >> 		pinctrl-0 = <&top_exp_rst>;
> >> 		interrupt-parent = <&tlmm>;
> >> 		interrupts = <42 IRQ_TYPE_LEVEL_HIGH>;
> 
> As pointed out by ukleinek on IRC, I might have (??) specified the wrong
> trigger type. The data-sheet states:
> "The TCA9539 open-drain interrupt (INTn) output is activated when any input state
> differs from its corresponding Input Port register state, and is used to indicate
> to the system master that an input state has changed."
> (The data sheet speaks of "INT with a line on top"; what is the typical way to
> write that in ASCII? I was told that adding a trailing 'n' or 'b' was common.)

/INT or nINT are commonly used - I've never heard or seen 'b' (which is
commonly used as a suffix on binary numbers) or a trailing 'n'.

> According to that description, it looks like IRQ_TYPE_LEVEL_LOW?

Yes.

> > This specifies an interrupt signal, number 42, on the tlmm interrupt
> > controller. It isn't a GPIO specification. Not every interrupt is a
> > GPIO, and some SoCs can have dedicated interrupt pins that are
> > exactly that.
> > 
> > Hence, needlessly limiting an external device to requiring a GPIO for
> > its interrupt is detrimental.
> 
> That makes complete sense.
> 
> IIUC, what is missing in my DT spec is defining pin 42 as a GPIO pin.
> Looking more closely at top_exp_rst:
> 
> 	top_exp_rst: top_exp_rst {
> 		mux {
> 			pins = "gpio96";
> 			function = "gpio";
> 		};
> 
> 		config {
> 			pins = "gpio96";
> 			drive-strength = <2>;
> 			bias-pull-down;
> 		};
> 	};
> 
> IIUC, this defines pin 96 as a GPIO pin (as well as defining some low-level
> properties of the pin). Likely I need something similar for pin 42?

Is pin 42 something that can be muxed?  If so, it seems sane to specify
configuration for it.  Whether it needs to be a GPIO or whether it has
a specific "interrupt" function mux state depends on the SoC.

For example, on the LX2160A, there are a bunch of pins that can be muxed
as one of:
- gpio
- interrupt
- something else

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up