On Fri, Oct 24, 2014 at 8:23 AM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote:
> On Thu, Oct 23, 2014 at 8:23 PM, Pantelis Antoniou
> <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> 2. A way to have the pinmux configuration of said GPIO configured without
>> having to do anything explicit. I.e. on am335x the pinmux configuration is
>> decoupled from the GPIO driver; having a GPIO configured as a GPIO does not
>> alter the pinmux settings.
>
> Shouldn't that be fixed in the pinmux/GPIO kernel drivers? I am not
> too familiar with pinmux, but IIUC pixmux configuration when GPIOs are
> requested is something that is commonly done.
The answer is in Documentation/pinctrl.txt:
Pin control interaction with the GPIO subsystem
===============================================
Note that the following implies that the use case is to use a certain pin
from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
and similar functions. There are cases where you may be using something
that your datasheet calls "GPIO mode", but actually is just an electrical
configuration for a certain device. See the section below named
"GPIO mode pitfalls" for more details on this scenario.
The public pinmux API contains two functions named pinctrl_request_gpio()
and pinctrl_free_gpio(). These two functions shall *ONLY* be called from
gpiolib-based drivers as part of their gpio_request() and
gpio_free() semantics. Likewise the pinctrl_gpio_direction_[input|output]
shall only be called from within respective gpio_direction_[input|output]
gpiolib implementation.
NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be
controlled e.g. muxed in. Instead, implement a proper gpiolib driver and have
that driver request proper muxing and other control for its pins.
The function list could become long, especially if you can convert every
individual pin into a GPIO pin independent of any other pins, and then try
the approach to define every pin as a function.
In this case, the function array would become 64 entries for each GPIO
setting and then the device functions.
For this reason there are two functions a pin control driver can implement
to enable only GPIO on an individual pin: .gpio_request_enable() and
.gpio_disable_free().
This function will pass in the affected GPIO range identified by the pin
controller core, so you know which GPIO pins are being affected by the request
operation.
If your driver needs to have an indication from the framework of whether the
GPIO pin shall be used for input or output you can implement the
.gpio_set_direction() function. As described this shall be called from the
gpiolib driver and the affected GPIO range, pin offset and desired direction
will be passed along to this function.
Alternatively to using these special functions, it is fully allowed to use
named functions for each GPIO pin, the pinctrl_request_gpio() will attempt to
obtain the function "gpioN" where "N" is the global GPIO pin number if no
special GPIO-handler is registered.
(...)
>> There is no higher layer driver API. We don’t want to litter the kernel
>> with ‘valve’ drivers, there’s no such thing. There’s only digital I/Os
>> that’s connected to low speed devices.
This is true.
But we do want the kernel to handle: LEDs, switches, PWMs, and
other simple, yet normally kernel-business things. Here is an example:
/* The user LED on the board is set up to be used for heartbeat */
leds {
compatible = "gpio-leds";
user-led {
label = "user_led";
gpios = <&gpio0 2 0x1>;
default-state = "off";
linux,default-trigger = "heartbeat";
pinctrl-names = "default";
pinctrl-0 = <&user_led_default_mode>;
};
};
/* User key mapped in as "escape" */
gpio-keys {
compatible = "gpio-keys";
user-button {
label = "user_button";
gpios = <&gpio0 3 0x1>;
linux,code = <1>; /* KEY_ESC */
gpio-key,wakeup;
pinctrl-names = "default";
pinctrl-0 = <&user_button_default_mode>;
};
};
This is just setting up already existing in-kernel drivers to
use GPIOs as backend for a LED and a key (switch).
Is someone prefers to handle LEDs or keys in userspace
they are plain *WRONG* from our point of view.
I agree that valves and doors should not have kernel drivers,
that is not the issue. They should probably use sysfs. But for
hardware the kernel normally handles and that is not exceptional,
no way.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
