[v5,0/7] gpio: expose line bias flags to userspace
mbox series

Message ID 20191104153841.16911-1-warthog618@gmail.com
Headers show
Series
  • gpio: expose line bias flags to userspace
Related show

Message

Kent Gibson Nov. 4, 2019, 3:38 p.m. UTC
The changes from v4:
Review changes:
 - relocate restriction on applying bias to as-is from patch 2 to patch 1.
 - propagate errors, other than ENOTSUPP, from gpio_set_bias. (squashed 
   into patches 3 and 4).
 - include SET_CONFIG patch series v2 (patch 6 and 7 here).

I've also fixed a few other nits I noticed along the way:
 - rework gpio_set_bias as flags are mutually exclusive.
 - remove input flag required to set bias restriction from 
   lineevent_create as events are implicitly assumed inputs anyway.
 - reorder patches to group gpiolib bias patches together before the 
   gpio-mockup changes.


This series adds gross control of pull-up/pull-down to the GPIO uAPI.
Gross control means enabling and disabling of bias functionality,
not finer grained control such as setting biasing impedances.

The support allows both input and output lines to have any one of the
following biases applied as part of the line handle or event request:
 0. As Is - bias is left alone.  This is the default for ABI compatibility.
 1. Bias Disable - bias is explicitly disabled.
 2. Pull Down - pull-down bias is enabled.
 3. Pull Up - pull-up bias is enabled.

The biases are set via three flags, BIAS_DISABLE, BIAS_PULL_DOWN
and BIAS_PULL_UP.  These map directly to the similarly named 
pinctrl pin_config_param flags.
As Is corresponds to none of the flags being set.

The setting of biases on output lines may seem odd, but is to allow for
utilisation of internal pull-up/pull-down on open drain and open source
outputs, where supported in hardware.

The series also adds the GPIOHANDLE_SET_CONFIG_IOCTL to the gpio chardev.
The ioctl allows some of the configuration of a requested handle to be
changed without having to release the line.
The primary use case is the changing of direction for bi-directional 
lines.

Patches are against Bart's gpio/for-next branch[1].

The patch has been successfully tested against gpio-mockup, and 
on a Raspberry Pi, in both cases using the feature/pud_set_config 
branch of my Go gpiod library[2], as well as with my feature/pud 
development branch of libgpiod[3].  Patch 7 has only been tested using 
my gpiod library as libgpiod has not yet been updated to support the 
SET_CONFIG ioctl.

Patch 1 adds pull-up/pull-down support to line handle requests.
Patch 2 adds pull-up/pull-down support to line event requests.
Patch 3 adds support for disabling bias.
Patch 4 adds support for setting bias on output lines.
Patch 5 adds pull-up/down support to the gpio-mockup for uAPI testing.
Patch 6 refactors the flag validation from linehandle_create.
Patch 7 adds the SET_CONFIG ioctl.

Drew Fustini (1):
  gpio: expose pull-up/pull-down line flags to userspace

Kent Gibson (6):
  gpiolib: add support for pull up/down to lineevent_create
  gpiolib: add support for disabling line bias
  gpiolib: add support for biasing output lines
  gpio: mockup: add set_config to support pull up/down
  gpiolib: move validation of line handle flags into helper function
  gpio: add new SET_CONFIG ioctl() to gpio chardev

 drivers/gpio/gpio-mockup.c |  94 ++++++++++------
 drivers/gpio/gpiolib.c     | 213 +++++++++++++++++++++++++++++++------
 drivers/gpio/gpiolib.h     |   1 +
 include/uapi/linux/gpio.h  |  24 +++++
 4 files changed, 264 insertions(+), 68 deletions(-)

Comments

Drew Fustini Nov. 4, 2019, 7:58 p.m. UTC | #1
On Mon, Nov 04, 2019 at 11:38:34PM +0800, Kent Gibson wrote:
> on a Raspberry Pi, in both cases using the feature/pud_set_config 
> branch of my Go gpiod library[2], as well as with my feature/pud 
> development branch of libgpiod[3].  Patch 7 has only been tested using 
> my gpiod library as libgpiod has not yet been updated to support the 
> SET_CONFIG ioctl.
> 
> Patch 1 adds pull-up/pull-down support to line handle requests.
> Patch 2 adds pull-up/pull-down support to line event requests.
> Patch 3 adds support for disabling bias.
> Patch 4 adds support for setting bias on output lines.
> Patch 5 adds pull-up/down support to the gpio-mockup for uAPI testing.
> Patch 6 refactors the flag validation from linehandle_create.
> Patch 7 adds the SET_CONFIG ioctl.

Hi Kent, thanks for continuing pushing this patch series forward.

I've not used gpiomockup before and I was hoping you might be able to share
the commands you use to run it to test the patches.

thanks,
drew
Kent Gibson Nov. 5, 2019, 12:12 a.m. UTC | #2
On Mon, Nov 04, 2019 at 11:58:38AM -0800, Drew Fustini wrote:
> On Mon, Nov 04, 2019 at 11:38:34PM +0800, Kent Gibson wrote:
> > on a Raspberry Pi, in both cases using the feature/pud_set_config 
> > branch of my Go gpiod library[2], as well as with my feature/pud 
> > development branch of libgpiod[3].  Patch 7 has only been tested using 
> > my gpiod library as libgpiod has not yet been updated to support the 
> > SET_CONFIG ioctl.
> > 
> > Patch 1 adds pull-up/pull-down support to line handle requests.
> > Patch 2 adds pull-up/pull-down support to line event requests.
> > Patch 3 adds support for disabling bias.
> > Patch 4 adds support for setting bias on output lines.
> > Patch 5 adds pull-up/down support to the gpio-mockup for uAPI testing.
> > Patch 6 refactors the flag validation from linehandle_create.
> > Patch 7 adds the SET_CONFIG ioctl.
> 
> Hi Kent, thanks for continuing pushing this patch series forward.
> 
> I've not used gpiomockup before and I was hoping you might be able to share
> the commands you use to run it to test the patches.
> 

