linux-toradex.git/tools/gpio, branch v4.9.16

tools/gpio: fix gpio-event-mon header comment

2016-08-08T07:50:22+00:00

Fixes: 97f69747d8b1 ('tools/gpio: add the gpio-event-mon tool')
Signed-off-by: Baruch Siach 
Signed-off-by: Linus Walleij

tools/gpio: add install section

2016-06-23T09:07:13+00:00

Allow user to call install target.

Signed-off-by: Andy Shevchenko 
Acked-by: Alexandre Courbot 
Tested-by: Alexandre Courbot 
Signed-off-by: Linus Walleij

tools/gpio: move to tools buildsystem

2016-06-23T09:07:13+00:00

There is a nice buildsystem dedicated for userspace tools in Linux kernel tree.
Switch gpio target to be built by it.

Signed-off-by: Andy Shevchenko 
Acked-by: Alexandre Courbot 
Tested-by: Alexandre Courbot 
Signed-off-by: Linus Walleij

tools/gpio: add the gpio-event-mon tool

2016-06-15T07:29:29+00:00

The gpio-event-mon is used from userspace as an example of how
to monitor GPIO line events. It will latch on to a certain
GPIO line on a certain gpiochip and print timestamped events
as they arrive.

Example output:
$ gpio-event-mon -n gpiochip2 -o 0 -r -f
Monitoring line 0 on gpiochip2
Initial line value: 1
GPIO EVENT 946685798487609863: falling edge
GPIO EVENT 946685798732482910: rising edge
GPIO EVENT 946685799115997314: falling edge
GPIO EVENT 946685799381469726: rising edge

Signed-off-by: Linus Walleij

tools/gpio: add the gpio-hammer tool

2016-06-15T07:29:04+00:00

The gpio-hammer is used from userspace as an example of how
to retrieve a GPIO handle for one or several GPIO lines and
hammer the outputs from low to high and back again. It will
pulse the selected lines once per second for a specified
number of times or indefinitely if no loop count is
supplied.

Example output:
$ gpio-hammer -n gpiochip0 -o5 -o6 -o7
Hammer lines [5, 6, 7] on gpiochip0, initial states: [1, 1, 1]
[-] [5: 0, 6: 0, 7: 0]

Tested-by: Michael Welling 
Signed-off-by: Linus Walleij

tools/gpio: Add missing initialization of device_name

2016-03-31T09:51:30+00:00

lsgpio.c: In function ‘main’:
lsgpio.c:166:7: warning: ‘device_name’ may be used uninitialized in this functio
n [-Wmaybe-uninitialized]
   ret = list_device(device_name);
       ^

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Walleij

tools/gpio: Enable compiler optimization to catch more bugs

2016-03-31T09:50:21+00:00

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Walleij

gpio: present the consumer of a line to userspace

2016-02-25T20:07:23+00:00

I named the field representing the current user of GPIO line as
"label" but this is too vague and ambiguous. Before anyone gets
confused, rename it to "consumer" and indicate clearly in the
documentation that this is a string set by the user of the line.

Also clean up leftovers in the documentation.

Signed-off-by: Linus Walleij

tools: gpio: Small updates for output format

2016-02-23T13:20:58+00:00

Use %2d for the GPIO line number. This should align the results
horziontally for most gpio chips.

The GPIO label uses quotes for real values. For GPIO names this is
currently missing. The patch adds the missing quote.

Signed-off-by: Markus Pargmann 
Signed-off-by: Linus Walleij

gpio: add userspace ABI for GPIO line information

2016-02-19T08:48:46+00:00

This adds a GPIO line ABI for getting name, label and a few select
flags from the kernel.

This hides the kernel internals and only tells userspace what it
may need to know: the different in-kernel consumers are masked
behind the flag "kernel" and that is all userspace needs to know.

However electric characteristics like active low, open drain etc
are reflected to userspace, as this is important information.

We provide information on all lines on all chips, later on we will
likely add a flag for the chardev consumer so we can filter and
display only the lines userspace actually uses in e.g. lsgpio,
but then we first need an ABI for userspace to grab and use
(get/set/select direction) a GPIO line.

Sample output from "lsgpio" on ux500:

GPIO chip: gpiochip7, "8011e000.gpio", 32 GPIO lines
        line 0: unnamed unlabeled
        line 1: unnamed unlabeled
(...)
        line 25: unnamed "SFH7741 Proximity Sensor" [kernel output open-drain]
        line 26: unnamed unlabeled
(...)

Tested-by: Michael Welling 
Signed-off-by: Linus Walleij