On Tue, Sep 29, 2020 at 6:48 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
>
> On Tue, Sep 29, 2020 at 5:43 PM Flavio Suligoi <f.suligoi@xxxxxxx> wrote:
> >
> > Hi all,
> >
> > 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
> 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
