On Tue, 8 Mar 2016, Rickster wrote:
> acpidump:
...
Looks like another HW-reduced ACPI platform issue. From the decompiled
acpidump, the EC device definition includes:
Scope (_SB.PCI0.SBRG)
{
Device (EC0)
{
Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */) //
_HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0062, // Range Minimum
0x0062, // Range Maximum
0x00, // Alignment
0x01, // Length
)
IO (Decode16,
0x0066, // Range Minimum
0x0066, // Range Maximum
0x00, // Alignment
0x01, // Length
)
Memory32Fixed (ReadWrite,
0xFF000000, // Address Base
0x00001000, // Address Length
)
})
Name (_GPE, 0x03) // _GPE: General Purpose Events
...
We only accept 2 registers in the EC _CRS, but ACPI 5.0 spec section
12.11's Table 12-260 "Embedded Controller Device Object Control Methods"
says this about the EC _CRS:
The first address region returned is the data port, and the second
address region returned is the status/command port for the
embedded controller. If the EC is used on a HW-Reduced ACPI
platform, a third resource is required, which is the GPIO
Interrupt Connection resource for the EC's SCI Interrupt.
I guess acpiec.c's sci handling will need to be taught how to use that 3rd
register for this hardware to be supported...
Philip Guenther
