On Mon, Jan 20, 2014 at 01:54:15PM -0500, Gabriel L. Somlo wrote:
> On Mon, Jan 20, 2014 at 01:16:02PM +0100, Paolo Bonzini wrote:
> > Il 20/01/2014 13:08, Michael S. Tsirkin ha scritto:
> > >>> > > I think the hack looking for the SMC device is safer than _OSI:
> > >>> > > OSPMs
> > >>> > > are known to do crazy things when they see _OSI, such as assuming
> > >>> > > they
> > >>> > > need to try and emulate the OS probed.
> >
> > Source for "OSPMs do crazy things when they see _OSI".
>
> After a bit more digging, I believe this has to do with the fact that
> OSPM is responsible for define _OSI, and referencing it from e.g. the
> HPET._CRS method when it's NOT defined (e.g. by a misbehaving OSPM)
> results in all sorts of unpleasantness.
No, that's not what I meant.
Responded to the original question with what my
real concern was.
> In fact, looking on the MacBookPro, we see the following:
>
> DefinitionBlock ("dsdt.aml", "DSDT", 1, "APPLE ", "MacBookP", 0x00090001)
> {
> ...
> Field (GNVS, AnyAcc, Lock, Preserve) {
> OSYS, 16,
> ...
> }
> ...
> Scope (\_SB) {
> Method (_INI, 0, NotSerialized) {
> Store (0x07DC, OSYS)
> If (CondRefOf (\_OSI, Local0)) {
> If (_OSI ("Darwin")) {
> Store (0x2710, OSYS)
> }
> If (\_OSI ("Linux")) {
> Store (0x03E8, OSYS)
> }
> If (\_OSI ("Windows 2009")) {
> Store (0x07D9, OSYS)
> }
> If (\_OSI ("Windows 2012")) {
> Store (0x07DC, OSYS)
> }
> }
> }
> ...
> }
> ...
>
> So, basically, they give OSYS a default value, then *if* _OSI is
> defined by a well-behaved OSPM, they use it to give OSYS a more
> useful, specific value. CondRefOf is used to avoid a fatal error
> in case _OSI does not exist.
Good to know, thanks for the info.
> And later:
>
> Device (HPET) {
> Name (_HID, EisaId ("PNP0103"))
> Name (_CID, EisaId ("PNP0C01"))
> Name (BUF0, ResourceTemplate () {
> IRQNoFlags () {0}
> IRQNoFlags () {8}
> Memory32Fixed (ReadWrite,
> 0xFED00000, // Address Base
> 0x00000400, // Address Length
> _Y16)
> })
> Method (_STA, 0, NotSerialized) {
> If (LGreaterEqual (OSYS, 0x07D1)) {
> If (HPAE) {
> Return (0x0F)
> }
> } Else {
> If (HPAE) {
and where does HPAE come from?
> Return (0x0B)
> }
> }
> Return (0x00)
> }
> ...
> }
>
> Which begins to explain why, on the MBP2,2 I didn't see the HPET show
> up in the XP device tree at all ! :)
>
> I.e., I wonder if XP actually defines _OSI (my inner gambling addict
> says it probably does not).
This document says it does:
http://msdn.microsoft.com/library/windows/hardware/gg463275
> Long story short, we could use CondRefOf as an intermediary wrapper
> around _OSI to avoid referencing SMC._STA from within HPET.CRS...
I'm not sure why it's a problem to refer to SMC._STA
but if it is, we can just patch in another variable
in the HPET scope instead of _OSI.
> Not sure we want to "complicate" the rest of the HPET (e.g. return
> different values for bit2, "show device in acpi u/i" depending on
> _OSI, the way Apple machines do).
>
> Thanks,
> --Gabriel
They seem to clear this bit for linux?
No idea why they do this - want to try looking into
linux source to figure out?
--
MST
