mt7621 GPIO mapping mystery

[Arınç ÜNAL]

Pins from 22 to 33 are on the rgmii2 pin group. They don't function as 
GPIO by default. Requesting a gpio by either from devicetree or `echo 
203 >  /sys/class/gpio/export` won't change anything. You have to claim 
the pin group as gpio on the devicetree.

Quoting my response from [0]:

> state_default is there to explicitly set the function of a pin group to gpio, this is done because the bootloader may have set the function of a pin group to something else before booting OpenWrt which would render the pins of that group uncontrollable for general purpose aka GPIO.
> 
>     Actually I think @arinc9 did some work around that.
> 
> Not yet, I plan to modify the gpio_request_enable pinmux operation to set the pin group as gpio when there's a gpio request for a pin in that pin group. gpio_request_enable pinmux operation can only set the function of an individual pin currently. Since ralink pinctrl driver can only set the function of a group of pins, the operation currently cannot be used.
> 
> If we make it work, any GPIO defined on devicetree or exported from userspace will automatically have the function of the pin group it's in set to gpio, completely getting rid of the need for explicitly defining functions of certain pin groups on the devicetree.

Of course when I said "I plan to modify this code" I actually meant I 
was going to talk this through with Sergio but I never had the 
opportunity to do so. I guess this thread is a good place to start 
talking about this.

I had this case on a user:

They got an LED wired to wdt pin. GPIO is already exported on the DT. 
However their LED just won't work.

It turns out the bootloader sets the wdt pin's function to something 
other than gpio. And when OpenWrt boots, the pinctrl driver makes no 
changes to the pin's function.

So we had to specifically claim that pin as gpio to make the LED work.
Now there is already a solution for this which is the 
gpio_request_enable pinmux operation but it's not supposed to be used on 
pinctrl drivers that cannot control pins individually.

Sergio, you think we can somehow make this pinmux operation mux a pin 
group as gpio instead of a single pin?

Or introduce a new pinmux operation that can do this?

[0] https://github.com/openwrt/openwrt/pull/4470#issuecomment-1243345944

Arınç

On 20.01.2023 22:24, Peter Naulls wrote:
> 
> 
> I posted previously on GPIOs, which caused some debate; this may or may not
> be relevant, but I'd be remiss to not mention it:
> 
> http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html
> 
> I've been chasing an issue with GPIO mapping in for an mt7621 on the 
> OpenWrt
> 5.10.161 etc kernels.
> 
> In short, GPIOS up to at least 17 work, but 22 and beyond do not - 5-17 
> and 22-24 are LEDs, so their operation should be immediately obvious. 
> The are all active high and are all wired as you'd expect.
> 
> This all works as expected on a previous 4.14 kernel.  To say that there
> have been significant changes in drivers, GPIO handling and device tree 
> since
> that kernel would be an understatement.
> 
> I have tried exporting the GPIOS as LEDs, named GPIOs, direct 
> manipulation in
> /sys/class/gpio and libgpiod, but something is amiss. The actual value 
> of the GPIO as seen in software can manipulated in all cases, but the 
> physical value
> does not change.
> 
> Suspiciously, MDIO/MDC are at GPIOs 20 and 21, so I don't know if these are
> upsetting the physical mapping.  I've also turned off as much as 
> possible in
> the device tree, and built the kernel without switch and ethernet 
> drivers, etc.
> 
> I'm tearing my hair out here, so any clues at all would be appreciated.
> 
> Thanks!
> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel