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

DISCUSSION Flavio Suligoi 3 participants 17 messages Sep 29, 2020 – Oct 2, 2020

Subsystems (2)

ACPI GPIO

lore

Share & tools

lore

Flavio Suligoi

author

2020-09-29 15:42 UTC #0 lore raw

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

Best regards,

Flavio

Bartosz Golaszewski

2020-09-29 15:48 UTC #1 lore raw

Quoted 41 lines · Flavio Suligoi

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.

Quoted 7 lines

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...
Best regards,
Flavio

Adding Andy who knows ACPI GPIO well.

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.

Bartosz

Andy Shevchenko

2020-09-29 16:10 UTC #2 lore raw

Quoted 41 lines · Bartosz Golaszewski

Quoted 39 lines · Flavio Suligoi
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.

Quoted 5 lines

Quoted 5 lines
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

Quoted 1 line

Adding Andy who knows ACPI GPIO well.

Thanks.

Quoted 3 lines

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.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Flavio Suligoi

author

2020-09-29 16:21 UTC #3 lore raw

Hi Andy and Bartosz,

Quoted 75 lines

Quoted 2 lines
Quoted 2 lines
I need to expose to the userspace a GPIO, physically connected to a
board
Quoted 2 lines
Quoted 2 lines
push-button. This GPIO must expose a pre-defined name, such as "user-push-button", so that the userspace applications can use it
without
Quoted 3 lines
Quoted 3 lines
know any physical GPIO details.
I can customize the board BIOS and so my goal is to add an ACPI table
with
Quoted 10 lines
Quoted 10 lines
a content like this:
...
Scope (\_SB.GPO1)
        {
                Device (BTNS)
                {
                        Name (_HID, "PRP0001")
                        Name (_DDN, "GPIO buttons device")
Quoted 5 lines
Quoted 5 lines
Name (_CRS, ResourceTemplate () {
GpioIo (
Exclusive, // Not shared
PullNone, // No need
for pulls
Quoted 1 line
Quoted 1 line
0, // Debounce
timeout
Quoted 1 line
Quoted 1 line
0, // Drive
strength
Quoted 1 line
Quoted 1 line
IoRestrictionInputOnly, // Only used
as input
Quoted 1 line
Quoted 1 line
                                "\\_SB.GPO1",            // GPIO
controller
Quoted 3 lines
Quoted 3 lines
0, ResourceConsumer, , ) // Must be 0 {
25, // GPIO
number
Quoted 5 lines
Quoted 5 lines
                                }
...
I know that this GPIO can be used from other drivers. For example I successfully tested it using the "gpio-keys" device
driver,
Quoted 4 lines
Quoted 4 lines
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.
Quoted 2 lines
Quoted 2 lines
I was wondering if there is a generic GPIO driver that I can use to
expose
Quoted 1 line
Quoted 1 line
this GPIO with its pre-defined name (caming from the ACPI table
declaration),
Quoted 1 line
Quoted 1 line
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) &

Quoted 9 lines

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

Quoted 8 lines

Quoted 1 line
Adding Andy who knows ACPI GPIO well.
Thanks.
Quoted 3 lines
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.

Quoted 5 lines

Right. ACPI supports properties via _DSD() method.
--
With Best Regards,
Andy Shevchenko

Thanks and best regards,
Flavio

Andy Shevchenko

2020-09-29 16:27 UTC #4 lore raw

Quoted 83 lines · Flavio Suligoi

Quoted 74 lines
Quoted 1 line
Quoted 1 line
I need to expose to the userspace a GPIO, physically connected to a
board
Quoted 2 lines
Quoted 2 lines
push-button. This GPIO must expose a pre-defined name, such as "user-push-button", so that the userspace applications can use it
without
Quoted 3 lines
Quoted 3 lines
know any physical GPIO details.
I can customize the board BIOS and so my goal is to add an ACPI table
with
Quoted 10 lines
Quoted 10 lines
a content like this:
...
Scope (\_SB.GPO1)
        {
                Device (BTNS)
                {
                        Name (_HID, "PRP0001")
                        Name (_DDN, "GPIO buttons device")
Quoted 5 lines
Quoted 5 lines
Name (_CRS, ResourceTemplate () {
GpioIo (
Exclusive, // Not shared
PullNone, // No need
for pulls
Quoted 1 line
Quoted 1 line
0, // Debounce
timeout
Quoted 1 line
Quoted 1 line
0, // Drive
strength
Quoted 1 line
Quoted 1 line
IoRestrictionInputOnly, // Only used
as input
Quoted 1 line
Quoted 1 line
                                "\\_SB.GPO1",            // GPIO
controller
Quoted 3 lines
Quoted 3 lines
0, ResourceConsumer, , ) // Must be 0 {
25, // GPIO
number
Quoted 5 lines
Quoted 5 lines
                                }
...
I know that this GPIO can be used from other drivers. For example I successfully tested it using the "gpio-keys" device
driver,
Quoted 4 lines
Quoted 4 lines
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.
Quoted 2 lines
Quoted 2 lines
I was wondering if there is a generic GPIO driver that I can use to
expose
Quoted 1 line
Quoted 1 line
this GPIO with its pre-defined name (caming from the ACPI table
declaration),
Quoted 1 line
Quoted 1 line
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) &
Quoted 8 lines
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

Quoted 8 lines

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

Maybe I was not so clear, but as Bart mentioned the least you can do is simply define line name via "gpio-line-names" property. The problem here is when and how you would like to have them incorporated.
When: if ACPI tables are being provided by firmware which you may not alter, then you must use initramfs type of solution (no configfs, don't know about EFI var though). How: In that case you might have a chance to incorporate _DSD() method into *existing* _CRS() one. Possible impediments: if ACPI table from firmware already has a _DSD() defined or above is not working for some reason. In such a case you must upgrade entire DSDT via initramfs.

Quoted 9 lines

Quoted 9 lines
Quoted 1 line
Adding Andy who knows ACPI GPIO well.
Thanks.
Quoted 3 lines
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.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Flavio Suligoi

author

2020-09-30 12:04 UTC #5 lore raw

Hi Andy,

Quoted 4 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
I was wondering if there is a generic GPIO driver that I can use
Maybe I was not so clear, but as Bart mentioned the least you can do is simply define line name via "gpio-line-names" property. The problem here is when and how you would like to have them incorporated.

I already tried adding the "gpio-line-names" property, but the problem is the same: no driver asks for this GPIO, as shown by the following kernel messages:

ACPI: Host-directed Dynamic ACPI Table Load:
ACPI: SSDT 0xFFFF994034D42A00 0000E8 (v05 ASEMsp GPIO_BTN 00000001 INTL 20200717)
ACPI: \_SB_.GPO1.BTNS: PRP0001 requires 'compatible' property

So I'll start to write a simple device driver to use this GPIO. I'll keep you informed!

Quoted 16 lines

When: if ACPI tables are being provided by firmware which you may not alter, then you must use initramfs type of solution (no configfs, don't know about EFI var though). How: In that case you might have a chance to incorporate _DSD() method into *existing* _CRS() one. Possible impediments: if ACPI table from firmware already has a _DSD() defined or above is not working for some reason. In such a case you must upgrade entire DSDT via initramfs.
Quoted 8 lines
Quoted 8 lines
Quoted 1 line
Adding Andy who knows ACPI GPIO well.
Thanks.
Quoted 3 lines
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.

Quoted 5 lines

Quoted 1 line
Quoted 1 line
Right. ACPI supports properties via _DSD() method.
--
With Best Regards,
Andy Shevchenko

Thanks Andy and Bartosz for your support!
Best regards,

Flavio

Andy Shevchenko

2020-09-30 13:01 UTC #6 lore raw

Quoted 9 lines · Flavio Suligoi

Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
I was wondering if there is a generic GPIO driver that I can use
Maybe I was not so clear, but as Bart mentioned the least you can do is simply define line name via "gpio-line-names" property. The problem here is when and how you would like to have them incorporated.
I already tried adding the "gpio-line-names" property, but the problem is the same: no driver asks for this GPIO, as shown by the following kernel messages:

Quoted 24 lines

ACPI: Host-directed Dynamic ACPI Table Load:
ACPI: SSDT 0xFFFF994034D42A00 0000E8 (v05 ASEMsp GPIO_BTN 00000001 INTL 20200717)
ACPI: \_SB_.GPO1.BTNS: PRP0001 requires 'compatible' property
So I'll start to write a simple device driver to use this GPIO. I'll keep you informed!
Quoted 17 lines
When: if ACPI tables are being provided by firmware which you may not alter, then you must use initramfs type of solution (no configfs, don't know about EFI var though). How: In that case you might have a chance to incorporate _DSD() method into *existing* _CRS() one. Possible impediments: if ACPI table from firmware already has a _DSD() defined or above is not working for some reason. In such a case you must upgrade entire DSDT via initramfs.
Quoted 9 lines
Quoted 9 lines
Quoted 1 line
Adding Andy who knows ACPI GPIO well.
Thanks.
Quoted 3 lines
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.

I guess you simply didn't get. The "gpio-line-names" property of GPIO *controller* (provider!) and you are trying to do something with the *consumer* if I got it right.

And of course GPIO line, which has name, has no difference in use from another w/o name assigned. You will need to request it by *consumer* either in kernel or in user space.

To be more precise we have to look at your DSDT.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Flavio Suligoi

author

2020-09-30 15:39 UTC #7 lore raw

Hi Andy,

Quoted 11 lines

I guess you simply didn't get. The "gpio-line-names" property of GPIO *controller* (provider!) and you are trying to do something with the *consumer*
if I got it right.
And of course GPIO line, which has name, has no difference in use from another
w/o name assigned. You will need to request it by *consumer* either in kernel
or in user space.

Quoted 6 lines

To be more precise we have to look at your DSDT.
--
With Best Regards,
Andy Shevchenko

My SSDT table is:

DefinitionBlock ("gpio_button.aml", "SSDT", 5, "ASEMsp", "GPIO_BTN", 1)

{
	External (_SB_.GPO1, DeviceObj)

	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
				{
					1,              // GPIO number
				}
			})
	
			Name (_DSD, Package () {
				ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
				Package () {
					Package () {
						"gpio-line-names",
						Package () {
							"USER_PUSH_BUTTON",
						}
					},
				}
			})
		}
	}
}

And the kernel messages, after loading the table, are:

ACPI: Host-directed Dynamic ACPI Table Load:
ACPI: SSDT 0xFFFF908274285200 0000E8 (v05 ASEMsp GPIO_BTN 00000001 INTL 20200717)
ACPI: \_SB_.GPO1.BTNS: PRP0001 requires 'compatible' property

So I need a "consumer", but I don't want to export the GPIO using its number... If you have any suggestion ...

Thanks!

Flavi

Andy Shevchenko

2020-09-30 15:55 UTC #8 lore raw

Quoted 5 lines · Flavio Suligoi

Quoted 5 lines
I guess you simply didn't get. The "gpio-line-names" property of GPIO *controller* (provider!) and you are trying to do something with the *consumer*
if I got it right.

Quoted 7 lines

Quoted 7 lines
And of course GPIO line, which has name, has no difference in use from another
w/o name assigned. You will need to request it by *consumer* either in kernel
or in user space.
To be more precise we have to look at your DSDT.

^^^^^^^ **DSDT**.

Quoted 1 line

My SSDT table is:

^^^^ See the difference? I can't help here.

Quoted 41 lines

DefinitionBlock ("gpio_button.aml", "SSDT", 5, "ASEMsp", "GPIO_BTN", 1)

{
        External (_SB_.GPO1, DeviceObj)

        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
                                {
                                        1,              // GPIO number
                                }
                        })

                        Name (_DSD, Package () {
                                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                                Package () {
                                        Package () {
                                                "gpio-line-names",
                                                Package () {
                                                        "USER_PUSH_BUTTON",
                                                }
                                        },
                                }
                        })
                }
        }
}

