From: Flavio Suligoi <f.suligoi@asem.it>
To: Andy Shevchenko <andy.shevchenko@gmail.com>,
Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: How to use an ACPI declared GPIO in a userspace ...
Date: Tue, 29 Sep 2020 16:21:38 +0000 [thread overview]
Message-ID: <feb8567c830748c483c8c66dd4717003@asem.it> (raw)
In-Reply-To: <CAHp75VfgEGydXN1A+Y=wn3iX1MbLhN8F9kYyfQwTZBJydr+0+Q@mail.gmail.com>
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
next prev parent reply other threads:[~2020-09-29 16:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 15:37 How to use an ACPI declared GPIO in a userspace Flavio Suligoi
2020-09-29 15:47 ` Bartosz Golaszewski
2020-09-29 16:10 ` Andy Shevchenko
2020-09-29 16:21 ` Flavio Suligoi [this message]
2020-09-29 16:27 ` Andy Shevchenko
2020-09-30 12:04 ` Flavio Suligoi
2020-09-30 13:01 ` Andy Shevchenko
2020-09-30 15:39 ` Flavio Suligoi
2020-09-30 15:54 ` Andy Shevchenko
2020-09-30 16:10 ` Andy Shevchenko
2020-10-02 10:02 ` Flavio Suligoi
2020-10-02 12:48 ` Andy Shevchenko
2020-10-02 13:23 ` Andy Shevchenko
2020-10-02 13:29 ` Flavio Suligoi
2020-10-02 10:26 ` Flavio Suligoi
2020-10-02 12:40 ` Andy Shevchenko
2020-09-29 16:10 ` Flavio Suligoi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=feb8567c830748c483c8c66dd4717003@asem.it \
--to=f.suligoi@asem.it \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=brgl@bgdev.pl \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).