Hi,
Adding linux-gpio and Linus W to Cc. Some questions and comments below
towards the end.
* Niedermayr, BENEDIKT <benedikt.niedermayr@xxxxxxxxxxx> [230503 08:38]:
> 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.
Care to post what your fix for #2 above looks like?
> I'm not sure if I miss something important here?
> Are you aware of this issue?
Sounds like something needs to be implemented for pinctrl-single.c.
Regards,
Tony
