- 11 Jul, 2014 9 commits
-
-
Benjamin Herrenschmidt authored
-
Anton Blanchard authored
We are seeing a lot of PMU warnings on POWER8: Can't find PMC that caused IRQ Looking closer, the active PMC is 0 at this point and we took a PMU exception on the transition from negative to 0. Some versions of POWER8 have an issue where they edge detect and not level detect PMC overflows. A number of places program the PMC with (0x80000000 - period_left), where period_left can be negative. We can either fix all of these or just ensure that period_left is always >= 1. This patch takes the second option. Cc: <stable@vger.kernel.org> Signed-off-by:Anton Blanchard <anton@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Guenter Roeck authored
powerpc:allmodconfig has been failing for some time with the following error. arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 A number of attempts to fix the problem by moving around code have been unsuccessful and resulted in failed builds for some configurations and the discovery of toolchain bugs. Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead. While this is less than perfect, it avoids substantial code changes which would otherwise be necessary just to make COMPILE_TEST builds happy and might have undesired side effects. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Joel Stanley authored
On POWER8 when switching to a KVM guest we set bits in MMCR2 to freeze the PMU counters. Aside from on boot they are then never reset, resulting in stuck perf counters for any user in the guest or host. We now set MMCR2 to 0 whenever enabling the PMU, which provides a sane state for perf to use the PMU counters under either the guest or the host. This was manifesting as a bug with ppc64_cpu --frequency: $ sudo ppc64_cpu --frequency WARNING: couldn't run on cpu 0 WARNING: couldn't run on cpu 8 ... WARNING: couldn't run on cpu 144 WARNING: couldn't run on cpu 152 min: 18446744073.710 GHz (cpu -1) max: 0.000 GHz (cpu -1) avg: 0.000 GHz The command uses a perf counter to measure CPU cycles over a fixed amount of time, in order to approximate the frequency of the machine. The counters were returning zero once a guest was started, regardless of weather it was still running or had been shut down. By dumping the value of MMCR2, it was observed that once a guest is running MMCR2 is set to 1s - which stops counters from running: $ sudo sh -c 'echo p > /proc/sysrq-trigger' CPU: 0 PMU registers, ppmu = POWER8 n_counters = 6 PMC1: 5b635e38 PMC2: 00000000 PMC3: 00000000 PMC4: 00000000 PMC5: 1bf5a646 PMC6: 5793d378 PMC7: deadbeef PMC8: deadbeef MMCR0: 0000000080000000 MMCR1: 000000001e000000 MMCRA: 0000040000000000 MMCR2: fffffffffffffc00 EBBHR: 0000000000000000 EBBRR: 0000000000000000 BESCR: 0000000000000000 SIAR: 00000000000a51cc SDAR: c00000000fc40000 SIER: 0000000001000000 This is done unconditionally in book3s_hv_interrupts.S upon entering the guest, and the original value is only save/restored if the host has indicated it was using the PMU. This is okay, however the user of the PMU needs to ensure that it is in a defined state when it starts using it. Fixes: e05b9b9e ("powerpc/perf: Power8 PMU support") Cc: stable@vger.kernel.org Signed-off-by:Joel Stanley <joel@jms.id.au> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Joel Stanley authored
Instead of separate bits for every POWER8 PMU feature, have a single one for v2.07 of the architecture. This saves us adding a MMCR2 define for a future patch. Cc: stable@vger.kernel.org Signed-off-by:
-
Joel Stanley authored
These two registers are already saved in the block above. Aside from being unnecessary, by the time we get down to the second save location r8 no longer contains MMCR2, so we are clobbering the saved value with PMC5. MMCR2 primarily consists of counter freeze bits. So restoring the value of PMC5 into MMCR2 will most likely have the effect of freezing counters. Fixes: 72cde5a8 ("KVM: PPC: Book3S HV: Save/restore host PMU registers that are new in POWER8") Cc: stable@vger.kernel.org Signed-off-by:
Paul Mackerras <paulus@samba.org> Reviewed-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Preeti U Murthy authored
Commit 8d6f7c5a: "powerpc/powernv: Make it possible to skip the IRQHAPPENED check in power7_nap()" added code that prevents cpus from checking for pending interrupts just before entering sleep state, which is wrong. These interrupts are delivered during the soft irq disabled state of the cpu. A cpu cannot enter any idle state with pending interrupts because they will never be serviced until the next time the cpu is woken up by some other interrupt. Its only then that the pending interrupts are replayed. This can result in device timeouts or warnings about this cpu being stuck. This patch fixes ths issue by ensuring that cpus check for pending interrupts just before entering any idle state as long as they are not in the path of split core operations. Signed-off-by:
Preeti U Murthy <preeti@linux.vnet.ibm.com> Acked-by:
-
Michael Ellerman authored
In fb5a5157 "powerpc: Remove platforms/wsp and associated pieces", we removed the last user of MMU_FTRS_A2. So remove it. MMU_FTRS_A2 was the last user of MMU_FTR_TYPE_3E, so remove it also. This leaves some unreachable code in mmu_context_nohash.c, so remove that also. Signed-off-by:
-
Michael Ellerman authored
Commit 046d662f "coredump: make core dump functionality optional" made the coredump optional, but didn't update the spufs code that depends on it. That leads to build errors such as: arch/powerpc/platforms/built-in.o: In function `.spufs_arch_write_note': coredump.c:(.text+0x22cd4): undefined reference to `.dump_emit' coredump.c:(.text+0x22cf4): undefined reference to `.dump_emit' coredump.c:(.text+0x22d0c): undefined reference to `.dump_align' coredump.c:(.text+0x22d48): undefined reference to `.dump_emit' coredump.c:(.text+0x22e7c): undefined reference to `.dump_skip' Fix it by adding some ifdefs in the cell code. Signed-off-by:
-
- 02 Jul, 2014 3 commits
-
-
Laurentiu TUDOR authored
They're almost a duplicate of the boards array and we can build them at run-time. Signed-off-by:
Laurentiu Tudor <Laurentiu.Tudor@freescale.com> Signed-off-by:
Scott Wood <scottwood@freescale.com>
-
Shengzhou Liu authored
Add support for Freescale T2080/T2081 QDS Development System Board. The T2080QDS Development System is a high-performance computing, evaluation, and development platform that supports T2080 QorIQ Power Architecture processor, with following major features: T2080QDS feature overview: Processor: - T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz Memory: - Single memory controller capable of supporting DDR3 and DDR3-LP - Dual DIMM slots up 2133MT/s with ECC Ethernet interfaces: - Two 1Gbps RGMII on-board ports - Four 10Gbps XFI on-board cages - 1Gbps/2.5Gbps SGMII Riser card - 10Gbps XAUI Riser card Accelerator: - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC SerDes: - 16 lanes up to 10.3125GHz - Supports Aurora debug, PEX, SATA, SGMII, sRIO, HiGig, XFI and XAUI IFC: - 128MB NOR Flash, 512MB NAND Flash, PromJet debug port and FPGA eSPI: - Three SPI flash (16MB N25Q128A + 8MB EN25S64 + 512KB SST25WF040) USB: - Two USB2.0 ports with internal PHY (one Type-A + one micro Type-AB) PCIE: - Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0, SR-IOV) SATA: - Two SATA 2.0 ports on-board SRIO: - Two Serial RapidIO 2.0 ports up to 5 GHz eSDHC: - Supports SD/MMC/eMMC Card DMA: - Three 8-channels DMA controllers I2C: - Four I2C controllers. UART: - Dual 4-pins UART serial ports System Logic: - QIXIS-II FPGA system controll T2081QDS board shares the same PCB with T1040QDS with some differences. Signed-off-by:
Shengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by:
-
Shengzhou Liu authored
The T2080 QorIQ multicore processor combines four dual-threaded e6500 Power Architecture processor cores with high-performance datapath acceleration logic and network and peripheral bus interfaces required for networking, telecom/datacom, wireless infrastructure, and mil/aerospace applications. The T2080 SoC includes the following function and features: - Four dual-threaded 64-bit Power architecture e6500 cores, up to 1.8GHz - 2MB L2 cache and 512KB CoreNet platform cache (CPC) - Hierarchical interconnect fabric - One 32-/64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving - Data Path Acceleration Architecture (DPAA) incorporating acceleration - 16 SerDes lanes up to 10.3125 GHz - 8 Ethernet interfaces (multiple 1G/2.5G/10G MACs) - High-speed peripheral interfaces - Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0) - Two Serial RapidIO 2.0 controllers/ports running at up to 5 GHz - Additional peripheral interfaces - Two serial ATA (SATA 2.0) controllers - Two high-speed USB 2.0 controllers with integrated PHY - Enhanced secure digital host controller (SD/SDXC/eMMC) - Enhanced serial peripheral interface (eSPI) - Four I2C controllers - Four 2-pin UARTs or two 4-pin UARTs - Integrated Flash Controller supporting NAND and NOR flash - Three eight-channel DMA engines - Support for hardware virtualization and partitioning enforcement - QorIQ Platform's Trust Architecture 2.0 T2081 is a reduced personality of T2080 with following difference: Feature T2080 T2081 1G Ethernet numbers: 8 6 10G Ethernet numbers: 4 2 SerDes lanes: 16 8 Serial RapidIO,RMan: 2 no SATA Controller: 2 no Aurora: yes no SoC Package: 896-pins 780-pins Signed-off-by:
-
- 25 Jun, 2014 8 commits
-
-
Scott Wood authored
m8xx_pcmcia_ops was the only thing in this file (other than a comment that describes a usage that doesn't match the file's contents); now that m8xx_pcmcia_ops is gone, remove the empty file. Signed-off-by: -
Scott Wood authored
This driver doesn't build, and apparently has not built since arch/ppc was removed in 2008 (when mk_int_int_mask was removed from asm/irq.h, among other build errors). A few weeks ago I asked whether anyone was actively maintaining this code, and got no positive response: http://patchwork.ozlabs.org/patch/352082/ So, let's remove it. Signed-off-by:
-
Bharat Bhushan authored
This fixes below compilation error on SOCs where CONFIG_PHYS_64BIT is not defined: arch/powerpc/kvm/e500_mmu_host.c: In function 'kvmppc_e500_shadow_map': | arch/powerpc/kvm/e500_mmu_host.c:631:20: error: 'PTE_WIMGE_SHIFT' undeclared (first use in this function) | wimg = (*ptep >> PTE_WIMGE_SHIFT) & MAS2_WIMGE_MASK; | ^ | arch/powerpc/kvm/e500_mmu_host.c:631:20: note: each undeclared identifier is reported only once for each function it appears in | make[1]: *** [arch/powerpc/kvm/e500_mmu_host.o] Error 1 Signed-off-by:
Bharat Bhushan <Bharat.Bhushan@freescale.com> Signed-off-by:
-
Wladislav Wiebe authored
In machine_check_e500 exception handler is a wrong indication in case of MCSR_BUS_WBERR - so print "Write" instead of "Read". Signed-off-by:
Wladislav Wiebe <wladislav.kw@gmail.com> Signed-off-by:
-
Chunhe Lan authored
T4240RDB board Specification ---------------------------- Memory subsystem: 6GB DDR3 128MB NOR flash 2GB NAND flash Ethernet: Eight 1G SGMII ports Four 10Gbps SFP+ ports PCIe: Two PCIe slots USB: Two USB2.0 Type A ports SDHC: One SD-card port SATA: One SATA port UART: Dual RJ45 ports Signed-off-by:Chunhe Lan <Chunhe.Lan@freescale.com> Cc: Scott Wood <scottwood@freescale.com> Signed-off-by:
-
Scott Wood authored
Commit 59a53afe "powerpc: Don't setup CPUs with bad status" broke ePAPR SMP booting. ePAPR says that CPUs that aren't presently running shall have status of disabled, with enable-method being used to determine whether the CPU can be enabled. Fix by checking for spin-table, which is currently the only supported enable-method. Signed-off-by:
-
Laurent Dufour authored
The commit 71ec7c55 introduced the magic symbol ".TOC." for ELFv2 ABI. This symbol is built manually and has no CRC value computed. A zero value is put in the CRC section to avoid modpost complaining about a missing CRC. Unfortunately, this breaks the kernel module loading when the kernel is relocated (kdump case for instance) because of the relocation applied to the kcrctab values. This patch compute a CRC value for the TOC symbol which will match the one compute by the kernel when it is relocated - aka '0 - relocate_start' done in maybe_relocated called by check_version (module.c). Signed-off-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Cc: Anton Blanchard <anton@samba.org> Signed-off-by:
-
Michael Ellerman authored
In commit 27f44888 "Add OPAL takeover from PowerVM" we added support for "takeover" on OPAL v1 machines. This was a mode of operation where we would boot under pHyp, and query for the presence of OPAL. If detected we would then do a special sequence to take over the machine, and the kernel would end up running in hypervisor mode. OPAL v1 was never a supported product, and was never shipped outside IBM. As far as we know no one is still using it. Newer versions of OPAL do not use the takeover mechanism. Although the query for OPAL should be harmless on machines with newer OPAL, we have seen a machine where it causes a crash in Open Firmware. The code in early_init_devtree() to copy boot_command_line into cmd_line was added in commit 817c21ad "Get kernel command line accross OPAL takeover", and AFAIK is only used by takeover, so should also be removed. Signed-off-by:
-
- 24 Jun, 2014 13 commits
-
-
Catalin Marinas authored
The DART table allocation is registered to kmemleak via the memblock_alloc_base() call. However, the DART table is later unmapped and dart_tablebase VA no longer accessible. This patch tells kmemleak not to scan this block and avoid an unhandled paging request. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Michael Ellerman authored
This gives us standardised success/failure output and also handles killing the test if it runs forever (2 minutes). Signed-off-by:
-
Rickard Strandqvist authored
This variable is of the wrong type, everywhere it is used it should be an unsigned int rather than a int. Signed-off-by:
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by:
-
Michael Ellerman authored
In commit 721aeaa9 "Build little endian ppc64 kernel with ABIv2", we missed some updates required in the kprobes code to make jprobes work when the kernel is built with ABI v2. Firstly update arch_deref_entry_point() to do the right thing. Now that we have added ppc_global_function_entry() we can just always use that, it will do the right thing for 32 & 64 bit and ABI v1 & v2. Secondly we need to update the code that sets up the register state before calling the jprobe handler. On ABI v1 we setup r2 to hold the TOC, on ABI v2 we need to populate r12 with the function entry point address. Signed-off-by:
-
Michael Ellerman authored
The printks() in our ftrace code have no prefix, so they appear on the console with very little context, eg: Branch out of range Use pr_fmt() & pr_err() to add a prefix. While we're at it, collapse a few split lines that don't need to be, and add a missing newline to one message. Signed-off-by:
-
Michael Ellerman authored
There is a bug in the handling of the function entry when we are nopping out a branch from a module in ftrace. We compare the result of module_trampoline_target() with the value of ppc_function_entry(), and expect them to be true. But they never will be. module_trampoline_target() will always return the global entry point of the function, whereas ppc_function_entry() will always return the local. Fix it by using the newly added ppc_global_function_entry(). Signed-off-by:
-
Michael Ellerman authored
In commit 24a1bdc3, "Fix ABIv2 issues with __ftrace_make_call", Anton changed the logic that creates and patches the branch, and added a thinko in the check of create_branch(). create_branch() returns the instruction that was generated, so if we get zero then it succeeded. The result is we can't ftrace modules: Branch out of range WARNING: at ../kernel/trace/ftrace.c:1638 ftrace failed to modify [<d000000004ba001c>] fuse_req_init_context+0x1c/0x90 [fuse] We should probably fix patch_instruction() to do that check and make the API saner, but that's a separate patch. For now just invert the test. Signed-off-by:
-
Michael Ellerman authored
In commit 24a1bdc3, "Fix ABIv2 issues with __ftrace_make_call", Anton changed the logic that checks for the expected code sequence when patching a module. We missed the typo in the mask, 0xffff00000 should be 0xffff0000, which has the effect of making the test always true. That makes it impossible to ftrace against modules, eg: Unexpected call sequence: 48000008 e8410018 WARNING: at ../kernel/trace/ftrace.c:1638 ftrace failed to modify [<d000000007cf001c>] rng_dev_open+0x1c/0x70 [rng_core] Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
-
Michael Ellerman authored
ABIv2 has the concept of a global and local entry point to a function. In most cases we are interested in the local entry point, and so that is what ppc_function_entry() returns. However we have a case in the ftrace code where we want the global entry point, and there may be other places we need it too. Rather than special casing each, add an accessor. For ABIv1 and 32-bit there is only a single entry point, so we return that. That means it's safe for the caller to use this without also checking the ABI version. Signed-off-by:
-
Rasmus Villemoes authored
A closing brace followed by "if" is almost certainly a mistake. Maybe "else if" was meant, but in this case it doesn't really matter. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Benjamin Herrenschmidt authored
The generic code uses gcc built-ins which work fine so there's no benefit in implementing our own anymore. We can't completely remove the ld/st_le* functions as some historical cruft still uses them, but that's next on the radar Signed-off-by: -
Michael Ellerman authored
We have some compile-time disabled debug code in signal_xx.c. It's from some ancient time BG, almost certainly part of the original port, given the very similar code on other arches. The show_unhandled_signal logic, added in d0c3d534 (2.6.24) is cleaner and prints more useful information, so drop the debug code. Signed-off-by:
-
Gavin Shan authored
In arch/powerpc/kernel/iomap.c, lots of IO reading accessors missed to check EEH error as Ben pointed. The patch fixes it. For the writing accessors, we change the called functions only for making them look similar to the reading counterparts. Suggested-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
- 20 Jun, 2014 7 commits
-
-
Valentin Longchamp authored
The mux2 node is missing the clock-output-names field that is required by the clk-ppc-corenet driver. Signed-off-by:
Valentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by:
-
Scott Wood authored
About a year ago I began taking patches, technically as Kumar's assistant -- but since then all of the pull requests for this area have come from me, and I've been doing most of the reviews. Update MAINTAINERS to reflect this. Signed-off-by: -
Laurentiu Tudor authored
Virtualized environments may expose a e6500 dual-threaded core as two single-threaded e6500 cores. Take advantage of this and get rid of the tlb lock and the trap-causing tlbsx in the htw miss handler by guarding with CPU_FTR_SMT, as it's already being done in the bolted tlb1 miss handler. As seen in the results below, measurements done with lmbench random memory access latency test running under Freescale's Embedded Hypervisor, there is a ~34% improvement. Memory latencies in nanoseconds - smaller is better (WARNING - may not be correct, check graphs) ---------------------------------------------------- Host Mhz L1 $ L2 $ Main mem Rand mem --------- --- ---- ---- -------- -------- smt 1665 1.8020 13.2 83.0 1149.7 nosmt 1665 1.8020 13.2 83.0 758.1 Signed-off-by: -
Marcelo Tosatti authored
Not involved in 8xx activities for years, update MAINTAINERS to reflect it. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Chunhe Lan authored
T4240 has a third DMA engine controller, so add the corresponding DMA node into the dts file. Signed-off-by:
-
Shengzhou Liu authored
- remove CONFIG_RTC_DRV_CMOS in corenet32_smp_defconfig(it's unused), reserve CONFIG_RTC_DRV_CMOS in mpc85xx_defconfig(needed on some CDS boards) - enable CONFIG_RTC_DRV_DS1307, CONFIG_RTC_DRV_DS1374, CONFIG_RTC_DRV_DS3232 in mpc85xx_defconfig, mpc85xx_smp_defconfig - enable RTC support in corenet64_smp_defconfig Signed-off-by:
-
Scott Wood authored
Signed-off-by:
Ed Swarthout <ed.swarthout@freescale.com>
-
