On 23/02/2018 17:27, Bartosz Golaszewski wrote:
2018-02-14 15:59 GMT+01:00 Jonas Mark (ST-FIR/ENG1) <Mark.Jonas@xxxxxxxxxxxx>:
Hello,
tl;dr: How do I set the polarity (active state) of a GPIO in the device
tree and use it from user space?
I am still not able to declare the polarity of a GPIO via device tree
so it can be used from user space using libgpio.
I read the kernel documentation and did not find hint how to do this.
What I found is how to set the polarity of a GPIO for a gpio-hog or a
kernel driver. But that prevents the GPIO being used from user space.
Thank you in advance for your help,
Mark Jonas
Hi Jonas,
the active state of a GPIO line is a consumer-specific setting. For
example: you want to indicate to the GPIO push button driver that the
line it's using is active-low so that it correctly interprets the
falling edge event as a button *press* instead of a *release*.
It doesn't make sense to set it globally for a line in the kernel.
I'm not sure this is true.
We can apply labels / names to GPIO lines and then look them up by that label form user space.
Now say I have two revisions of a board that has a control line called "SomeGPIO"
On one board it is active low. On another it is active high and on a different device.
Currently we can define a label in the DT to allow it to be easily found.
But userspace needs to know about the board revision to determine if it is active high or low.
That doesn't make sense to me. So of the hardware definition is now in the dt
and the rest is in some user application.
Currently the only way at the moment is too write a driver that consumes the GPIO
and provide a simple sysfs interface to toggle the gpio to abstract that. Things
like the led-gpio can be bastardised for that.But I think it sorta defeats the
purpose of being able to name gpio lines for user space lookup if we can't also layer
hardware constraints on that gpio from the dt.
--
Regards
Phil Reid
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