Quoted 8 lines

And the kernel messages, after loading the table, are:
ACPI: Host-directed Dynamic ACPI Table Load:
ACPI: SSDT 0xFFFF908274285200 0000E8 (v05 ASEMsp GPIO_BTN 00000001 INTL 20200717)
ACPI: \_SB_.GPO1.BTNS: PRP0001 requires 'compatible' property
So I need a "consumer", but I don't want to export the GPIO using its number... If you have any suggestion ...

Define "gpio-line-names" property in the *provider* (controller) device node _DSD().

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Andy Shevchenko

2020-09-30 16:11 UTC #9 lore raw

Quoted 12 lines · Andy Shevchenko

Quoted 11 lines · Flavio Suligoi
Quoted 11 lines
I guess you simply didn't get. The "gpio-line-names" property of GPIO *controller* (provider!) and you are trying to do something with the *consumer*
if I got it right.
And of course GPIO line, which has name, has no difference in use from another
w/o name assigned. You will need to request it by *consumer* either in kernel
or in user space.

Quoted 7 lines

Quoted 1 line
Quoted 1 line
To be more precise we have to look at your DSDT.
^^^^^^^ **DSDT**.
Quoted 1 line
My SSDT table is:
^^^^ See the difference? I can't help here.

There are two ways to get DSDT:
1. % cp -a /sys/firmware/acpi/tables /tmp/mytables; tar -cf
mytables.tar /tmp/mytables
2. % acpidump -o mytables.dat # preferable

Quoted 5 lines

Quoted 2 lines
So I need a "consumer", but I don't want to export the GPIO using its number... If you have any suggestion ...
Define "gpio-line-names" property in the *provider* (controller) device node _DSD().

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Flavio Suligoi

author

2020-10-02 10:02 UTC #10 lore raw

Hi Andy,

sorry for the delay!

Quoted 3 lines

Quoted 3 lines
Quoted 1 line
My SSDT table is:
^^^^ See the difference? I can't help here.

This is the DSDT table related to the GPIO controller of my board:

Device (GPO1)

        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "INT3452")  // _HID: Hardware ID
            Name (_CID, "INT3452")  // _CID: Compatible ID
            Name (_DDN, "General Purpose Input/Output (GPIO) Controller - Northwest")  // _DDN: DOS Device Name
            Name (_UID, 0x02)  // _UID: Unique ID
            Name (RBUF, ResourceTemplate ()
            {
                Memory32Fixed (ReadWrite,
                    0x00000000,         // Address Base
                    0x00004000,         // Address Length
                    _Y08)
                Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                {
                    0x0000000E,
                }
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                CreateDWordField (RBUF, \_SB.GPO1._Y08._BAS, B0BA)  // _BAS: Base Address
                CreateDWordField (RBUF, \_SB.GPO1._Y08._LEN, B0LN)  // _LEN: Length
                B0BA = GP1A /* \GP1A */
                B0LN = GP1L /* \GP1L */
                Return (RBUF) /* \_SB_.GPO1.RBUF */
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If ((OSYS < 0x07DC))
                {
                    Return (Zero)
                }

                Return (0x0F)
            }
        }

Quoted 3 lines

--
With Best Regards,
Andy Shevchenko

Best regards,

Flavio

Andy Shevchenko

2020-10-02 12:48 UTC #11 lore raw

Quoted 35 lines · Flavio Suligoi

Quoted 3 lines

Quoted 3 lines
Quoted 1 line
My SSDT table is:
^^^^ See the difference? I can't help here.

This is the DSDT table related to the GPIO controller of my board:

Device (GPO1)

        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "INT3452")  // _HID: Hardware ID
            Name (_CID, "INT3452")  // _CID: Compatible ID
            Name (_DDN, "General Purpose Input/Output (GPIO) Controller - Northwest")  // _DDN: DOS Device Name
            Name (_UID, 0x02)  // _UID: Unique ID
            Name (RBUF, ResourceTemplate ()
            {
                Memory32Fixed (ReadWrite,
                    0x00000000,         // Address Base
                    0x00004000,         // Address Length
                    _Y08)
                Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                {
                    0x0000000E,
                }
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                CreateDWordField (RBUF, \_SB.GPO1._Y08._BAS, B0BA)  // _BAS: Base Address
                CreateDWordField (RBUF, \_SB.GPO1._Y08._LEN, B0LN)  // _LEN: Length
                B0BA = GP1A /* \GP1A */
                B0LN = GP1L /* \GP1L */
                Return (RBUF) /* \_SB_.GPO1.RBUF */
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {

Quoted 8 lines

                If ((OSYS < 0x07DC))
                {
                    Return (Zero)
                }

                Return (0x0F)
            }
        }

So, what about adding the following

DefinitionBlock ("linename.aml", "SSDT", 5, "", "LINENAME", 1) {
External (_SB_.GPO1, DeviceObj)
Scope (\_SB.GPO1)

  {
      Name (_DSD, Package () {
          ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
          Package () {
              Package () {
                  "gpio-line-names",
                  Package () {
                      "Line0",
                      "Line1",
                      "Line2",
                      ...
                  }
              },
          }
      })

}
}

(Replace '...' with meaningful line names or drop for now, but in any case you need to provide as much names as lines of such GPIO controller)

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Andy Shevchenko

2020-10-02 13:23 UTC #12 lore raw

Quoted 68 lines · Andy Shevchenko

Quoted 35 lines · Flavio Suligoi

Quoted 3 lines

Quoted 3 lines
Quoted 1 line
My SSDT table is:
^^^^ See the difference? I can't help here.

This is the DSDT table related to the GPIO controller of my board:

Device (GPO1)

        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "INT3452")  // _HID: Hardware ID
            Name (_CID, "INT3452")  // _CID: Compatible ID
            Name (_DDN, "General Purpose Input/Output (GPIO) Controller - Northwest")  // _DDN: DOS Device Name
            Name (_UID, 0x02)  // _UID: Unique ID
            Name (RBUF, ResourceTemplate ()
            {
                Memory32Fixed (ReadWrite,
                    0x00000000,         // Address Base
                    0x00004000,         // Address Length
                    _Y08)
                Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                {
                    0x0000000E,
                }
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                CreateDWordField (RBUF, \_SB.GPO1._Y08._BAS, B0BA)  // _BAS: Base Address
                CreateDWordField (RBUF, \_SB.GPO1._Y08._LEN, B0LN)  // _LEN: Length
                B0BA = GP1A /* \GP1A */
                B0LN = GP1L /* \GP1L */
                Return (RBUF) /* \_SB_.GPO1.RBUF */
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {

Quoted 8 lines

                If ((OSYS < 0x07DC))
                {
                    Return (Zero)
                }

                Return (0x0F)
            }
        }

So, what about adding the following

DefinitionBlock ("linename.aml", "SSDT", 5, "", "LINENAME", 1) {
External (_SB_.GPO1, DeviceObj)
Scope (\_SB.GPO1)

  {
      Name (_DSD, Package () {
          ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
          Package () {
              Package () {
                  "gpio-line-names",
                  Package () {
                      "Line0",
                      "Line1",
                      "Line2",
                      ...
                  }
              },
          }
      })

Quoted 8 lines

}
}
?
(Replace '...' with meaningful line names or drop for now, but in any case you need to provide as much names as lines of such GPIO controller)

I have checked the code, so it allows you to define from 0 up to all lines, but no gaps.
Thus, I have dropped '...' line in above excerpt, added the compiled AML to initramfs (initrd method) and voila!

% gpioinfo gpiochip1
gpiochip1 - 77 lines:

       line   0:      "Line0"       unused   input  active-high
       line   1:      "Line1"       unused   input  active-high
       line   2:      "Line2"       unused   input  active-high
       line   3:      unnamed       unused   input  active-high

% gpiofind Line2
gpiochip1 2

Of course you may convert _DSD to be a Method and fill the line names dynamically with help of ASL.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Flavio Suligoi

author

2020-10-02 13:29 UTC #13 lore raw

HI Andy,

Quoted 20 lines

Quoted 6 lines
So, what about adding the following
(Replace '...' with meaningful line names or drop for now, but in any case you need to provide as much names as lines of such GPIO controller)
I have checked the code, so it allows you to define from 0 up to all lines, but no gaps.
Thus, I have dropped '...' line in above excerpt, added the compiled AML to initramfs (initrd method) and voila!
% gpioinfo gpiochip1
gpiochip1 - 77 lines:
       line   0:      "Line0"       unused   input  active-high
       line   1:      "Line1"       unused   input  active-high
       line   2:      "Line2"       unused   input  active-high
       line   3:      unnamed       unused   input  active-high

Quoted 5 lines

% gpiofind Line2
gpiochip1 2
Of course you may convert _DSD to be a Method and fill the line names dynamically with help of ASL.

Thanks for your help, I try now!

Quoted 4 lines

--
With Best Regards,
Andy Shevchenko

Best regards,

Flavio

Flavio Suligoi

author

2020-10-02 10:26 UTC #14 lore raw

In reply to Andy Shevchenko

Hi Andy,

with my custom SSDT table:

DefinitionBlock ("gpio_button.aml", "SSDT", 5, "ASEMsp", "GPIO_BTN", 1)
{
External (_SB_.GPO1, DeviceObj)
Scope (\_SB.GPO1)
{
Device (BTNS)
{
Name (_HID, "ASEM0005") // _HID: Hardware ID PRP0001
Name (_UID, Zero) // _UID: Unique ID
Name (_DDN, "DDN - SW Readable Button") // _DDN: DOS Device Name Name (_STR, Unicode ("STR - SW Readable Button")) // _STR: Description String

Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
GpioIo (
Shared, // 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 25
}
})
}
}
}

