| Message ID | 4CD35CD1F8085945B597F80EEC89421303B8AD0C@exc01.bk.prodrive.nl (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi Stef, Stef van Os wrote: > Hello Felix, > > I had a problem similar to this on the 440GX, the PCI code was not > sending type 1 transactions when scanning behind bridges. Perhaps you > could try this: > > Index: linux/arch/powerpc/sysdev/ppc4xx_pci.c > =================================================================== > --- linux/arch/powerpc/sysdev/ppc4xx_pci.c (revision 26) > +++ linux/arch/powerpc/sysdev/ppc4xx_pci.c (revision 27) > @@ -569,7 +569,7 @@ > hose->last_busno = bus_range ? bus_range[1] : 0xff; > > /* Setup config space */ > - setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 0x4, > 0); > + setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 0x4, > PPC_INDIRECT_TYPE_SET_CFG_TYPE); > > /* Disable all windows */ > writel(0, reg + PCIX0_POM0SA); > > > > With kind regards / Met vriendelijke groet, > > Stef van Os > > Prodrive B.V. > > > I think you patch is a valid one, and should be applied, but unfortunately it doesn't fix by problem. BTW, in u-boot transaction type bit is set correctly. Felix.
Hi Stef Felix Radensky wrote: > Hi Stef, > > Stef van Os wrote: >> Hello Felix, >> >> I had a problem similar to this on the 440GX, the PCI code was not >> sending type 1 transactions when scanning behind bridges. Perhaps you >> could try this: >> >> Index: linux/arch/powerpc/sysdev/ppc4xx_pci.c >> =================================================================== >> --- linux/arch/powerpc/sysdev/ppc4xx_pci.c (revision 26) >> +++ linux/arch/powerpc/sysdev/ppc4xx_pci.c (revision 27) >> @@ -569,7 +569,7 @@ >> hose->last_busno = bus_range ? bus_range[1] : 0xff; >> >> /* Setup config space */ >> - setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 0x4, >> 0); >> + setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 0x4, >> PPC_INDIRECT_TYPE_SET_CFG_TYPE); >> >> /* Disable all windows */ >> writel(0, reg + PCIX0_POM0SA); >> >> >> >> With kind regards / Met vriendelijke groet, >> >> Stef van Os >> >> Prodrive B.V. >> >> > > I think you patch is a valid one, and should be applied, but > unfortunately it doesn't fix by problem. > BTW, in u-boot transaction type bit is set correctly. > > It seems I was wrong. I've manually applied the patch at the wrong place. After patching the correct function I'm not getting hard resets any more, which is a great improvement ! Thanks a lot, I really appreciate your help ! Unfortunately not all problems are gone. PLX is now identified correctly, but device behind it is not detected, although u-boot detects it correctly. See below. PCI: Probing PCI hardware pci_bus 0000:00: scanning bus pci 0000:00:02.0: found [3388:0020] class 000604 header type 01 pci 0000:00:02.0: calling pcibios_fixup_resources+0x0/0xf4 pci 0000:00:02.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154 pci 0000:00:02.0: calling quirk_resource_alignment+0x0/0x200 pci 0000:00:02.0: supports D1 D2 pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot pci 0000:00:02.0: PME# disabled pci_bus 0000:00: fixups for bus pci 0000:00:02.0: scanning behind bridge, config 010100, pass 0 pci_bus 0000:01: scanning bus pci 0000:01:02.0: found [3388:0020] class 000604 header type 01 pci 0000:01:02.0: calling pcibios_fixup_resources+0x0/0xf4 pci 0000:01:02.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154 pci 0000:01:02.0: calling quirk_resource_alignment+0x0/0x200 pci 0000:01:02.0: supports D1 D2 pci 0000:01:02.0: PME# supported from D0 D1 D2 D3hot pci 0000:01:02.0: PME# disabled pci_bus 0000:01: fixups for bus pci 0000:00:02.0: PCI bridge to [bus 01-01] pci 0000:00:02.0: bridge window [mem 0x80000000-0x8c0fffff] pci 0000:01:02.0: scanning behind bridge, config 010100, pass 0 pci 0000:01:02.0: bus configuration invalid, reconfiguring pci 0000:01:02.0: scanning behind bridge, config 010100, pass 1 pci_bus 0000:01: bus scan returning with max=01 pci 0000:00:02.0: scanning behind bridge, config 010100, pass 1 pci_bus 0000:00: bus scan returning with max=01 pci 0000:00:02.0: disabling bridge window [mem 0xd80000000-0xd8c0fffff] to [bus 01-01] (unused) pci 0000:00:02.0: PCI bridge to [bus 01-01] pci 0000:00:02.0: bridge window [io disabled] pci 0000:00:02.0: bridge window [mem disabled] pci 0000:00:02.0: bridge window [mem pref disabled] pci_bus 0000:00: resource 0 [io 0x0000-0xffff] pci_bus 0000:00: resource 1 [mem 0xd80000000-0xdffffffff] pci_bus 0000:01: resource 1 [??? 57982058496-58184433663 flags 0x0] Any ideas what could be wrong now ? Thanks a lot. Felix.
> It seems I was wrong. I've manually applied the patch at the wrong > place. After patching the correct function > I'm not getting hard resets any more, which is a great improvement ! > Thanks a lot, I really appreciate your help ! This is somewhat funny... I wonder how it would have managed to find anything behind the root complex P2P bridge with broken type 1 cycles... very very strange. > Unfortunately not all problems are gone. PLX is now identified > correctly, but device behind it is not detected, > although u-boot detects it correctly. See below. You have removed all your changes to that code right ? Also the log still looks weird: > pci 0000:01:02.0: scanning behind bridge, config 010100, pass 0 > pci 0000:01:02.0: bus configuration invalid, reconfiguring > pci 0000:01:02.0: scanning behind bridge, config 010100, pass 1 > pci_bus 0000:01: bus scan returning with max=01 > pci 0000:00:02.0: scanning behind bridge, config 010100, pass 1 > pci_bus 0000:00: bus scan returning with max=01 Unless you left some experimental changes in, the above isn't right, the "config" value should have changed due to the write of ~ffffff to it If the code running is indeed unmodified from upsteam, can you try with just that change: /* Check if setup is sensible at all */ - if (!pass && - ((buses & 0xff) != bus->number || ((buses >> 8) & 0xff) <= bus->number)) { + if (((buses & 0xff) != bus->number || ((buses >> 8) & 0xff) <= bus->number)) { dev_dbg(&dev->dev, "bus configuration invalid, reconfiguring\n"); broken = 1; } (IE remove the check for !pass) Cheers, Ben. > pci 0000:00:02.0: disabling bridge window [mem 0xd80000000-0xd8c0fffff] > to [bus 01-01] (unused) > pci 0000:00:02.0: PCI bridge to [bus 01-01] > pci 0000:00:02.0: bridge window [io disabled] > pci 0000:00:02.0: bridge window [mem disabled] > pci 0000:00:02.0: bridge window [mem pref disabled] > pci_bus 0000:00: resource 0 [io 0x0000-0xffff] > pci_bus 0000:00: resource 1 [mem 0xd80000000-0xdffffffff] > pci_bus 0000:01: resource 1 [??? 57982058496-58184433663 flags 0x0] > > Any ideas what could be wrong now ? > > Thanks a lot. > > Felix. >
Hi, Ben Benjamin Herrenschmidt wrote: >> It seems I was wrong. I've manually applied the patch at the wrong >> place. After patching the correct function >> I'm not getting hard resets any more, which is a great improvement ! >> Thanks a lot, I really appreciate your help ! >> > > This is somewhat funny... I wonder how it would have managed to find > anything behind the root complex P2P bridge with broken type 1 cycles... > very very strange. > Maybe because the bus behind root P2P bridge is bus 0, and type 1 cycles are needed for bus numbers greater than 0. That's what 460EX manual says. > >> Unfortunately not all problems are gone. PLX is now identified >> correctly, but device behind it is not detected, >> although u-boot detects it correctly. See below. >> > > You have removed all your changes to that code right ? > Yes, I've removed all experimental changes. > Also the log still looks weird: > > >> pci 0000:01:02.0: scanning behind bridge, config 010100, pass 0 >> pci 0000:01:02.0: bus configuration invalid, reconfiguring >> pci 0000:01:02.0: scanning behind bridge, config 010100, pass 1 >> pci_bus 0000:01: bus scan returning with max=01 >> pci 0000:00:02.0: scanning behind bridge, config 010100, pass 1 >> pci_bus 0000:00: bus scan returning with max=01 >> > > Unless you left some experimental changes in, the above isn't right, the > "config" value should have changed due to the write of ~ffffff to it > You are correct, the log is from older version, without Stef's fix. I don't have access to a system with devices behind PLX, and the guy who did the testing used wrong kernel. I'll make sure he uses the correct one and get back to you. Maybe everything works after all :) I'm really sorry for confusion. Felix.
On Tue, 2010-01-12 at 00:48 +0200, Felix Radensky wrote: > > Maybe because the bus behind root P2P bridge is bus 0, and type 1 > cycles are > needed for bus numbers greater than 0. That's what 460EX manual says. Well, no... the bus behind the root P2P is bus 1 ... the root P2P itself is on bus 0... but then, it's some trick in the way they implemented it I suppose. > You are correct, the log is from older version, without Stef's fix. I > don't have access to a > system with devices behind PLX, and the guy who did the testing used > wrong kernel. > I'll make sure he uses the correct one and get back to you. Maybe > everything works after all :) > I'm really sorry for confusion. No worries :-) Feel free to send a proper patch to fix that problem upstream too ! Cheers, Ben.
Hi Ben Benjamin Herrenschmidt wrote: > On Tue, 2010-01-12 at 00:48 +0200, Felix Radensky wrote: > >> Maybe because the bus behind root P2P bridge is bus 0, and type 1 >> cycles are >> needed for bus numbers greater than 0. That's what 460EX manual says. >> > > Well, no... the bus behind the root P2P is bus 1 ... the root P2P itself > is on bus 0... but then, it's some trick in the way they implemented it > I suppose. > > >> You are correct, the log is from older version, without Stef's fix. I >> don't have access to a >> system with devices behind PLX, and the guy who did the testing used >> wrong kernel. >> I'll make sure he uses the correct one and get back to you. Maybe >> everything works after all :) >> I'm really sorry for confusion. >> > > No worries :-) Feel free to send a proper patch to fix that problem > upstream too ! > > The kernel with Stef's fix works fine, and recognizes both PLX and device behind it. Stef, do want to provide a patch for upstream kernel, or do you want me to do that on your behalf ? Thanks a lot everyone for you help ! Felix. Felix.
Hello Felix, Glad to know this is working for you! I'll try to send out a patch later today. The same change should also be applied to the "ppc4xx_probe_pci_bridge" function, as it also initialises PCI without type 1 transactions. With kind regards / Met vriendelijke groet, Stef van Os Prodrive B.V. -----Original Message----- From: Felix Radensky [mailto:felix@embedded-sol.com] Sent: dinsdag 12 januari 2010 12:03 To: Benjamin Herrenschmidt Cc: Stef van Os; Stefan Roese; Feng Kan; linuxppc-dev@ozlabs.org Subject: Re: PCI-PCI bridge scanning broken on 460EX Hi Ben Benjamin Herrenschmidt wrote: > On Tue, 2010-01-12 at 00:48 +0200, Felix Radensky wrote: > >> Maybe because the bus behind root P2P bridge is bus 0, and type 1 >> cycles are needed for bus numbers greater than 0. That's what 460EX >> manual says. >> > > Well, no... the bus behind the root P2P is bus 1 ... the root P2P > itself is on bus 0... but then, it's some trick in the way they > implemented it I suppose. > > >> You are correct, the log is from older version, without Stef's fix. I >> don't have access to a system with devices behind PLX, and the guy >> who did the testing used wrong kernel. >> I'll make sure he uses the correct one and get back to you. Maybe >> everything works after all :) I'm really sorry for confusion. >> > > No worries :-) Feel free to send a proper patch to fix that problem > upstream too ! > > The kernel with Stef's fix works fine, and recognizes both PLX and device behind it. Stef, do want to provide a patch for upstream kernel, or do you want me to do that on your behalf ? Thanks a lot everyone for you help ! Felix. Felix. Disclaimer: The information contained in this email, including any attachments is confidential and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments.
Index: linux/arch/powerpc/sysdev/ppc4xx_pci.c =================================================================== --- linux/arch/powerpc/sysdev/ppc4xx_pci.c (revision 26) +++ linux/arch/powerpc/sysdev/ppc4xx_pci.c (revision 27) @@ -569,7 +569,7 @@ hose->last_busno = bus_range ? bus_range[1] : 0xff; /* Setup config space */ - setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 0x4, 0); + setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 0x4, PPC_INDIRECT_TYPE_SET_CFG_TYPE);
Hello Felix, I had a problem similar to this on the 440GX, the PCI code was not sending type 1 transactions when scanning behind bridges. Perhaps you could try this: /* Disable all windows */ writel(0, reg + PCIX0_POM0SA); With kind regards / Met vriendelijke groet, Stef van Os Prodrive B.V. -----Original Message----- From: linuxppc-dev-bounces+stef.van.os=prodrive.nl@lists.ozlabs.org [mailto:linuxppc-dev-bounces+stef.van.os=prodrive.nl@lists.ozlabs.org] On Behalf Of Benjamin Herrenschmidt Sent: zondag 10 januari 2010 22:32 To: Felix Radensky Cc: linuxppc-dev@ozlabs.org; Stefan Roese; Feng Kan Subject: Re: PCI-PCI bridge scanning broken on 460EX > OK, I'll try writing byte by byte. The funny thing is the u-boot also > writes the same value to PCI_PRIMARY_BUS register and it doesn't cause > reset. Maybe the bridge doesn't want to be programmed more than once on these registers ? In any case, that's very very fishy.... I wonder if the bridge is causing a PCI reset -upstream- (which would really be a weird thing to do) and the 460 is turning that into a system reset ? Check if there are ways to control how the 460 reacts to PCI resets... In any case, it looks like a fucked up bridge to me. I don't suppose you've seen anything in the bridge data sheet or errata sheet that could explain what it's doing ? Cheers, Ben.