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

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

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)

[Moore, Robert]

We are in the process of formatting the document, it should be posted soon.

-----Original Message-----
From: KOCHI, Takayoshi [mailto:t-kouchi-dPjYVeZdYcz+G+EEi5ephHgSJqDPrsil@public.gmane.org] 
Sent: Tuesday, October 22, 2002 9:51 PM
To: acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org
Subject: Re: [ACPI] ACPI Source patches updated (20021022)

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
_______________________________________________
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: 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)

[Grover, Andrew]

> From: Ville Syrjälä [mailto:syrjala-ORSVBvAovxo@public.gmane.org] 
> > In this list it is normal.
> > You have to justify what this fix do.

Did anyone else test it?

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

I didn't think video needed an IRQ. I'm pretty leery about modifying the IRQ
routing code at all - I know we have bugs left, but I don't want to add
more. ;-)

That said, I'll put this in the next release and we can see what happens. If
people want to try this in the meantime, that would be great, too.

Regards -- Andy


-------------------------------------------------------
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)

[Ducrot Bruno]

On Wed, Oct 23, 2002 at 10:11:52AM -0700, Grover, Andrew wrote:
> > From: Ville Syrjälä [mailto:syrjala-ORSVBvAovxo@public.gmane.org] 
> > > In this list it is normal.
> > > You have to justify what this fix do.
> 
> Did anyone else test it?
> 
> > Simply put it fixes the AGP slot's IRQ routing on my Abit KT7 :)
> 
> I didn't think video needed an IRQ.

Please look at
drivers/char/drm/drm_dma.h
drivers/char/drm/radeon_irq.c

for examples.


-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
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 08:36:46PM +0200, Ducrot Bruno wrote:
> On Wed, Oct 23, 2002 at 10:11:52AM -0700, Grover, Andrew wrote:
> > I didn't think video needed an IRQ.
> 
> Please look at
> drivers/char/drm/drm_dma.h
> drivers/char/drm/radeon_irq.c
> 
> for examples.

In my case the cause is DirectFB.

-- 
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

Re: ACPI Source patches updated (20021022)

[Ducrot Bruno]

On Wed, Oct 23, 2002 at 09:41:59PM +0300, Ville Syrjälä wrote:
> 
> On Wed, Oct 23, 2002 at 08:36:46PM +0200, Ducrot Bruno wrote:
> > On Wed, Oct 23, 2002 at 10:11:52AM -0700, Grover, Andrew wrote:
> > > I didn't think video needed an IRQ.
> > 
> > Please look at
> > drivers/char/drm/drm_dma.h
> > drivers/char/drm/radeon_irq.c
> > 
> > for examples.
> 
> In my case the cause is DirectFB.

AFAIK, DirectFB is 'only' a user space library, so it should ioctl a
drm-aware driver in order to be interrupt-driven?
(just a question, I am not sure a 100% because I didn't look at
the DirectFB code).

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
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 09:19:29PM +0200, Ducrot Bruno wrote:
> AFAIK, DirectFB is 'only' a user space library

Yes.

> so it should ioctl a
> drm-aware driver in order to be interrupt-driven?

There's a patch for matroxfb distributed with DirectFB. I suppose it could
be modified to use drm instead if that's how things get standardised. IMO
fbdev feels like a better place for vsync irq sutff.

-- 
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

RE: ACPI Source patches updated (20021022)

[Grover, Andrew]

> > From: Ville Syrjälä [mailto:syrjala-ORSVBvAovxo@public.gmane.org] 
> That said, I'll put this in the next release and we can see 
> what happens. If
> people want to try this in the meantime, that would be great, too.

Wait a second. Looking at the calling code (acpi_pci_irq_enable) we check
the device itself for PRT entries there, so we shouldn't have to also do
this in pci_irq_derive, which only gets called if there aren't any found for
the device.

Thoughts?

Regards -- Andy


-------------------------------------------------------
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 10:17:57AM -0700, Grover, Andrew wrote:
> > > From: Ville Syrjälä [mailto:syrjala-ORSVBvAovxo@public.gmane.org] 
> > That said, I'll put this in the next release and we can see 
> > what happens. If
> > people want to try this in the meantime, that would be great, too.
> 
> Wait a second. Looking at the calling code (acpi_pci_irq_enable) we check
> the device itself for PRT entries there, so we shouldn't have to also do
> this in pci_irq_derive, which only gets called if there aren't any found for
> the device.

I'm not sure what you're saying. There isn't an entry in the PRT for the
AGP device so the derive code will look at the bridge's entry. But the
code gets the pin number wrong. It should be looking at A while
it's looking at B. But still the driver code doesn't care what the ACPI
code things so eventually INTA of the card will be assigned to the IRQ
found. Now if I were to attach a card to PCI1 things might become weird.
The AGP card would get one IRQ and the PCI card other even though both
share the INTA line. I'm no expert but I'm pretty sure that would cause
problems.

-- 
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

Re: ACPI Source patches updated (20021022)

[Ducrot Bruno]

On Wed, Oct 23, 2002 at 08:54:41PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 23, 2002 at 10:17:57AM -0700, Grover, Andrew wrote:
> > > > From: Ville Syrjälä [mailto:syrjala-ORSVBvAovxo@public.gmane.org] 
> > > That said, I'll put this in the next release and we can see 
> > > what happens. If
> > > people want to try this in the meantime, that would be great, too.
> > 
> > Wait a second. Looking at the calling code (acpi_pci_irq_enable) we check
> > the device itself for PRT entries there, so we shouldn't have to also do
> > this in pci_irq_derive, which only gets called if there aren't any found for
> > the device.
> 
> I'm not sure what you're saying. There isn't an entry in the PRT for the
> AGP device so the derive code will look at the bridge's entry. But the
> code gets the pin number wrong. It should be looking at A while
> it's looking at B. But still the driver code doesn't care what the ACPI
> code things so eventually INTA of the card will be assigned to the IRQ
> found. Now if I were to attach a card to PCI1 things might become weird.
> The AGP card would get one IRQ and the PCI card other even though both
> share the INTA line. I'm no expert but I'm pretty sure that would cause
> problems.
> 

