All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
To: Arjan van de Ven <arjanv-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: ACPI global lock macros
Date: Tue, 09 Dec 2003 01:50:16 -0800	[thread overview]
Message-ID: <3FD59AD8.1060507@google.com> (raw)
In-Reply-To: <20031209094356.GA19702-s/M1imWmeEoQw3kMeb7FcACJwEvxM/w9@public.gmane.org>

Arjan van de Ven wrote:
>>>maybe the odd thing is that it exists at all?
>>>(eg why does ACPI need to have it's own locking primitives...)
>>
>>Because the ACPI spec defines its own locking protocol for 
>>synchronization between the OS and the BIOS.
> 
> 
> ... which can't be written based on linux locks ?

I assume (hope!) there's already a higher-level linux lock serializing 
access to acpi_acquire_global_lock() although I've not delved deeply 
into the code. This is the lock described on p112 of 
http://www.acpi.info/DOWNLOADS/ACPIspec-2-0c.pdf, which has the 
semantics that if the OS wants to take the lock while the BIOS holds it, 
it sets a bit and waits for an interrupt from the BIOS. I don't see that 
it could be naturally implemented using a linux lock.

Paul



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

WARNING: multiple messages have this Message-ID (diff)
From: Paul Menage <menage@google.com>
To: Arjan van de Ven <arjanv@redhat.com>
Cc: agrover@groveronline.com, linux-kernel@vger.kernel.org,
	acpi-devel@lists.sourceforge.net
Subject: Re: ACPI global lock macros
Date: Tue, 09 Dec 2003 01:50:16 -0800	[thread overview]
Message-ID: <3FD59AD8.1060507@google.com> (raw)
In-Reply-To: <20031209094356.GA19702@devserv.devel.redhat.com>

Arjan van de Ven wrote:
>>>maybe the odd thing is that it exists at all?
>>>(eg why does ACPI need to have it's own locking primitives...)
>>
>>Because the ACPI spec defines its own locking protocol for 
>>synchronization between the OS and the BIOS.
> 
> 
> ... which can't be written based on linux locks ?

I assume (hope!) there's already a higher-level linux lock serializing 
access to acpi_acquire_global_lock() although I've not delved deeply 
into the code. This is the lock described on p112 of 
http://www.acpi.info/DOWNLOADS/ACPIspec-2-0c.pdf, which has the 
semantics that if the OS wants to take the lock while the BIOS holds it, 
it sets a bit and waits for an interrupt from the BIOS. I don't see that 
it could be naturally implemented using a linux lock.

Paul


  parent reply	other threads:[~2003-12-09  9:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-09  9:22 ACPI global lock macros Paul Menage
2003-12-09  9:22 ` Paul Menage
     [not found] ` <3FD59441.2000202-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2003-12-09  9:36   ` Arjan van de Ven
2003-12-09  9:36     ` Arjan van de Ven
     [not found]     ` <1070962573.5223.2.camel-PDvaWZGbcxi0rsOeZxrteAC/G2K4zDHf@public.gmane.org>
2003-12-09  9:42       ` Paul Menage
2003-12-09  9:42         ` Paul Menage
     [not found]         ` <3FD5990A.9020908-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2003-12-09  9:43           ` Arjan van de Ven
2003-12-09  9:43             ` Arjan van de Ven
     [not found]             ` <20031209094356.GA19702-s/M1imWmeEoQw3kMeb7FcACJwEvxM/w9@public.gmane.org>
2003-12-09  9:50               ` Paul Menage [this message]
2003-12-09  9:50                 ` Paul Menage
2003-12-10  7:45   ` Andi Kleen
2003-12-10  7:45     ` [ACPI] " Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2003-12-09 18:20 Grover, Andrew
     [not found] ` <F760B14C9561B941B89469F59BA3A8470255EFB3-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org>
2003-12-09 19:04   ` Paul Menage
2003-12-11  7:06 Yu, Luming
2003-12-11  8:07 ` [ACPI] " Andi Kleen
     [not found]   ` <20031211090716.0c3662d3.ak-l3A5Bk7waGM@public.gmane.org>
2003-12-11  8:27     ` Paul Menage
     [not found] ` <3ACA40606221794F80A5670F0AF15F8401720C21-SRlDPOYGfgogGBtAFL8yw7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2003-12-11  8:20   ` Paul Menage
2003-12-11  7:27 Yu, Luming
     [not found] ` <3ACA40606221794F80A5670F0AF15F8401720C22-SRlDPOYGfgogGBtAFL8yw7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2003-12-11 17:46   ` Nate Lawson

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=3FD59AD8.1060507@google.com \
    --to=menage-hpiqsd4aklfqt0dzr+alfa@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org \
    --cc=arjanv-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@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.