I'm able to see the GPIO in:

/sys/bus/platform/devices/ASEM0005:00/firmware_node:

-r--r--r--    1 root     root          4096 Oct  2 12:10 description
-r--r--r--    1 root     root          4096 Oct  2 12:10 hid
-r--r--r--    1 root     root          4096 Oct  2 12:10 modalias
-r--r--r--    1 root     root          4096 Oct  2 12:10 path
lrwxrwxrwx    1 root     root             0 Oct  2 12:10 physical_node -> ../../../../platform/INT3452:01/ASEM0005:00
drwxr-xr-x    2 root     root             0 Oct  2 12:10 power
lrwxrwxrwx    1 root     root             0 Oct  2 12:10 subsystem -> ../../../../../bus/acpi
-rw-r--r--    1 root     root          4096 Oct  2 12:10 uevent
-r--r--r--    1 root     root          4096 Oct  2 12:10 uid

and so I can see some useful info:

# cat description
STR - SW Readable Button
# cat hid
ASEM0005
# cat modalias
acpi:ASEM0005:
bmxxxx-x86-64:/sys/bus/platform/devices/ASEM0005:00/firmware_node# cat path
\_SB_.GPO1.BTNS

So, from userspace, I can discover the GPIO controller /dev/gpiochip1, but I don't know how to discover the GPIO number (25 in this case). Do you have any suggestion about how to discover this GPIO number?

