RE: Re: ACPI ignoring IRQ flags in PRT

RE: Re: ACPI ignoring IRQ flags in PRT

[Grover, Andrew]

> From: Andrew de Quincey [mailto:adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org] 
> > I think what was throwing Matthew is that the interupt 
> trigger types are
> > specified in  _PRS objects
> > The _PRT object is a mapping from PCI device to a particular "PCI
> > Interrupt Link device" and in the defintion of the link 
> device, the IRQs
> > are defined in _PRS objects.
> 
> Yeah, I suspected I wasn't using the right terminology.
> 
> Where are the parameters for "global system interrupts" 
> defined? It looks like 
> we have to support this configuration method as well. The 
> MADT table sounded 
> likely, but that is only for overriding ISA IRQs. Where are 
> >15 IRQs defined?

Hi Andrew,

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.

Regards -- Andy


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

Re: Re: ACPI ignoring IRQ flags in PRT

[Andrew de Quincey]

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



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

Re: ACPI ignoring IRQ flags in PRT

[Rob North]

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

ACPI ignoring IRQ flags in PRT

[Andrew de Quincey]

Hi, from my understanding of the ACPI spec, each IRQ as specified in the _PRT 
has additional flags associated with it (e.g. specifying the polarity, level 
etc) that should be used for this IRQ. 

The Linux ACPI code seems to be ignoring these, and hardcodes them to the 
values that cause problems for me. Is there a reason, or has that code just 
not been written yet?



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

Re: ACPI ignoring IRQ flags in PRT

[Matthew Wilcox]

On Sun, Jul 13, 2003 at 02:52:38PM +0100, Andrew de Quincey wrote:
> 
> Hi, from my understanding of the ACPI spec, each IRQ as specified in the _PRT 
> has additional flags associated with it (e.g. specifying the polarity, level 
> etc) that should be used for this IRQ. 
> 
> The Linux ACPI code seems to be ignoring these, and hardcodes them to the 
> values that cause problems for me. Is there a reason, or has that code just 
> not been written yet?

you can't mean the _PRT.  the _PRT describes PCI interrupts, and those
have their polarity and trigger specified by the PCI spec.  i suspect you
mean someting else, but i'm not sure what.  can't be the SCI interrupt
since that's defined to be level, low, sharable.

some of the ia64 acpi code pays attention to polarity and edge vs level.
now that we know this is an issue on x86, maybe some more people will be
interested in thinking about how to fix this properly.  here's what we
currently have on ia64:

int acpi_register_irq (u32 gsi, u32 polarity, u32 trigger);

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


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

Re: ACPI ignoring IRQ flags in PRT

[Andrew de Quincey]

On Sunday 13 July 2003 15:23, Matthew Wilcox wrote:
> On Sun, Jul 13, 2003 at 02:52:38PM +0100, Andrew de Quincey wrote:
> > Hi, from my understanding of the ACPI spec, each IRQ as specified in the
> > _PRT has additional flags associated with it (e.g. specifying the
> > polarity, level etc) that should be used for this IRQ.
> >
> > The Linux ACPI code seems to be ignoring these, and hardcodes them to the
> > values that cause problems for me. Is there a reason, or has that code
> > just not been written yet?
>
> you can't mean the _PRT.  the _PRT describes PCI interrupts, and those
> have their polarity and trigger specified by the PCI spec.  i suspect you
> mean someting else, but i'm not sure what.  can't be the SCI interrupt
> since that's defined to be level, low, sharable.
>
> some of the ia64 acpi code pays attention to polarity and edge vs level.
> now that we know this is an issue on x86, maybe some more people will be
> interested in thinking about how to fix this properly.  here's what we
> currently have on ia64:
>
> int acpi_register_irq (u32 gsi, u32 polarity, u32 trigger);

On my system, each _PRT entry points to a NamePath giving the "name of the 
device that allocates the interrupt to which the above pin is connected". It, 
in turn points to an IRQ resource descriptor. Byte 3 of IRQ resource 
descriptors contain flags giving sharability, the polarity, mode 
(level/edge). So it is theoretically feasible to specify them.

My USB devices are definitely PCI devices. They work fine when they're 
allocated to ISA IRQs (i.e. active high). When they're allocated to "PCI" 
(i.e. >15) IRQs by linux they do not work, yet the _PRT tables in ACPI 
specify IRQs 20,21, and 22. When I hardcode all the "PCI" IRQs to be active 
high, they start working again. 

It all works fine in Windows, and my USB devices are allocated IRQs 20,21,22.

