On Fri, Dec 20, 2013 at 10:38:30PM +0100, Igor Mammedov wrote:
> > + Device (SMC) {
> > + Name(_HID, EisaId("APP0001"))
> > + /* _STA will be patched to 0x0B if AppleSMC is present */
> > + ACPI_EXTRACT_NAME_WORD_CONST CONCAT_SYM(SMC_PFX, smc_sta)
> typically dynamic variables are put in SSDT
When I tried statically building the SMC node as part of the SSDT, it
was not recognized by Mac OS X -- it only seems to work when it's part
of the DSDT.
> > + Name(_STA, 0xFF00)
> > + Name(_CRS, ResourceTemplate () {
> > + IO (Decode16, 0x0300, 0x0300, 0x01, 0x20)
> > + IRQNoFlags() { 6 }
> > + })
> > + }
> Device looks pretty simplistic, Have you considered building it completely
> dynamically?
> See build_ssdt() for examples, you might need to add extra building block for
> ResourceTemplate{} the rest could be done with existing build_* primitives.
If we consider "pasting" the SMC into the DSDT or not, based on
whether it was configured via -device applesmc or not, it comes
down to compiling the following ASL:
Device (SMC) {
Name(_HID, EisaId("APP0001"))
Name(_STA, 0x0B)
Name(_CRS, ResourceTemplate () {
IO (Decode16, 0x0300, 0x0300, 0x01, 0x20)
IRQNoFlags() { 6 }
})
}
into AML, and somehow conditionally appending the resulting blob,
unmodified, to the DSDT.
I would explore this approach before I'd consider compiling the blob
dynamically each time during QEMU startup, which would IMHO be harder
to follow.
However, I thought flipping one uint16_t from 0x0B to 0x00 (i.e., the
return value of SMC._STA) is much less intrusive to the DSDT than
pasting an entire blob dynamically during startup, which is why I
thought my approach was a bit cleaner.
Let me know what you think.
Thanks,
--Gabriel