Thanks!

Quoted 3 lines

--
With Best Regards,
Andy Shevchenko

Best regards,
Flavio

Andy Shevchenko

2020-10-02 12:40 UTC #15 lore raw

Quoted 59 lines · Flavio Suligoi

Hi Andy,
with my custom SSDT table:
DefinitionBlock ("gpio_button.aml", "SSDT", 5, "ASEMsp", "GPIO_BTN", 1)
{
External (_SB_.GPO1, DeviceObj)
Scope (\_SB.GPO1)
{
Device (BTNS)
{
Name (_HID, "ASEM0005") // _HID: Hardware ID PRP0001
Name (_UID, Zero) // _UID: Unique ID
Name (_DDN, "DDN - SW Readable Button") // _DDN: DOS Device Name Name (_STR, Unicode ("STR - SW Readable Button")) // _STR: Description String
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings {
GpioIo (
Shared, // 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 25
}
})
}
}
}
I'm able to see the GPIO in:
/sys/bus/platform/devices/ASEM0005:00/firmware_node:
(quoted diff) +0 -4
-r--r--r--    1 root     root          4096 Oct  2 12:10 description
-r--r--r--    1 root     root          4096 Oct  2 12:10 hid
-r--r--r--    1 root     root          4096 Oct  2 12:10 modalias
-r--r--r--    1 root     root          4096 Oct  2 12:10 path
lrwxrwxrwx    1 root     root             0 Oct  2 12:10 physical_node -> ../../../../platform/INT3452:01/ASEM0005:00
drwxr-xr-x    2 root     root             0 Oct  2 12:10 power
lrwxrwxrwx    1 root     root             0 Oct  2 12:10 subsystem -> ../../../../../bus/acpi
(quoted diff) +0 -2
-rw-r--r--    1 root     root          4096 Oct  2 12:10 uevent
-r--r--r--    1 root     root          4096 Oct  2 12:10 uid
and so I can see some useful info:
# cat description
STR - SW Readable Button
# cat hid
ASEM0005
# cat modalias
acpi:ASEM0005:
bmxxxx-x86-64:/sys/bus/platform/devices/ASEM0005:00/firmware_node# cat path
\_SB_.GPO1.BTNS

