How to set GPIO state in the dts or in platform

How to set GPIO state in the dts or in platform

[Ayman El-Khashab]

I've got a custom board akin to the walnut.  I've successfully got u-boot,
the kernel, and a working filesystem.  The only thing I lack is a clear idea
of how to set a GPIO. 

I have the PHY reset connected to GPIO 3.  I've got it setup in u-boot
correctly, but by the time linux boots, it has touched the GPIOs and now the
PHY is held in reset.  I tried to follow how to adjust my device tree, 
but I
haven't been able to get it to work yet.  My kernel (circa mid 2008) 
doesn't
have the "keep" property of the GPIO node, so I can't use that. 

Based on what I've read it seems that I might need to add a node to the dts
and then a custom piece of code in the platform directory for my board.  I
am just not sure how to proceed there.

thanks
ayman

Re: How to set GPIO state in the dts or in platform

[Bill Gatliff]

Ayman El-Khashab wrote:
> I've got a custom board akin to the walnut.  I've successfully got
> u-boot,
> the kernel, and a working filesystem.  The only thing I lack is a
> clear idea
> of how to set a GPIO.

Isn't that the "flags" parameter, e.g.:

gpios = <phandle gpioid flags>

?

If you are passing a 0 for the flags, try a 1.  I know of at least one
driver that interprets that to mean a polarity inversion.  Maybe you'll
get lucky.  :)


b.g.

-- 
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com

Re: How to set GPIO state in the dts or in platform

[Ayman El-Khashab]

On 1/5/2010 10:38 PM, Bill Gatliff wrote:
> Ayman El-Khashab wrote:
>   
>> I've got a custom board akin to the walnut.  I've successfully got
>> u-boot,
>> the kernel, and a working filesystem.  The only thing I lack is a
>> clear idea
>> of how to set a GPIO.
>>     
>
> Isn't that the "flags" parameter, e.g.:
>
> gpios = <phandle gpioid flags>
>
> ?
>
> If you are passing a 0 for the flags, try a 1.  I know of at least one
> driver that interprets that to mean a polarity inversion.  Maybe you'll
> get lucky.  :)
>
>   
Possibly, I saw that in the documentation directory, but didn't quite 
follow the explanation that
was given.  Below is what I was using as  a reference, but is it as 
simple as that?  Do the flags encode
just the state or also, the open drain, hi-z and everything else?  In my 
case, I want the GPIO 3 actively
driven high.


Example of the node using GPIOs:
20	
21		node {
22			gpios = <&qe_pio_e 18 0>;
23		};
24	
25	In this example gpio-specifier is "18 0" and encodes GPIO pin number,
26	and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.

Re: How to set GPIO state in the dts or in platform

[Bill Gatliff]

Ayman El-Khashab wrote:
> On 1/5/2010 10:38 PM, Bill Gatliff wrote:
>> Ayman El-Khashab wrote:
>>  
>>> I've got a custom board akin to the walnut.  I've successfully got
>>> u-boot,
>>> the kernel, and a working filesystem.  The only thing I lack is a
>>> clear idea
>>> of how to set a GPIO.
>>>     
>>
>> Isn't that the "flags" parameter, e.g.:
>>
>> gpios = <phandle gpioid flags>
>>
>> ?
>>
>> If you are passing a 0 for the flags, try a 1.  I know of at least one
>> driver that interprets that to mean a polarity inversion.  Maybe you'll
>> get lucky.  :)
>>
>>   
> Possibly, I saw that in the documentation directory, but didn't quite
> follow the explanation that
> was given.  Below is what I was using as  a reference, but is it as
> simple as that?  Do the flags encode
> just the state or also, the open drain, hi-z and everything else?  In
> my case, I want the GPIO 3 actively
> driven high.

The flags can encode everything, or nothing.  It all depends on what the
caller of of_get_gpio_flags() does with them.  (Note that I'm not an
authority on this topic, I'm just telling what I've learned about it
recently).

For example, in of_mpc8xxx_spi_get_chipselects(), the flag is tested
against OF_GPIO_ACTIVE_LOW, and the result is passed to
gpio_direction_output() as the initial value.  So it both inverts the
sense of the pin, and sets its initial state.

In of_gpio_leds_probe(), the flag is tested against OF_GPIO_ACTIVE_LOW
as well.

In both of the above examples, the drivers can make assumptions about
things like the pin must be an output, will be actively driven in either
direction, and so on.  The convention is for the flag to be a bitmap of
values from the of_gpio_flags enumeration, but the only value there
is--- you guessed it--- OF_GPIO_ACTIVE_LOW.  :)

If you provide your own xlate() function in a of_gpio_chip driver, you
can make the flags mean anything you want.  As for anywhere you call
of_gpio_get_flags().  For now, the only established interpretation is
the OF_GPIO_ACTIVE_LOW one.


b.g.

-- 
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com