How to set GPIOs to pre-defined value

[Brad Chou]

> On May 10, 2019, at 11:34 AM, Andrew Jeffery <andrew at aj.id.au> wrote:
> 
> 
> 
> On Thu, 9 May 2019, at 17:12, Brad Chou wrote:
>> 
>>> On May 8, 2019, at 9:53 AM, Andrew Jeffery <andrew at aj.id.au> wrote:
>>> 
>>> 
>>> 
>>> On Tue, 7 May 2019, at 18:23, Brad Chou wrote:
>>>> Hi Samuel,
>>>> Thanks for your reply, I am using AST2500.
>>>> I tried add gpio-hog settings into my device tree, and yes, the GPIO 
>>>> works as it defined.
>>>> But all GPIOs defined by gpio-hog can not be modified in user space by 
>>>> gpioset / gpioget utility.
>>>> I need to set all GPIOs to pre-defined state and can change it at run 
>>>> time.
>>>> Set GPIOs in Device tree is trying to lock it by a fixed direction and 
>>>> value.
>>>> 
>>> 
>>> This problem is probably best taken up with upstream. Currently GPIO
>>> nodes in the devicetree are ignored if they do not have the `gpio-hog`
>>> property:
>>> 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpiolib-of.c?h=v5.1#n454
>>> 
>>> Changing that might be a hard argument - it may impact existing
>>> devicetrees that expect the current behaviour.
>>> 
>>> However, I'm interested in what you see wrong with doing this from
>>> userspace? What requirements do you have that would need this to
>>> be done in the kernel?
>>> 
>>> Cheers,
>>> 
>>> Andrew
>> 
>> I don’t really need it to be set in the kernel.
>> Just curious about how openBMC initial all GPIOs, especially for 
>> AST2500 that has over 200+ GPIOs.
> 
> Well, the GPIOs are muxed with other functionality (LPC, I2C, SPI etc),
> and generally your platform design is going to only use a subset of the
> pins that are left for GPIO functionality, so you don't tend to need to
> initialise the state of 200+ pins. Some take fixed values, in which case
> you can use the kernel's gpio-hog mechanism to configure them.
> Accessing GPIOs at run-time generally means you want to change their
> state, in which case we usually have dedicated applications that handle
> the state transitions based on other events (e.g. "Power-on the host")
> and as such there's no need for a general "GPIO initialisation" script.
> These applications should apply the right state as part of their
> initialisation.

You are right, I should write several applications to control my GPIO state,
Instead of a general GPIO initial script to initial all of it.
Thanks for the advice. 

> 
> Does that help?
> 
> If you have requirements outside of what's outlined above then I can't
> see a problem with using a shell script to drive the libgpiod tools to
> configure the necessary GPIOs, it just depends on your requirements
> and how you feel like doing the system integration.
> 
> Cheers,
> 
> Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190510/f2f0d3af/attachment-0001.htm>