The _PRT entry for one of my USB devices is:

            Package(0x4) {
                0x0002ffff,
                0x0,
                \_SB_.PCI0.APCF,
                0x0,
            },

The corresponding device is:

        Device(APCF) {
            Name(_HID, 0x0f0cd041)
            Name(_UID, 0x10)
            Method(_STA) {
                If(INTG) {
                    Return(0xb)
                }
                Else {
                    Return(0x9)
                }
            }
            Method(_PRS) {
                Return(BUFF)
            }
            Method(_DIS) {
                Store(0x0, INTG)
            }
            Method(_CRS) {
                Return(CRSA(INTG))
            }
            Method(_SRS, 1) {
                Store(SRSA(Arg0), INTG)
            }
        }

And the actual raw descriptor data is:

Name(BUFF, Buffer(0x13) {0x89, 0xe, 0x0, 0x9, 0x3, 0x14, 0x0, 0x0, 0x0, 0x15, 
0x0, 0x0, 0x0, 0x16, 0x0, 0x0, 0x0, 0x79, 0x0 })

Byte 3 here (00001001) specifies the flags:
bit[0]==1 -- The device consumes the resource
bit[1]==0 -- Level triggered
bit[2]==0 -- Active High
bit[3]==1 -- Sharable
bit[4-7] -- reserved (set to 0)

The IRQs specified are 20,21,22.

So, the code in io_apic.c is assuming that all IRQs > 15 are PCI-compatable. 
For me, at least, they are not, *EVEN THOUGH they're in the _PRT*. The ACPI 
tables are describing them as I have experimentally found them to be.



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

Re: ACPI ignoring IRQ flags in PRT

[Rob North]

Andrew de Quincey wrote:
> On Sunday 13 July 2003 15:23, Matthew Wilcox wrote:
> 

> 
> So, the code in io_apic.c is assuming that all IRQs > 15 are PCI-compatable. 
> For me, at least, they are not, *EVEN THOUGH they're in the _PRT*. The ACPI 
> tables are describing them as I have experimentally found them to be.
> 
> 
> 
> -------------------------------------------------------
> 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

Andrew, I think you're on to something big here.
I've been having similiar problems with my A7N8x Deluxe motherboard, and
I've been looking into the kernel code in the 2.4.X series of kernels,
and you've definately found something that look amiss.

I think what was throwing Matthew is that the interupt trigger types are 
specified in  _PRS objects
The _PRT object is a mapping from PCI device to a particular "PCI 
Interrupt Link device" and in the defintion of the link device, the IRQs 
are defined in _PRS objects.

I'm about to re-compile a 2.4.22-pre3-ac1 kernel with your suggested 
quick fix.
Will report back.

Keep up the good work
	-Rob.




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

Re: ACPI ignoring IRQ flags in PRT

[Andrew de Quincey]

On Sunday 13 July 2003 15:23, Matthew Wilcox wrote:
> On Sun, Jul 13, 2003 at 02:52:38PM +0100, Andrew de Quincey wrote:
> > Hi, from my understanding of the ACPI spec, each IRQ as specified in the
> > _PRT has additional flags associated with it (e.g. specifying the
> > polarity, level etc) that should be used for this IRQ.
> >
> > The Linux ACPI code seems to be ignoring these, and hardcodes them to the
> > values that cause problems for me. Is there a reason, or has that code
> > just not been written yet?
>
> you can't mean the _PRT.  the _PRT describes PCI interrupts, and those
> have their polarity and trigger specified by the PCI spec.  i suspect you
> mean someting else, but i'm not sure what.  can't be the SCI interrupt
> since that's defined to be level, low, sharable.
>
> some of the ia64 acpi code pays attention to polarity and edge vs level.
> now that we know this is an issue on x86, maybe some more people will be
> interested in thinking about how to fix this properly.  here's what we
> currently have on ia64:
>
> int acpi_register_irq (u32 gsi, u32 polarity, u32 trigger);

My first thoughts are:

Need to modify io_apic.c/io_apic_set_pci_routing() in the i386 architecture so 
it takes the polarity and trigger.

In i386, the actual PRT parsing and calls to io_apic_set_pci_routing() is done 
by mpparse.c/mp_parse_prt(), so that has to change... possibly not the API 
though.

I'm going to have a look into developing a prototype patch for this this 
evening.

As for Jurriaan's problem, I think it _may_ be a slightly different issue... 
so it is probably best to sort this on a board I have access to, then see if 
it needs more development iterations....



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