Pinctrl for can_int interfers with pinctrl of gpio-keys even if pinctrl_can_int is not referenced by a driver

Technical Support
, ,
1

Hi all,

I have added a device tree level on vf-colibri-eval-v3.dtsi to add several gpio keys, but the pin setting of one of the gpio is not the expected one.

I have something like this to manage the buttons (I have only kept the gpio with the issue )

...
        gpio-keys_front {
        	compatible = "gpio-keys";
        	pinctrl-names = "default";
         		pinctrl-0 = <&pinctrl_gpio_keys>;
         		Button1 {
         			label = "Button1";
         			gpios = <&gpio1 11> GPIO_ACTIVE_HIGH>;
          			linux,code = <KEY_1>;
         			debounce-interval = <1>;
         		};
          };  		
...
        pinctrl_gpio_keys: gpio_keys {
         			fsl,pins = <VF610_PAD_PTB21__GPIO_43	0x22cd>;
         		 };

but the GPIO_43 conflict with pinctrl_can_int:

		pinctrl_can_int: can_int {
			fsl,pins = <
				VF610_PAD_PTB21__GPIO_43	0x22ed
			>;
		};

so I have disabled it with:

&dspi1 {
	status = "okay";
	// Remove unused drivers
	/delete-node/can@0;
};

but at the end, when I’m checking the pin setting via cat /sys/kernel/debug/40048000.iomuxc/pinconf-pins | grep PTB21, I get 0x22ed, which is the setting of pinctrl_can_int that is not used by any node …

However if I also delete the pinctrl_can_int group, I get the expected pin setting (0x22cd).

&iomuxc {
	vf610-colibri {

	/delete-node/can_int;
...
        };
};

How is it possible that pinctrl_can_int has an impact on the final setting if it is not referenced by any entry in the device tree file?

Thanks for your help to clarify this strange behavior

2

This is a behavior which is particular to the Vybrid GPIO driver. In Vybrid, the GPIO and pinctrl drivers have some direct dependencies: The direction of the pin is controlled through pinctrl registers. But there is no explicit link between a GPIO and a particular pinctrl setting of a pad where a GPIO is available on… Now when the GPIO driver requests the pinctrl driver to enable the pin the pinctrl driver searches through all pinctrl settings to find the pinctrl register matching the GPIO number (offset). The first pinctrl setting which comes up will be used (see pinctrl-imx.c)…

This is arguable somewhat hacky. However, it emulates the behavior of other SoC, where it is not necessary to explicitly mux a pin before they can be used as GPIO.

In your case, it seems that the mux of pinctrl_can_int appears earlier in the list then your new pinctrl_gpio_keys pinmux. To work around this, just remove (or use delete-node) the can_int pinmux.

3

Deleting the can_int node solve the issue, but now I’m facing a similar issue with DCU pins that I want to use with gpioleds driver.
From my dtb, I set it with:

		pinctrl_gpio_leds: gpioleds {
			fsl,pins = <
				VF610_PAD_PTE21__GPIO_126	0x22e6
			>;
		};

then I disable the DCU to avoid collision:

&iomuxc {
	vf610-colibri {
		/delete-node/dcu0grp_1;
...
         };
};

But at the end, with cat /sys/kernel/debug/40048000.iomuxc/pinctrl/pinconf-pins | grep PTE21, I get:
pin 126 (VF610_PAD_PTE21):0x101902
and no other pingroups are using this pin.

How can I properly set the pin settings?

Regards

4

I think that the mux configuration get applied the pinctrl node need still be assigned to a node ( pinctrl-0 = <&pinctrl_gpio_leds>;).

5

Sorry for the error, I have commented the gpio-leds driver entry.
After the comments are removed, everything gives expected results.

Thanks