On Tue, Mar 08, 2016 at 11:32:02PM -0800, Philip Guenther wrote:
> 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
>
Nice find. I didn't notice that. I agree with your assessment.
-ml
