How to set GPIOs to pre-defined value

[Andrew Jeffery]

On Fri, 10 May 2019, at 20:48, Brad Chou wrote:
> 
> 
> > 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. 

Make sure you look through the phosphor-* projects under the openbmc
organisation on Github to see if the project already has something that
does what you need (you may just need to write a configuration file).

Andrew

> 
> > 
> > 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
>