/sys/class/gpio behaviour changed in newer Raspbian?

[panik]

Interfacing /sys/class/gpio on the new firmware (Raspbian 2015-01-31) seems different than older firmware.

On older firmware, the following script leaves an LED connected to GPIO 4 on after the script finishes (and keeps the pin an output). In the new firmware, the LED turns off after 1 second (and the pin returns to an input) even though the script never explicitly told it to.

Code: Select all

#!/bin/bash

echo "4" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio4/direction
echo "1" > /sys/class/gpio/gpio4/value

sleep 1

echo "4" > /sys/class/gpio/unexport

This happens on both the Model B+ and the new Pi 2 with the 2015-01-31 Raspbian with 'apt-get upgrade' (no rpi-update).

Is there a way around it and get the old behaviour back?

[notro]

With Device Tree a new gpio driver is used: pinctrl-bcm2835.
When you unexport, the pin is set back as input. If you want to keep it, don't unexport it.
Unexporting tells Linux that you don't use the pin anymore.

Call cain:
unexport_store() => gpiod_free() => __gpiod_free() => chip->free():bcm2835_gpio_free() => pinctrl_free_gpio() => pinmux_free_gpio() => pin_free() => ops->gpio_disable_free():bcm2835_pmx_gpio_disable_free()

Code: Select all

static void bcm2835_pmx_gpio_disable_free(struct pinctrl_dev *pctldev,
                struct pinctrl_gpio_range *range,
                unsigned offset)
{
        struct bcm2835_pinctrl *pc = pinctrl_dev_get_drvdata(pctldev);

        /* disable by setting to GPIO_IN */
        bcm2835_pinctrl_fsel_set(pc, offset, BCM2835_FSEL_GPIO_IN);
}

Refs:
- http://lxr.free-electrons.com/ident?i=unexport_store
- http://lxr.free-electrons.com/ident?i=b ... sable_free

[panik]

Ah yes, that explains it. After disabling it by adding 'device_tree=' in /boot/config.txt, the old behaviour is back.

I'll look into cleaner ways of handling this new 'device tree' thing, but at least everything is working again for now.

Thanks for the in-depth answer!

[FTrevorGowen]

With Device Tree a new gpio driver is used: pinctrl-bcm2835.
When you unexport, the pin is set back as input. If you want to keep it, don't unexport it.
Unexporting tells Linux that you don't use the pin anymore.
...

To some extent this behaviour is what I thought "ought to happen" but didn't (and thus now "breaks" some of my 'C' demo. (G)LCD display programs which used wiringPi's variant of the export process, unexporting all used pins on closure - ie. backlights turned on via an exported pin now turn off shortly after exit). So that leads to two questions:
1) Is it O.K. to re-request a pin to be exported that hasn't been unexported previously (as opposed to one that's never been exported)?
2) If not, is there a "robust" or "preferred" way of testing whether a pin has previously been exported (and still is)?
Trev.

[notro]

1) Is it O.K. to re-request a pin to be exported that hasn't been unexported previously (as opposed to one that's never been exported)?
2) If not, is there a "robust" or "preferred" way of testing whether a pin has previously been exported (and still is)?

Re-requesting returns an error, because the pin is in use.
Check for the /sys/class/gpio/gpioNN directory to see if the pin has been exported to userspace.

Code: Select all

$ sudo -i
# cd /sys/class/gpio/
# echo 4 > export
# ls -l gpio4
lrwxrwxrwx 1 root gpio 0 Feb  8 20:14 gpio4 -> ../../devices/soc/3f200000.gpio/gpio/gpio4
# echo 4 > export
bash: echo: write error: Device or resource busy
#
# echo 4 > unexport
# ls -l gpio4
ls: cannot access gpio4: No such file or directory
#

[FTrevorGowen]

1) Is it O.K. to re-request a pin to be exported that hasn't been unexported previously (as opposed to one that's never been exported)?
2) If not, is there a "robust" or "preferred" way of testing whether a pin has previously been exported (and still is)?

Re-requesting returns an error, because the pin is in use.
Check for the /sys/class/gpio/gpioNN directory to see if the pin has been exported to userspace.

Code: Select all

$ sudo -i
# cd /sys/class/gpio/
# echo 4 > export
# ls -l gpio4
lrwxrwxrwx 1 root gpio 0 Feb  8 20:14 gpio4 -> ../../devices/soc/3f200000.gpio/gpio/gpio4
# echo 4 > export
bash: echo: write error: Device or resource busy
#
# echo 4 > unexport
# ls -l gpio4
ls: cannot access gpio4: No such file or directory
#

Hmmm... I had a "nasty suspicion" that it'd be something like that. I'll have to check exactly how gordon (drogon) does the export etc. in his wiringPi 'C' library, since, in practice, I currently perform a 'C' system call to his gpio program from that.
Trev.