Update the MCP23017 overlay to support using multiple devices with repeated calls

[Dloranger]

Describe the bug
Currently the overlay only supports 1 chipset, but the device is capable of having 8 on the bus with only an address change (pin setting) and using a new gpio pin for the int pin.

Can we upgrade this dtbo to be able to use the address field to make each call unique to be able to load from 2-8 chipsets with multiple calls to the dtbo?

This would greatly simplify my development workflow by allowing me to use stock dtbo calls rather than having to recompile custom dtbo regularly.

To reproduce
call the mcp23017 overlay 2x, only the last one is used.

Expected behaviour
call the overlay 2-8x and all 2-8 devices would be loaded as unique devices.

Actual behaviour
Only 1 device gets loaded

System
this is an issue that has persisted due to the implementation of the overlay, not specific to any particular version of code or hardware.

[6by9]

I suspect the issue is the collision in the name mcp23017_pins to describe the interrupt GPIO.
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/overlays/mcp23017-overlay.dts

The interrupt GPIO is optional, so one could remove it and the mcp23017_pins fragment. Making it an overlay option to remove it would require someone with more DT overlay knowledge than me....

[6by9]

Having said that, I think that falls out easily.

// Definitions for MCP23017 Gpio Extender from Microchip Semiconductor

/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2835";

	fragment@0 {
		target = <&i2c1>;
		__overlay__ {
			status = "okay";
		};
	};

	fragment@1 {
		target = <&gpio>;
		__overlay__ {
			mcp23017_pins: mcp23017_pins {
				brcm,pins = <4>;
				brcm,function = <0>;
			};
		};
	};

	fragment@2 {
		target = <&i2c1>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;

			mcp23017: mcp@20 {
				compatible = "microchip,mcp23017";
				reg = <0x20>;
				gpio-controller;
				#gpio-cells = <2>;

				status = "okay";
			};
		};
	};

	fragment@3 {
		target = <&mcp23017>;
		__dormant__ {
			compatible = "microchip,mcp23008";
		};
	};

	fragment@4 {
		target = <&mcp23017>;
		__overlay__ {
			#interrupt-cells=<2>;
			interrupt-parent = <&gpio>;
			interrupts = <4 2>;
			interrupt-controller;
			microchip,irq-mirror;
		};
	};

	__overrides__ {
		gpiopin = <&mcp23017_pins>,"brcm,pins:0",
				<&mcp23017>,"interrupts:0";
		addr = <&mcp23017>,"reg:0";
		mcp23008 = <0>,"=3";
		noints = <0>,"!1!4";
	};
};

Save that as mcp23017-overlay.dts
Run dtc -@ -I dts -O dtb -o mcp23017.dtbo mcp23017-overlay.dts
sudo cp mcp23017.dtbo /boot/overlays/
Edit your config.txt lines to read dtoverlay=mcp23017,addr=0x20,noints=1 or similar.
Reboot.
Report back (I don't have any mcp23017's to hand, but it seems to set up the DT nodes that I'd expect).

[pelwell]

There is a better way - renaming the _pins node using the address:

		__overlay__ {
			mcp23017_pins: mcp23017_pins@20 {
				brcm,pins = <4>;
				brcm,function = <0>;
...
		addr = <&mcp23017>,"reg:0", <&mcp23017_pins>,"reg:0";

[6by9]

Too much magic seeing as mcp23017_pins doesn't have a reg field! :-S

If tweaking the overlay then adding the option of not having to allocate an interrupt line has some uses, eg if you only want it for lots of outputs.

[pelwell]

Nah - it's just sufficiently advanced technology.

But yes, if the device can function without an interrupt line then we can make it an option.

[6by9]

Well I tried with the commits on https://github.com/6by9/linux/tree/3207.
Renaming the mcp23017_pins node works, but having moved the interrupt block out of the fragment 2 the interrupts node doesn't get updated. Leave that bit for tomorrow.

[ghost]

But yes, if the device can function without an interrupt line then we can make it an option.

The MCP23017 can certainly function without an interrupt. I've got an Adafruit i2c 16x2 RGB LCD Pi Plate that doesn't even have the two interrupt lines connected (which is a bit annoying as you have to poll the buttons).

[Dloranger]

I am understanding the interrupts are broken anyways based on some work by a co-developer (MyTechGuyRI) a while back, and another in the thread so this might be opportune time to get that all cleaned up as well? https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=104638&sid=a7b45465cf3346699e24feb073c2ccd6&start=50 See the tail messages of the thread for his use case Even when subscribing to the interrupts, nothing gets triggered from what was encountered at the time. I have a similar situation where I monitor the interrupts for triage and have noticed the interrupt signals never increment either unless something is fundamentally broken (like int pin is not pulled up, or in my current issue, mismapped). I need to come back to this following issue, but this will hopefully help with that one as well. https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=246985 I can make hardware with 2 of these devices available on the network for poking and testing if needed, just PM me so I can share the credentials. The one with 3 chips has a power up problem so its not good for debugging as you can't reboot it.

…

On Thu, Sep 5, 2019, 12:49 PM andrum99 ***@***.***> wrote: But yes, if the device can function without an interrupt line then we can make it an option. The MCP23017 can certainly function without an interrupt. I've got an Adafruit 12c 16x2 RGB LCD Pi Plate that doesn't even have the two interrupt lines connected (which is a bit annoying as you have to poll the buttons). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3207?email_source=notifications&email_token=ACPI3DIUOTQHO7DS2FCRRSLQIFPFVA5CNFSM4IT7EMZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6AQ2OA#issuecomment-528551224>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPI3DKDLKSOJQ6AD4U2Z7DQIFPFVANCNFSM4IT7EMZQ> .

[pelwell]

I don't have the time to debug an MCP23017 interrupt problem. You can open a separate issue to record the problem, but don't expect it to get much attention for the foreseeable future.

[6by9]

I was hooking up an MCP23017 to see what it did and confirm that disabling the interrupts works.

Reading that thread, it looks like it's an issue of trying to claim the interrupt for the interrupt GPIO from the MCP23017, rather than registering for interrupts off the individual pins of the MCP23017.
I also note from the readme on https://github.com/mytechguyri/dtmfdecoder/

The interrupt driven version has been merged into the master branch now that interrupts are functioning correctly.

There's messing setting a pullup on the interrupt GPIO pin though. That should be handled by the dtoverlay (or on the external board).

There is a minor difference between the DT example bindings and our config on the int pin.
Our usage is
interrupts = <4 2>; https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/overlays/mcp23017-overlay.dts#L39 (2 would appear to be IRQ_TYPE_EDGE_FALLING)
The example:
interrupts = <17 IRQ_TYPE_LEVEL_LOW>; https://github.com/raspberrypi/linux/blob/rpi-4.19.y/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt#L74
Understanding whether that is an issue or not would be some serious datasheet reading.

[pelwell]

Fixed by #3211 .

[JamesH65]

Closing this issue as questions answered/issue resolved.