ACPI Source patches updated (20021022)

ACPI Source patches updated (20021022)

[Grover, Andrew]

Hi all,

New ACPI patches are now available on http://sf.net/projects/acpi .
Non-Linux source releases will be up by Thursday evening.

Most notable about this release is the Scope operator changes. People who
have been modifying their DSDTs to get around previous versions' problems
with Scope(OKEC) or Scope(_SB) should find this is no longer necessary.
Please speak up if problems persist.

Regards -- Andy

----------------------------------------
22 October 2002.  Summary of changes for version 20021022.


1) Linux

EC Driver:  No longer attempts to acquire the Global Lock at
interrupt level.

Exported some additional functions needed for PCI hot plug (JI Lee)

Clear ARB_DIS when returning from S1 (Ducrot Bruno)

Rename acpi_power_off to acpi_power_off_device (Pavel Machek)

2) ACPI CA Core Subsystem:

Implemented a restriction on the Scope operator that the
target must already exist in the namespace at the time the
operator is encountered (during table load or method
execution).  In other words, forward references are not
allowed and Scope() cannot create a new object. This changes
the previous behavior where the interpreter would create the
name if not found.  This new behavior correctly enables the
search-to-root algorithm during namespace lookup of the target
name.  Because of this upsearch, this fixes the known Compaq
_SB_.OKEC problem and makes both the AML interpreter and iASL
compiler compatible with other ACPI implementations.

Completed a major overhaul of the internal ACPI object types
for the ACPI Namespace and the associated operand objects.
Many of these types had become obsolete with the introduction
of the two-pass namespace load.  This cleanup simplifies the
code and makes the entire namespace load mechanism much
clearer and easier to understand.

Improved debug output for tracking scope opening/closing to
help diagnose scoping issues.  The old scope name as well as
the new scope name are displayed.  Also improved error
messages for problems with ASL Mutex objects and error
messages for GPE problems.

Cleaned up the namespace dump code, removed obsolete code.

All string output (for all namespace/object dumps) now uses
the common ACPI string output procedure which handles escapes
properly and does not emit non-printable characters.

Fixed some issues with constants in the 64-bit version of the
local C library (utclib.c)

3) iASL Compiler/Disassembler

Implemented ACPI 2.0B grammar change that disallows all Type 1
and 2 opcodes outside of a control method.  This means that
the "executable" operators (versus the "namespace" operators)
cannot be used at the table level; they can only be used
within a control method.

Implemented the restriction on the Scope() operator where the
target must already exist in the namespace at the time the
operator is encountered (during ASL compilation). In other
words, forward references are not allowed and Scope() cannot
create a new object.  This makes the iASL compiler compatible
with other ACPI implementations and makes the Scope()
implementation adhere to the ACPI specification.

Fixed a problem where namepath optimization for the Alias
operator was optimizing the wrong path (of the two namepaths.)
This caused a "Missing alias link" error message.

Fixed a problem where an "unknown reserved name" warning could
be incorrectly generated for names like "_SB" when the
trailing underscore is not used in the original ASL.

Fixed a problem where the reserved name check did not handle
NamePaths with multiple NameSegs correctly.  The first nameseg
of the NamePath was examined instead of the last NameSeg.

-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org



-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote

Re: ACPI Source patches updated (20021022)

[KOCHI, Takayoshi]

Hi,

> 3) iASL Compiler/Disassembler
> 
> Implemented ACPI 2.0B grammar change that disallows all Type 1
> and 2 opcodes outside of a control method.  This means that
> the "executable" operators (versus the "namespace" operators)
> cannot be used at the table level; they can only be used
> within a control method.

Where can I find ACPI 2.0B?
http://www.acpi.info/ seems to provide only 2.0a.

Thanks,
-- 
KOCHI, Takayoshi <t-kouchi-f7IHDacdhdx8UrSeD/g0lQ@public.gmane.org/t-kouchi>



-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

Re: ACPI Source patches updated (20021022)

[Ville Syrjälä]

On Tue, Oct 22, 2002 at 07:19:33PM -0700, Grover, Andrew wrote:
> Hi all,
> 
> New ACPI patches are now available on http://sf.net/projects/acpi .
> Non-Linux source releases will be up by Thursday evening.

You didn't pick up my IRQ derive fix. Is it incorrect or did you just
miss it?

--- linux-2.4.20-pre7/drivers/acpi/pci_irq.c~   Thu Sep 19 17:17:58 2002
+++ linux-2.4.20-pre7/drivers/acpi/pci_irq.c    Tue Oct  8 01:45:29 2002
@@ -285,7 +285,7 @@
 	 * PCI interrupt routing entry (a.k.a. the "bridge swizzle").
 	 */
 	while (!irq && (bridge = bridge->bus->self)) {
-		pin = (pin + PCI_SLOT(bridge->devfn)) % 4;
+		pin = (pin + PCI_SLOT(dev->devfn)) % 4;
 		irq = acpi_pci_irq_lookup(0, bridge->bus->number, PCI_SLOT(bridge->devfn), pin);
 	}
 

-- 
Ville Syrjälä
syrjala-ORSVBvAovxo@public.gmane.org
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

Re: ACPI Source patches updated (20021022)

[Sérgio Monteiro Basto]

Citando Ville Syrjälä <syrjala-ORSVBvAovxo@public.gmane.org>:

} You didn't pick up my IRQ derive fix. Is it incorrect
} or did you just
} miss it?

In this list it is normal.
You have to justify what this fix do.
I try it in my laptop and the IRQ derive warning disappears, 
but doesn't warranty  that code is correct, so can you explain,
what is the difference of this code?

