ACPI DSDT language

ACPI DSDT language

[Jan Slezak]

Hi,

I would like to know what way should be buffers handled when are passed as arguments to 
ACPI methods. I don't have a time to read the ACPI specs so I hope someone knows. 

I find out by tracing my /_TZ/TMP method that they are passed by value so following 
construction (part of my original DSDT slightly modified) doesn't work (PNPG called) 
because PGET is not modified:

    Method (SX33, 2, NotSerialized)
    {
        If (LLess (Arg1, SizeOf (Arg0)))
        {
            CreateByteField (Arg0, Arg1, SX20)
            Store (Something, SX20)
        }
    }

    Method (PNPG, 1, NotSerialized)
    {
	.
	.
        Name (PGET, Buffer (8) {})
        SX33 (PGET, 2)
        Return (PGET)
    }

I need to know it to decide wheter it is my BIOS or the linux ACPI implementation what is 
buggy and to decide whether to send my DSDT patch to my notebook manufacturer (DELL).


Thanks,
  Jan

P.S.: If it is right behaviour and the BIOS is buggy I don't understand why the ACPI 
(actually ACPI battery info) is working under WinXP, where there is no DSDT override and 
no buggy feature workaround in the biosinfo.inf for my DELL.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: ACPI DSDT language

[Jan Slezak]

Ducrot Bruno píše:
> 
> On Wed, Jan 29, 2003 at 10:33:52AM +0100, Ing. Jan Slezak wrote:
> > Ducrot Bruno pí?e:
> > >
> > > On Tue, Jan 28, 2003 at 11:47:03AM +0100, Jan Slezak wrote:
> > > > Hi,
> > > >
> > > > I would like to know what way should be buffers handled when are passed as arguments to
> > > > ACPI methods. I don't have a time to read the ACPI specs so I hope someone knows.
> > > >
> > > > I find out by tracing my /_TZ/TMP method that they are passed by value so following
> > > > construction (part of my original DSDT slightly modified) doesn't work (PNPG called)
> > > > because PGET is not modified:
> > > >
> > > >     Method (SX33, 2, NotSerialized)
> > > >     {
> > > >         If (LLess (Arg1, SizeOf (Arg0)))
> > > >         {
> > > >             CreateByteField (Arg0, Arg1, SX20)
> > > >             Store (Something, SX20)
> > > >         }
> > > >     }
> > > >
> > > >     Method (PNPG, 1, NotSerialized)
> > > >     {
> > > >       .
> > > >       .
> > > >         Name (PGET, Buffer (8) {})
> > > >         SX33 (PGET, 2)
> > > >         Return (PGET)
> > > >     }
> > > >
> > >
> > > Why don't make something like that instead:
> > >
> > >     Method (PNPG, 1, NotSerialized)
> > >     {
> > >       .
> > >       .
> > >         Name (PGET, Buffer (8) {})
> > >         Store (something, Index(PGET, 2))
> > >         Return (PGET)
> > >     }
> > >
> > > (unless 'something' is not 8-bits long, though)
> > >
> > > --
> > > Ducrot Bruno
> > >
> > > --  Which is worse:  ignorance or apathy?
> > > --  Don't know.  Don't care.
> >
> >
> > Sure, it is possible and I modified my DSDT in a similar way, but I want
> > to know if the original DSDT is correct (by specs, let's say
> > theoreticaly). I don't want to beat my notebok manufacturer and get the
> > answer "it is by spec" then.
> 
> Ah, yep, I have not read carrefully your first email.
> 
> By spec (2.0b, somewhere in 5.5.3 to 5.5.4):
> any namespace creation in a control method can only be acceded in the control method.
> 
> Here, the buffer PNPG will be created only for _internal_ use of PNPG.
> 
> When the SX33(PGET, 2) occur, the control method SX33 can not have direct
> access of PGET, but of a _local copy_ of the buffer (which is referenced by Arg0)
> but still only for _internal_ use of SX33.
> 
> Please note also that 'Return (PGET)' at end of PNPG control method will actually create
> a _copy_ for the caller of PNPG (the initial PGET will be destroyed at end of
> the method).
> 
> Cheers,
> 
> --
> Ducrot Bruno
> 
> --  Which is worse:  ignorance or apathy?
> --  Don't know.  Don't care.

