Hello,
We encountered some issues when accessing the gpiochardev interface on an
AM65xx plaform.
The basic idea was to fully rely on all features the gpiochardev seems to
offer.
I got all relevant information from the Linux Kernel Documentation
(Documentation/driver-api/pin-control.rst) and saw
some presentations from Linus Walleij regarding the gpiochardev
capabilities.
If I understand that correctly the gpiochardev interface should support the
following features:
* Requesting gpio pins from userspace
* Set input/output directions
* Set BIAS settings (pull-up, pull-down, etc.)
* Gpio function of that pin automatically gets muxed in if requested
Requesting pins worked for me as expected after I added the required DTB
properties:
* pinctrl-single: Add each required pin to "pinctrl-single,gpio-range" in
the pincontroller node
* gpio: Add each required pin to gpio-range property in the gpio node
I also added the required childnodes in the pinctrl node:
&main_pmx0 {
...
d6_gpio: d6-gpio {
pinctrl-single,pins = <
/* (AH16) GPIO0_38 */
AM65X_IOPAD(0x0098, PIN_INPUT, 7)
>;
pinctrl-single,bias-pullup = <0x20000 0x20000 0x10000 0x30000>;
pinctrl-single,bias-pulldown = <0x00000 0x0 0x10000 0x30000>;
};
...
}
When I tried to set any BIAS settings nothing happened or some error occured
in the kernel logs (i'm not 100% sure anymore since almost 2 months have
past).
The first thing I had to do was to assign the gpiochip_generic_config
callback to the gpiochiop for that (gpio-davinci.c). This callback in turn
will finally call pcs_pinconf_set(), which
is the pinctrl drivers related callback for setting the pinconf.
But still no success...
Then I went deeper into the rabbit whole and encountered that the error had
to do with pcs_get_function() (pinctrl-single.c).
I found out that this function requests the current function (or pinmux
state) from the pinctrl subsystem core.
The pinctrl driver needs this information for accessing the correct pinctrl
childnode bits.
So what is the Problem here?
The pinctrl offers 3 different options for muxing:
1. Using the generic kernel APIs:
Call pinctrl_select_state() function as stated
in Documentation/driver-api/pin-control.rst (section "Pin control requests
from drivers").
This function will select a defined state which has been defined in DTB
with "pinctrl-0", "pinctrl-1", "pinctrl-x"
2. Mux pins with debugfs:
Write the desired pingroup and pinfunction into the "pinmux-select"
file of the related pin controller.
3. Mux the GPIO function of a requested GPIO pin by calling the pinctrl
drivers pcs_request_gpio() function.
The problem now is that only option 1. will store the current mux
information in the pinctrl subsystems core.
The pinctrl-single driver highly depends on that information, which is not
available at all wenn muxing with options 2&3.
I was able to fix that for option 2 but not for option 3. The problem here
is that the pcs_request_gpio() function just does not provide enough
parameters with sufficient information for achieving that task.
I'm not sure if I miss something important here?
Are you aware of this issue?
Cheers,
benedikt
