Hi Linus,
I have recently started testing a omap-lcdk board which uses the
davinci gpio driver,
and im running into an issue when i try to request a gpio larger than 31, which
i think might be a regression of gpiolib-of.
The davinci gpio driver, creates several chips, and relies in a single DT node.
in other words, davinci gpio chips have a single DT entry were ngpio = 144
but the driver internally creates multiple chips of ngpio = 32.
It used to be that gpiolib-of would iterate through all gpio chips
calling xlate until
xlate would match for the chip that can handle a particular gpio number.
Starting form a series sent on june:
"gpio: refactor of_parse_own_gpio() and of_get_named_gpiod_flags()"
https://lkml.org/lkml/2016/6/14/188
patches:
99468c1 gpio: of: factor out common code to a new helper function
762c2e4 gpio: of: remove of_gpiochip_and_xlate() and struct gg_data
1020dfd gpio: of: move chip->of_gpio_n_cells checking to of_gpiochip_add()
be71534 gpio: of: drop needless gpio_chip look-up in of_parse_own_gpio()
3f9547e gpio: of: optimize "gpios" property parsing of of_parse_own_gpio()
The gpiolib-of will fail at of_get_named_gpiod_flags the first time if the xlate
function returns error. Which means that only the first gpio chip will be tried.
For the davinci dirver, for example, we are not able to use any gpio outside of
the first gpio chip (32 gpios).
if you agree with the above, What is the best way to proceed ?
- fix the davinci gpio driver to the new behavior of gpiolib-of
- fix the gpiolib-of to loop all chips again?
- revert the patches?
Regards
Axel.
Hi Alex,
On Thu, 2016-10-20 at 17:22 +0200, Axel Haslam wrote:
> Hi Linus,
>
> I have recently started testing a omap-lcdk board which uses the
> davinci gpio driver,
> and im running into an issue when i try to request a gpio larger than 31, which
> i think might be a regression of gpiolib-of.
>
> The davinci gpio driver, creates several chips, and relies in a single DT node.
> in other words, davinci gpio chips have a single DT entry were ngpio = 144
> but the driver internally creates multiple chips of ngpio = 32.
>
> It used to be that gpiolib-of would iterate through all gpio chips
> calling xlate until
> xlate would match for the chip that can handle a particular gpio number.
>
> Starting form a series sent on june:
> "gpio: refactor of_parse_own_gpio() and of_get_named_gpiod_flags()"
> https://lkml.org/lkml/2016/6/14/188
>
> patches:
> 99468c1 gpio: of: factor out common code to a new helper function
> 762c2e4 gpio: of: remove of_gpiochip_and_xlate() and struct gg_data
> 1020dfd gpio: of: move chip->of_gpio_n_cells checking to of_gpiochip_add()
> be71534 gpio: of: drop needless gpio_chip look-up in of_parse_own_gpio()
> 3f9547e gpio: of: optimize "gpios" property parsing of of_parse_own_gpio()
>
>
> The gpiolib-of will fail at of_get_named_gpiod_flags the first time if the xlate
> function returns error. Which means that only the first gpio chip will be tried.
> For the davinci dirver, for example, we are not able to use any gpio outside of
> the first gpio chip (32 gpios).
>
> if you agree with the above, What is the best way to proceed ?
> - fix the davinci gpio driver to the new behavior of gpiolib-of
> - fix the gpiolib-of to loop all chips again?
> - revert the patches?
>
Other GPIO drivers are also affected.
This was reported for the LPC32xx platform on Tuesday:
http://www.spinics.net/lists/linux-gpio/msg17283.html
> Regards
> Axel.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Sylvain
On Thu, Oct 20, 2016 at 5:22 PM, Axel Haslam <[email protected]> wrote:
> if you agree with the above, What is the best way to proceed ?
> - fix the davinci gpio driver to the new behavior of gpiolib-of
> - fix the gpiolib-of to loop all chips again?
Either fix all users or make the same semantic come back, whatever
makes most sense and gives the cleanest code.
> - revert the patches?
Nah, it's a nice cleanup. Let's see if we can do something better first.
It should be a last resort.
Yours,
Linus Walleij