imx93 - GPIO blocked (or no more reachable)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

imx93 - GPIO blocked (or no more reachable)

1,294 Views
patrick_agrain
Contributor I

Hello,

Our custom board is based on the IMX93-11x11-EVK board. All our GPIO are located on gpiochip0.

These GPIO may be:

- Interrupt inputs (managed by linux drivers).

- Reset outputs (mostly managed by Linux drivers).

- One is intended to drive a LED (managed with the gpio-leds linux driver).

- Inputs reflecting static information (managed by a proprietary linux driver)

- 'Isolated' (not managed by drivers and intended to be used through libgpiod).

SW context:

- The board is running a Rocky 9 linux.

- libgpiod(-utils) are picked up from Rocky repository (package version is 1.6.3).

What we observed:

- We connect manually the timer trigger to GPIO LED (see cpu below) and let it run. It blinks at a 1s rate.

- As soon as we handle the 'isolated GPIO' with gpioset, the LED stops blinking and there is no way to bring it back to work (either with a trigger or by using the brightness input from sysfs).

- This is only valid for 'isolated' GPIO. GPIOs handled by Linux drivers are still working as expected.

Additional tests:

- HW people were able to connect another LED on the BOOT_MODE1 pin belonging to gpiochip 3 (see test below). This pin was declared in the same way as the GPIO LED. The same test was performed, this time successfully. Handling the isolated GPIO with gpioset has no influence on the other GPIO.

- I patched the kernel to be able to get the deprecated /sys/class/gpio inputs. When handling the 'isolated' GPIO that way (export, direction, value), I observed the same behavior: the cpu LED stops blinking and we have no more access to it. The test LED is still blinking.

Has anybody already faced that behavior ?

Any information will be appreciated.

Thanks.

Best regards,

Patrick Agrain

Our GPIO in the device tree:

'isolated': eps-resetn-gpios = <&gpio2 0x5 0x1>;

LED:

leds {
compatible = "gpio-leds";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_leds>;

cpu {
gpios = <&gpio2 0x4 GPIO_ACTIVE_LOW>;
label = "CPUgreen";
default-state = "off";
linux,default-trigger = "none";
};

test {
gpios = <&gpio1 0x7 GPIO_ACTIVE_LOW>;
label = "CPUtest";
default-state = "off";
linux,default-trigger = "none";
};
};

Labels (2)
0 Kudos
Reply
3 Replies

1,256 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi

Please kindly note that when you use gpioset line, it requests exclusive ownership of that line from kernel. for imx93 gpiochip0 controller, it may affect the entire bank.

The LED on gpiochip3 is on a different GPIO controller, so using gpioset on gpiochip0 doesn't affect it.

 

Regards

Daniel

0 Kudos
Reply

1,251 Views
patrick_agrain
Contributor I

Hello Daniel,

Thanks for pointing out that.

Does it mean that we should avoid mixing kernel-driven GPIO and userspace-driven GPIO on the same GPIO controller ?

Best regards,

Patrick Agrain

0 Kudos
Reply

1,197 Views
danielchen
NXP TechSupport
NXP TechSupport

YES

0 Kudos
Reply