Re: ACPI ignoring IRQ flags in PRT

[Rob North <tzwvgwv2001-O/bDAPVd7B0N+BqQ9rBEUg@public.gmane.org>]

Andrew de Quincey wrote:
>>Great to see someone's digging into this. BTW have you looked at the
>>ACPI 2.0 spec section 6.2.8? It talks about the contents of _PRT.
>>Basically, it can contain either the interrupt number itself OR point to
>>a link device, which in turn lets ACPI read (via _CRS) write (via _SRS)
>>and see the possiblities (_BRS) for controlling the interrupt routing
>>for that device.
>>
>>The code *should* be handling both these cases, but obviously there are
>>still some bugs lurking.
> 
> 
> I think its handling both cases OK, its just that it was ignoring the polarity 
> and mode settings for link device IRQs.
> 
> What I was wondering was if/where these settings were for global IRQs... i.e. 
> when the _PRT contains the actual interrupt number, what settings should be 
> used.
> 
> I suppose since its the PCI routing table, it might just expect you to default 
> to PCI settings, but as I found link-device IRQs specified in the PRT don't 
> necessary follow the PCI standard... problem is, my board doesn't specify 'em 
> in this way.

Yes, I assumed that global IRQs were set up with default PCI polarities:
I was assuming that there was a direct electrical connection from the
PCI bus to the APIC pins in the global IRQ case.

As you have decompiled you ACPI table maybe you should look for
Interrupt definitions in strange places. i.e. outside link devices?

Might there also be a default polarity specified in the APIC defintions?
(Or after looking at the spec, might APICs with you APIC ID have 
interupt polarities reverse of "normal" APICS?)






-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1