Project OS X Forums > Dsdt Finite Timeouts

locks

Apr 27 2010, 04:24 PM

Hi I was wondering if anyone new how to add a check for Acquire Mute finite time outs? Everywhere I have looked people have fixed this by making the timeout infinite (0xFFFF), but that changes the semantic and I'm not wanting to do this. Here is a piece of the code:

CODE

    Scope (_SB)
    {
        Name (XCPD, Zero)
        Name (XNPT, One)
        Name (XCAP, 0x02)
        Name (XDCP, 0x04)
        Name (XDCT, 0x08)
        Name (XDST, 0x0A)
        Name (XLCP, 0x0C)
        Name (XLCT, 0x10)
        Name (XLST, 0x12)
        Name (XSCP, 0x14)
        Name (XSCT, 0x18)
        Name (XSST, 0x1A)
        Name (XRCT, 0x1C)
        Mutex (MUTE, 0x00)
        Method (RBPE, 1, NotSerialized)
        {
            Acquire (MUTE, 0x03E8)
            Add (Arg0, PCIB, Local0)
            OperationRegion (PCFG, SystemMemory, Local0, One)
            Field (PCFG, ByteAcc, NoLock, Preserve)
            {
                XCFG,   8
            }

            Release (MUTE)
            Return (XCFG)
        }

        Method (RWPE, 1, NotSerialized)
        {
            Acquire (MUTE, 0x03E8)
            And (Arg0, 0xFFFFFFFE, Arg0)
            Add (Arg0, PCIB, Local0)
            OperationRegion (PCFG, SystemMemory, Local0, 0x02)
            Field (PCFG, WordAcc, NoLock, Preserve)
            {
                XCFG,   16
            }

            Release (MUTE)
            Return (XCFG)
        }

        Method (RDPE, 1, NotSerialized)
        {
            Acquire (MUTE, 0x03E8)
            And (Arg0, 0xFFFFFFFC, Arg0)
            Add (Arg0, PCIB, Local0)
            OperationRegion (PCFG, SystemMemory, Local0, 0x04)
            Field (PCFG, DWordAcc, NoLock, Preserve)
            {
                XCFG,   32
            }

            Release (MUTE)
            Return (XCFG)
        }

        Method (WBPE, 2, NotSerialized)
        {
            Acquire (MUTE, 0x0FFF)
            Add (Arg0, PCIB, Local0)
            OperationRegion (PCFG, SystemMemory, Local0, One)
            Field (PCFG, ByteAcc, NoLock, Preserve)
            {
                XCFG,   8
            }

            Store (Arg1, XCFG)
            Release (MUTE)
        }

        Method (WWPE, 2, NotSerialized)
        {
            Acquire (MUTE, 0x03E8)
            And (Arg0, 0xFFFFFFFE, Arg0)
            Add (Arg0, PCIB, Local0)
            OperationRegion (PCFG, SystemMemory, Local0, 0x02)
            Field (PCFG, WordAcc, NoLock, Preserve)
            {
                XCFG,   16
            }

            Store (Arg1, XCFG)
            Release (MUTE)
        }

        Method (WDPE, 2, NotSerialized)
        {
            Acquire (MUTE, 0x03E8)
            And (Arg0, 0xFFFFFFFC, Arg0)
            Add (Arg0, PCIB, Local0)
            OperationRegion (PCFG, SystemMemory, Local0, 0x04)
            Field (PCFG, DWordAcc, NoLock, Preserve)
            {
                XCFG,   32
            }

            Store (Arg1, XCFG)
            Release (MUTE)
        }

        Method (RWDP, 3, NotSerialized)
        {
            Acquire (MUTE, 0x03E8)
            And (Arg0, 0xFFFFFFFC, Arg0)
            Add (Arg0, PCIB, Local0)
            OperationRegion (PCFG, SystemMemory, Local0, 0x04)
            Field (PCFG, DWordAcc, NoLock, Preserve)
            {
                XCFG,   32
            }

            And (XCFG, Arg2, Local1)
            Or (Local1, Arg1, XCFG)
            Release (MUTE)
        }

Thanks in advance to anyone that can offer some insight.

Signal64

May 2 2010, 06:03 AM

Are you worried about the warning "Possible operator timeout is ignored" the ACPICA iasl compiler generates?
Don't. That is a Warning vs. an Error and can be ignored.

From http://mjg59.livejournal.com/94998.html which discusses a blown out of proportion issue brought up a few years ago..

QUOTE

The only remaining thing is the mutex handwaving. I've got no clue what's going on there. Ryan's suggested change (from Acquire (MUTE, 0x03E8) to Acquire (MUTE, 0xFFFF)) simply means that the OS will wait forever until it acquires the mutex - in the past it would only wait a second. The reason the compiler generates a warning here is that the firmware never checks whether it acquired the mutex or not! Bumping the timeout to infinity obviously fixes this warning (there's no need to check the return code if you're happy to wait forever rather than failing), but the original code is merely stupid as opposed to a spec violation.

I've found many (if not all) of the DSDT's that I get that Warning on came from AWARD BIOS's and the ACPI was compiled with the Microsoft ASL compiler (look for Compiler ID "MSFT" in the header). Microsoft ASL doesn't check these things and therefor doesn't generate the Warning. Either it really is "stupid code" and MS ASL lead the programmer to a false sense of security or the programmer does know what they are doing (hmmm.. ).

These days I personally don't even bother changing it to 0xFFFF and put up with the warning when using iasl. As youself and mjg59 points out 0xFFFF isn't exactly a fix either and in the end is purely a cosmetic one for iasl compiling to get 0 Warnings.

Either way, Like many things it works despite itself.

If you really, really, want to "correct" it then you have to add a check that it got the mutex. What to do when it doesn't? Try again? Infinite Loop? Would need to dig into the ACPI specs.

locks

May 5 2010, 06:58 AM

First off thanks for replying it's much appreciated! Umm I wasn't worried about the warning I know about Microsoft lax compiler and was aware about that "chicken little" incident lol. It was more of a personal thing because I know it's there and would like to fix it, but wanted to do so without changing the semantic

. The part you mentioned about adding a check had already crossed my mind. Thought about using an "If" statement but wasn't sure how to go about it or the proper syntax. I was hoping that KING or SLICE or someone more knowledgable in DSDT than me would ring in and could explain better how to go about it so I could learn and apply it. Similiar to what you said I have just left it for the time being because I am wanting to silence the compiler but without having to change the semantic. Thanks for taking the time to at least respond