I refer you to the libgpiod tests, particularly
libgpiod/tests/mockup/gpio-mockup.c as well as gpio/gpio-mockup.c
itself.

If you run the libgpiod tests they will load and manipulate the module
themselves.  My gpiod tests do similarly.  I run them in a VM to ensure
they can't interfere with real hardware by accident.

Here is a quick guide to using the mockup manually.

Load the module with two chips with 4 and 8 lines respectively:  

 modprobe gpio-mockup gpio_mockup_named_lines gpio_mockup_ranges=-1,4,-1,8

$ gpiodetect
gpiochip0 [gpio-mockup-A] (4 lines)
gpiochip1 [gpio-mockup-B] (8 lines)

You add a -1,N pair for each chip you want mocked.
The -1s is there for historical reasons.

The gpio_mockup_named_lines is optional and creates labels for the lines 
based on chip and line number (the labels are quoted here):

$ gpioinfo
gpiochip0 - 4 lines:
	line   0: "gpio-mockup-A-0" unused input active-high
	line   1: "gpio-mockup-A-1" unused input active-high
	line   2: "gpio-mockup-A-2" unused input active-high
	line   3: "gpio-mockup-A-3" unused input active-high
gpiochip1 - 8 lines:
	line   0: "gpio-mockup-B-0" unused input active-high
	line   1: "gpio-mockup-B-1" unused input active-high
	line   2: "gpio-mockup-B-2" unused input active-high
	line   3: "gpio-mockup-B-3" unused input active-high
	line   4: "gpio-mockup-B-4" unused input active-high
	line   5: "gpio-mockup-B-5" unused input active-high
	line   6: "gpio-mockup-B-6" unused input active-high
	line   7: "gpio-mockup-B-7" unused input active-high

You manipulate the lines using debugfs as per these examples.

Pull line 1 of chip 0 high:

 echo 1 > /sys/kernel/debug/gpio-mockup/gpiochip0/1

Pull line 2 of chip 1 low:

 echo 0 > /sys/kernel/debug/gpio-mockup/gpiochip1/2

Check the value of a line, which can be set from the kernel side
for gpio output lines:

 cat /sys/kernel/debug/gpio-mockup/gpiochip0/1

Cheers,
Kent.
Kent Gibson Nov. 5, 2019, 5:34 a.m. UTC | #3
On Tue, Nov 05, 2019 at 08:12:13AM +0800, Kent Gibson wrote:
> On Mon, Nov 04, 2019 at 11:58:38AM -0800, Drew Fustini wrote:
> > On Mon, Nov 04, 2019 at 11:38:34PM +0800, Kent Gibson wrote:
> > > on a Raspberry Pi, in both cases using the feature/pud_set_config 
> > > branch of my Go gpiod library[2], as well as with my feature/pud 
> > > development branch of libgpiod[3].  Patch 7 has only been tested using 
> > > my gpiod library as libgpiod has not yet been updated to support the 
> > > SET_CONFIG ioctl.
> > > 
> > > Patch 1 adds pull-up/pull-down support to line handle requests.
> > > Patch 2 adds pull-up/pull-down support to line event requests.
> > > Patch 3 adds support for disabling bias.
> > > Patch 4 adds support for setting bias on output lines.
> > > Patch 5 adds pull-up/down support to the gpio-mockup for uAPI testing.
> > > Patch 6 refactors the flag validation from linehandle_create.
> > > Patch 7 adds the SET_CONFIG ioctl.
> > 
> > Hi Kent, thanks for continuing pushing this patch series forward.
> > 
> > I've not used gpiomockup before and I was hoping you might be able to share
> > the commands you use to run it to test the patches.
> > 
> 
> I refer you to the libgpiod tests, particularly
> libgpiod/tests/mockup/gpio-mockup.c as well as gpio/gpio-mockup.c
> itself.
> 
> If you run the libgpiod tests they will load and manipulate the module
> themselves.  My gpiod tests do similarly.  I run them in a VM to ensure
> they can't interfere with real hardware by accident.
> 

It occurs to me that you might want to know how to run the Go tests that
I'm refering to when I say I've tested against gpio-mockup using gpiod.
While that is probably obvious for Go developers, it probably isn't 
so obvious for kernel developers.

So here is a quick guide for running the gpiod tests:

1. Install Go[1].

2. Checkout gpiod:
  git clone https://github.com/warthog618/gpiod.git

3. The uapi sub-package contains the tests for the uapi itself so
  cd gpiod/uapi

4. Checkout the appropriate branch - in this case 
  git checkout feature/pud_set_config

5. Build the tests
  go test -c

6. Run the tests (requires modprobe rights hence the sudo)
  sudo ./uapi.test

You can get a list of the tests being run by adding a --test.v
parameter to uapi.test, or run particular tests with 
  uapi.test --test.run [pattern]

The tests themselves are in uapi_test.go, in case you get errors or want
to see what they do.  The gpio-mockup wrapper is in gpiod/mockup.

There are also tests for gpiod itself in gpiod/*_test.go, though 
those focus on the gpiod library rather than the uapi and kernel.

Cheers,
Kent.

[1] https://golang.org/doc/install