0

I'm working on a board based on the iMX6 and am trying to configure a number of GPIOs that are being used as chip enable and reset lines. Based on the research I've done, the way to handle this is via the gpio-reset driver in the device tree. Following the documentation I've come up with the below code which compiles but I'm not sure how to then control these reset lines from user space.

The first device tree driver I used was the gpio-leds which created an leds folder in sys/class with nodes to control the LED. However I don't see anything similar for reset. So I have 2 questions:

1) Is GPIO-RESET the correct binding to use for controlling reset lines, enable lines, etc.

2) Is there documentation on how to handle this and other bindings from user space, similar to how I'm controlling the GPIO-LED?

Kernel: Linux buildroot 4.1.15

/dts-v1/;

#include <dt-bindings/input/input.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/omap.h>
#include "imx6ul.dtsi"

/ {
    model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
    compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";

    memory {
        reg = <0x80000000 0x20000000>;
    };

    /* Reset Line Configuration */
    gpio_resets {
        compatible = "linux,gpio-reset";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpioreset>;

        gnss {
            gpios = <&gpio1 4 0>;
            asserted-state = <0>;
            duration-ms = <100>;
            auto;
        };
    };

    ...

};

&iomuxc {
  pinctrl-names = "default";
  imx6ul-evk {

    pinctrl_gpioreset:
    gpiorstgrp {
      fsl,pins = <
      MX6UL_PAD_GPIO1_IO04__GPIO1_IO04         0x000010B0  /* GNSS RESET_N */
      >;
    };

    ...

};
Otus
  • 305
  • 1
  • 5
  • 16
  • 2
    The API to use will depend on the kernel version, which you neglect to mention. Instead of standalone GPIO, have you considered incorporating any of them into a device driver (i.e. *"chip enable and reset lines"* seem like they could be related to a device)? – sawdust Aug 09 '17 at 21:02
  • if your configuration is correct, you will see the device node populated under /sys/class/gpio/gpioNUMBER – ntshetty Aug 10 '17 at 09:59
  • sawdust- these are going to be basic enable lines for devices that don't otherwise require a driver which is why I was looking at using the gpio-reset but maybe there's a better way. – Otus Aug 10 '17 at 21:19
  • Thiru Shetty- I'm not seeing the nodes being populated... is there anything I'm missing in the device tree? – Otus Aug 10 '17 at 21:20
  • I'm seeing the devices show up in /sys/firmware/devicetree/base/gpio_resets but not in /sys/class/gpio – Otus Aug 11 '17 at 14:01
  • @ThiruShetty, can you point to the kernel sources which are doing what you think it should to populate */sys/class/gpio/gpioN*? – 0andriy Aug 13 '17 at 17:02
  • It depends to what you are trying to achieve. If you are talking about CPU reset line which you can assert via GPIO (self hard reset) it's one story. If you are talking about some device reset line as GPIO it should be described in that device node in DTS. – 0andriy Aug 13 '17 at 17:04
  • @0andriy - Do yo have an example of how this would be done? – Otus Aug 14 '17 at 18:39
  • What *would be done*? I pointed to (at least) two possibilities, which one is your case? – 0andriy Aug 14 '17 at 18:50
  • I meant including the device reset line as part of the device node – Otus Aug 15 '17 at 20:49
  • How does the driver handle reset line currently for that device? – 0andriy Aug 18 '17 at 15:38
  • There is no driver currently. The device controlled via a serial interface. – Otus Aug 19 '17 at 19:56

2 Answers2

0

I'm not exactly sure about the gpio-reset sysfs interface as I couldn't find any information in bindings documentation, but for the normal gpio interface you need to export the gpio before it will show up in /sys/class/gpio/gpio*. Basically you just need to write the number of the gpio you wish to use to the export file underneath /sys/class/gpio. Here is an example of someone doing that. If you're just toggling the gpio on/off that interface should be enough.

zeus_masta_funk
  • 1,388
  • 2
  • 11
  • 34
0
  1. Is GPIO-RESET the correct binding to use for controlling reset lines, enable lines, etc.

I have been looking for such a driver too.

I can see that there was a proposal for exactly this:

https://lwn.net/Articles/585145/

but I cannot find it in my kernel version (tracking the 5.4.y releases).

Only in some stale imx6 kernel: https://github.com/samnazarko/linux-imx6/blob/master/Documentation/devicetree/bindings/reset/gpio-reset.txt

So I will either

  • create a small driver to support the "delayed" function based on the above proposal (time of asserting the reset at boot).
  • use gpio-led with a default-state. Maybe using the "one-shot" trigger, to provide a single-write API to my apps. (Write once to the sysfs shot file results in a single toggle of the pin for a configurable time.)
  • Totally handle it from the userspace via libgpio or sysfs. (Maybe combined with gpio-led, to have at least a clearly defined state of the line during boot.)
lnksz
  • 421
  • 3
  • 15