Re: [U-Boot] What can cause gpio_request return negative value

2019-08-29 Thread Nemanja Savic
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  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; ret =
> uclass_next_device()) {
> 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  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  wrote:
>>
>>> On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic 
>>> 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


Re: [U-Boot] What can cause gpio_request return negative value

2019-08-15 Thread Nemanja Savic
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; ret =
uclass_next_device()) {
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  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  wrote:
>
>> On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic  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ć
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] What can cause gpio_request return negative value

2019-08-15 Thread Nemanja Savic
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  wrote:

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


Re: [U-Boot] What can cause gpio_request return negative value

2019-08-15 Thread Adam Ford
On Thu, Aug 15, 2019 at 7:46 AM Nemanja Savic  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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot