- 05 Jun, 2014 13 commits
-
-
Vasant Hegde authored
We pass actual buffer size to opal_validate_flash() OPAL API call and in return it contains output buffer size. Commit cc146d1d (Fix little endian issues) missed to set the size param before making OPAL call. So firmware image validation fails. This patch sets size variable before making OPAL call. Signed-off-by:
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Tested-by:
Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Anton Blanchard authored
The hcall macros may call out to c code for tracing, so we need to set up a valid r2. This fixes an oops found when testing ibmvscsi as a module. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Anton Blanchard authored
__clear_user and copy_page load from the TOC and are also exported to modules. This means we have to use _GLOBAL_TOC() so that we create the global entry point that sets up the TOC. Signed-off-by:
-
Anton Blanchard authored
powerpc sets a low SECTION_SIZE_BITS to accomodate small pseries boxes. We default to 16MB memory blocks, and boxes with a lot of memory end up with enormous numbers of sysfs memory nodes. Set a more reasonable default for powernv of 256MB. Signed-off-by:
-
Anton Blanchard authored
The pseries platform code unconditionally overrides memory_block_size_bytes regardless of the running platform. Create a ppc_md hook that so each platform can choose to do what it wants. Signed-off-by:
-
Anton Blanchard authored
struct OpalMemoryErrorData is passed to us from firmware, so we have to byteswap it. Signed-off-by:
-
Wei Yang authored
When eeh is not enabled, and hotplug two pci devices on the same bus, eeh related sysfs would be added twice for the first added pci device. Since the eeh_dev is not created when eeh is not enabled. This patch adds the check, if eeh is not enabled, eeh sysfs will not be created. After applying this patch, following warnings are reduced: sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:00.0/eeh_mode' sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:00.0/eeh_config_addr' sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:00.0/eeh_pe_config_addr' Signed-off-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Acked-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
Anton Blanchard authored
commit 8f9c0119 (compat: fs: Generic compat_sys_sendfile implementation) changed the PowerPC 64bit sendfile call from sys_sendile64 to sys_sendfile. Unfortunately this broke sendfile of lengths greater than 2G because sys_sendfile caps at MAX_NON_LFS. Restore what we had previously which fixes the bug. Cc: stable@vger.kernel.org Signed-off-by:
-
Benjamin Herrenschmidt authored
This provides debugfs files to access the LPC bus on Power8 non-virtualized using the appropriate OPAL firmware calls. The usage is simple: one file per space (IO, MEM and FW), lseek to the address and read/write the data. IO and MEM always generate series of byte accesses. FW can generate word and dword accesses if aligned properly. Based on an original patch from Rob Lippert and reworked. Signed-off-by: -
Benjamin Herrenschmidt authored
We had a mix & match of flags used when creating legacy ports depending on where we found them in the device-tree. Among others we were missing UPF_SKIP_TEST for some kind of ISA ports which is a problem as quite a few UARTs out there don't support the loopback test (such as a lot of BMCs). Let's pick the set of flags used by the SoC code and generalize it which means autoconf, no loopback test, irq maybe shared and fixed port. Sending to stable as the lack of UPF_SKIP_TEST is breaking serial on some machines so I want this back into distros Signed-off-by: -
Michael Ellerman authored
This patch adds some documentation on the different cpu families supported by arch/powerpc. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Michael Ellerman authored
There are a couple of places where xmon is using %x to print values that are unsigned long. I found this out the hard way recently: 0:mon> p c000000000d0e7c8 c00000033dc90000 00000000a0000089 c000000000000000 return value is 0x96300500 Which is calling find_linux_pte_or_hugepte(), the result should be a kernel pointer. After decoding the page tables by hand I discovered the correct value was c000000396300500. So fix up that case and a few others. We also use a mix of 0x%x, %x and %u to print cpu numbers. So standardise on 0x%x. Signed-off-by:
-
Benjamin Herrenschmidt authored
When running as a powernv "host" system on P8, we need to switch the endianness of interrupt handlers. This does it via the appropriate call to the OPAL firmware which may result in just switching HID0:HILE but depending on the processor version might need to do a few more things. This call must be done early before any other processor has been brought out of firmware. Signed-off-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
- 28 May, 2014 17 commits
-
-
Sam bobroff authored
Add some documentation about ... /sys/devices/system/cpu/dscr_default /sys/devices/system/cpu/cpuN/dscr ... to Documentation/ABI/stable. Signed-off-by:
Sam Bobroff <sam.bobroff@au1.ibm.com> Signed-off-by:
-
Sam bobroff authored
Since commit "efcac658 powerpc: Per process DSCR + some fixes (try#4)" it is no longer possible to set the DSCR on a per-CPU basis. The old behaviour was to minipulate the DSCR SPR directly but this is no longer sufficient: the value is quickly overwritten by context switching. This patch stores the per-CPU DSCR value in a kernel variable rather than directly in the SPR and it is used whenever a process has not set the DSCR itself. The sysfs interface (/sys/devices/system/cpu/cpuN/dscr) is unchanged. Writes to the old global default (/sys/devices/system/cpu/dscr_default) now set all of the per-CPU values and reads return the last written value. The new per-CPU default is added to the paca_struct and is used everywhere outside of sysfs.c instead of the old global default. Signed-off-by:
-
Sam bobroff authored
Split the __SYSFS_SPRSETUP macro into two parts so that registers requiring custom read and write functions can use common code for their show and store functions. Signed-off-by:
-
Rickard Strandqvist authored
Cleaning up inconsistent NULL checks. There is otherwise a risk of a possible null pointer dereference. Was largely found by using a static code analysis program called cppcheck. Signed-off-by:
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by:
-
Preeti U Murthy authored
Commit 32e45ff4 changed the default value of RECLAIM_DISTANCE to 30. However the comment around arch specifc definition of RECLAIM_DISTANCE is not updated to reflect the same. Correct the value mentioned in the comment. Signed-off-by:
Preeti U Murthy <preeti@linux.vnet.ibm.com> Cc: Anton Blanchard <anton@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by:
KOSAKI Motohiro <Kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
-
Michael Ellerman authored
Upcoming POWER8 chips support a concept called split core. This is where the core can be split into subcores that although not full cores, are able to appear as full cores to a guest. The splitting & unsplitting procedure is mildly complicated, and explained at length in the comments within the patch. One notable detail is that when splitting or unsplitting we need to pull offline cpus out of their offline state to do work as part of the procedure. The interface for changing the split mode is via a sysfs file, eg: $ echo 2 > /sys/devices/system/cpu/subcores_per_core Currently supported values are '1', '2' and '4'. And indicate respectively that the core should be unsplit, split in half, and split in quarters. These modes correspond to threads_per_subcore of 8, 4 and 2. We do not allow changing the split mode while KVM VMs are active. This is to prevent the value changing while userspace is configuring the VM, and also to prevent the mode being changed in such a way that existing guests are unable to be run. CPU hotplug fixes by Srivatsa. max_cpus fixes by Mahesh. cpuset fixes by benh. Fix for irq race by paulus. The rest by mikey and mpe. Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by:
-
Michael Ellerman authored
To support split core on POWER8 we need to modify various parts of the KVM code to use threads_per_subcore instead of threads_per_core. On systems that do not support split core threads_per_subcore == threads_per_core and these changes are a nop. We use threads_per_subcore as the value reported by KVM_CAP_PPC_SMT. This communicates to userspace that guests can only be created with a value of threads_per_core that is less than or equal to the current threads_per_subcore. This ensures that guests can only be created with a thread configuration that we are able to run given the current split core mode. Although threads_per_subcore can change during the life of the system, the commit that enables that will ensure that threads_per_subcore does not change during the life of a KVM VM. Signed-off-by:
Alexander Graf <agraf@suse.de> Acked-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Michael Ellerman authored
To support split core we need to change the check in __cpu_up() that determines if a cpu is allowed to come online. Currently we refuse to online cpus which are not the primary thread within their core. On POWER8 with split core support this check needs to instead refuse to online cpus which are not the primary thread within their *sub* core. On POWER7 and other systems that do not support split core, threads_per_subcore == threads_per_core and so the check is equivalent. Signed-off-by:
-
Michael Ellerman authored
On POWER8 we have a new concept of a subcore. This is what happens when you take a regular core and split it. A subcore is a grouping of two or four SMT threads, as well as a handfull of SPRs which allows the subcore to appear as if it were a core from the point of view of a guest. Unlike threads_per_core which is fixed at boot, threads_per_subcore can change while the system is running. Most code will not want to use threads_per_subcore. Signed-off-by:
-
Michael Ellerman authored
To support split core we need to be able to force all secondaries into nap, so the core can detect they are idle and do an unsplit. Currently power7_nap() will return without napping if there is an irq pending. We want to ignore the pending irq and nap anyway, we will deal with the interrupt later. Signed-off-by:
-
Michael Ellerman authored
As part of the support for split core on POWER8, we want to be able to block splitting of the core while KVM VMs are active. The logic to do that would be exactly the same as the code we currently have for inhibiting onlining of secondaries. Instead of adding an identical mechanism to block split core, rework the secondary inhibit code to be a "HV KVM is active" check. We can then use that in both the cpu hotplug code and the upcoming split core code. Signed-off-by:
-
Nishanth Aravamudan authored
Based off fd1197f1 for ia64, enable CONFIG_HAVE_MEMORYLESS_NODES if NUMA. Initialize the local memory node in start_secondary. With this commit and the preceding to enable CONFIG_USER_PERCPU_NUMA_NODE_ID, which is a prerequisite, in a PowerKVM guest with the following topology: numactl --hardware available: 3 nodes (0-2) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 node 0 size: 1998 MB node 0 free: 521 MB node 1 cpus: 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 node 1 size: 0 MB node 1 free: 0 MB node 2 cpus: node 2 size: 2039 MB node 2 free: 1739 MB node distances: node 0 1 2 0: 10 40 40 1: 40 10 40 2: 40 40 10 the unreclaimable slab is reduced by close to 130M: Before: Slab: 418176 kB SReclaimable: 26624 kB SUnreclaim: 391552 kB After: Slab: 298944 kB SReclaimable: 31744 kB SUnreclaim: 267200 kB Signed-off-by:
Nishanth Aravamudan <nacc@linux.vnet.ibm.com> Signed-off-by:
-
Nishanth Aravamudan authored
Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU topology tracking, specifically: initialize per cpu numa_node entry in start_secondary remove the powerpc cpu_to_node() define CONFIG_USE_PERCPU_NUMA_NODE_ID if NUMA Signed-off-by:
-
Benjamin Herrenschmidt authored
Merge the binutils and kexec fixes.
-
Srivatsa S. Bhat authored
If we try to perform a kexec when the machine is in ST (Single-Threaded) mode (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we get the following messages during boot: [ 0.089866] POWER8 performance monitor hardware support registered [ 0.089985] power8-pmu: PMAO restore workaround active. [ 5.095419] Processor 1 is stuck. [ 10.097933] Processor 2 is stuck. [ 15.100480] Processor 3 is stuck. [ 20.102982] Processor 4 is stuck. [ 25.105489] Processor 5 is stuck. [ 30.108005] Processor 6 is stuck. [ 35.110518] Processor 7 is stuck. [ 40.113369] Processor 9 is stuck. [ 45.115879] Processor 10 is stuck. [ 50.118389] Processor 11 is stuck. [ 55.120904] Processor 12 is stuck. [ 60.123425] Processor 13 is stuck. [ 65.125970] Processor 14 is stuck. [ 70.128495] Processor 15 is stuck. [ 75.131316] Processor 17 is stuck. Note that only the sibling threads are stuck, while the primary threads (0, 8, 16 etc) boot just fine. Looking closer at the previous step of kexec, we observe that kexec tries to wakeup (bring online) the sibling threads of all the cores, before performing kexec: [ 9464.131231] Starting new kernel [ 9464.148507] kexec: Waking offline cpu 1. [ 9464.148552] kexec: Waking offline cpu 2. [ 9464.148600] kexec: Waking offline cpu 3. [ 9464.148636] kexec: Waking offline cpu 4. [ 9464.148671] kexec: Waking offline cpu 5. [ 9464.148708] kexec: Waking offline cpu 6. [ 9464.148743] kexec: Waking offline cpu 7. [ 9464.148779] kexec: Waking offline cpu 9. [ 9464.148815] kexec: Waking offline cpu 10. [ 9464.148851] kexec: Waking offline cpu 11. [ 9464.148887] kexec: Waking offline cpu 12. [ 9464.148922] kexec: Waking offline cpu 13. [ 9464.148958] kexec: Waking offline cpu 14. [ 9464.148994] kexec: Waking offline cpu 15. [ 9464.149030] kexec: Waking offline cpu 17. Instrumenting this piece of code revealed that the cpu_up() operation actually fails with -EBUSY. Thus, only the primary threads of all the cores are online during kexec, and hence this is a sure-shot receipe for disaster, as explained in commit e8e5c215 (powerpc/kexec: Fix orphaned offline CPUs across kexec), as well as in the comment above wake_offline_cpus(). It turns out that cpu_up() was returning -EBUSY because the variable 'cpu_hotplug_disabled' was set to 1; and this disabling of CPU hotplug was done by migrate_to_reboot_cpu() inside kernel_kexec(). Now, migrate_to_reboot_cpu() was originally written with the assumption that any further code will not need to perform CPU hotplug, since we are anyway in the reboot path. However, kexec is clearly not such a case, since we depend on onlining CPUs, atleast on powerpc. So re-enable cpu-hotplug after returning from migrate_to_reboot_cpu() in the kexec path, to fix this regression in kexec on powerpc. Also, wrap the cpu_up() in powerpc kexec code within a WARN_ON(), so that we can catch such issues more easily in the future. Fixes: c97102ba (kexec: migrate to reboot cpu) Cc: stable@vger.kernel.org Signed-off-by:
-
Guenter Roeck authored
With binutils 2.24, various 64 bit builds fail with relocation errors such as arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o The assembler maintainer says: I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs. Replacing @h with @high in one strategic location fixes the relocation errors. This has to be done conditionally since the assembler either supports @h or @high but not both. Cc: <stable@vger.kernel.org> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Benjamin Herrenschmidt authored
<< Highlights include a few new boards, a device tree binding for CCF (including backwards-compatible device tree updates to distinguish incompatible versions), and some fixes. >>
-
- 22 May, 2014 10 commits
-
-
Scott Wood authored
Signed-off-by:Scott Wood <scottwood@freescale.com> Cc: Diana Craciun <diana.craciun@freescale.com>
-
Alexander Graf authored
We get an array of instructions from the hypervisor via device tree that we write into a buffer that gets executed whenever we want to make an ePAPR compliant hypercall. However, the hypervisor passes us these instructions in BE order which we have to manually convert to LE when we want to run them in LE mode. With this fixup in place, I can successfully run LE kernels with KVM PV enabled on PR KVM. Signed-off-by:
-
harninder rai authored
- BSC9132 is an integrated device that targets Femto base station market. It combines Power Architecture e500v2 and DSP StarCore SC3850 technologies with MAPLE-B2F baseband acceleration processing elements - BSC9132QDS Overview 2Gbyte DDR3 (on board DDR) 32Mbyte 16bit NOR flash 128Mbyte 2K page size NAND Flash 256 Kbit M24256 I2C EEPROM 128 Mbit SPI Flash memory SD slot eTSEC1: Connected to SGMII PHY eTSEC2: Connected to SGMII PHY DUART interface: supports one UARTs up to 115200 bps for console display Signed-off-by:Harninder Rai <harninder.rai@freescale.com> Signed-off-by:
Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by:
-
Lijun Pan authored
P1023RDS is no longer supported/manufactured by Freescale while P1023RDB is. Signed-off-by:
Lijun Pan <Lijun.Pan@freescale.com> Signed-off-by:
-
Scott Wood authored
Besides other potential problems, if MPIC_NO_RESET is not set, the error interrupt will be masked after it is requested. Signed-off-by: -
Prabhakar Kushwaha authored
Add support for T104x board in board file t104x_qds.c, It is common for both T1040 and T1042 as they share same QDS board. T1040QDS board Overview ----------------------- - SERDES Connections, 8 lanes supporting: — PCI Express: supporting Gen 1 and Gen 2; — SGMII — QSGMII — SATA 2.0 — Aurora debug with dedicated connectors (T1040 only) - DDR Controller - Supports rates of up to 1600 MHz data-rate - Supports one DDR3LP UDIMM/RDIMMs, of single-, dual- or quad-rank types. -IFC/Local Bus - NAND flash: 8-bit, async, up to 2GB. - NOR: 8-bit or 16-bit, non-multiplexed, up to 512MB - GASIC: Simple (minimal) target within Qixis FPGA - PromJET rapid memory download support - Ethernet - Two on-board RGMII 10/100/1G ethernet ports. - PHY #0 remains powered up during deep-sleep (T1040 only) - QIXIS System Logic FPGA - Clocks - System and DDR clock (SYSCLK, “DDRCLK”) - SERDES clocks - Power Supplies - Video - DIU supports video at up to 1280x1024x32bpp - USB - Supports two USB 2.0 ports with integrated PHYs — Two type A ports with 5V@1.5A per port. — Second port can be converted to OTG mini-AB - SDHC - SDHC port connects directly to an adapter card slot, featuring: - Supporting SD slots for: SD, SDHC (1x, 4x, 8x) and/or MMC — Supporting eMMC memory devices - SPI - On-board support of 3 different devices and sizes - Other IO - Two Serial ports - ProfiBus port - Four I2C ports Add T104xQDS support in Kconfig and Makefile. Also create device tree. Following features are currently not implmented. - SerDes: Aurora - IFC: GASIC, Promjet - QIXIS - Ethernet - DIU - power supplies management - ProfiBus Signed-off-by:Priyanka Jain <Priyanka.Jain@freescale.com> Signed-off-by:
Poonam Aggrwal <poonam.aggrwal@freescale.com> Signed-off-by:
Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by:
-
Prabhakar Kushwaha authored
The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA processor cores with high-performance data path acceleration architecture and network peripheral interfaces required for networking & telecommunications. T1042 personality is a reduced personality of T1040 without Integrated 8-port Gigabit Ethernet switch. The T1040/T1042 SoC includes the following function and features: - Four e5500 cores, each with a private 256 KB L2 cache - 256 KB shared L3 CoreNet platform cache (CPC) - Interconnect CoreNet platform - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving support - Data Path Acceleration Architecture (DPAA) incorporating acceleration for the following functions: - Packet parsing, classification, and distribution - Queue management for scheduling, packet sequencing, and congestion management - Cryptography Acceleration (SEC 5.0) - RegEx Pattern Matching Acceleration (PME 2.2) - IEEE Std 1588 support - Hardware buffer management for buffer allocation and deallocation - Ethernet interfaces - Integrated 8-port Gigabit Ethernet switch (T1040 only) - Four 1 Gbps Ethernet controllers - Two RGMII interfaces or one RGMII and one MII interfaces - High speed peripheral interfaces - Four PCI Express 2.0 controllers running at up to 5 GHz - Two SATA controllers supporting 1.5 and 3.0 Gb/s operation - Upto two QSGMII interface - Upto six SGMII interface supporting 1000 Mbps - One SGMII interface supporting upto 2500 Mbps - Additional peripheral interfaces - Two USB 2.0 controllers with integrated PHY - SD/eSDHC/eMMC - eSPI controller - Four I2C controllers - Four UARTs - Four GPIO controllers - Integrated flash controller (IFC) - Change this to LCD/ HDMI interface (DIU) with 12 bit dual data rate - TDM interface - Multicore programmable interrupt controller (PIC) - Two 8-channel DMA engines - Single source clocking implementation - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB) Signed-off-by:Varun Sethi <Varun.Sethi@freescale.com> Signed-off-by:
-
Diana Craciun authored
Updated the device trees according to the corenet-cf binding definition. Signed-off-by:
Diana Craciun <Diana.Craciun@freescale.com> Signed-off-by:
-
Diana Craciun authored
Updated the device trees according to the corenet-cf binding definition. Signed-off-by:
-
Diana Craciun authored
The CoreNet coherency fabric is a fabric-oriented, conectivity infrastructure that enables the implementation of coherent, multicore systems. The CCF acts as a central interconnect for cores, platform-level caches, memory subsystem, peripheral devices and I/O host bridges in the system. Signed-off-by:
-
