DTS: Leds defined in device tree does not appear in /sys/class/leds

[Mikkie67]

I have configured a section in DTS file for leds, did the pin controls etc, but the items do not appear in the /sys/class/leds directory on the target.

The DTS is parsed correctly and on the target the items are in the /proc/device-tree/eds folder as expected but not in the /sys/class/leds

Any ideas why? I am sure this worked in an older version of kernel...

DTS LEDS section:

Code: Select all

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

		blue1 {
			label = "blue1";
			gpios = <&pioC 16 GPIO_ACTIVE_LOW>;
			linux,default-trigger = "heartbeat";
		};
		..more definitions in similar fashion....
	};

DTS PINCTRL section

Code: Select all

			
				leds {
					pinctrl_leds: gpio_leds {
						atmel,pins =
							<
							AT91_PIOC 16 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOC 17 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOC 18 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOC 19 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOC 20 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOC 21 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOE 16 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOE 18 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOE 20 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOB 20 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOB 10 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOD 10 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOD 11 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOD 13 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							AT91_PIOB 15 AT91_PERIPH_GPIO AT91_PINCTRL_NONE
							>;
					};
				};

Listing of /proc/device-tree/leds

• # ls -l
  total 0
  drwxr-xr-x 2 root root 0 Jan 2 23:51 blue1
  drwxr-xr-x 2 root root 0 Jan 2 23:51 blue2
  drwxr-xr-x 2 root root 0 Jan 2 23:51 bluetooth_en
  -r--r--r-- 1 root root 10 Jan 2 23:51 compatible
  drwxr-xr-x 2 root root 0 Jan 2 23:51 d2
  drwxr-xr-x 2 root root 0 Jan 2 23:51 debug_en
  drwxr-xr-x 2 root root 0 Jan 2 23:51 enleg1
  drwxr-xr-x 2 root root 0 Jan 2 23:51 enleg2
  drwxr-xr-x 2 root root 0 Jan 2 23:51 gps_extint
  drwxr-xr-x 2 root root 0 Jan 2 23:51 gps_nreset
  drwxr-xr-x 2 root root 0 Jan 2 23:51 green1
  drwxr-xr-x 2 root root 0 Jan 2 23:51 green2
  -r--r--r-- 1 root root 5 Jan 2 23:51 name
  -r--r--r-- 1 root root 4 Jan 2 23:51 pinctrl-0
  -r--r--r-- 1 root root 8 Jan 2 23:51 pinctrl-names
  drwxr-xr-x 2 root root 0 Jan 2 23:51 red1
  drwxr-xr-x 2 root root 0 Jan 2 23:51 red2
  drwxr-xr-x 2 root root 0 Jan 2 23:51 serial1_de
  drwxr-xr-x 2 root root 0 Jan 2 23:51 serial1_nre
  drwxr-xr-x 2 root root 0 Jan 2 23:51 serial2_de
  drwxr-xr-x 2 root root 0 Jan 2 23:51 serial2_nre
  -r--r--r-- 1 root root 5 Jan 2 23:51 status

Listing of /sys/class/leds

• total 0
  drwxr-xr-x 2 root root 0 Jan 2 23:19 .
  drwxr-xr-x 33 root root 0 Jan 2 23:18 ..
  lrwxrwxrwx 1 root root 0 Jan 2 23:19 pwm:keypad:user -> ../../devices/platform/pwm_leds/leds/pwm:keypad:user

[blue_z]

Any ideas why? I am sure this worked in an older version of kernel...

Maybe there's a PIO conflict?
Your post is missing basic salient information. What SoC and board? What kernel version?

Regards

[Mikkie67]

Missing salient information.
SAMA5D31 as per SAMA5D31EK board.

Code: Select all

Linux version 4.9.87-linux4sam_5.8 (at91@vbox) (gcc version 6.4.0 (Buildroot 2018.02) ) #16 Thu Oct 4 16:05:04 SAST 2018
CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt:Machine model: Atmel SAMA5D31-EK

There are no conflicts of the pins(that I know of). I can go into the /sys/class/gpio and export the pins and control the leds from userland.

I enabled some OF debug output and snippet is below. Perhaps that gives a clue. The command cat /dev/input/event1 shows reaction when buttons are pressed.

Code: Select all

of_get_named_gpiod_flags: parsed 'gpios' property of node '/leds/blue1[0]' - status (0)
of_get_named_gpiod_flags: parsed 'gpios' property of node '/leds/green1[0]' - status (0)
of_get_named_gpiod_flags: parsed 'gpios' property of node '/leds/red1[0]' - status (0)
of_get_named_gpiod_flags: parsed 'gpios' property of node '/leds/blue2[0]' - status (0)
of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio_keys/pwr_sw[0]' - status (0)
of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio_keys/key1_sw[0]' - status (0)
of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio_keys/key2_sw[0]' - status (0)
of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio_keys/key3_sw[0]' - status (0)
gpio-95 (pwr_sw): gpiod_set_debounce: missing set() or set_debounce() operations
gpio-93 (key1_sw): gpiod_set_debounce: missing set() or set_debounce() operations
gpio-92 (key2_sw): gpiod_set_debounce: missing set() or set_debounce() operations
gpio-94 (key3_sw): gpiod_set_debounce: missing set() or set_debounce() operations
input: gpio_keys as /devices/platform/gpio_keys/input/input0
evbug: Event. Dev: input0, Type: 1, Code: 256, Value: 1
evbug: Event. Dev: input0, Type: 0, Code: 0, Value: 0
evbug: Event. Dev: input0, Type: 1, Code: 259, Value: 1
evbug: Event. Dev: input0, Type: 0, Code: 0, Value: 0
evbug: Event. Dev: input0, Type: 1, Code: 264, Value: 1
evbug: Event. Dev: input0, Type: 0, Code: 0, Value: 0
evbug: Connected device: input0 (gpio_keys at gpio-keys/input0)