bye
Sérgio Monteiro Basto
		

--------------------------------------------
SAPO ADSL.PT Agora o kit apenas por 75 Eur. e tráfego ilimitado até ao final de 2002!
Mais informações em http://www.sapo.pt/kitadsl


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

Re: ACPI Source patches updated (20021022)

[Ville Syrjälä]

On Wed, Oct 23, 2002 at 03:47:42PM +0100, Sérgio Monteiro Basto wrote:
> Citando Ville Syrjälä <syrjala-ORSVBvAovxo@public.gmane.org>:
> 
> } You didn't pick up my IRQ derive fix. Is it incorrect
> } or did you just
> } miss it?
> 
> In this list it is normal.
> You have to justify what this fix do.

Simply put it fixes the AGP slot's IRQ routing on my Abit KT7 :)

> I try it in my laptop and the IRQ derive warning disappears, 
> but doesn't warranty  that code is correct, so can you explain,
> what is the difference of this code?

The AGP slot doesn't have an entry in the PRT but the AGP bridge does.
Without this change the code gets the devfn field from the bridge which
causes it to think it wants INTB instead of INTA even though the card
wants INTA. The effect of which is one IRQ completely unused and AGP card
sharing it's IRQ with two other PCI cards.

As I said I'm not sure it's correct but I'm pretty confident since the
IO-APIC code uses dev->devfn instead of bridge->devfn.

-- 
Ville Syrjälä
syrjala-ORSVBvAovxo@public.gmane.org
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

Toshiba Tecra 9xxx and S1 (was: ACPI Source patches updated (20021022))

[Sebastian Zimmermann]

Am Mit, 2002-10-23 um 04.19 schrieb Grover, Andrew:
> New ACPI patches are now available on http://sf.net/projects/acpi .

Using this new patch together with 2.4.20-pre11, my Toshiba Tecra 9000
still doesn't wake up from S1-sleep.

echo -n 1 > /proc/acpi/sleep

puts the laptop to sleep. Display light goes off and power LED turns
orange. Hard disk is still running.

When I push the power button, the power LED turns green again, but
nothing else happens. Magic Sys-Rq keys don't work either.

Does anybody have a hint what I have to look for?

Thanks,

 Sebastian



-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote

Re: ACPI Source patches updated (20021022)

[Kai Germaschewski]

On Wed, 23 Oct 2002, Ville Syrjälä wrote:

> On Tue, Oct 22, 2002 at 07:19:33PM -0700, Grover, Andrew wrote:
> > Hi all,
> > 
> > New ACPI patches are now available on http://sf.net/projects/acpi .
> > Non-Linux source releases will be up by Thursday evening.
> 
> You didn't pick up my IRQ derive fix. Is it incorrect or did you just
> miss it?
> 
> --- linux-2.4.20-pre7/drivers/acpi/pci_irq.c~   Thu Sep 19 17:17:58 2002
> +++ linux-2.4.20-pre7/drivers/acpi/pci_irq.c    Tue Oct  8 01:45:29 2002
> @@ -285,7 +285,7 @@
>  	 * PCI interrupt routing entry (a.k.a. the "bridge swizzle").
>  	 */
>  	while (!irq && (bridge = bridge->bus->self)) {
> -		pin = (pin + PCI_SLOT(bridge->devfn)) % 4;
> +		pin = (pin + PCI_SLOT(dev->devfn)) % 4;
>  		irq = acpi_pci_irq_lookup(0, bridge->bus->number, PCI_SLOT(bridge->devfn), pin);
>  	}

Well, this patch is obviously not correct, consider the case where the 
loop is executed more than once.

I think it should be

	while (!irq && bridge->bus->self) {
		pin = (pin + PCI_SLOT(bridge->devfn)) % 4;
		bridge = bridge->bus->self;
		irq = acpi_pci_irq_lookup(0, bridge->bus->number, PCI_SLOT(bridge->devfn), pin);
	}

Want to give that a try?

--Kai




-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote

Re: ACPI Source patches updated (20021022)

[Ville Syrjälä]

On Thu, Oct 24, 2002 at 10:29:04AM -0500, Kai Germaschewski wrote:
> Well, this patch is obviously not correct, consider the case where the 
> loop is executed more than once.
> 
> I think it should be
> 
> 	while (!irq && bridge->bus->self) {
> 		pin = (pin + PCI_SLOT(bridge->devfn)) % 4;
> 		bridge = bridge->bus->self;
> 		irq = acpi_pci_irq_lookup(0, bridge->bus->number, PCI_SLOT(bridge->devfn), pin);
> 	}

Yes I see the logic in that. But I don't know enough about PCI to relly
understand how things work. Over one iteration this does exactly what my
patch did and that's what I care about :) Is it even realistic to expect
that multiple bridges are lined up so that the loop would get executed
more than once?

-- 
Ville Syrjälä
syrjala-ORSVBvAovxo@public.gmane.org
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en

Re: ACPI Source patches updated (20021022)

[Kai Germaschewski]

On Thu, 24 Oct 2002, Ville Syrjälä wrote:

> Yes I see the logic in that. But I don't know enough about PCI to relly
> understand how things work. Over one iteration this does exactly what my
> patch did and that's what I care about :) Is it even realistic to expect
> that multiple bridges are lined up so that the loop would get executed
> more than once?

Well, it's possible, though I don't have any box which does. Say you have 
a PCI hotplug controller, which I think appears as bridge and put a 4-port 
tulip network card into it. These network cards are implemented using a 
PCI bridge as well, so that'd be a case where it would actually happen.

--Kai




-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en