Quoted 3 lines

So, from userspace, I can discover the GPIO controller /dev/gpiochip1, but I don't know how to discover the GPIO number (25 in this case). Do you have any suggestion about how to discover this GPIO number?

You don't need this SSDT at all.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Flavio Suligoi

author

2020-09-29 16:10 UTC #16 lore raw

In reply to Bartosz Golaszewski

Hi Bartosz,

Quoted 57 lines

Quoted 1 line
I need to expose to the userspace a GPIO, physically connected to a
board
Quoted 2 lines
push-button. This GPIO must expose a pre-defined name, such as "user-push-button", so that the userspace applications can use it
without
Quoted 3 lines
know any physical GPIO details.
I can customize the board BIOS and so my goal is to add an ACPI table
with
Quoted 4 lines
a content like this:
...
Scope (\_SB.GPO1)
Quoted 11 lines
        {
                Device (BTNS)
                {
                        Name (_HID, "PRP0001")
                        Name (_DDN, "GPIO buttons device")

                        Name (_CRS, ResourceTemplate ()
                        {
                                GpioIo (
                                Exclusive,               // Not shared
                                PullNone,                // No need for
pulls
Quoted 1 line
0, // Debounce
timeout
Quoted 1 line
0, // Drive
strength
Quoted 1 line
IoRestrictionInputOnly, // Only used as
input
Quoted 1 line
                                "\\_SB.GPO1",            // GPIO
controller
Quoted 8 lines
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,
Quoted 6 lines
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
Quoted 1 line
this GPIO with its pre-defined name (caming from the ACPI table
declaration),
Quoted 5 lines
to the userspace...
Best regards,
Flavio

Quoted 7 lines

Adding Andy who knows ACPI GPIO well.
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.
Bartosz

Thanks! I'll try!!!

Flavio