Re: [PATCH] [RFC] gpio: Retry deferred GPIO hogging on pin range change

[Maxime Ripard <maxime.ripard@free-electrons.com>]

[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]

Hi Geert,

On Tue, Jun 16, 2015 at 02:36:48PM +0200, Geert Uytterhoeven wrote:
> If a GPIO driver uses gpiochip_add_pin_range() (which is usually the
> case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT
> doesn't work:
> 
>     requesting hog GPIO lcd0 (chip r8a7740_pfc, offset 176) failed
> 
> The actual error code is -517 == -EPROBE_DEFER.
> 
> The problem is that PFC+GPIO registration is handled in multiple steps:
>   1. pinctrl_register(),
>   2. gpiochip_add(),
>   3. gpiochip_add_pin_range().
> 
> Configuration of the hogs is handled in gpiochip_add():
> 
>     gpiochip_add
>         of_gpiochip_add
>             of_gpiochip_scan_hogs
>                 gpiod_hog
>                     gpiochip_request_own_desc
>                         __gpiod_request
>                             chip->request
>                                 pinctrl_request_gpio
>                                     pinctrl_get_device_gpio_range
> 
> However, at this point the GPIO controller hasn't been added to
> pinctrldev_list yet, so the range can't be found, and the operation fails
> with -EPROBE_DEFER.
> 
>   - Exchanging the order of the calls to gpiochip_add() and
>     gpiochip_add_pin_range() is not an option, as the latter depends on
>     initialization done by the former.
>   - Just moving the call of of_gpiochip_scan_hogs() from gpiochip_add()
>     to gpiochip_add_pin_range() is also not an option, as the latter is
>     optional, and thus not used by all drivers.
> 
> Hence if of_gpiochip_scan_hogs() fails with -EPROBE_DEFER, call it
> again every time the pin range is changed, until it succeeded.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Questions:
>   - Is there a better solution to handle this?
> 
>   - Should the pin ranges be configured by passing an array of data to
>     gpiochip_add() instead of having calls to gpiochip_add_pin_range()?
>     That would require changing all drivers.
> 
>   - What happens if you have multiple hogs in multiple ranges?
>     The first hog(s) may be configured multiple times.  Is that a problem?
> 
>   - In one of the threads that discussed the GPIO hogging mechanism, Maxime
>     Ripard said: "Our pinctrl driver is also our GPIO driver, so they both
>     share the same node."
>     Maxime: Did you try GPIO hogging? Did it work?
>     If yes, which driver are you using? What's different compared to sh-pfc?
>     If no, did you get it to work?

I'm using pinctrl-sunxi, and no, I haven't tried it yet, so it
probably have the issue you reported :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]