meta-acpi layer for at least Intel boards about meta-iot2000 HOT 9 CLOSED

I already stumbled over this in the Galileo forum but didn't dig into all its details. Could you summarize what it contributes? Is is a replacement of meta-intel (it comes with its own kernel recipe but also lists the latter as dependency, that confuses me)? Is is limited to the specific kernel version it selects? TIA!

from meta-iot2000.

I think @westeri, who is main contributor to that, can explain better than me.

P.S. Kernel version needed should be recent, indeed. This is due to (GPIO) framework limitations in older versions.

from meta-iot2000.

OK, then this layer may help us with an upstream variant of the BSP. But we will still needs some 4.4.superlongterm for users that start development now (or soon) and will not want to do a major kernel update in the field then.

from meta-iot2000.

@andy-shev @westeri, does meta-acpi only enable us to augment the DSDT (for extension devices), or can we also use it for overwriting some incorrect fragment in the firmware-provided part? I'm considering to patch a bug this way, until we have new firmware released and flashed. The task is about overwriting only a small part of the DSDT because I would have to provide different DSDTs for two device variants we have if I replace them completely.

from meta-iot2000.

In principle yes, you can do that but in many cases it is not possible. For example you can't replace a method using this. You can add _STA() returning 0 for the faulty device (if it does not have _STA() already) and then provide an updated version of the device.

from meta-iot2000.

It's this device

    Scope (_SB)
    {
        [...]
        Device (NIO3)
        {
            Name (_HID, "INT3491")  // _HID: Hardware ID
            Name (_CID, "INT3491")  // _CID: Compatible ID
            Name (_UID, 0x03)  // _UID: Unique ID
            Name (RBUF, ResourceTemplate ()
            {
                I2cSerialBus (0x0027, ControllerInitiated, 0x00061A80,
                    AddressingMode7Bit, "\\_SB.PCI0.GIP0.I2C_",
                    0x00, ResourceConsumer, ,
                    )
                GpioInt (Level, ActiveLow, Exclusive, PullDefault, 0x0000,
                    "\\_SB.PCI0.GIP0.GPO", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0009
                    }
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Return (RBUF) /* \_SB_.NIO3.RBUF */
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (LNotEqual (PTYP, 0x08)) {}
                Return (0x0F)
            }
        }

where we need to adjust the pin list value. My naive plan was to provide fragment containing this with the corrected value and was hoping that Linux would pick that version from the initrd in favour of the firmware's variant.

from meta-iot2000.

Yeah, that is kind of hard to fix with the current system. I suppose we could teach the kernel (or rather ACPICA) to allow upgrading a method. There is already a way to customize methods in the kernel (see Documentation/acpi/method-customizing.txt) perhaps that could be leveraged?

from meta-iot2000.

Hmm, won't work here either: I need the patch to fix the parameters for GPIO_PCA953X probing, more exactly GPIO_PCA953X_IRQ. The former can be turned into a module so that I would have time to patch the method but the latter wants to be built into the kernel. Thanks nevertheless!

from meta-iot2000.

@westeri @andy-shev, I've started to use the patterns of meta-acpi in 3b1d1df, but there was no way yet to reuse the layer directly. Besides the facts that EDK II is anything but a bootloader 😉, your recipe is using the host iasl instead the yocto-built one, and I don't need acpidump on the target by default, there is specifically support missing to specify SSDT fragments outside of meta-acpi, only reusing the build and installation machinery.

Even if our firmware is once updated and the hotfixes are gone, it might be useful on the long run to have SSDT extension to describe Arduino shield hardware. If meta-acpi is updated by then, we can reconsider it. For now, we will not use it.

from meta-iot2000.