All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Slezak <jan.slezak-aRb0bU7PRFPrBKCeMvbIDA@public.gmane.org>
To: "Moore, Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org
Subject: Re: ACPI DSDT language
Date: Thu, 30 Jan 2003 10:49:20 +0100	[thread overview]
Message-ID: <3E38F520.89609A15@centrum.cz> (raw)
In-Reply-To: B9ECACBD6885D5119ADC00508B68C1EA0D19BA5F@orsmsx107.jf.intel.com

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

  reply	other threads:[~2003-01-30  9:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-29 16:24 ACPI DSDT language Moore, Robert
2003-01-30  9:49 ` Jan Slezak [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-30 16:32 Moore, Robert
2003-01-28 10:47 Jan Slezak
     [not found] ` <20030128133617.GM32050@poup.poupinou.org>
     [not found]   ` <3E37A000.DB4190B@centrum.cz>
     [not found]     ` <20030129121715.GP32050@poup.poupinou.org>
2003-01-29 13:39       ` Jan Slezak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E38F520.89609A15@centrum.cz \
    --to=jan.slezak-arb0bu7prfprbkcemvbida@public.gmane.org \
    --cc=acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org \
    --cc=robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.