So I think this is an AML issue.  Your AGP device is actually a
bridge and ACPI spec require a _PRT entry for each bridge.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
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 08:25:27PM +0200, Ducrot Bruno wrote:
>
> So I think this is an AML issue.  Your AGP device is actually a
> bridge and ACPI spec require a _PRT entry for each bridge.

The DSDT has PCI0._PRT in which 00:01.0 (the AGP bridge) is listed. Are
you saying that there should also be PCI1._PRT with just one entry for
01:00.0? If that were the case there wouldn't be any need to derive the
IRQ would there?

Either way please look at the IO-APIC code. You'll see it's almost
identical to the ACPI code and clearly one of them is wrong. My bet goes
to IO-APIC code being correct in which case my fix is also correct.

-- 
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

Re: ACPI Source patches updated (20021022)

[Ducrot Bruno]

On Wed, Oct 23, 2002 at 09:40:46PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 23, 2002 at 08:25:27PM +0200, Ducrot Bruno wrote:
> >
> > So I think this is an AML issue.  Your AGP device is actually a
> > bridge and ACPI spec require a _PRT entry for each bridge.
> 
> The DSDT has PCI0._PRT in which 00:01.0 (the AGP bridge) is listed. Are
> you saying that there should also be PCI1._PRT with just one entry for
> 01:00.0? If that were the case there wouldn't be any need to derive the
> IRQ would there?
> 

You should have something like this:

Device(PCI0) {
	Name(..)
	Name (_ADR, 0x00)
	...
	Name (_PRT, Package(...) ) {
		...
	}
	...
	Device (AGP) {
		Name (_ADR, 0x00010000)
		Name (_PRT, Package(1) {
			Package(4) {
				...,
				0x00,
				PATH.TO.LNKA,
				...
			}
		})
		Device (VGA) {
			...
		}
	}
	...

}

If you have Name(_ADR, 0x00010000) for your Device (AGP), it
should ok to add the _PRT entry.  This is also a requirement, but
only for 2.0 specs.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
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 09:47:51PM +0200, Ducrot Bruno wrote:
> You should have something like this:
> 
> 	Device (AGP) {

Doesn't exist. But the derive code works just fine with that small fix.
I have my DSDT at http://www.sci.fi/~syrjala/acpi if you want to take a
look.


-- 
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

Re: ACPI Source patches updated (20021022)

[Ducrot Bruno]

On Wed, Oct 23, 2002 at 09:47:51PM +0200, Ducrot Bruno wrote:
> On Wed, Oct 23, 2002 at 09:40:46PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 23, 2002 at 08:25:27PM +0200, Ducrot Bruno wrote:
> > >
> > > So I think this is an AML issue.  Your AGP device is actually a
> > > bridge and ACPI spec require a _PRT entry for each bridge.
> > 

I should read a little bit more specs.  A _PRT entry is required
only for root bridges.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
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)

[Grover, Andrew]

> From: Ville Syrjälä [mailto:syrjala-ORSVBvAovxo@public.gmane.org] 
> The DSDT has PCI0._PRT in which 00:01.0 (the AGP bridge) is 
> listed. Are
> you saying that there should also be PCI1._PRT with just one entry for
> 01:00.0? If that were the case there wouldn't be any need to 
> derive the
> IRQ would there?
> 
> Either way please look at the IO-APIC code. You'll see it's almost
> identical to the ACPI code and clearly one of them is wrong. 
> My bet goes
> to IO-APIC code being correct in which case my fix is also correct.

OK thanks for taking the time to explain. Applied.

Regards -- Andy


-------------------------------------------------------
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)

[Lee, Jung-Ik]

> > > >
> > > > So I think this is an AML issue.  Your AGP device is actually a
> > > > bridge and ACPI spec require a _PRT entry for each bridge.
> > > 
> 
> I should read a little bit more specs.  A _PRT entry is required
> only for root bridges.
> 
_PRT could be in non root bridges.

J.I.


-------------------------------------------------------
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)

[Ducrot Bruno]

On Thu, Oct 24, 2002 at 10:04:29AM -0700, Lee, Jung-Ik wrote:
> 
> > > > >
> > > > > So I think this is an AML issue.  Your AGP device is actually a
> > > > > bridge and ACPI spec require a _PRT entry for each bridge.
> > > > 
> > 
> > I should read a little bit more specs.  A _PRT entry is required
> > only for root bridges.
> > 
> _PRT could be in non root bridges.

Of course.  'required' is the keyword, here.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
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)

[Lee, Jung-Ik]

> From: Kai Germaschewski [mailto:kai-germaschewski-Q3dYeWy5uxSHXe+LvDLADg@public.gmane.org]
> 
> 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.

And any bridge adapters hot-added will need swizzling to map irq exactly as
Kai mentioned.
We have a box that needs this. 

thanks,
J.I.



-------------------------------------------------------
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)

[Grover, Andrew]

> From: Kai Germaschewski [mailto:kai-germaschewski-Q3dYeWy5uxSHXe+LvDLADg@public.gmane.org] 
> 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.

OK, so everyone agrees Kai's version is the way to go? ;-)

Regards -- Andy


-------------------------------------------------------
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