Re: Using a GPIO as an interrupt line

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Marc,

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.)

Or a # as pre- or suffix ... (Didn't know about 'b')

> According to that description, it looks like IRQ_TYPE_LEVEL_LOW?
> (Weird, because it worked well with IRQ_TYPE_LEVEL_HIGH.)
> 
> > 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?

Having a pin configured as GPIO is the boot default setting for many
SoCs/pins. So you might get away with not specifying a setting for pin
42, but that's not as robust as configuring that explicitly.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux