RE: How to use an ACPI declared GPIO in a userspace ...

[Flavio Suligoi]

Hi Andy and Bartosz,

> > >
> > > I need to expose to the userspace a GPIO, physically connected to a
> board
> > > push-button. This GPIO must expose a pre-defined name, such as
> > > "user-push-button", so that the userspace applications can use it
> without
> > > know any physical GPIO details.
> > >
> > > I can customize the board BIOS and so my goal is to add an ACPI table
> with
> > > a content like this:
> > >
> > > ...
> > > Scope (\_SB.GPO1)
> > >         {
> > >                 Device (BTNS)
> > >                 {
> > >                         Name (_HID, "PRP0001")
> > >                         Name (_DDN, "GPIO buttons device")
> > >
> > >                         Name (_CRS, ResourceTemplate ()
> > >                         {
> > >                                 GpioIo (
> > >                                 Exclusive,               // Not shared
> > >                                 PullNone,                // No need
> for pulls
> > >                                 0,                       // Debounce
> timeout
> > >                                 0,                       // Drive
> strength
> > >                                 IoRestrictionInputOnly,  // Only used
> as input
> > >                                 "\\_SB.GPO1",            // GPIO
> controller
> > >                                 0, ResourceConsumer, , ) // Must be 0
> > >                                 {
> > >                                         25,              // GPIO
> number
> > >                                 }
> > > ...
> > >
> > > I know that this GPIO can be used from other drivers.
> > > For example I successfully tested it using the "gpio-keys" device
> driver,
> > > giving to my GPIO a key-code and emulating in this way a keyboard key.
> > > This could be a possible solution.
> > >
> > > But I prefer to expose my GPIO as a classic GPIO, not as a keyboard
> key.
> > >
> > > I was wondering if there is a generic GPIO driver that I can use to
> expose
> > > this GPIO with its pre-defined name (caming from the ACPI table
> declaration),
> > > to the userspace...
> 
> Unfortunately what you are describing in the second part is rather
> property of the controller which can hog the line, but this is not
> what you want in the first part.
> The Linux kernel, in many ways, is designed that you need a driver
> (I²C user space device node is rather a mistake, but compromise for
> that time when most of the devices have access from user space
> drivers). So, the proper way is to define this as gpio-keys (either
> interrupt version or polling one) and connect a listener to the event.
> 
> Summarize: you need to describe pin(s) via "gpio-line-names" property
> of the controller (it's not so easy task if ACPI tables already have
> parts of it, but I think your case should be feasible). And either
> provide a gpio-keys device, or use line directly by name as (libgpiod
> example):
>  gpiodetect
>  gpioinfo gpiochipX
>  gpiofind $GPIO_LINE_NAME
>  gpiomon gpiochipX $(gpiofind $GPIO_LINE_NAME) &
> 
> Examples of ACPI are here [1] for controller part (look at the name
> list) and for device part [2]. You may look into other folders as
> well, though they are not so reach of examples.
> 
> [1]: https://github.com/westeri/meta-acpi/blob/master/recipes-bsp/acpi-
> tables/samples/edison/arduino.asli
> [2]: https://github.com/westeri/meta-acpi/blob/master/recipes-bsp/acpi-
> tables/samples/edison/buttons.asli
> 


I have already written and ACPI table, not in the BIOS but as separate
SSDT, loaded manually at runtime, using the gpio-keys (with interrupt)
and in this way all works good. So I have already tested this solution.

But I prefer obtain this result in the classic way, with GPIO...

So I think I'll write a device driver for it. A device driver which
reads the ACPI table and publishes the GPIO, with its name, in sysfs...


> > Adding Andy who knows ACPI GPIO well.
> 
> Thanks.
> 
> > In general, the "gpio-line-names" property is used for that and it's
> > supported both for device tree as well as ACPI, although I have only
> > ever used the former.
> 
> Right. ACPI supports properties via _DSD() method.
> 
> --
> With Best Regards,
> Andy Shevchenko

Thanks and best regards,
Flavio