The PCI 2.x cells used on some 44x SoCs only let us configure the decode for the low 32-bit of the incoming PLB addresses. The top 4 bits (this is a 36-bit bus) are hard wired to different values depending on the specific SoC in use. Our code used to work "by accident" until I added support for the ISA memory holes and while at it added more validity checking of the addresses. This patch should bring it back to working condition. It still relies on the device-tree being correct but that's somewhat a pre-requisite for anything to work anyway. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
This is a simple change to correct problems when using set_irq_type on platforms using CPM2. This code corrects the problem on most platform but may have issues on 8272 derived platforms for some interrupts. On 8272 PC2 & 3 are missing and PC 23 & 29 are added, which this patch does not address. Signed-off-by: Paul Bilke <paul@conspiracy.net> Reviewed-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
I noticed this doing some randconfig testing (.config below). I have CONFIG_PM but no CONFIG_SUSPEND. Bug is against mainline. arch/powerpc/sysdev/built-in.o: In function `ipic_suspend': ipic.c:(.text+0x6b34): undefined reference to `fsl_deep_sleep' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 Looks like #ifdef CONFIG_PM in arch/powerpc/sysdev/ipic.c should be CONFIG_SUSPEND. d49747bdfb2ddebea24d1580da55b79d093d48a9 introduced this. Fix build when we have CONFIG_PM but no CONFIG_SUSPEND. Signed-off-by: Michael Neuling <mikey@neuling.org> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Convert arch/powerpc/ over to long long based u64: -#ifdef __powerpc64__ -# include <asm-generic/int-l64.h> -#else -# include <asm-generic/int-ll64.h> -#endif +#include <asm-generic/int-ll64.h> This will avoid reoccuring spurious warnings in core kernel code that comes when people test on their own hardware. (i.e. x86 in ~98% of the cases) This is what x86 uses and it generally helps keep 64-bit code 32-bit clean too. [Adjusted to not impact user mode (from paulus) - sfr] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Provides a small speedup when accessing pefetchable ranges. To indicate that a memory range is prefetchable, mark it in the dts file with 42000000 instead of 02000000. A powepc pci_controller is allowed three memory ranges, any of which may be prefetchable. However, the PCI-PCI bridge configuration space only has one field for "non-prefetchable memory behind bridge", which has a 32 bit address, and one field for "prefetchable memory behind bridge", which may have a 64 bit address. These are PCI bus addresses, not CPU physical addresses. So really you're only allowed one memory range of each type. And if you want the range at a PCI address above 32 bits you must make it prefetchable. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The code that sets up the outbound ATMU windows, which is used to map CPU physical addresses into PCI bus addresses where BARs will be mapped, didn't work so well. For one, it leaked the ioremap() of the ATMU registers. Another small bug was the high 20 bits of the PCI bus address were left as zero. It's legal for prefetchable memory regions to be above 32 bits, so the high 20 bits might not be zero. Mainly, it couldn't handle ranges that were not a power of two in size or were not naturally aligned. The ATMU windows have these requirements (size & alignment), but the code didn't bother to check if the ranges it was programming met them. If they didn't, the windows would silently be programmed incorrectly. This new code can handle ranges which are not power of two sized nor naturally aligned. It simply splits the ranges into multiple valid ATMU windows. As there are only four windows, pooly aligned or sized ranges (which didn't even work before) may run out of windows. In this case an error is printed and an effort is made to disable the unmapped resources. An improvement that could be made would be to make use of the default outbound window. Iff hose->pci_mem_offset is zero, then it's possible that some or all of the ranges might not need an outbound window and could just use the default window. The default ATMU window can support a pci_mem_offset less than zero too, but pci_mem_offset is unsigned. One could say the abilities allowed a powerpc pci_controller is neither subset nor a superset of the abilities of a Freescale PCIe controller. Thankfully, the most useful bits are in the intersection of the two abilities. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
* 'cpus4096-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (66 commits) x86: export vector_used_by_percpu_irq x86: use logical apicid in x2apic_cluster's x2apic_cpu_mask_to_apicid_and() sched: nominate preferred wakeup cpu, fix x86: fix lguest used_vectors breakage, -v2 x86: fix warning in arch/x86/kernel/io_apic.c sched: fix warning in kernel/sched.c sched: move test_sd_parent() to an SMP section of sched.h sched: add SD_BALANCE_NEWIDLE at MC and CPU level for sched_mc>0 sched: activate active load balancing in new idle cpus sched: bias task wakeups to preferred semi-idle packages sched: nominate preferred wakeup cpu sched: favour lower logical cpu number for sched_mc balance sched: framework for sched_mc/smt_power_savings=N sched: convert BALANCE_FOR_xx_POWER to inline functions x86: use possible_cpus=NUM to extend the possible cpus allowed x86: fix cpu_mask_to_apicid_and to include cpu_online_mask x86: update io_apic.c to the new cpumask code x86: Introduce topology_core_cpumask()/topology_thread_cpumask() x86: xen: use smp_call_function_many() x86: use work_on_cpu in x86/kernel/cpu/mcheck/mce_amd_64.c ... Fixed up trivial conflict in kernel/time/tick-sched.c manually