How to Configure Acpi *.Asl for a Virtual Mdio-Gpio Device Connected to a I2C Gpio Expander

How to configure ACPI *.asl for a virtual mdio-gpio device connected to a I2C gpio expander

First of all let's see the main architecture of the design:

+-------------------+
|  HOST             |       +------+
|              MDIO <------>+ MDIO |
|              Intf |       | Phy  |
|                   |       +--^---+
| +------+          |          |       +-----+
| | I²C  |          |          |       | LED |
| | host |          |          |       +--^--+
| +--^---+          |          |          |
|    |              |       +--+---+      |
+-------------------+       | I²C  |      |
     +----------------------> GPIO +------+
                            +------+

From this schematic we see how devices are related to each other. Now let's move to ACPI representation. At the beginning we need to define I²C GPIO expander. From the examples in meta-acpi project we can find how PCA9535 can be described. Assuming we found the I²C host controller device (\_SB_.PCI0.D01D as per your post) and the fact that you have expander without latching IRQ events, the following is the mix between original ASL excerpt and how to match it with proper configuration in the driver:

Device (ABC0)
{

    Name (_HID, "PRP0001")
    Name (_DDN, "NXP PCA9575 GPIO expander")

    Name (RBUF, ResourceTemplate()
    {
        I2cSerialBusV2(0x0020, ControllerInitiated, 400000,
            AddressingMode7Bit, "\\_SB.PCI0.D01D",
            0x00, ResourceConsumer, , Exclusive, )
    })

    Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () {"compatible", "nxp,pca9575"},
            Package () {"gpio-line-names", Package () {
                "LED_Red",
                "",
                "MDC",
                "MDIO",
            }},
        }
    })

    Method (_CRS, 0, NotSerialized)
    {
        Return (RBUF)
    }

    Method (_STA, 0, NotSerialized)
    {
        Return (0x0F)
    }
}

This excerpt provides us a new GPIO chip in the system, resources of which can be consumed by others.

For example, in your Virtual MDIO Phy case (see _DSD Device Properties Related to GPIO as well)

Device (MD00)
{
    Name (_HID, "PRP0001")

    Name (_CRS, ResourceTemplate () {
        GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
            "\\_SB.PCI0.D01D.ABC0", 0, ResourceConsumer) {2} // pin 2
        GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
            "\\_SB.PCI0.D01D.ABC0", 0, ResourceConsumer) {3} // pin 3
    })

    Name (_DSD, Package() {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () { "compatible", "virtual,mdio-gpio" },
            Package () {
                "gpios", Package () {
                    ^MD00, 0, 0, 0, // index 0 in _CRS -> pin 2
                    ^MD00, 1, 0, 0, // index 1 in _CRS -> pin 3
                }
            },
        }
    })
}

Now it is a time to look at the LED binding code. For the sake of clarification hogging is when you want a GPIO provider to consume a resource itself. And it is quite likely not your case. Better is to connect this with the LED GPIO driver:

Device (LEDS)
{
    Name (_HID, "PRP0001")
    Name (_DDN, "GPIO LEDs device")

    Name (_CRS, ResourceTemplate () {
        GpioIo (
            Exclusive,                  // Not shared
            PullUp,                     // Default off
            0,                          // Debounce timeout
            0,                          // Drive strength
            IoRestrictionOutputOnly,    // Only used as output
            "\\_SB.PCI0.D01D.ABC0",     // GPIO controller
            0)                          // Must be 0
        {
            0,                          // LED_Red
        }
    })

    Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () { "compatible", Package() { "gpio-leds" } },
        },
        ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
        Package () {
            Package () { "led-0", "LED0" },
        }
    })

    /*
     * For more information about these bindings see:
     * Documentation/devicetree/bindings/leds/common.yaml,
     * Documentation/devicetree/bindings/leds/leds-gpio.yaml and
     * Documentation/firmware-guide/acpi/gpio-properties.rst.
     */
    Name (LED0, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () { "label", "red" },
            Package () { "default-state", "on" },
            Package () { "gpios", Package () { ^LEDS, 0, 0, 1 } }, // active low
        }
    })
}

Also you may look into similar questions (starting from the given link and there are references to the rest) on StackOverflow site.

Control intel edison GPIO problem for ACPI table

Follow this leds.asli and try to create test example that is work now.

example:

Device (DEV)
{
    Name (_HID, "PRP0001")
    Name (_DDN, "GPIO LEDs device")

    Name (_CRS, ResourceTemplate()
    {
            GpioIo (Shared, PullNone, 0x0000, 0x0000,
                    IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
                    0x00, ResourceConsumer,,){12,13}
    })

    Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
            Package () { "compatible", Package() { "gpio-leds" } },
        },
        ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
        Package () {
            Package () {"led-0", "LED0"},
            Package () {"led-1", "LED1"},
        }
    })

    /*
     * For more information about these bindings see:
     * Documentation/devicetree/bindings/leds/common.yaml,
     * Documentation/devicetree/bindings/leds/leds-gpio.yaml and
     * Documentation/firmware-guide/acpi/gpio-properties.rst.
     */
     Name (LED0, Package () {
            ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () {
                Package () {"label", "green"},
                Package () {"default-state", "off"},
                Package () {"gpios", Package () {^LEDS, 0, 0, 0}},
                Package () {"retain-state-suspended", 1},
            }
        })

     Name (LED1, Package () {
            ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
            Package () {
                Package () {"label", "red"},
                Package () {"default-state", "off"},
                Package () {"gpios", Package () {^LEDS, 0, 1, 0}},
                Package () {"retain-state-suspended", 1},
            }
        })
}

/sys/kernel/debug/gpio:

root@:~# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-191, parent: pci/0000:00:0c.0, 0000:00:0c.0:
gpio-12  (                    |green               ) out lo
gpio-13  (                    |red                 ) out lo
gpio-71  (                    |shutdown            ) out hi
gpio-77  (                    |sd_cd               ) in  hi IRQ
gpio-96  (                    |ACPI:OpRegion       ) out hi
gpio-110 (                    |cs                  ) out hi
gpio-111 (                    |cs                  ) out hi
gpio-112 (                    |cs                  ) out lo
gpio-113 (                    |cs                  ) out lo
gpio-184 (                    |device-wakeup       ) out lo
gpio-185 (                    |host-wakeup         ) in  lo IRQ

How to unload an overlay loaded using ACPI_CONFIG_SYSFS

The kernel documentation indeed doesn't describe this moment. However, if you look into the source code of ACPI ConfigFS support you may see that it supports dropping items. It is a basic stuff by ConfigFS API, namely reaction to rmdir() system call. So, it means that simple removing the folder is what you need in order to unload the table:

rm -rf /sys/kernel/config/acpi/table/my_ssdt

Note, this is a debug feature and not guaranteed to work properly on all possible type of tables. In kernel only SPI, I2C and platform devices can be unbound.

Also note, that unloading tables wasn't in the kernel till the commit Unload SSDT on configfs entry removal appears.

---

Related Topics