public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
To: Nate Lawson <nate-Y6VGUYTwhu0@public.gmane.org>
Cc: "Moore,
	Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [PATCH] Stall semantics
Date: Wed, 1 Oct 2003 18:16:57 +0100	[thread overview]
Message-ID: <20031001171657.GW24824@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20031001093943.J85056-Y6VGUYTwhu0@public.gmane.org>

On Wed, Oct 01, 2003 at 09:59:49AM -0700, Nate Lawson wrote:
> Let me quote that line again:
> > Because of this, delays longer than 100 microseconds must use Sleep
> > instead of Stall.
> 
> The current code is incorrect.  It uses Stall (i.e. a delay loop) for
> waits of up to 1000 us, not 100 us like the standard.  My patch makes the
> code match the standard.
> 
> Your point is whether Sleep should automatically be called by OSPM when
> the AML specifies a Stall of more than a certain amount (let's stick to
> 100 us for this example).  I believe OSPM can and should automatically
> call Sleep when the time requested exceeds the maximum for Stall.  Look at
> that line again.  The key word is "use".  If OSPM automatically translates
> the call, delays longer than 100 us will indeed _use_ Sleep instead of
> Stall.  This gives correct, standard behavior even when the AML didn't
> originally match the standard.

Hang on though.  We've got two contradictory requirements from the
combination of the AML and the Specification.  You've chosen one
requirement over the other without discussion.  I think an equally valid
interpretation is "This code must not relinquish the CPU", in which case,
it would conform to the specification to Stall for only 100us and then
return to the AML.

Fundamentally, we're outside the specification and into nasal demon
territory.  We can do whatever we like.  The question is: what to do that
will break the least number of machines.  Sleeping unexpectedly can easily
break code -- this is why you can't schedule while holding a spinlock,
for example.  Of course, Stalling for too long is also a bad idea.

I think the current ACPI behaviour is probably adequate -- accommodate
incopetent BIOS writers up to a point, then sleep, and damn them anyway.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

  parent reply	other threads:[~2003-10-01 17:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-30 22:04 [PATCH] Stall semantics Moore, Robert
     [not found] ` <D3A3AA459175A44CB5326F26DA7A189C1C3DAF-sBd4vmA9Se58QrAoInS571DQ4js95KgL@public.gmane.org>
2003-10-01 16:59   ` Nate Lawson
     [not found]     ` <20031001093943.J85056-Y6VGUYTwhu0@public.gmane.org>
2003-10-01 17:16       ` Matthew Wilcox [this message]
     [not found]         ` <20031001171657.GW24824-+pPCBgu9SkPzIGdyhVEDUDl5KyyQGfY2kSSpQ9I8OhVaa/9Udqfwiw@public.gmane.org>
2003-10-01 17:27           ` Nate Lawson
     [not found]             ` <20031001101854.J85056-Y6VGUYTwhu0@public.gmane.org>
2003-10-01 18:55               ` Matthew Wilcox
     [not found]                 ` <20031001185524.GX24824-+pPCBgu9SkPzIGdyhVEDUDl5KyyQGfY2kSSpQ9I8OhVaa/9Udqfwiw@public.gmane.org>
2003-10-01 19:45                   ` Nate Lawson
  -- strict thread matches above, loose matches on Subject: below --
2003-10-03 20:23 Moore, Robert
     [not found] ` <D3A3AA459175A44CB5326F26DA7A189C1C3DD1-sBd4vmA9Se58QrAoInS571DQ4js95KgL@public.gmane.org>
2003-10-03 20:28   ` Matthew Wilcox
2003-10-03 20:49   ` Nate Lawson
2003-09-30 21:38 Moore, Robert
     [not found] ` <D3A3AA459175A44CB5326F26DA7A189C1C3DAB-sBd4vmA9Se58QrAoInS571DQ4js95KgL@public.gmane.org>
2003-09-30 21:45   ` Nate Lawson
2003-09-30 19:37 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=20031001171657.GW24824@parcelfarce.linux.theplanet.co.uk \
    --to=willy-8fiuurrzop0dnm+yrofe0a@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=nate-Y6VGUYTwhu0@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox