Does Linux make use of the S3D methods?

Does Linux make use of the S3D methods?

[John Knottenbelt]

Hi

I have been inspecting my DSDT and I noticed this:

Scope(\_SB_) {
    Device(PWRB) {
        Name(_HID, 0x0c0cd041)
        Method(_STA) {
            Return(0xb)
        }
    }
    Device(PCI0) {
        Name(_HID, 0x030ad041)
        Name(_ADR, 0x0)
        Name(_BBN, 0x0)
        Method(_S3D) {
            If(OSFL) {
                Return(0x2)
            }
            Else {
                Return(0x3)
            }
        }

The ACPI spec says that the _S3D method returns the highest power saving level 
that the device can be put into. As you can see from the above (and other 
similar S3D methods) the result depends on the OSFL variable, which is 
defined with:

         Method(_INI) {
            \_SB_.PCI0.SBRG.IODT()
            If(MCTH(\_OS_, "Microsoft Windows NT")) {
                Store(0x0, OSFL)
            }
            Else {
                If(MCTH(\_OS_, "Microsoft Windows")) {
                    Store(0x1, OSFL)
                }
                Else {
                    If(MCTH(\_OS_, "Microsoft WindowsME: Millennium Edition"))
                   {
                        Store(0x2, OSFL)
                    }
                    Else {
                        Store(0x3, OSFL)
                    }
                }
            }
        }

So for under Linux, the OSFL will be 3, and _S3D methods will return 2. My 
question is, does the kernel make use of this information at all? Is it worth 
editing the DSDT so that OSFL=0 (i.e. Windows NT) ?

Thanks

John



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Does Linux make use of the S3D methods?

[Ducrot Bruno]

On Mon, Jan 19, 2004 at 01:54:36PM +0000, John Knottenbelt wrote:
> Hi
> 
> I have been inspecting my DSDT and I noticed this:
> 
> Scope(\_SB_) {
>     Device(PWRB) {
>         Name(_HID, 0x0c0cd041)
>         Method(_STA) {
>             Return(0xb)
>         }
>     }
>     Device(PCI0) {
>         Name(_HID, 0x030ad041)
>         Name(_ADR, 0x0)
>         Name(_BBN, 0x0)
>         Method(_S3D) {
>             If(OSFL) {
>                 Return(0x2)
>             }
>             Else {
>                 Return(0x3)
>             }
>         }
> 
> The ACPI spec says that the _S3D method returns the highest power saving level 
> that the device can be put into. As you can see from the above (and other 
> similar S3D methods) the result depends on the OSFL variable, which is 
> defined with:
> 
>          Method(_INI) {
>             \_SB_.PCI0.SBRG.IODT()
>             If(MCTH(\_OS_, "Microsoft Windows NT")) {
>                 Store(0x0, OSFL)
>             }
>             Else {
>                 If(MCTH(\_OS_, "Microsoft Windows")) {
>                     Store(0x1, OSFL)
>                 }
>                 Else {
>                     If(MCTH(\_OS_, "Microsoft WindowsME: Millennium Edition"))
>                    {
>                         Store(0x2, OSFL)
>                     }
>                     Else {
>                         Store(0x3, OSFL)
>                     }
>                 }
>             }
>         }
> 
> So for under Linux, the OSFL will be 3, and _S3D methods will return 2. My 
> question is, does the kernel make use of this information at all? Is it worth 
> editing the DSDT so that OSFL=0 (i.e. Windows NT) ?
> 

An alternative is to use the acpi_os_name kernel boot option.
It was written to address this kind of issue without having to hack
the dsdt.

Boot with acpi_os_name='Microsoft Windows NT' and see if that work or
not.

Another way also is to add something like:

	If(MTCH(\_OS, "Linux")) {
		Store(3, OSFL)
	}

and try to get it in the BIOS by writting to the manufacturer (but, for
an unknown reason, I never had success to get that...)

Do the same with FreeBSD, NetBSD if the manufacturer is OK, who knows ;)

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Does Linux make use of the S3D methods?

[Len Brown]

On Mon, 2004-01-19 at 08:54, John Knottenbelt wrote:
> Hi
> 
> I have been inspecting my DSDT and I noticed this:
> 
> Scope(\_SB_) {
>     Device(PWRB) {
>         Name(_HID, 0x0c0cd041)
>         Method(_STA) {
>             Return(0xb)
>         }
>     }
>     Device(PCI0) {
>         Name(_HID, 0x030ad041)
>         Name(_ADR, 0x0)
>         Name(_BBN, 0x0)
>         Method(_S3D) {
>             If(OSFL) {
>                 Return(0x2)
>             }
>             Else {
>                 Return(0x3)
>             }
>         }
> 
> The ACPI spec says that the _S3D method returns the highest power saving level 
> that the device can be put into.

Actually the spec says that _S3D returns the HIGHEST POWER (not highest
power saving) state that the device can be put into during S3.  This
corresponds to the lowest D-state number (D0 being full power) available
during S3.

So for NT, OSFL is 0, and _S3D returns 3, meaning that the device can't
be left in any state higher than D3 (full off).  However, the other
Windows return OSFL !=0, and thus the device could be kept in D2 --
which consumes more power.


>  As you can see from the above (and other 
> similar S3D methods) the result depends on the OSFL variable, which is 
> defined with:
> 
>          Method(_INI) {
>             \_SB_.PCI0.SBRG.IODT()
>             If(MCTH(\_OS_, "Microsoft Windows NT")) {
>                 Store(0x0, OSFL)
>             }
>             Else {
>                 If(MCTH(\_OS_, "Microsoft Windows")) {
>                     Store(0x1, OSFL)
>                 }
>                 Else {
>                     If(MCTH(\_OS_, "Microsoft WindowsME: Millennium Edition"))
>                    {
>                         Store(0x2, OSFL)
>                     }
>                     Else {
>                         Store(0x3, OSFL)
>                     }
>                 }
>             }
>         }
> 
> So for under Linux, the OSFL will be 3, and _S3D methods will return 2. My 
> question is, does the kernel make use of this information at all? Is it worth 
> editing the DSDT so that OSFL=0 (i.e. Windows NT) ?

I don't think so.  I don't see any reference to _S3D in Linux.

Of course, _OS_ returns ACPI_OS_NAME as defined in aclinux.h, so
you could change that and see if it makes any difference;-)

cheers,
-Len




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click