Re: PCI woes with 2.6.37
On 01/08/2011 12:33 AM, Benjamin Herrenschmidt wrote: On Fri, 2011-01-07 at 16:06 -0700, Gary Thomas wrote: I just tried porting my target (MPC8347) from 2.6.28 (remember that one?) to 2.6.37. Recently I tried this with 2.6.32 without a lot of success, so I thought I'd try the latest :-) The changes are very simple, pretty much just the addition of my 8347 based platform DTS. Sadly, it fails even worse than it did on 2.6.32. For some reason, although everything seems to report that the PCI bus is alive, MEM access fails completely. If I try to access various PCI devices via their memory space (I only have memory peripherals so I can't test IO space access), I get what I assume are BUS timeouts - all 0x My PCI bus is defined in DTS like this: ranges =0x0200 0x0 0xC000 0xC000 0x0 0x2000 What are the #address-cells and #size-cells properties of the parent of the PCI controller node ? PCI has 3 cells, so that accounts for the first 3 numbers of each of these. That leaves only 3 numbers, so either you have #address-cells = 1 and #size-cells = 2 or the other way around. The first sounds the most plausible and would mean that you are mapping c000 CPU space to c000 PCI space and the window is 512M long. Now of course, one needs to double check that the HW is configured that way (I suppose fsl_pci.c does the configuration based on the ranges property but I don't know for sure). So far nothing strikes me as totally odd. 0x0100 0x0 0x 0xB800 0x0 0x0010; This looks reasonable too with the same assumption as above. PCI: Probing PCI hardware PCI: Scanning PHB /p...@ff008500 PCI: PHB IO resource= -000FF FFf [100] PCI: PHB MEM resource 0 = c000-dFF FFfff [200] Did you edit those by hand ? :-) They look correct tho as far as I can tell. Sorry, I did a little editing of the dump below (to make it more readable, no content changes) and find replace went wild on me :-( It should have read: PCI: PHB MEM resource 0 = c000-dfff [200] PCI: PHB MEM offset = PCI: PHB IO offset = And that too. probe mode: 0 PCI::00:0b.0 Resource 0 1000-1007 [40101] fixup... PCI::00:0b.01000-1007 PCI::00:0b.0 Resource 1 1008-100b [40101] fixup... PCI::00:0b.01008-100b PCI::00:0b.0 Resource 2 1010-1017 [40101] fixup... PCI::00:0b.01010-1017 PCI::00:0b.0 Resource 3 1018-101b [40101] fixup... PCI::00:0b.01018-101b PCI::00:0b.0 Resource 4 1020-102f [40101] fixup... PCI::00:0b.01020-102f PCI::00:0b.0 Resource 5 0010-001001ff [40200] fixup... PCI::00:0b.00010-001001ff PCI::00:0b.0 Resource 6 -0007FF FF [4e200] is unassigned PCI::00:0c.0 Resource 0 0400-07FF FFff [40200] fixup... PCI::00:0c.00400-07FF FFff PCI: Fixup bus devices 0 (PHB) PCI: Try to map irq for :00:0b.0... Got one, spec 2 cells (0x0016 0x0008...) on /soc8...@ff00/p...@700 Mapped to linux irq 22 PCI: Try to map irq for :00:0c.0... Got one, spec 2 cells (0x0013 0x0008...) on /soc8...@ff00/p...@700 Mapped to linux irq 19 PCI: Allocating bus resources for :00... PCI: PHB (bus 0) bridge rsrc 0: -000FF FFf [0x100], parent c03b5740 (PCI IO) PCI: PHB (bus 0) bridge rsrc 1: c000-dFF FFfff [0x200], parent c03b5724 (PCI mem) PCI: Allocating :00:0b.0: Resource 0: 1000..1007 [40101] PCI: Allocating :00:0b.0: Resource 1: 1008..100b [40101] PCI: Allocating :00:0b.0: Resource 2: 1010..1017 [40101] PCI: Allocating :00:0b.0: Resource 3: 1018..101b [40101] PCI: Allocating :00:0b.0: Resource 4: 1020..102f [40101] PCI: Allocating :00:0b.0: Resource 5: 0010..001001ff [40200] PCI: Cannot allocate resource region 5 of device :00:0b.0, will remap PCI: Allocating :00:0c.0: Resource 0: 0400..07FF FFff [40200] That's huge, is this your Coral framebuffer ? It's clearly using a different address scheme which won't fit, so the kernel decides to remap it, so far so good. Indeed, the frame buffer takes 4MB PCI: Cannot allocate resource region 0 of device :00:0c.0, will remap Reserving legacy ranges for domain Candidate legacy IO: [io 0x-0x0fff] hose mem offset: hose mem res:
[PATCH] powerpc/mpc8xxx_gpio: simplify searching for 'fsl, qoriq-gpio' compatiable
Commit da3ed89e7ce272ebcc918487e2a28736ca0dd6bb added
'fsl,qoriq-gpio' compatiable searching in the old way
using for_each_compatible_node(). But the driver have
previously been changed to use a struct of_device_id
compatible list passed to for_each_matching_node().
Add 'fsl,qoriq-gpio' compatiable to the existing
compatible list instead of adding another
for_each_compatible_node() loop.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
arch/powerpc/sysdev/mpc8xxx_gpio.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c
b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index c48cd81..0c2a91a 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -310,6 +310,7 @@ static struct of_device_id mpc8xxx_gpio_ids[] __initdata = {
{ .compatible = fsl,mpc8572-gpio, },
{ .compatible = fsl,mpc8610-gpio, },
{ .compatible = fsl,mpc5121-gpio, .data = mpc512x_irq_set_type, },
+ { .compatible = fsl,qoriq-gpio, },
{}
};
@@ -389,9 +390,6 @@ static int __init mpc8xxx_add_gpiochips(void)
for_each_matching_node(np, mpc8xxx_gpio_ids)
mpc8xxx_add_controller(np);
- for_each_compatible_node(np, NULL, fsl,qoriq-gpio)
- mpc8xxx_add_controller(np);
-
return 0;
}
arch_initcall(mpc8xxx_add_gpiochips);
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc880 linux-2.6.32 slow running processes
Rafael Beims rbe...@gmail.com wrote on 2011/01/07 11:00:56: On Thu, Jan 6, 2011 at 2:52 PM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: The 8xx tlbil_va should not be needed in recent 2.6 after I fixed the 8xx TLB code to workaround the dcbst bug there instead. See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=60e071fee994ff98c37d03a4a7c5a3f8b1e3b8e5 Not sure what release it went into though. Jocke I saw that the commit you mention did make it in the 2.6.33 version. I will try to boot it here and see if the problem is also solved in this version. Once you have tested it and it works, please send a patch to remove the 8xx workaround. Make sure Scott is cc:ed ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/boot/Makefile: Use $(src) and $(obj) as per makefiles.txt
$(src) and $(obj) are normally the same, but are supposed to be used for paths under $(srctree) and $(objtree) respectively. Also use $(dtstree) and $(wrapper) as appropriate. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- This is totally untested, so please review carefully! Ben. arch/powerpc/boot/Makefile |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 8917816..bd7abba 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -33,7 +33,7 @@ ifeq ($(call cc-option-yn, -fstack-protector),y) BOOTCFLAGS += -fno-stack-protector endif -BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj) +BOOTCFLAGS += -I$(obj) -I$(srctree)/$(src) DTC_FLAGS ?= -p 1024 @@ -399,10 +399,10 @@ $(extra-installed): $(DESTDIR)$(WRAPPER_OBJDIR)/% : $(obj)/% | $(DESTDIR)$(WRAP $(hostprogs-installed) : $(DESTDIR)$(WRAPPER_BINDIR)/% : $(obj)/% | $(DESTDIR)$(WRAPPER_BINDIR) $(call cmd,install_exe) -$(dts-installed) : $(DESTDIR)$(WRAPPER_DTSDIR)/% : $(srctree)/$(obj)/dts/% | $(DESTDIR)$(WRAPPER_DTSDIR) +$(dts-installed) : $(DESTDIR)$(WRAPPER_DTSDIR)/% : $(dtstree)/% | $(DESTDIR)$(WRAPPER_DTSDIR) $(call cmd,install_dts) -$(wrapper-installed): $(DESTDIR)$(WRAPPER_BINDIR) $(srctree)/$(obj)/wrapper | $(DESTDIR)$(WRAPPER_BINDIR) +$(wrapper-installed): $(DESTDIR)$(WRAPPER_BINDIR) $(wrapper) | $(DESTDIR)$(WRAPPER_BINDIR) $(call cmd,install_wrapper) $(obj)/bootwrapper_install: $(all-installed) -- 1.7.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/boot/dts: Install dts from the right directory
The dts-installed variable is initialised using a wildcard path that will be expanded relative to the build directory. Use the existing variable dtstree to generate an absolute wildcard path that will work when building in a separate directory. Reported-by: Gerhard Pircher gerhard_pirc...@gmx.net Signed-off-by: Ben Hutchings b...@decadent.org.uk Tested-by: Gerhard Pircher gerhard_pirc...@gmx.net [against 2.6.32] --- arch/powerpc/boot/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 96deec6..8917816 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -368,7 +368,7 @@ INSTALL := install extra-installed:= $(patsubst $(obj)/%, $(DESTDIR)$(WRAPPER_OBJDIR)/%, $(extra-y)) hostprogs-installed:= $(patsubst %, $(DESTDIR)$(WRAPPER_BINDIR)/%, $(hostprogs-y)) wrapper-installed := $(DESTDIR)$(WRAPPER_BINDIR)/wrapper -dts-installed := $(patsubst $(obj)/dts/%, $(DESTDIR)$(WRAPPER_DTSDIR)/%, $(wildcard $(obj)/dts/*.dts)) +dts-installed := $(patsubst $(dtstree)/%, $(DESTDIR)$(WRAPPER_DTSDIR)/%, $(wildcard $(dtstree)/*.dts)) all-installed := $(extra-installed) $(hostprogs-installed) $(wrapper-installed) $(dts-installed) -- 1.7.2.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
