On Thu, May 4, 2023 at 7:35 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Niedermayr, BENEDIKT <benedikt.niedermayr@xxxxxxxxxxx> [230503 08:38]: > > We encountered some issues when accessing the gpiochardev interface on an > > AM65xx plaform. Thank you for using contemporary APIs! > > 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. The fact that 3) doesn't work has to do with how pinctrl-single has been engineered I think, what the pinctrl_ops .gpio_request_enable/ .gpio_disable_free/.gpio_set_direction provide is a "shortcut" for drivers that want to take it, in case they can provide the right information. The pinctrl-single driver only implements .gpio_request_enable() but often that is enough. Then it is the callbacks for generic config that you said you already added to gpio-davinci.c, so that part should be fine, patches welcome! Yours, Linus Walleij
