<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>i.MX Processorsのトピックimx93 - GPIO blocked (or no more reachable)</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/imx93-GPIO-blocked-or-no-more-reachable/m-p/2113426#M238031</link>
    <description>&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;Our custom board is based on the IMX93-11x11-EVK board. All our GPIO are located on gpiochip0.&lt;/P&gt;&lt;P&gt;These GPIO may be:&lt;/P&gt;&lt;P&gt;- Interrupt inputs (managed by linux drivers).&lt;/P&gt;&lt;P&gt;- Reset outputs (mostly managed by Linux drivers).&lt;/P&gt;&lt;P&gt;- One is intended to drive a LED (managed with the gpio-leds linux driver).&lt;/P&gt;&lt;P&gt;- Inputs reflecting static information (managed by a proprietary linux driver)&lt;/P&gt;&lt;P&gt;- 'Isolated' (not managed by drivers and intended to be used through libgpiod).&lt;/P&gt;&lt;P&gt;SW context:&lt;/P&gt;&lt;P&gt;- The board is running a Rocky 9 linux.&lt;/P&gt;&lt;P&gt;- libgpiod(-utils) are picked up from Rocky repository (package version is 1.6.3).&lt;/P&gt;&lt;P&gt;What we observed:&lt;/P&gt;&lt;P&gt;- We connect manually the timer trigger to GPIO LED (see cpu below) and let it run. It blinks at a 1s rate.&lt;/P&gt;&lt;P&gt;- 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).&lt;/P&gt;&lt;P&gt;- This is only valid for 'isolated' GPIO. GPIOs handled by Linux drivers are still working as expected.&lt;/P&gt;&lt;P&gt;Additional tests:&lt;/P&gt;&lt;P&gt;- 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.&lt;/P&gt;&lt;P&gt;- 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.&lt;/P&gt;&lt;P&gt;Has anybody already faced that behavior ?&lt;/P&gt;&lt;P&gt;Any information will be appreciated.&lt;/P&gt;&lt;P&gt;Thanks.&lt;/P&gt;&lt;P&gt;Best regards,&lt;/P&gt;&lt;P&gt;Patrick Agrain&lt;/P&gt;&lt;P&gt;Our GPIO in the device tree:&lt;/P&gt;&lt;P&gt;'isolated': eps-resetn-gpios = &amp;lt;&amp;amp;gpio2 0x5 0x1&amp;gt;;&lt;/P&gt;&lt;P&gt;LED:&lt;/P&gt;&lt;P&gt;leds {&lt;BR /&gt;compatible = "gpio-leds";&lt;BR /&gt;pinctrl-names = "default";&lt;BR /&gt;pinctrl-0 = &amp;lt;&amp;amp;pinctrl_leds&amp;gt;;&lt;/P&gt;&lt;P&gt;cpu {&lt;BR /&gt;gpios = &amp;lt;&amp;amp;gpio2 0x4 GPIO_ACTIVE_LOW&amp;gt;;&lt;BR /&gt;label = "CPUgreen";&lt;BR /&gt;default-state = "off";&lt;BR /&gt;linux,default-trigger = "none";&lt;BR /&gt;};&lt;/P&gt;&lt;P&gt;test {&lt;BR /&gt;gpios = &amp;lt;&amp;amp;gpio1 0x7 GPIO_ACTIVE_LOW&amp;gt;;&lt;BR /&gt;label = "CPUtest";&lt;BR /&gt;default-state = "off";&lt;BR /&gt;linux,default-trigger = "none";&lt;BR /&gt;};&lt;BR /&gt;};&lt;/P&gt;</description>
    <pubDate>Tue, 10 Jun 2025 08:23:50 GMT</pubDate>
    <dc:creator>patrick_agrain</dc:creator>
    <dc:date>2025-06-10T08:23:50Z</dc:date>
    <item>
      <title>imx93 - GPIO blocked (or no more reachable)</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/imx93-GPIO-blocked-or-no-more-reachable/m-p/2113426#M238031</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;Our custom board is based on the IMX93-11x11-EVK board. All our GPIO are located on gpiochip0.&lt;/P&gt;&lt;P&gt;These GPIO may be:&lt;/P&gt;&lt;P&gt;- Interrupt inputs (managed by linux drivers).&lt;/P&gt;&lt;P&gt;- Reset outputs (mostly managed by Linux drivers).&lt;/P&gt;&lt;P&gt;- One is intended to drive a LED (managed with the gpio-leds linux driver).&lt;/P&gt;&lt;P&gt;- Inputs reflecting static information (managed by a proprietary linux driver)&lt;/P&gt;&lt;P&gt;- 'Isolated' (not managed by drivers and intended to be used through libgpiod).&lt;/P&gt;&lt;P&gt;SW context:&lt;/P&gt;&lt;P&gt;- The board is running a Rocky 9 linux.&lt;/P&gt;&lt;P&gt;- libgpiod(-utils) are picked up from Rocky repository (package version is 1.6.3).&lt;/P&gt;&lt;P&gt;What we observed:&lt;/P&gt;&lt;P&gt;- We connect manually the timer trigger to GPIO LED (see cpu below) and let it run. It blinks at a 1s rate.&lt;/P&gt;&lt;P&gt;- 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).&lt;/P&gt;&lt;P&gt;- This is only valid for 'isolated' GPIO. GPIOs handled by Linux drivers are still working as expected.&lt;/P&gt;&lt;P&gt;Additional tests:&lt;/P&gt;&lt;P&gt;- 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.&lt;/P&gt;&lt;P&gt;- 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.&lt;/P&gt;&lt;P&gt;Has anybody already faced that behavior ?&lt;/P&gt;&lt;P&gt;Any information will be appreciated.&lt;/P&gt;&lt;P&gt;Thanks.&lt;/P&gt;&lt;P&gt;Best regards,&lt;/P&gt;&lt;P&gt;Patrick Agrain&lt;/P&gt;&lt;P&gt;Our GPIO in the device tree:&lt;/P&gt;&lt;P&gt;'isolated': eps-resetn-gpios = &amp;lt;&amp;amp;gpio2 0x5 0x1&amp;gt;;&lt;/P&gt;&lt;P&gt;LED:&lt;/P&gt;&lt;P&gt;leds {&lt;BR /&gt;compatible = "gpio-leds";&lt;BR /&gt;pinctrl-names = "default";&lt;BR /&gt;pinctrl-0 = &amp;lt;&amp;amp;pinctrl_leds&amp;gt;;&lt;/P&gt;&lt;P&gt;cpu {&lt;BR /&gt;gpios = &amp;lt;&amp;amp;gpio2 0x4 GPIO_ACTIVE_LOW&amp;gt;;&lt;BR /&gt;label = "CPUgreen";&lt;BR /&gt;default-state = "off";&lt;BR /&gt;linux,default-trigger = "none";&lt;BR /&gt;};&lt;/P&gt;&lt;P&gt;test {&lt;BR /&gt;gpios = &amp;lt;&amp;amp;gpio1 0x7 GPIO_ACTIVE_LOW&amp;gt;;&lt;BR /&gt;label = "CPUtest";&lt;BR /&gt;default-state = "off";&lt;BR /&gt;linux,default-trigger = "none";&lt;BR /&gt;};&lt;BR /&gt;};&lt;/P&gt;</description>
      <pubDate>Tue, 10 Jun 2025 08:23:50 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/imx93-GPIO-blocked-or-no-more-reachable/m-p/2113426#M238031</guid>
      <dc:creator>patrick_agrain</dc:creator>
      <dc:date>2025-06-10T08:23:50Z</dc:date>
    </item>
    <item>
      <title>Re: imx93 - GPIO blocked (or no more reachable)</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/imx93-GPIO-blocked-or-no-more-reachable/m-p/2115190#M238134</link>
      <description>&lt;P&gt;Hi&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;
