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

From: Maxime Ripard
Date: Tue Jun 16 2015 - 13:30:20 EST


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@xxxxxxxxx>
> ---
> 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: signature.asc
Description: Digital signature