[blue_z]

I can go into the /sys/class/gpio and export the pins and control the leds from userland.

That means that those PIO pins are available to be used as free GPIOs because they were not assigned to any other purpose/function in the DT.
In other words the declarations for those pins in the DT are ineffective.
You posted the directory listing for /proc/device-tree/leds. What about /proc/device-tree/ahb/apb/pinctrl@*/leds ?

DTs written by Atmel do not use any pinctrl properties for gpio-led nodes.
Try revising your DT to do the same.

Regards

[Mikkie67]

Hi Blue_z, thanks for taking the time to answer again.

Below is the listings of the /proc/device-tree/ahb/apb/pinctrl@fffff200/leds

Code: Select all

total 0
drwxr-xr-x    3 root     root             0 Jan  2 15:31 .
drwxr-xr-x   36 root     root             0 Jan  2 15:31 ..
drwxr-xr-x    2 root     root             0 Jan  2 15:31 gpio_leds
-r--r--r--    1 root     root             5 Jan  2 15:31 name

and then the listing for the /proc/device-tree/ahb/apb/pinctrl@fffff200/leds/gpio-leds

Code: Select all

total 0
drwxr-xr-x    2 root     root             0 Jan  2 15:31 .
drwxr-xr-x    3 root     root             0 Jan  2 15:31 ..
-r--r--r--    1 root     root           256 Jan  2 15:31 atmel,pins
-r--r--r--    1 root     root             4 Jan  2 15:31 linux,phandle
-r--r--r--    1 root     root            10 Jan  2 15:31 name
-r--r--r--    1 root     root             4 Jan  2 15:31 phandle

I tried just removing the sections for pincntrl of gpio-leds and also removed the lines defining which pincntrl to use int eh gpio-leds section. The change is then that in the pinctrl section there are no longer pinctrl for leds, as exepcted. The leds however are still not exported to sysfs.

Hope you have some other ideas...

[blue_z]

I tried just removing the sections for pincntrl of gpio-leds and also removed the lines defining which pincntrl to use int eh gpio-leds section. The change is then that in the pinctrl section there are no longer pinctrl for leds, as exepcted. The leds however are still not exported to sysfs.

I did a quick test of the Linux4SAM 5.8 kernel on a SAMA5D36-EK. Hacked the .dts to disable the ssc0 device and added

Code: Select all

	leds {
		compatible = "gpio-leds";

		blue1 {
			label = "blue1";
			gpios = <&pioC 16 GPIO_ACTIVE_LOW>;
			linux,default-trigger = "heartbeat";
		};
		blue2 {
			label = "blue2";
			gpios = <&pioC 17 GPIO_ACTIVE_LOW>;
			linux,default-trigger = "heartbeat";
		};
		blue3 {
			label = "blue3";
			gpios = <&pioC 18 GPIO_ACTIVE_LOW>;
			linux,default-trigger = "heartbeat";
		};
	};

Contrary to your results, everything worked as expected.

Hope you have some other ideas...

Try enabling debug for the pinctrl subsystem (via menuconfig).
For each gpio-led the output (combined with gpio debug) should be like:

Code: Select all

of_get_named_gpiod_flags: parsed 'gpios' property of node '/leds/blue1[0]' - status (0)
pinctrl-at91 ahb:apb:pinctrl@fffff200: request pin 80 (pioC16) for fffff600.gpio:80
pinctrl-at91 ahb:apb:pinctrl@fffff200: enable pin 80 as GPIO
pinctrl-at91 ahb:apb:pinctrl@fffff200: enable pin 80 as PIOC16 0x10000

Worse case is you will have to start hacking leds-gpio.c with a lot of printk()s to understand what is going wrong.

Regards

[Mikkie67]

Blue Z, thanks for the response again, especially the testing of it on your 5.8 kernel.

Your testing gave me hope and I revisited the device tree configuration of the leds:

I found an error in one of the configurations as below. Obviously there is no pin 178, it should be 17.

Code: Select all

		green2 {
			label = "green2";
			gpios = <&pioC 178 GPIO_ACTIVE_LOW>;
			default-state = "off";
		};

I corrected only that error and now all the LEDs are working.

The presence or absence of the pin controls does not seem to matter much in this case.

I am a bit worried why the complete section was ignored because of the single pin error, but probably it is because of the linux coding style where functions simple exit with error code when any error is found, instead of using some more sensible error handling.

Your answer really sparked the solution, so thanks again for the time you spent looking into this.

Just maybe I will have a look at GPIO-leds.c to make the error handling a bit better, even if it is just more complete reporting.

Thanks again