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 <vlasi...@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 <vlasi...@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 <aford...@gmail.com> wrote:
>>
>>> On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic <vlasi...@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ć
>
--
Nemanja Savić
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
