* Discussion: ACPI selective IRQ blacklist
@ 2003-09-03 22:16 Andrew de Quincey
[not found] ` <200309032316.11076.adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Andrew de Quincey @ 2003-09-03 22:16 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: linux-acpi-ral2JQCrhuEAvxtiuMwx3w
Hi, I've been looking into this VIA ACPI issue some more. From various
reports, if you disable ACPI, the standard linux PCI IRQ routing system is
able to correctly set up the board.
Some VIA motherboards DO work correctly in ACPI APIC mode however. These
boards have the APIC IRQ settings hardwired (i.e. they do not use link
devices).
The problem comes when the BIOS does use link devices. These will work fine in
PIC mode. However, in APIC mode, the AML code is wrong in several respects in
lots of BIOSes:
1) The _SRS method can only cope with IRQs <= 15, yet the BIOS returns IRQs >
15 in the _PRS method.
2) The _CRS method is hardcoded to return 0 ALWAYS for link devices in APIC
mode.
The above means we cannot use the AML code for setting APIC IRQ devices on
many VIA motherboards.
My new patch (acpi-picmode) should mean the boards are functional... just that
they do not take advantage of any APIC/IO-APIC present.
I looked into trying to fall back to the non-ACPI PCI IRQ routing code. Its
not really feasible: ACPI does an awful lot of setup before setting up the
link devices, which it is not really possible to undo without lots of pain.
My suggestion is I expand the current ACPI blacklist to have a field
specifying whether ACPI PCI routing can be relied upon.
Using the current blacklisting (which disables ACPI completely) on masses of
VIA motherboards is not really an option IMO.
So:
If a motherboard is dodgy and IS in the bad-routing-blacklist, ACPI will not
be used for PCI routing.
If a motherboard is dodgy and is NOT in the bad-routing-blacklist, the
fallback to picmode code should catch it. If the user then wants APIC with
ACPI, they report the issue and the board is added to the
bad-routing-blacklist.
What do people think? This is the best solution I can come up for this problem
that would not involve a large messy error-prone change.
I'm gonna start implementing this.. but I'd appreciate feedback on this idea.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Discussion: ACPI selective IRQ blacklist
[not found] ` <200309032316.11076.adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org>
@ 2003-09-04 1:15 ` Andrew de Quincey
[not found] ` <200309040215.23281.adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Andrew de Quincey @ 2003-09-04 1:15 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: linux-acpi-ral2JQCrhuEAvxtiuMwx3w
On Wednesday 03 September 2003 23:16, Andrew de Quincey wrote:
> So:
> If a motherboard is dodgy and IS in the bad-routing-blacklist, ACPI will
> not be used for PCI routing.
>
> If a motherboard is dodgy and is NOT in the bad-routing-blacklist, the
> fallback to picmode code should catch it. If the user then wants APIC with
> ACPI, they report the issue and the board is added to the
> bad-routing-blacklist.
On further thought, I realise this isn't future proof. This relies on the
existence of legacy BIOS tables (e.g. MPBIOS). My machine for one does not
have such a table; instead it relies on ACPI.
In the meantime, VIA have kindly sent me the docs I need. It turns out the PCI
routing entries for the problem BIOSes are wrong. The south bridge chip in
question is the VT8235 (device ID 0x1337), which explains the spread of
motherboards I've been seeing.
I have a solution in mind; should have something in the next few days.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Discussion: ACPI selective IRQ blacklist
@ 2003-09-04 1:19 Nakajima, Jun
0 siblings, 0 replies; 5+ messages in thread
From: Nakajima, Jun @ 2003-09-04 1:19 UTC (permalink / raw)
To: Andrew de Quincey, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f; +Cc: linux-acpi
I think acpi-picmode is reasonable and probably it would work more
reliably compared with APIC mode, but the behavior is triggered by
"noapic" (i.e. boot parameter). It was broken for ACPI, but Len has
fixed it.
Which VIA motherboards should be listed in the blacklist?
Thanks,
Jun
> -----Original Message-----
> From: Andrew de Quincey [mailto:adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org]
> Sent: Wednesday, September 03, 2003 3:16 PM
> To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Cc: linux-acpi
> Subject: Discussion: ACPI selective IRQ blacklist
>
> Hi, I've been looking into this VIA ACPI issue some more. From various
> reports, if you disable ACPI, the standard linux PCI IRQ routing
system is
> able to correctly set up the board.
>
> Some VIA motherboards DO work correctly in ACPI APIC mode however.
These
> boards have the APIC IRQ settings hardwired (i.e. they do not use link
> devices).
>
> The problem comes when the BIOS does use link devices. These will work
> fine in
> PIC mode. However, in APIC mode, the AML code is wrong in several
respects
> in
> lots of BIOSes:
>
> 1) The _SRS method can only cope with IRQs <= 15, yet the BIOS returns
> IRQs >
> 15 in the _PRS method.
>
> 2) The _CRS method is hardcoded to return 0 ALWAYS for link devices in
> APIC
> mode.
>
> The above means we cannot use the AML code for setting APIC IRQ
devices on
> many VIA motherboards.
>
> My new patch (acpi-picmode) should mean the boards are functional...
just
> that
> they do not take advantage of any APIC/IO-APIC present.
>
> I looked into trying to fall back to the non-ACPI PCI IRQ routing
code.
> Its
> not really feasible: ACPI does an awful lot of setup before setting up
the
> link devices, which it is not really possible to undo without lots of
pain.
>
> My suggestion is I expand the current ACPI blacklist to have a field
> specifying whether ACPI PCI routing can be relied upon.
>
> Using the current blacklisting (which disables ACPI completely) on
masses
> of
> VIA motherboards is not really an option IMO.
>
> So:
> If a motherboard is dodgy and IS in the bad-routing-blacklist, ACPI
will
> not
> be used for PCI routing.
>
> If a motherboard is dodgy and is NOT in the bad-routing-blacklist, the
> fallback to picmode code should catch it. If the user then wants APIC
with
> ACPI, they report the issue and the board is added to the
> bad-routing-blacklist.
>
> What do people think? This is the best solution I can come up for this
> problem
> that would not involve a large messy error-prone change.
>
>
> I'm gonna start implementing this.. but I'd appreciate feedback on
this
> idea.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Discussion: ACPI selective IRQ blacklist
[not found] ` <200309040215.23281.adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org>
@ 2003-09-04 1:47 ` James Courtier-Dutton
[not found] ` <3F5699A4.3090608-l7zRWeYnyd2TY6FTCsQk+9Bc4/FLrbF6@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: James Courtier-Dutton @ 2003-09-04 1:47 UTC (permalink / raw)
To: Andrew de Quincey
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-acpi-ral2JQCrhuEAvxtiuMwx3w
Andrew de Quincey wrote:
> On Wednesday 03 September 2003 23:16, Andrew de Quincey wrote:
>
>>So:
>>If a motherboard is dodgy and IS in the bad-routing-blacklist, ACPI will
>>not be used for PCI routing.
>>
>>If a motherboard is dodgy and is NOT in the bad-routing-blacklist, the
>>fallback to picmode code should catch it. If the user then wants APIC with
>>ACPI, they report the issue and the board is added to the
>>bad-routing-blacklist.
>
>
> On further thought, I realise this isn't future proof. This relies on the
> existence of legacy BIOS tables (e.g. MPBIOS). My machine for one does not
> have such a table; instead it relies on ACPI.
>
> In the meantime, VIA have kindly sent me the docs I need. It turns out the PCI
> routing entries for the problem BIOSes are wrong. The south bridge chip in
> question is the VT8235 (device ID 0x1337), which explains the spread of
> motherboards I've been seeing.
>
> I have a solution in mind; should have something in the next few days.
>
Would it be possible to bypass the BIOS completely, and talk to the
chips on the motherboard direct ?
It should work, unless the BIOS provides information that the chips on
the motherboard do not have. At a guess, I would say that the chips on
the motherboard might not have information like a wiring diagram.
Cheers
James
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Discussion: ACPI selective IRQ blacklist
[not found] ` <3F5699A4.3090608-l7zRWeYnyd2TY6FTCsQk+9Bc4/FLrbF6@public.gmane.org>
@ 2003-09-04 1:50 ` Andrew de Quincey
0 siblings, 0 replies; 5+ messages in thread
From: Andrew de Quincey @ 2003-09-04 1:50 UTC (permalink / raw)
To: James Courtier-Dutton
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-acpi-ral2JQCrhuEAvxtiuMwx3w
> Would it be possible to bypass the BIOS completely, and talk to the
> chips on the motherboard direct ?
> It should work, unless the BIOS provides information that the chips on
> the motherboard do not have. At a guess, I would say that the chips on
> the motherboard might not have information like a wiring diagram.
Yeah, that was what I was hoping from the docs.
However, the VIA8235, its even easier.. the IRQ routing is hardwired in the
chip itself.. so those BIOSes which provide a list of potential IRQs for link
devices are completely wrong.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-09-04 1:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-09-03 22:16 Discussion: ACPI selective IRQ blacklist Andrew de Quincey
[not found] ` <200309032316.11076.adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org>
2003-09-04 1:15 ` Andrew de Quincey
[not found] ` <200309040215.23281.adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org>
2003-09-04 1:47 ` James Courtier-Dutton
[not found] ` <3F5699A4.3090608-l7zRWeYnyd2TY6FTCsQk+9Bc4/FLrbF6@public.gmane.org>
2003-09-04 1:50 ` Andrew de Quincey
-- strict thread matches above, loose matches on Subject: below --
2003-09-04 1:19 Nakajima, Jun
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox