[U-Boot] What can cause gpio_request return negative value
Hi all,
I am struggling with porting our old board init code for a sabre auto based custom board with i.MX6 DualLite processor. The code used to work in our older u-boot version, but what I saw in mx6qsabreauto.c is that the new style is by using new driver model which means the gpio should be first requested. However gpio_request returns negative value in my case. Where could the problem be? As far as I could see our device tree doesn't reserve this pin for other purpose. It is even not mentioned there. The only thing related to those pins are iomux pin definitions in the device tree but removing that doesn't help at all. Also device tree for the Sabre Auto board doesn't mention gpio pins that they use in their u-boot. I am dealing with 2017.03 version of u-boot.
On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic vlasinac@gmail.com wrote:
Hi all,
I am struggling with porting our old board init code for a sabre auto based custom board with i.MX6 DualLite processor. The code used to work in our older u-boot version, but what I saw in mx6qsabreauto.c is that the new style is by using new driver model which means the gpio should be first requested. However gpio_request returns negative value in my case. Where could the problem be? As far as I could see our device tree doesn't reserve this pin for other purpose. It is even not mentioned there. The only thing related to those pins are iomux pin definitions in the device tree but removing that doesn't help at all. Also device tree for the Sabre Auto board doesn't mention gpio pins that they use in their u-boot. I am dealing with 2017.03 version of u-boot.
Do you know what the negative value is? include/linux/errno.h should have a list of error numbers which should correlate to the error you're seeing. That should also tell you what the error means. From there, you should be able to search the code for where that error might return.
adam
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
It return -2 which should be -ENOENT. In the comment at the end of gpio_to_device() it is written "No such GPIO". Are there any prerequisites before calling gpio_request regarding device tree or something else?
On Thu, Aug 15, 2019 at 3:09 PM Adam Ford aford173@gmail.com wrote:
On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic vlasinac@gmail.com wrote:
Hi all,
I am struggling with porting our old board init code for a sabre auto
based
custom board with i.MX6 DualLite processor. The code used to work in our older u-boot version, but what I saw in mx6qsabreauto.c is that the new style is by using new driver model which means the gpio should be first requested. However gpio_request returns negative value in my case. Where could the problem be? As far as I could see our device tree doesn't
reserve
this pin for other purpose. It is even not mentioned there. The only
thing
related to those pins are iomux pin definitions in the device tree but removing that doesn't help at all. Also device tree for the Sabre Auto board doesn't mention gpio pins that they use in their u-boot. I am
dealing
with 2017.03 version of u-boot.
Do you know what the negative value is? include/linux/errno.h should have a list of error numbers which should correlate to the error you're seeing. That should also tell you what the error means. From there, you should be able to search the code for where that error might return.
adam
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
And to be more precise inside gpio-uclass.c, the function gpio_to_device which is called by gpio_request loops through all gpio objects in order to search for the gpio number provided never loops in my case.
puts("gpio-uclass"); for (ret = uclass_first_device(UCLASS_GPIO, &dev); dev; ret = uclass_next_device(&dev)) { puts("gpio-uclass loop\n"); ...
puts inside loop is never executed, that's why I asked if I should maybe first declare GPIOs to the system via device tree.
On Thu, Aug 15, 2019 at 4:05 PM Nemanja Savic vlasinac@gmail.com wrote:
It return -2 which should be -ENOENT. In the comment at the end of gpio_to_device() it is written "No such GPIO". Are there any prerequisites before calling gpio_request regarding device tree or something else?
On Thu, Aug 15, 2019 at 3:09 PM Adam Ford aford173@gmail.com wrote:
On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic vlasinac@gmail.com wrote:
Hi all,
I am struggling with porting our old board init code for a sabre auto
based
custom board with i.MX6 DualLite processor. The code used to work in our older u-boot version, but what I saw in mx6qsabreauto.c is that the new style is by using new driver model which means the gpio should be first requested. However gpio_request returns negative value in my case. Where could the problem be? As far as I could see our device tree doesn't
reserve
this pin for other purpose. It is even not mentioned there. The only
thing
related to those pins are iomux pin definitions in the device tree but removing that doesn't help at all. Also device tree for the Sabre Auto board doesn't mention gpio pins that they use in their u-boot. I am
dealing
with 2017.03 version of u-boot.
Do you know what the negative value is? include/linux/errno.h should have a list of error numbers which should correlate to the error you're seeing. That should also tell you what the error means. From there, you should be able to search the code for where that error might return.
adam
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
-- Nemanja Savić
This is solved. Namely, I called gpio_request from checkboard function, and it seems like at that point it is not possible to use gpios. When I moved my code to board_init it started working fine.
On Thu, Aug 15, 2019 at 4:18 PM Nemanja Savic vlasinac@gmail.com wrote:
And to be more precise inside gpio-uclass.c, the function gpio_to_device which is called by gpio_request loops through all gpio objects in order to search for the gpio number provided never loops in my case.
puts("gpio-uclass"); for (ret = uclass_first_device(UCLASS_GPIO, &dev); dev; ret = uclass_next_device(&dev)) { puts("gpio-uclass loop\n"); ...
puts inside loop is never executed, that's why I asked if I should maybe first declare GPIOs to the system via device tree.
On Thu, Aug 15, 2019 at 4:05 PM Nemanja Savic vlasinac@gmail.com wrote:
It return -2 which should be -ENOENT. In the comment at the end of gpio_to_device() it is written "No such GPIO". Are there any prerequisites before calling gpio_request regarding device tree or something else?
On Thu, Aug 15, 2019 at 3:09 PM Adam Ford aford173@gmail.com wrote:
On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic vlasinac@gmail.com wrote:
Hi all,
I am struggling with porting our old board init code for a sabre auto
based
custom board with i.MX6 DualLite processor. The code used to work in
our
older u-boot version, but what I saw in mx6qsabreauto.c is that the new style is by using new driver model which means the gpio should be first requested. However gpio_request returns negative value in my case.
Where
could the problem be? As far as I could see our device tree doesn't
reserve
this pin for other purpose. It is even not mentioned there. The only
thing
related to those pins are iomux pin definitions in the device tree but removing that doesn't help at all. Also device tree for the Sabre Auto board doesn't mention gpio pins that they use in their u-boot. I am
dealing
with 2017.03 version of u-boot.
Do you know what the negative value is? include/linux/errno.h should have a list of error numbers which should correlate to the error you're seeing. That should also tell you what the error means. From there, you should be able to search the code for where that error might return.
adam
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
-- Nemanja Savić
-- Nemanja Savić
participants (2)
-
Adam Ford -
Nemanja Savic