Re: Broken PCI on Sequoia
On Fri, 30 Jan 2009, Benjamin Herrenschmidt wrote:
Yeah. In fact, I think you have that bug in almost every board. You only
updated Bamboo and Canyonlands with the initial patch and the changelog
says other boards can be updated separately. Nobody did that. So not
so weird after all.
I still don't see off hand what's wrong in the code..
Geert, any chance you can sprinkle printk's in
ppc4xx_configure_pci_PMMs() ? I'd like to see the arguments to the
various calls to ppc4xx_setup_one_pci_PMM(), and the value of
hose-pci_mem_offset and hose-isa_mem_phys size.
| PCI host bridge /plb/p...@1ec00 (primary) ranges:
| MEM 0x00018000..0x0001bfff - 0x8000
| IO 0x0001e800..0x0001e800 - 0x
| IO 0x0001e880..0x0001ebff - 0x
| \-- Skipped (too many) !
| 4xx PCI DMA offset set to 0x
| ppc4xx_configure_pci_PMMs: i = 0, hose-pci_mem_offset = 0x1
| ppc4xx_setup_one_pci_PMM: hose = 0xcf825000
| ppc4xx_setup_one_pci_PMM: reg = 0xd100
| ppc4xx_setup_one_pci_PMM: plb_addr = 0x18000
| ppc4xx_setup_one_pci_PMM: pci_addr = 0x8000
| ppc4xx_setup_one_pci_PMM: size = 0x4000
| ppc4xx_setup_one_pci_PMM: flags = 0x200
| ppc4xx_setup_one_pci_PMM: index = 0
| /plb/p...@1ec00: Resource out of range
^
because plb_addr + size lies outside 32-bit space.
| ppc4xx_configure_pci_PMMs: hose-isa_mem_phys = 0x0, hose-isa_mem_size = 0x0
| PCI: Probing PCI hardware
| PCI: Hiding 4xx host bridge resources :00:00.0
| pci :00:0a.0: PME# supported from D0 D1 D2 D3hot
| pci :00:0a.0: PME# disabled
| pci :00:0a.1: PME# supported from D0 D1 D2 D3hot
| pci :00:0a.1: PME# disabled
| pci :00:0a.2: PME# supported from D0 D1 D2 D3hot
| pci :00:0a.2: PME# disabled
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 77fae5f..70684ee 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -16,6 +16,8 @@
*
*/
+#define pr_fmt(fmt) %s: fmt, __func__
+
#undef DEBUG
#include linux/kernel.h
@@ -204,6 +206,13 @@ static int __init ppc4xx_setup_one_pci_PMM(struct
pci_controller *hose,
{
u32 ma, pcila, pciha;
+pr_info(hose = 0x%p\n, hose);
+pr_info(reg = 0x%p\n, reg);
+pr_info(plb_addr = 0x%llx\n, plb_addr);
+pr_info(pci_addr = 0x%llx\n, pci_addr);
+pr_info(size = 0x%llx\n, size);
+pr_info(flags = 0x%x\n, flags);
+pr_info(index = %d\n, index);
if ((plb_addr + size) 0xull || !is_power_of_2(size) ||
size 0x1000 || (plb_addr (size - 1)) != 0) {
printk(KERN_WARNING %s: Resource out of range\n,
@@ -244,6 +253,7 @@ static void __init ppc4xx_configure_pci_PMMs(struct
pci_controller *hose,
}
/* Configure the resource */
+pr_info(i = %d, hose-pci_mem_offset = 0x%llx\n, i, hose-pci_mem_offset);
if (ppc4xx_setup_one_pci_PMM(hose, reg,
res-start,
res-start - hose-pci_mem_offset,
@@ -260,6 +270,7 @@ static void __init ppc4xx_configure_pci_PMMs(struct
pci_controller *hose,
}
}
+pr_info(hose-isa_mem_phys = 0x%llx, hose-isa_mem_size = 0x%llx\n,
hose-isa_mem_phys, hose-isa_mem_size);
/* Handle ISA memory hole if not already covered */
if (j = 2 !found_isa_hole hose-isa_mem_size)
if (ppc4xx_setup_one_pci_PMM(hose, reg, hose-isa_mem_phys, 0,
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Broken PCI on Sequoia
| PCI host bridge /plb/p...@1ec00 (primary) ranges: | MEM 0x00018000..0x0001bfff - 0x8000 | IO 0x0001e800..0x0001e800 - 0x | IO 0x0001e880..0x0001ebff - 0x | \-- Skipped (too many) ! | 4xx PCI DMA offset set to 0x | ppc4xx_configure_pci_PMMs: i = 0, hose-pci_mem_offset = 0x1 | ppc4xx_setup_one_pci_PMM: hose = 0xcf825000 | ppc4xx_setup_one_pci_PMM: reg = 0xd100 | ppc4xx_setup_one_pci_PMM: plb_addr = 0x18000 | ppc4xx_setup_one_pci_PMM: pci_addr = 0x8000 | ppc4xx_setup_one_pci_PMM: size = 0x4000 | ppc4xx_setup_one_pci_PMM: flags = 0x200 | ppc4xx_setup_one_pci_PMM: index = 0 | /plb/p...@1ec00: Resource out of range ^ because plb_addr + size lies outside 32-bit space. Ok so the code was buggy already, the ISA hole patch just makes it trigger... For that sort of 4xx PHB (ie, the PCI 2.x ones, not the PCI-X nor the PCI-E), we only know how to program 32-bit of PLB address. IE. The old code would have cropped the plb_addr when writing to the register, the new code complains. I suspect some implementation support a register to put the high part of the PLB address, and that it already contains 1, so the old code would have worked by chance, the new code doesn't because it bails out. I need to check the doco for your CPU or any other using that cell to see who supports what regarding the location of the outbound windows in PLB space. I think the original 440GP which I used as a basis for the PCI 2.x host bridge only supports 32-bits here but maybe I'm just confused. I'll have a look next week. Cheers, Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Broken PCI on Sequoia
For that sort of 4xx PHB (ie, the PCI 2.x ones, not the PCI-X nor the PCI-E), we only know how to program 32-bit of PLB address. IE. The old code would have cropped the plb_addr when writing to the register, the new code complains. I suspect some implementation support a register to put the high part of the PLB address, and that it already contains 1, so the old code would have worked by chance, the new code doesn't because it bails out. Hrm... from the doco it's also one 32-bit register... I'm starting to think that those guys always assume the top 1 bit is set or something like that ... The doc is unclear. Maybe somebody form AMCC can confirm ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Broken PCI on Sequoia
Hi: It looks like the top bit is hard coded to 1. There doesn't seem to be anyway Of changing it. Feng Kan AMCC Engineering -Original Message- From: linuxppc-dev-bounces+fkan=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+fkan=amcc@ozlabs.org] On Behalf Of Benjamin Herrenschmidt Sent: Friday, January 30, 2009 1:30 PM To: Geert Uytterhoeven Cc: Linux/PPC Development Subject: Re: Broken PCI on Sequoia For that sort of 4xx PHB (ie, the PCI 2.x ones, not the PCI-X nor the PCI-E), we only know how to program 32-bit of PLB address. IE. The old code would have cropped the plb_addr when writing to the register, the new code complains. I suspect some implementation support a register to put the high part of the PLB address, and that it already contains 1, so the old code would have worked by chance, the new code doesn't because it bails out. Hrm... from the doco it's also one 32-bit register... I'm starting to think that those guys always assume the top 1 bit is set or something like that ... The doc is unclear. Maybe somebody form AMCC can confirm ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Broken PCI on Sequoia
On Fri, 2009-01-30 at 17:19 -0800, Feng Kan wrote: Hi: It looks like the top bit is hard coded to 1. There doesn't seem to be anyway Of changing it. Thanks ! Would it be possible for you to check other 4xx parts using that PCI controller as to whether the top bit is always hard-coded to 1 or it changes from part to part ? Thanks ! Cheers, Ben. Feng Kan AMCC Engineering -Original Message- From: linuxppc-dev-bounces+fkan=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+fkan=amcc@ozlabs.org] On Behalf Of Benjamin Herrenschmidt Sent: Friday, January 30, 2009 1:30 PM To: Geert Uytterhoeven Cc: Linux/PPC Development Subject: Re: Broken PCI on Sequoia For that sort of 4xx PHB (ie, the PCI 2.x ones, not the PCI-X nor the PCI-E), we only know how to program 32-bit of PLB address. IE. The old code would have cropped the plb_addr when writing to the register, the new code complains. I suspect some implementation support a register to put the high part of the PLB address, and that it already contains 1, so the old code would have worked by chance, the new code doesn't because it bails out. Hrm... from the doco it's also one 32-bit register... I'm starting to think that those guys always assume the top 1 bit is set or something like that ... The doc is unclear. Maybe somebody form AMCC can confirm ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Broken PCI on Sequoia
On Thu, 2009-01-29 at 18:37 +0100, Geert Uytterhoeven wrote: Hi Ben, Josh, .../... Git-reverting this commit on top of 2.6.29-rc3 makes the crash go away. Perhaps sequoia.dts (and other 44x DTS files) had to be changed, too? Weird, maybe I have a bug when there is no ISA hole in the DT, I'll have a look later today. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Broken PCI on Sequoia
On Fri, Jan 30, 2009 at 09:11:01AM +1100, Benjamin Herrenschmidt wrote: On Thu, 2009-01-29 at 18:37 +0100, Geert Uytterhoeven wrote: Hi Ben, Josh, .../... Git-reverting this commit on top of 2.6.29-rc3 makes the crash go away. Perhaps sequoia.dts (and other 44x DTS files) had to be changed, too? Weird, maybe I have a bug when there is no ISA hole in the DT, I'll have a look later today. Yeah. In fact, I think you have that bug in almost every board. You only updated Bamboo and Canyonlands with the initial patch and the changelog says other boards can be updated separately. Nobody did that. So not so weird after all. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Broken PCI on Sequoia
Yeah. In fact, I think you have that bug in almost every board. You only updated Bamboo and Canyonlands with the initial patch and the changelog says other boards can be updated separately. Nobody did that. So not so weird after all. I still don't see off hand what's wrong in the code.. Geert, any chance you can sprinkle printk's in ppc4xx_configure_pci_PMMs() ? I'd like to see the arguments to the various calls to ppc4xx_setup_one_pci_PMM(), and the value of hose-pci_mem_offset and hose-isa_mem_phys size. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
