drivers: led: gpio: Add pinctrl support

[Ayush1325]

Allow specifying pinmuxing in gpio-leds. A lot of board have on-board LEDs, so allowing specifying pinmux in these nodes helps keep the base GPIO node cleaner, and easier to write overlays for.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jeppenodgaard]

Since they are just regular GPIOs I cannot see why this is needed. Can you elaborate?

E.g. how would this look using pinmuxing?:

	leds: leds {
		compatible = "gpio-leds";
		green_led_1: led_1 {
			gpios = <&gpiob 0 GPIO_ACTIVE_HIGH>;
			label = "User LD1";
		};
		yellow_led_1: led_2 {
			gpios = <&gpiof 4 GPIO_ACTIVE_HIGH>;
			label = "User LD2";
		};
		red_led_1: led_3 {
			gpios = <&gpiog 4 GPIO_ACTIVE_HIGH>;
			label = "User LD3";
		};
	};

If it makes sense. pinctrl-device.yaml should be included in bindings and some kind of example should exist I think.

[Ayush1325]

So, I might be a bit biased since I am coming from linux dt. Here is how I currently need to do pimuxing:

/ {
	leds: leds {
		compatible = "gpio-leds";
		green_led_1: led_1 {
			gpios = <&gpiob 0 GPIO_ACTIVE_HIGH>;
			label = "User LD1";
		};
	};
};

&gpiob {
    pinctrl-0 = <&green_led_1_default>
    pinctrl-names = "default";
};

Now, if I want to add a new LED for a single application, I can write the following overlay:

/ {
	techlab-cape-leds {
		compatible = "gpio-leds";
		led_1 {
			gpios = <&gpiob 1 GPIO_ACTIVE_HIGH>;
		};
	};
};

&gpiob {
    pinctrl-0 = <&green_led_1_default &techalb_led_1>
};

As you can see, the overlay for gpiob needs to have the pinmuxes from the base tree as well, since there is no way to just append new values. At least there is none in Linux. Maybe Zephyr has something?

If pinmuxing is supported in the gpio-leds itself, then things become a bit cleaner. The base dt will be as follows:

/ {
	leds: leds {
		compatible = "gpio-leds";
                pinctrl-0 = <&green_led_1_default>
                pinctrl-names = "default";

		green_led_1: led_1 {
			gpios = <&gpiob 0 GPIO_ACTIVE_HIGH>;
			label = "User LD1";
		};
	};
};

And overlay:

/ {
	techlab-cape-leds {
		compatible = "gpio-leds";
                pinctrl-0 = <&green_led_1_default &techalb_led_1>
                pinctrl-names = "default";
		led_1 {
			gpios = <&gpiob 1 GPIO_ACTIVE_HIGH>;
		};
	};
};

[jeppenodgaard]

I have only used pinmuxing when the GPIO is used with a non-gpio driver, e.g. ADC, PWM, SPI, etc.

Are you sure you need pinmuxing?
I guess you use ti,davinci-gpio.yaml which is the only GPIO binding that includes pinctrl-device.yaml. I wonder why that is the only GPIO binding that has it included.

[Ayush1325]

I have only used pinmuxing when the GPIO is used with a non-gpio driver, e.g. ADC, PWM, SPI, etc.

Are you sure you need pinmuxing? I guess you use ti,davinci-gpio.yaml which is the only GPIO binding that includes pinctrl-device.yaml. I wonder why that is the only GPIO binding that has it included.

Well, not sure about other boards, but at least on beagles (which use Ti chipsets), each pin can pretty much be used as any peripheral. So GPIO is just another pinmux on most pins, the same as I2C, SPI, etc.

Normally, in case of boards like PocketBeagle 2, we try to have 3 modes documented for each pin. So pinmuxing is quite important.

[simonguinot]

In Linux, the default pin configuration is not applied by the end drivers but by the pinctrl driver. I am not sure that's the right way to do that. Let's ask for some advice. @gmarull, what do you think ?

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.