&lt;P&gt;The LED on gpiochip3 is on a different GPIO controller, so using gpioset on gpiochip0 doesn't affect it.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Regards&lt;/P&gt;
&lt;P&gt;Daniel&lt;/P&gt;</description>
      <pubDate>Thu, 12 Jun 2025 08:19:56 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/imx93-GPIO-blocked-or-no-more-reachable/m-p/2115190#M238134</guid>
      <dc:creator>danielchen</dc:creator>
      <dc:date>2025-06-12T08:19:56Z</dc:date>
    </item>
    <item>
      <title>Re: imx93 - GPIO blocked (or no more reachable)</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/imx93-GPIO-blocked-or-no-more-reachable/m-p/2115224#M238136</link>
      <description>&lt;P&gt;Hello Daniel,&lt;/P&gt;&lt;P&gt;Thanks for pointing out that.&lt;/P&gt;&lt;P&gt;Does it mean that we should avoid mixing kernel-driven GPIO and userspace-driven GPIO on the same GPIO controller ?&lt;/P&gt;&lt;P&gt;Best regards,&lt;/P&gt;&lt;P&gt;Patrick Agrain&lt;/P&gt;</description>
      <pubDate>Thu, 12 Jun 2025 08:42:06 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/imx93-GPIO-blocked-or-no-more-reachable/m-p/2115224#M238136</guid>
      <dc:creator>patrick_agrain</dc:creator>
      <dc:date>2025-06-12T08:42:06Z</dc:date>
    </item>
    <item>
      <title>Re: imx93 - GPIO blocked (or no more reachable)</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/imx93-GPIO-blocked-or-no-more-reachable/m-p/2116452#M238221</link>
      <description>&lt;P&gt;YES&lt;/P&gt;</description>
      <pubDate>Sun, 15 Jun 2025 14:10:08 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/imx93-GPIO-blocked-or-no-more-reachable/m-p/2116452#M238221</guid>
      <dc:creator>danielchen</dc:creator>
      <dc:date>2025-06-15T14:10:08Z</dc:date>
    </item>
  </channel>
</rss>

