RE: [ACPI] [PATCH] Stall semantics

[Moore, R. <rob...@in...>]

Here's what the MS interpreter does for Stall(n);

1) If n <=3D 255 (MAX_BYTE), perform the stall.
2) If n > 255, throw an error and abort the control method.

In this case, I suggest that we simply duplicate the MS behavior, it
seems like a good compromise and also provides ACPI CA with exact
compatibility.

Bob


-----Original Message-----
From: Nate Lawson [mailto:na...@ro...]=20
Sent: Wednesday, October 01, 2003 10:27 AM
To: Matthew Wilcox
Cc: Moore, Robert; acp...@li...
Subject: Re: [ACPI] [PATCH] Stall semantics

On Wed, 1 Oct 2003, Matthew Wilcox wrote:
> 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.
>
> 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.

You're assuming the AML mistake is made both ways.  If it is uniformly
made one way, it's easy to work around correctly.

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

It damns us OS vendors a different way in that we get unacceptably long
idle spin loops on some machines.  Spinning for 1000 us is not correct
any
way you interpret the standard.

If we can't reach agreement, it's better to leave things the same.  The
other part of my patch is still useful in reducing redundant code.

-Nate