Hello Linus,
On 05/30/2013 10:03 PM, Linus Walleij wrote:
On Thu, May 30, 2013 at 11:19 AM, Florian Vaussard
<[email protected]> wrote:
Even if work is progressing towards
having gpio-controlled reset pins [1], some boards still need GPIOs to
be exported to userspace for other functionalities.
Which are these?
Sorry, I should have been more precise.
When I have inquired I have heard all kind of horrible things:
- Userspace replicating drivers/leds/leds-gpio.c to
turn on/off and even PWM (!) LEDs from userspace, when we have
a standard sysfs interface for LEDs.
- Userspace replicating drivers/input/keyboard/gpio_keys[_polled].c
to "just read this one button" instead of going through the
Linux input subsystem like everyone else.
- Userspace replicating drivers/regulator/gpio-regulator.c
to "turn on just this one voltage source".
All invalid reasons for using the sysfs ABI and trying to do the
kernels work. All creating horrs for users and developers who now
have to stash everything were trying to stach into the device tree
(the above is all perfectly expressed with DT nodes) into their
userspace app and then requiring their users to match a certain
app to a certain board.
100% agree with you.
The only examples I've really come to accept considers using
things like relays and switches on factory lines where the meaning
(semantics) of the GPIOs can only be properly understood from the
GUI in the userspace APP running that factory line. Or robotics.
In both cases presumably RT processes.
Indeed, I work in a robotics lab :-) One of our board (mach-imx/
mx31moboard*.c) controls for example the multiplexing of two cameras
sharing the same acquisition bus (I know, a bit hackish).
I developed a similar board with an OMAP3. Such control do not
fit well in the above-mentioned cases, but we do not need RT processes.
Best regards,
Florian
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
