Device Tree Configuration Generic GPIO Inputs & Outputs

nRF52833-DK
nRF Connect SDK v2.3.0
Zephyr v3.2.99

I am trying to figure out the best practise for defining generic GPIO input & output pins. To my understanding, devicetree is where all the hardware configuration resides.

It appears these are the goto bindings when trying to setup basic gpios
    compatible: "gpio-keys"
    compatible: "gpio-leds"

I have also seen suggestions on creating a custom binding for dealing with generic GPIOs,  extra gpios in board overlay for nrf9160dk
With that in mind I compared the .yaml files for gpio-leds (assuming these would be ouput GPIOs) & gpio-keys (assuming these would be input GPIOs) but found no obvious difference/explanation as to what determines input or output.

For reference:

gpio-keys.yaml

# Copyright (c) 2018, Linaro Limited
# SPDX-License-Identifier: Apache-2.0

description: GPIO KEYS parent node

compatible: "gpio-keys"

include: base.yaml

child-binding:
    description: GPIO KEYS child node
    properties:
       gpios:
          type: phandle-array
          required: true
       label:
          type: string
          description: Descriptive name of the key


gpio-leds.yaml

# Copyright (c) 2018, Linaro Limited
# SPDX-License-Identifier: Apache-2.0

description: |
  This allows you to define a group of LEDs. Each LED in the group is
  controlled by a GPIO. Each LED is defined in a child node of the
  gpio-leds node.

  Here is an example which defines three LEDs in the node /leds:

  / {
  	leds {
  		compatible = "gpio-leds";
  		led_0 {
  			gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
  		};
  		led_1 {
  			gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
  		};
  		led_2 {
  			gpios = <&gpio1 15 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
  		};
  	};
  };

  Above:

  - led_0 is pin 1 on gpio0. The LED is on when the pin is low,
    and off when the pin is high.
  - led_1 is pin 2 on gpio0. The LED is on when the pin is high,
    and off when it is low.
  - led_2 is pin 15 on gpio1. The LED is on when the pin is low,
    and the pin's internal pull-up resistor should be enabled.

compatible: "gpio-leds"

child-binding:
    description: GPIO LED child node
    properties:
       gpios:
          type: phandle-array
          required: true
       label:
          type: string
          description: |
            Human readable string describing the LED. It can be used by an
            application to identify this LED or to retrieve its number/index
            (i.e. child node number) on the parent device.

If pins are inputs by default, will adding polarity flags in the device tree configure them as outputs, but omitting polarity flags leave them as inputs? (Maybe thats what the comments in yaml suggest, but then again polarity applies to both inputs & outputs)

Anyway, if gpio direction config isnt possible in device tree, then the required approach is to call 

gpio_pin_configure(PORT_DEVICE, PIN_NUMBER, _____ /* GPIO_OUTPUT or GPIO_INPUT */);

With this in mind, is there any point adding gpio configs to device tree, other than the initial configuration for polarity & pin biasing? Polarit & pin-biasing can be configured with gpio_pin_configure() anyway?

Parents Reply Children
No Data
Related