Re: ACPI Source patches updated (20021022)

[Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>]

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