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
On Tue, Sep 29, 2020 at 5:43 PM Flavio Suligoi <[email protected]> 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...
>
> 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
On Tue, Sep 29, 2020 at 6:48 PM Bartosz Golaszewski <[email protected]> wrote:
>
> On Tue, Sep 29, 2020 at 5:43 PM Flavio Suligoi <[email protected]> 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
Hi 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...
> >
> > 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
Thanks! I'll try!!!
Flavio
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
On Tue, Sep 29, 2020 at 7:21 PM Flavio Suligoi <[email protected]> wrote:
> > > > 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...
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.
> > > 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
Hi Andy,
> > > > > 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!
> 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.
>
> > > > 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 Andy and Bartosz for your support!
Best regards,
Flavio
On Wed, Sep 30, 2020 at 12:04:43PM +0000, Flavio Suligoi wrote:
> > > > > > 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!
>
> > 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.
> >
> > > > > 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.
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.
--
With Best Regards,
Andy Shevchenko
Hi Andy,
> 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.
>
> --
> 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
On Wed, Sep 30, 2020 at 6:39 PM Flavio Suligoi <[email protected]> wrote:
> > 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.
^^^^^^^ **DSDT**.
> My SSDT table is:
^^^^ See the difference? I can't help here.
> 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 ...
Define "gpio-line-names" property in the *provider* (controller)
device node _DSD().
--
With Best Regards,
Andy Shevchenko
On Wed, Sep 30, 2020 at 6:54 PM Andy Shevchenko
<[email protected]> wrote:
> On Wed, Sep 30, 2020 at 6:39 PM Flavio Suligoi <[email protected]> wrote:
> > > 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.
>
> ^^^^^^^ **DSDT**.
>
> > 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
> > 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().
--
With Best Regards,
Andy Shevchenko
Hi Andy,
sorry for the delay!
> > > 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)
}
}
> --
> With Best Regards,
> Andy Shevchenko
Best regards,
Flavio
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!
> --
> With Best Regards,
> Andy Shevchenko
Best regards,
Flavio
On Fri, Oct 2, 2020 at 1:26 PM Flavio Suligoi <[email protected]> wrote:
> 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?
You don't need this SSDT at all.
--
With Best Regards,
Andy Shevchenko
On Fri, Oct 2, 2020 at 1:02 PM Flavio Suligoi <[email protected]> wrote:
> > > > 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)
> }
> }
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)
--
With Best Regards,
Andy Shevchenko
On Fri, Oct 2, 2020 at 3:48 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Fri, Oct 2, 2020 at 1:02 PM Flavio Suligoi <[email protected]> wrote:
>
> > > > > 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)
> > }
> > }
>
> 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)
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.
--
With Best Regards,
Andy Shevchenko
HI Andy,
> > 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
>
>
> % 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!
>
> --
> With Best Regards,
> Andy Shevchenko
Best regards,
Flavio