I've spent a few horrible hours terrified by the idea of a possible XP
install on my new laptop. It's a Compaq Presario 3045US with SIS-650
chipset and there was no way to have USB bits work with it because of a
IRQ routing issue. The PCI routing table of that machine issues requests
for 0x60, 0x61 and 0x63 that, to have everything to work out, must be
handled like the 0x4* cases. Now, while 0x60 and 0x63 were ot documented
at all, 0x61 was documented as IDEIRQ and I was a bit worried about that.
But this is not the case since the machine issue 0x60..0x63 for the four
OHCI devices. Now USB is working great with keyboard, mouse and drives. I
still have to say bye to the Broadcom 54g wireless interface though ...
- Davide
On Sat, 17 May 2003, Davide Libenzi wrote:
> I've spent a few horrible hours terrified by the idea of a possible XP
> install on my new laptop. It's a Compaq Presario 3045US with SIS-650
> chipset and there was no way to have USB bits work with it because of a
> IRQ routing issue.
What are the device/revision id's of the pci irq router function?
> The PCI routing table of that machine issues requests
> for 0x60, 0x61 and 0x63 that, to have everything to work out, must be
> handled like the 0x4* cases.
This sounds different wrt. what we have documented for the older 85C503
ISA bridge which is used in the 5595 chipset family.
> Now, while 0x60 and 0x63 were ot documented
> at all, 0x61 was documented as IDEIRQ and I was a bit worried about that.
0x61=IDEIRQ / 0x62=USBIRQ is definitely correct for the 5595/85C503 rev 01
- according to the data sheet and playing with setpci ;-)
> But this is not the case since the machine issue 0x60..0x63 for the four
> OHCI devices. Now USB is working great with keyboard, mouse and drives. I
> still have to say bye to the Broadcom 54g wireless interface though ...
Looks like your chipset uses a different irq routing register layout. When
the existing sis pci-irq routing stuff was added, the primary concern was
to handle the ambigous link values (0x40-43 vs. 0x00-03) used by different
BIOS's. The IDEIRQ case was merely added for documentation, it's unused.
I think this might need some special treatment in pirq_sis_[sg]et(),
either checking for the revision id or a different pci device id.
Btw, have you tried with acpi interrupt routing enabled?
Martin
On Sun, 18 May 2003, Martin Diehl wrote:
> On Sat, 17 May 2003, Davide Libenzi wrote:
>
> > I've spent a few horrible hours terrified by the idea of a possible XP
> > install on my new laptop. It's a Compaq Presario 3045US with SIS-650
> > chipset and there was no way to have USB bits work with it because of a
> > IRQ routing issue.
>
> What are the device/revision id's of the pci irq router function?
I don't have the laptop under my nose now and honestly I do not remember
the whole output of pcitweak -l ;)
> > The PCI routing table of that machine issues requests
> > for 0x60, 0x61 and 0x63 that, to have everything to work out, must be
> > handled like the 0x4* cases.
>
> This sounds different wrt. what we have documented for the older 85C503
> ISA bridge which is used in the 5595 chipset family.
>
> > Now, while 0x60 and 0x63 were ot documented
> > at all, 0x61 was documented as IDEIRQ and I was a bit worried about that.
>
> 0x61=IDEIRQ / 0x62=USBIRQ is definitely correct for the 5595/85C503 rev 01
> - according to the data sheet and playing with setpci ;-)
>
> > But this is not the case since the machine issue 0x60..0x63 for the four
> > OHCI devices. Now USB is working great with keyboard, mouse and drives. I
> > still have to say bye to the Broadcom 54g wireless interface though ...
>
> Looks like your chipset uses a different irq routing register layout. When
> the existing sis pci-irq routing stuff was added, the primary concern was
> to handle the ambigous link values (0x40-43 vs. 0x00-03) used by different
> BIOS's. The IDEIRQ case was merely added for documentation, it's unused.
>
> I think this might need some special treatment in pirq_sis_[sg]et(),
> either checking for the revision id or a different pci device id.
This made it for me, but it could break other configurations though :
--- pci-irq.c.orig 2003-05-18 12:34:03.000000000 -0700
+++ pci-irq.c 2003-05-18 12:35:14.000000000 -0700
@@ -306,14 +306,16 @@
case 0x42:
case 0x43:
case 0x44:
+ case 0x60:
+ case 0x61:
case 0x62:
+ case 0x63:
pci_read_config_byte(router, reg, &x);
- if (reg != 0x62)
+ if (reg < 0x60)
break;
if (!(x & 0x40))
return 0;
break;
- case 0x61:
case 0x6a:
case 0x7e:
printk(KERN_INFO "SiS pirq: advanced IDE/ACPI/DAQ mapping not yet implemented\n");
@@ -340,14 +342,16 @@
case 0x42:
case 0x43:
case 0x44:
+ case 0x60:
+ case 0x61:
case 0x62:
+ case 0x63:
x = (irq&0x0f) ? (irq&0x0f) : 0x80;
- if (reg != 0x62)
+ if (reg < 0x60)
break;
/* always mark OHCI enabled, as nothing else knows about this */
x |= 0x40;
break;
- case 0x61:
case 0x6a:
case 0x7e:
printk(KERN_INFO "advanced SiS pirq mapping not yet implemented\n");
> Btw, have you tried with acpi interrupt routing enabled?
Nope, since last time I checked ACPI was not in wonderful shape. I'll try
though to see if it fixes the thing or if it'll add more issues.
- Davide
On Sun, 18 May 2003, Davide Libenzi wrote:
> I don't have the laptop under my nose now and honestly I do not remember
> the whole output of pcitweak -l ;)
Well, "lspci -vxxx -d 1039:0008" should be sufficient. If possible
combined with the pci routing table (from dump_pirq for example).
> > 0x61=IDEIRQ / 0x62=USBIRQ is definitely correct for the 5595/85C503 rev 01
> > - according to the data sheet and playing with setpci ;-)
> >
> > > But this is not the case since the machine issue 0x60..0x63 for the four
> > > OHCI devices. Now USB is working great with keyboard, mouse and drives. I
> > > still have to say bye to the Broadcom 54g wireless interface though ...
> >
> > Looks like your chipset uses a different irq routing register layout. When
> > the existing sis pci-irq routing stuff was added, the primary concern was
> > to handle the ambigous link values (0x40-43 vs. 0x00-03) used by different
> > BIOS's. The IDEIRQ case was merely added for documentation, it's unused.
> >
> > I think this might need some special treatment in pirq_sis_[sg]et(),
> > either checking for the revision id or a different pci device id.
>
> This made it for me, but it could break other configurations though :
It would, sure. There are BIOSes in the field which have the 0x62 (USB)
link included in the routing table for the old register layout. Maybe same
for 0x61(IDE).
> --- pci-irq.c.orig 2003-05-18 12:34:03.000000000 -0700
> +++ pci-irq.c 2003-05-18 12:35:14.000000000 -0700
> @@ -306,14 +306,16 @@
> case 0x42:
> case 0x43:
> case 0x44:
> + case 0x60:
> + case 0x61:
> case 0x62:
> + case 0x63:
Ok, looks like they have moved the location of the PCI INTA-INTD routing
registers from 0x41-0x44 to 0x60-0x63. Since this works for you it means
the vendor/device-id is still 1039:0008. We really need to check the
revision id here.
> pci_read_config_byte(router, reg, &x);
> - if (reg != 0x62)
> + if (reg < 0x60)
> break;
> if (!(x & 0x40))
> return 0;
[...]
> x = (irq&0x0f) ? (irq&0x0f) : 0x80;
> - if (reg != 0x62)
> + if (reg < 0x60)
> break;
> /* always mark OHCI enabled, as nothing else knows about this */
> x |= 0x40;
Do you really need this bit 6 tweaking? In the current code it's only
effective for the 0x62 link where it is used to enable the OHCI in the
southbridge. For most other routing registers it's reserved according to
the docs - for IDEIRQ (0x61) however it has some different meaning.
Writing to it for older router revisions might probably make IDE
unuseable or hang the box in irq storm.
Therefore, for your new 0x60-0x63 register layout I wouldn't suggest
writing this bit - unless we have some insight there.
So, for your patch I'd suggest to check the PCI_REVISION_ID from the
config space and apply your new layout for this revision only.
> > Btw, have you tried with acpi interrupt routing enabled?
>
> Nope, since last time I checked ACPI was not in wonderful shape. I'll try
> though to see if it fixes the thing or if it'll add more issues.
Ok, lets see. IIRC recent MS OSes don't require pci routing table anymore.
Furthermore we have seen too many broken routing tables. So it's probably
a big win, if it would work with ACPI...
Martin
On Sun, 18 May 2003, Martin Diehl wrote:
> On Sun, 18 May 2003, Davide Libenzi wrote:
>
> > I don't have the laptop under my nose now and honestly I do not remember
> > the whole output of pcitweak -l ;)
>
> Well, "lspci -vxxx -d 1039:0008" should be sufficient. If possible
> combined with the pci routing table (from dump_pirq for example).
I know, but even that one is hard to do w/out the machine under your nose ;)
> > This made it for me, but it could break other configurations though :
>
> It would, sure. There are BIOSes in the field which have the 0x62 (USB)
> link included in the routing table for the old register layout. Maybe same
> for 0x61(IDE).
I had no doubt about that either.
> > --- pci-irq.c.orig 2003-05-18 12:34:03.000000000 -0700
> > +++ pci-irq.c 2003-05-18 12:35:14.000000000 -0700
> > @@ -306,14 +306,16 @@
> > case 0x42:
> > case 0x43:
> > case 0x44:
> > + case 0x60:
> > + case 0x61:
> > case 0x62:
> > + case 0x63:
>
> Ok, looks like they have moved the location of the PCI INTA-INTD routing
> registers from 0x41-0x44 to 0x60-0x63. Since this works for you it means
> the vendor/device-id is still 1039:0008. We really need to check the
> revision id here.
Nope, I still see 0x4* commands for all devices != from USB. So more then
a "move" is an extension.
> > x = (irq&0x0f) ? (irq&0x0f) : 0x80;
> > - if (reg != 0x62)
> > + if (reg < 0x60)
> > break;
> > /* always mark OHCI enabled, as nothing else knows about this */
> > x |= 0x40;
>
> Do you really need this bit 6 tweaking? In the current code it's only
> effective for the 0x62 link where it is used to enable the OHCI in the
> southbridge. For most other routing registers it's reserved according to
> the docs - for IDEIRQ (0x61) however it has some different meaning.
> Writing to it for older router revisions might probably make IDE
> unuseable or hang the box in irq storm.
>
> Therefore, for your new 0x60-0x63 register layout I wouldn't suggest
> writing this bit - unless we have some insight there.
>
> So, for your patch I'd suggest to check the PCI_REVISION_ID from the
> config space and apply your new layout for this revision only.
Instead of just trolling, isn't there a documentation about this chipset ?
The SIS web site is pretty/very weak about docs.
> > > Btw, have you tried with acpi interrupt routing enabled?
> >
> > Nope, since last time I checked ACPI was not in wonderful shape. I'll try
> > though to see if it fixes the thing or if it'll add more issues.
>
> Ok, lets see. IIRC recent MS OSes don't require pci routing table anymore.
> Furthermore we have seen too many broken routing tables. So it's probably
> a big win, if it would work with ACPI...
BTW, according to the Compaq documentation, the vanilla XP fails on this
configuration either. You need their tweaked XP to have it working.
- Davide
On Sun, 18 May 2003, Davide Libenzi wrote:
> > Well, "lspci -vxxx -d 1039:0008" should be sufficient. If possible
> > combined with the pci routing table (from dump_pirq for example).
>
> I know, but even that one is hard to do w/out the machine under your nose ;)
Sure ;-)
> > Ok, looks like they have moved the location of the PCI INTA-INTD routing
> > registers from 0x41-0x44 to 0x60-0x63. Since this works for you it means
> > the vendor/device-id is still 1039:0008. We really need to check the
> > revision id here.
>
> Nope, I still see 0x4* commands for all devices != from USB. So more then
> a "move" is an extension.
Ok, second guess: they've kept the 0x41-44 for INTA-INTD and just added
the several onboard USB root-HC's at 0x6* - which might also explain if
you need bit 6 set. Well, it seems we'd really need the docs.
> > So, for your patch I'd suggest to check the PCI_REVISION_ID from the
> > config space and apply your new layout for this revision only.
>
> Instead of just trolling, isn't there a documentation about this chipset ?
> The SIS web site is pretty/very weak about docs.
Well, trolling or not, when I submitted the current sis pci irq routing
stuff it was based on existing documentation for the 85C503 isa-bridge
with pci router function (as used in the 5595 chipset).
We were also looking at a number of routing tables from different people
to get the stuff right - given the different ideas vendors have about link
values. IIRC it was around 2.4.0 release and we also had some confirmation
from somebody at SiS before Linus applied it.
I've no idea about docs for the 650 chipset, sorry.
Martin