Great! So I'm going to send my DSDT fix to Dell and ask them to apply it
to official BIOS.

Thanks,
Jan


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

RE: ACPI DSDT language

[Moore, Robert]

This is the purpose of the "RefOf()" operator in ASL.

>From the ACPI spec:

"The primary purpose of RefOf() is to allow an object to be passed to a
method as an argument without the object being evaluated at the time the
method was loaded."

Bob


-----Original Message-----
From: Jan Slezak [mailto:jan.slezak-aRb0bU7PRFPrBKCeMvbIDA@public.gmane.org] 
Sent: Tuesday, January 28, 2003 2:47 AM
To: acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org
Subject: [ACPI] ACPI DSDT language

Hi,

I would like to know what way should be buffers handled when are passed as
arguments to 
ACPI methods. I don't have a time to read the ACPI specs so I hope someone
knows. 

I find out by tracing my /_TZ/TMP method that they are passed by value so
following 
construction (part of my original DSDT slightly modified) doesn't work (PNPG
called) 
because PGET is not modified:

    Method (SX33, 2, NotSerialized)
    {
        If (LLess (Arg1, SizeOf (Arg0)))
        {
            CreateByteField (Arg0, Arg1, SX20)
            Store (Something, SX20)
        }
    }

    Method (PNPG, 1, NotSerialized)
    {
	.
	.
        Name (PGET, Buffer (8) {})
        SX33 (PGET, 2)
        Return (PGET)
    }

I need to know it to decide wheter it is my BIOS or the linux ACPI
implementation what is 
buggy and to decide whether to send my DSDT patch to my notebook
manufacturer (DELL).


Thanks,
  Jan

P.S.: If it is right behaviour and the BIOS is buggy I don't understand why
the ACPI 
(actually ACPI battery info) is working under WinXP, where there is no DSDT
override and 
no buggy feature workaround in the biosinfo.inf for my DELL.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: ACPI DSDT language

[Jan Slezak]

That is what I want to know! I suppose such operator exists but I didn't
find it in my DSDT and as I wrote earlier I didn't want to read spec. I
tried DerefOf(), but ... you know... :). So I modified my DSDT in a
different way. But anyway thanks for information.

For me the result is ... my original DSDT is buggy. Am I right?



And what about the case when the buffer is created in the root, for
instance:

     Name (PGET, Buffer (8) {})

     Method (SX33, 2, NotSerialized)
     {
         If (LLess (Arg1, SizeOf (Arg0)))
         {
             CreateByteField (Arg0, Arg1, SX20)
             Store (Something, SX20)
         }
     }
 
     Method (PNPG, 1, NotSerialized)
     {
         .
         .
         SX33 (PGET, 2)
         Return (PGET)
     }

Is it the same situation?



Jan


"Moore, Robert" píše:
> 
> This is the purpose of the "RefOf()" operator in ASL.
> 
> >From the ACPI spec:
> 
> "The primary purpose of RefOf() is to allow an object to be passed to a
> method as an argument without the object being evaluated at the time the
> method was loaded."
> 
> Bob
> 
> -----Original Message-----
> From: Jan Slezak [mailto:jan.slezak-aRb0bU7PRFPrBKCeMvbIDA@public.gmane.org]
> Sent: Tuesday, January 28, 2003 2:47 AM
> To: acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org
> Subject: [ACPI] ACPI DSDT language
> 
> Hi,
> 
> I would like to know what way should be buffers handled when are passed as
> arguments to
> ACPI methods. I don't have a time to read the ACPI specs so I hope someone
> knows.
> 
> I find out by tracing my /_TZ/TMP method that they are passed by value so
> following
> construction (part of my original DSDT slightly modified) doesn't work (PNPG
> called)
> because PGET is not modified:
> 
>     Method (SX33, 2, NotSerialized)
>     {
>         If (LLess (Arg1, SizeOf (Arg0)))
>         {
>             CreateByteField (Arg0, Arg1, SX20)
>             Store (Something, SX20)
>         }
>     }
> 
>     Method (PNPG, 1, NotSerialized)
>     {
>         .
>         .
>         Name (PGET, Buffer (8) {})
>         SX33 (PGET, 2)
>         Return (PGET)
>     }
> 
> I need to know it to decide wheter it is my BIOS or the linux ACPI
> implementation what is
> buggy and to decide whether to send my DSDT patch to my notebook
> manufacturer (DELL).
> 
> Thanks,
>   Jan
> 
> P.S.: If it is right behaviour and the BIOS is buggy I don't understand why
> the ACPI
> (actually ACPI battery info) is working under WinXP, where there is no DSDT
> override and
> no buggy feature workaround in the biosinfo.inf for my DELL.
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

