lkml.org 
[lkml]   [2020]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: How to use an ACPI declared GPIO in a userspace ...
    Date
    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

    \
     
     \ /
      Last update: 2020-09-29 18:22    [W:4.412 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site