Turn on GPIO from DTS

[novalisek]

Is your enhancement proposal related to a problem? Please describe.
Hi, I would like to turn on GPIO from DTS, I need to turn/hold ON "enable" pin of DC/DC converter as soon as firmware starts

Describe the solution you'd like
To be able to use something like

 outputs {
       compatible = "gpio-leds";
		dcdc: dcdc {
        	gpios = <&gpio0 18 (GPIO_ACTIVE_HIGH|GPIO_OUTPUT_HIGH)>;
       };   	 		        
    };     

When I try to add GPIO_OUTPUT_HIGH, I get DTS errors.

Additional context
I need this for MCUBOOT - I can turn on GPIO manualy by gpio_pin_set() in my firmware, but I also need to do it in MCUBOOT, so that DC/DC stays ON when user releases power-on button, because it takes few seconds if you swap firmware and I don't want DC/DC to be turned OFF while swapping, if user releases the button earlier :)

Describe alternatives you've considered
I could modify MCUBOOT source to use gpio_pin_set(), but I would better not to touch MCUBOOT source code and use DTS for this.

May be this feature is already possible and I am just doing something wrong ...

Thanks

[galak]

@novalisek I think you just need in the board port that builds MCUBOOT to call gpio_pin_set().

[novalisek]

@galak what do you mean by "board port"? I am just using my own dts overlay. thanks

[galak]

You are building for some board correct? How are you getting dcdc set right now?

[novalisek]

I am using nrf52dk_nrf52832 as base with my overlay. In my firmware I normaly use gpio_pin_set to switch EN pin of external DCDC.
I would like the EN pin also to be switched automaticaly immediately when mcuboot starts (idealy without modifying bootloader\mcuboot\boot\zephyr\main.c)

[galak]

I am using nrf52dk_nrf52832 as base with my overlay. In my firmware I normaly use gpio_pin_set to switch EN pin of external DCDC.
I would like the EN pin also to be switched automaticaly immediately when mcuboot starts (idealy without modifying bootloader\mcuboot\boot\zephyr\main.c)

I'm not an expert w/regards to mcuboot, but its my understanding that the mcuboot build would pull in part of zephyr and I assume that includes some board code. So in theory you should be able to add something in boards/arm/nrf52dk_nrf52832 that would call gpio_pin_set() and that should than happen in both mcuboot and zephyr.

[de-nordic]

I'm not an expert w/regards to mcuboot, but its my understanding that the mcuboot build would pull in part of zephyr and I assume that includes some board code. So in theory you should be able to add something in boards/arm/nrf52dk_nrf52832 that would call gpio_pin_set() and that should than happen in both mcuboot and zephyr.

You are right. The mcuboot basically is Zephyr app, for example the flash access is done via Zephyr drivers.

[galak]

@de-nordic, @d3zd3z I'm guessing you might be able to answer @novalisek question better than I can.

[de-nordic]

@novalisek Can you share the DTS error log?

[novalisek]

When I change

 outputs {
       compatible = "gpio-leds";
		dcdc: dcdc {
        	gpios = <&gpio0 18 (GPIO_ACTIVE_HIGH)>;
       };   	 		        
    };   

to

 outputs {
       compatible = "gpio-leds";
		dcdc: dcdc {
        	gpios = <&gpio0 18 (GPIO_ACTIVE_HIGH|GPIO_OUTPUT_HIGH)>;
       };   	 		        
    };   

this happens:

Including boilerplate (Zephyr base (cached)): D:/my-zephyr-parent-path/zephyr/cmake/app/boilerplate.cmake
-- Application: D:/my-zephyr-parent-path/bootloader/mcuboot/boot/zephyr
-- Zephyr version: 2.6.99 (D:/my-zephyr-parent-path/zephyr), build: zephyr-v2.5.0-4959-ga6cc3f18382a
-- Found west (found suitable version "0.10.1", minimum required is "0.7.1")
-- Board: nrf52dk_nrf52832
-- Cache files will be written to: D:/my-zephyr-parent-path/zephyr/.cache
-- Found toolchain: gnuarmemb (C:/gnu_arm_embedded/latest)
-- Found BOARD.dts: D:/my-zephyr-parent-path/zephyr/boards/arm/nrf52dk_nrf52832/nrf52dk_nrf52832.dts
-- Found devicetree overlay: D:/my-firmware-source/nrf52dk_nrf52832.overlay
-- Found devicetree overlay: D:/my-zephyr-parent-path/bootloader/mcuboot/boot/zephyr/dts.overlay
-- Found devicetree overlay: D:/my-zephyr-parent-path/bootloader/mcuboot/boot/zephyr/dts.overlay
Traceback (most recent call last):
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\gen_defines.py", line 890, in <module>
    main()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\gen_defines.py", line 61, in main
    edt = edtlib.EDT(args.dts, args.bindings_dirs,
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\edtlib.py", line 194, in __init__
    self._dt = DT(dts)
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 743, in __init__
    self._parse_dt()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 864, in _parse_dt
    self._parse_node(self.root)
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 969, in _parse_node
    self._parse_node(child)
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 969, in _parse_node
    self._parse_node(child)
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 981, in _parse_node
    self._parse_assignment(prop)
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1050, in _parse_assignment
    self._parse_cells(prop, 4)
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1108, in _parse_cells
    num = self._eval_prim()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1224, in _eval_prim
    val = self._eval_ternary()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1229, in _eval_ternary
    val = self._eval_or()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1238, in _eval_or
    val = self._eval_and()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1244, in _eval_and
    val = self._eval_bitor()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1250, in _eval_bitor
    val = self._eval_bitxor()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1256, in _eval_bitxor
    val = self._eval_bitand()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1262, in _eval_bitand
    val = self._eval_eq()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1268, in _eval_eq
    val = self._eval_rela()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1278, in _eval_rela
    val = self._eval_shift()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1292, in _eval_shift
    val = self._eval_add()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1302, in _eval_add
    val = self._eval_mul()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1312, in _eval_mul
    val = self._eval_unary()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1336, in _eval_unary
    return self._eval_prim()
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1223, in _eval_prim
    self._parse_error("expected number or parenthesized expression")
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1476, in _parse_error
    _err("{}:{} (column {}): parse error: {}".format(
  File "D:\my-zephyr-parent-path\zephyr\scripts\dts\python-devicetree\src\devicetree\dtlib.py", line 1903, in _err
    raise DTError(msg)
devicetree.dtlib.DTError: nrf52dk_nrf52832.dts.pre.tmp:633 (column 30): parse error: expected number or parenthesized expression
CMake Error at D:/my-zephyr-parent-path/zephyr/cmake/dts.cmake:240 (message):
  gen_defines.py failed with return code: 1
Call Stack (most recent call first):
  D:/my-zephyr-parent-path/zephyr/cmake/app/boilerplate.cmake:571 (include)
  D:/my-zephyr-parent-path/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
  D:/my-zephyr-parent-path/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
  CMakeLists.txt:44 (find_package)

[de-nordic]

@novalisek The GPIO_OUTPUT_HIGH is not available for DTS.
The gpio defines available for DTS are defined here: include/dt-bindings/gpio/gpio.h
Also, I do not think that "gpio-leds" is the right compatibility for the purpose.

Update: I do not think that Zephyr has basic device for on/off switch, so the "gpio-leds" device is the closest think you may get.

[novalisek]

@de-nordic I was also looking for closest basic gpio device, but couldn't find anything closer that gpio-leds :(

So it seems that turning GPIO from DTS is not possible now. It would be nice feature though

[henrikbrixandersen]

We are doing something similar in downstream projects. Basically, we have added a board.c file which sets the needed GPIOs at boot-up when building the MCUboot application (but not when building the chain-loaded application to avoid setting them twice).

[novalisek]

I will also need to be able to change the state from user space. For me as the user of zephyr, the easiest way would be possibility to use GPIO_OUTPUT_HIGH in DTS within gpio node definiction (btw something more general than gpio-leds would also be nice, ie. just "gpio" or gpio-general)

[nandojve]

I think this kind of problems could be simple solved using pinctrl.

This is an example that uses bias-pull-up property.

zephyr/boards/arm/arduino_due/arduino_due.dts

Lines 56 to 58 in b316d18

	&pa8a_uart_urxd {
	bias-pull-up;
	};

I think it is not ready yet to be use right now together with gpio driver on main tree but pinctrl properties could be used to this function, see some properties here pincfg-node. In case, the below properties just need to be available to be used as above example:

output-enable;
output-high/low:

I mean, if there is no current solution on gpio driver pinctrl could help in near future.

[mbolivar-nordic]

A thing to keep in mind is, that the Linux GPIO hogs actually "hogs" the GPIO line, preventing it from being used for anything else (e.g. changing its state from user space).

I wasn't aware of that. That doesn't sound like a solution, then.

output-enable;
output-high/low:

I mean, if there is no current solution on gpio driver pinctrl could help in near future.

That seems like a more reasonable approach -- @mnkp?

[mnkp]

A thing to keep in mind is, that the Linux GPIO hogs actually "hogs" the GPIO line, preventing it from being used for anything else (e.g. changing its state from user space).

I also wasn't aware of that. The description of the hogging mechanism in the Linux GPIO bindings states

GPIO hogging is a mechanism providing automatic GPIO request and configuration as part of the gpio-controller's driver probe function.

And the description of the patch that added the functionality to the Linux kernel states

This patch provides a way to initially configure specific GPIO when the GPIO controller is probed.

I wasn't able to find any mention that from the point the pin is configured it is owned exclusively by the GPIO controller.

I believe the proper solution to the GPIO pin initialization depends on a use case. For simple cases, when the pin needs to be configured only once and will not be modified during runtime, or when very early configuration during the boot process is required the GPIO hogging is the way to go.

If user needs to initialize the pin during the boot process and then change its state during the runtime a dedicated driver is better. And it could be regulator_fixed.c that reads data from the regulator-fixed DTS node. Or some switch driver (which we don't have yet) that reads data from the gpio-switch DTS node.

The driver could potentially rely on pinctrl DTS properties to configure the pin but I'm not sure if that's the best match. Or maybe I misunderstood the idea. In any case we shouldn't add a 'fake' pin to e.g. UART DTS node that would - as a side effect - connect a pin to GPIO controller and configure it to a predefined state during UART driver initialization.

The third option, extracting DTS description from e.g. gpio-leds node and using it directly in the application code - that's what we do in e.g. the blinky sample, it's a bit of misuse. gpio-leds node, or any other DTS node, should be controlled by its dedicated driver.

The one difference between GPIO hogging mechanism and other discussed solutions is that in case of GPIO hogging it's the GPIO driver itself that automatically configures the pins as defined in DTS. In any other case we need an extra dedicated driver that will act upon data contained in its DTS node.

[henrikbrixandersen]

A Linux DTS GPIO hog marks the GPIO line with FLAG_IS_HOGGED, which is tested in e.g. https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib-cdev.c#L1927 - this prevents the given GPIO line to be used from user-space once it has been "hogged".

We could of course deviate from this behaviour and go with GPIO hogs just as a way of setting an initial state of a GPIO line.

[chrta]

I use a regulator in the device tree to do this for a zephyr application (on nrf91, zephyr 2.6):

	vdd_per: vdd-per-ctrl {
		compatible = "regulator-fixed-sync", "regulator-fixed";
		label = "vdd-per-ctrl";
		regulator-name = "vdd-per-ctrl";
		enable-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
		regulator-always-on;
	};

                /* within some i2c peripheral */
		vin-supply = <&vdd_per>;

This works fine for my use-case. The specified gpio is pulled low when the application starts. No need to modify any source code for this. Only CONFIG_REGULATOR=y is required in the correct config file (or board defconfig)

[novalisek]

@chrta nice workaround, thanks. I still think that what @henrikbrixandersen suggests at #36651 (reply in thread) woul be much cleaner. I don't know how much work would that require, may be @galak would know better.

[novalisek]

Hi, has it been decided which way to choose?

[mnkp]

In my opinion the cleanest solution is the one suggested by @chrta with the regulator driver. It should not be considered a workaround. That's how such problem as yours should be handled. If the regulator driver is enabled in the DT it will be automatically enabled in Kconfig, compiled and when initialized during the boot process it will toggle the GPIO pin as needed.

This should work seamlessly with MCUboot, no need to touch its source code, just make sure that your board file enables GPIO. It should also work well when the control of the pin is passed from MCUboot to the main application.

Since the DC/DC can be controlled by the GPIO pin I assume that your application will make use of the regulator driver API to turn it on/off as required during the runtime. If the DC/DC needs to be turned on just once and will always stay on using the regulator driver would be a bit of an overkill, GPIO hogging mechanism might be a better choice in this case.

[novalisek]

Yes, it may be cleanest at current state, but wouldn't just setting GPIO_OUTPUT_HIGH in gpio config be more user friendly? Or regulator should be renamed to something more common, because sometimes you don't need it only for regulator at startup. Let's say you want to turn on LED at startup, it shouldn't be called regulator (same example as using gpio-leds with regular gpio used for something else than LED, because there is only gpio-leds, no common "gpio-common").

[Snevzor]

I've noticed the mentioning of board specific code to tackle this problem. An example can be found at boards/arm/thingy52_nrf52832/board.c where DEVICE_DEFINE is used to configure a GPIO high taking priorities into account.
Another example in boards/arm/efm32hg_slstk3400a/board.c where SYS_INIT is used instead to get a similar result.

I'm looking for a solution where a GPIO, connected to a load switch, controls the power to a sensor and I want to enable the GPIO before fetching a sample. The reason is that my device is low power, but the sensor isn't. This is a common problem when dealing with low power battery powered devices that have not-so-low-power sensors on board. I also want the driver init to be called when the GPIO gets enabled. I probably should be using the regulator driver here (although I have no clue how the driver re-init is called) but in my case it is not a regulator. It's more like a gpio-switch (as mentioned before). Although I need something different than what @novalisek needs I felt the need to post it here as when you look at the broader issue I have to disagree with having to use board code as the means to solve these user specific cases. And in my opinion a generic gpio driver does absolutely make sense.
Controlling GPIO in a generic way should not be regarded user specific in my opinion.
I see the gpio-led driver being misused for this purpose so often.

[chrta]

Another example in boards/arm/efm32hg_slstk3400a/board.c where SYS_INIT is used instead to get a similar result.

This was implemented this way, because when this was done, it was the only/easiest solution. This is imho not a good way to do this, i would also prefer if this could be done cleanly in the device tree somehow.

I'm looking for a solution where a GPIO, connected to a load switch, controls the power to a sensor and I want to enable the GPIO before fetching a sample.

For your use-case the regulator in the device tree is imho the correct approach. This is also often done in the linux kernel. If supply voltage to an IC or complete voltage rails on the pcb can be disabled/enabled (e.g. via gpio also if this is a simple transistor/switch), the voltage rail is put into the device tree as a voltage regulator. The devices that are supplied by this voltage rail reference this regulator in the device tree. This way you also have a good representation of the supply voltages from the schematic in the device tree.

[Snevzor]

Thanks for your clarification @chrta!

The API docs point me to supply-gpios instead of vin-supply. But for both I struggle to find some sample code.

Am I right that supply-gpios is only a way to get to that GPIO pin using the sensor node and additionally provide a good representation in the device tree? Toggling this GPIO from the application is a bad idea because the driver will need to be re-initialised? I've only seen this being used in board specific code to get the supply gpio active at the desired time during boot.
Or is it the intention I control this GPIO pin from the sensor driver? This latter would probably work but it feels wrong that all sensor drivers would have to check for a supply-gpio DT property and use it subsequently.

For vin-supply I can see how it's possible to get the device binding and use the API (still investigating though, reading about onoff stuff), but I don't see how this is tied to the sensor driver. Is it also the intention here that the driver itself checks for the vin-supply property and deals with it directly?

[optimiseddesign]

I have a similar need and came across this - have there been any developments in code or thinking in the mean time for what the cleanest method would be? I'm using nRF Connect SDK v1.7.1 / Zephyr 2.6.99 with whatever specific commits Nordic bundles Zephyr as.

I am using it for a GPIO which holds an external power circuit (for the whole board) on, so I need it to be held high during MCUBoot to work with remote firmware updates, but also able to be changed by the main image application code to initiate a shutdown.

Something in DTS only would be neat, as long as a user application could then override it. But if I need to add a board.c for the board file for MCUboot to do it in code that seems a decent enough compromise, as long as the MCUBoot code itself doesn't need tinkering with.

[mbolivar-nordic]

You can use GPIO hogs since zephyr v3.3. See drivers/gpio/gpio_hogs.c and dts/bindings/gpio/gpio-controller.yaml for details.

@henrikbrixandersen it would be good to have a documentation page in .rst for this feature, by the way.