RE: ACPI DSDT language

[Moore, Robert]

The problem is not where PGET gets created.  It's OK to create it in a
method and return it -- a copy will be created.

The problem is the invocation of the SX33() method.  It has to be
SX33(RefOf(PGET), 2).  I believe that using Arg0 within SX33 will cause an
automatic dereference of the argument.

Bob


-----Original Message-----
From: Jan Slezak [mailto:jan.slezak-aRb0bU7PRFPrBKCeMvbIDA@public.gmane.org] 
Sent: Thursday, January 30, 2003 1:49 AM
To: Moore, Robert
Cc: acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org
Subject: Re: [ACPI] ACPI DSDT language

That is what I want to know! I suppose such operator exists but I didn't
find it in my DSDT and as I wrote earlier I didn't want to read spec. I
tried DerefOf(), but ... you know... :). So I modified my DSDT in a
different way. But anyway thanks for information.

For me the result is ... my original DSDT is buggy. Am I right?



And what about the case when the buffer is created in the root, for
instance:

     Name (PGET, Buffer (8) {})

     Method (SX33, 2, NotSerialized)
     {
         If (LLess (Arg1, SizeOf (Arg0)))
         {
             CreateByteField (Arg0, Arg1, SX20)
             Store (Something, SX20)
         }
     }
 
     Method (PNPG, 1, NotSerialized)
     {
         .
         .
         SX33 (PGET, 2)
         Return (PGET)
     }

Is it the same situation?



Jan


"Moore, Robert" píše:
> 
> This is the purpose of the "RefOf()" operator in ASL.
> 
> >From the ACPI spec:
> 
> "The primary purpose of RefOf() is to allow an object to be passed to a
> method as an argument without the object being evaluated at the time the
> method was loaded."
> 
> Bob
> 
> -----Original Message-----
> From: Jan Slezak [mailto:jan.slezak-aRb0bU7PRFPrBKCeMvbIDA@public.gmane.org]
> Sent: Tuesday, January 28, 2003 2:47 AM
> To: acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org
> Subject: [ACPI] ACPI DSDT language
> 
> Hi,
> 
> I would like to know what way should be buffers handled when are passed as
> arguments to
> ACPI methods. I don't have a time to read the ACPI specs so I hope someone
> knows.
> 
> I find out by tracing my /_TZ/TMP method that they are passed by value so
> following
> construction (part of my original DSDT slightly modified) doesn't work
(PNPG
> called)
> because PGET is not modified:
> 
>     Method (SX33, 2, NotSerialized)
>     {
>         If (LLess (Arg1, SizeOf (Arg0)))
>         {
>             CreateByteField (Arg0, Arg1, SX20)
>             Store (Something, SX20)
>         }
>     }
> 
>     Method (PNPG, 1, NotSerialized)
>     {
>         .
>         .
>         Name (PGET, Buffer (8) {})
>         SX33 (PGET, 2)
>         Return (PGET)
>     }
> 
> I need to know it to decide wheter it is my BIOS or the linux ACPI
> implementation what is
> buggy and to decide whether to send my DSDT patch to my notebook
> manufacturer (DELL).
> 
> Thanks,
>   Jan
> 
> P.S.: If it is right behaviour and the BIOS is buggy I don't understand
why
> the ACPI
> (actually ACPI battery info) is working under WinXP, where there is no
DSDT
> override and
> no buggy feature workaround in the biosinfo.inf for my DELL.
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com