- 24 Aug, 2013 2 commits
-
-
Chunhe Lan authored
P1023RDB Specification: ----------------------- Memory subsystem: 512MB DDR3 (Fixed DDR on board) 64MB NOR flash 128MB NAND flash Ethernet: eTSEC1: Connected to Atheros AR8035 GETH PHY eTSEC2: Connected to Atheros AR8035 GETH PHY PCIe: Three mini-PCIe slots USB: Two USB2.0 Type A ports I2C: AT24C08 8K Board EEPROM (8 bit address) Signed-off-by:
Chunhe Lan <Chunhe.Lan@freescale.com> Cc: Scott Wood <scottwood@freescale.com> Signed-off-by:
Scott Wood <scottwood@freescale.com>
-
Haijun.Zhang authored
Add this file to help detect cpu type in runtime. These macros will be more favorable for driver to apply errata and workaround to specified cpu type. Signed-off-by:
Haijun Zhang <Haijun.Zhang@freescale.com> Signed-off-by:
Zhao Chenhui <chenhui.zhao@freescale.com> Signed-off-by:
-
- 21 Aug, 2013 4 commits
-
-
Scott Wood authored
Unlike 64-bit, we don't currently support multiplatform between e500 and non-e500, so the -mcpu is not configurable at this time. -msoft-float is specified when testing for -mcpu=8540 because otherwise some older toolchains will fail with "error: E500 and FPRs not supported". Signed-off-by: -
Scott Wood authored
By default use -mcpu=powerpc64 rather than -mtune=power7 Add options for e5500/e6500, with fallbacks for older compilers. Hide the POWER cpu options in booke configs. Signed-off-by: -
Scott Wood authored
This caused lwsync to be converted to sync on 64-bit (on 32-bit lwsync is generated at runtime, and so wasn't affected). Not using lwsync caused a significant slowdown on certain workloads. Setting this flag for any e500-enabled build is also not friendly to multiplatform kernels. Signed-off-by: -
Scott Wood authored
Some CPUs (such as e500v1/v2) don't implement mftb and will take a trap. mfspr should work on everything that has a timebase, and is the preferred instruction according to ISA v2.06. Currently we get away with mftb on 85xx because the assembler converts it to mfspr due to -Wa,-me500. However, that flag has other effects that are undesireable for certain targets (e.g. lwsync is converted to sync), and is hostile to multiplatform kernels. Thus we would like to stop setting it for all e500-family builds. mftb/mftbu instances which are in 85xx code or common code are converted. Instances which will never run on 85xx are left alone. Signed-off-by:
-
- 20 Aug, 2013 1 commit
-
-
Scott Wood authored
Erratum A-006598 says that 64-bit mftb is not atomic -- it's subject to a similar race condition as doing mftbu/mftbl on 32-bit. The lower half of timebase is updated before the upper half; thus, we can share the workaround for a similar bug on Cell. This workaround involves looping if the lower half of timebase is zero, thus avoiding the need for a scratch register (other than CR0). This workaround must be avoided when the timebase is frozen, such as during the timebase sync code. This deals with kernel and vdso accesses, but other userspace accesses will of course need to be fixed elsewhere. Signed-off-by:
-
- 16 Aug, 2013 1 commit
-
-
Benjamin Herrenschmidt authored
When reworking udbg_16550.c I forgot to remove the old and now useless code for the CONFIG_PPC_EARLY_DEBUG_WSP case, which doesn't build as a result. I also missed a cast. Signed-off-by:Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 14 Aug, 2013 32 commits
-
-
Anton Blanchard authored
Our ppc64 spinlocks and rwlocks use a trick where a lock token and the paca index are placed in the lock with a single store. Since we are using two u16s they need adjusting for little endian. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Anton Blanchard authored
We need to set ELF_DATA correctly on LE coredumps. Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Anton Blanchard authored
Add little endian support for demuxing SMP IPIs Signed-off-by:
-
Anton Blanchard authored
Alistair noticed we got a SIGILL on userspace mfpvr instructions. Remove the little endian check in the emulation code, it is probably there to protect against the old pseudo little endian implementations but doesn't make sense for real little endian. Signed-off-by:
-
Anton Blanchard authored
The lppaca, slb_shadow and dtl_entry hypervisor structures are big endian, so we have to byte swap them in little endian builds. LE KVM hosts will also need to be fixed but for now add an #error to remind us. Signed-off-by:
-
Anton Blanchard authored
Add endian annotation to various hypervisor structures which are defined as big endian. Signed-off-by:
-
Alistair Popple authored
The device tree is big endian so make sure we byteswap on little endian. We assume any pHyp calls also return big endian results in memory. Signed-off-by:
Alistair Popple <alistair@popple.id.au> Signed-off-by:
-
Alistair Popple authored
Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Benjamin Herrenschmidt authored
Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Anton Blanchard authored
We pass dma_window to of_parse_dma_window as a void * and then run through hoops to cast it back to a u32 array. In the process we lose endian annotation. Simplify it by just passing a __be32 * down. Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Anton Blanchard authored
Fix a couple of sparse warnings. Signed-off-by:
-
Alistair Popple authored
Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Anton Blanchard authored
RTAS expects arguments in the call buffer to be big endian so we need to byteswap on little endian builds Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
Alistair Popple authored
Signed-off-by:
-
Ian Munsie authored
On PowerPC the device tree is always big endian, but the CPU could be either, so add be32_to_cpu where appropriate and change the types of device tree data to __be32 etc to allow sparse to locate endian issues. Signed-off-by:
Ian Munsie <imunsie@au1.ibm.com> Acked-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Michael Neuling authored
When we have MMU on exceptions (POWER8) and a relocatable kernel, we need to branch from the initial exception vectors at 0x0 to up high where the kernel might be located. Currently we do this using the link register. Unfortunately this corrupts the link stack and instead we should use the count register. We did this for the syscall entry path in: 6a404806 powerpc: Avoid link stack corruption in MMU on syscall entry path but I stupidly forgot to do the same for other exceptions. This patch changes the initial exception vectors to use the count register instead of the link register when we need to branch up to the relocated kernel. I have a dodgy userspace test which loops calling a function that reads the PVR (mfpvr in userspace will be emulated by the kernel via the program check exception). On POWER8 and with CONFIG_RELOCATABLE=y, I get a ~10% performance improvement with my userspace test with this patch. Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
-
Vasant Hegde authored
So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id" was always default (-1) on ppc64 architecture. Now, some systems have an ibm,chip-id property in the cpu nodes in the device tree. On these systems, we now use this information to display physical_package_id. Signed-off-by:
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by:
Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by:
-
Mike Qiu authored
changes for V4: - changes the type of frozen_pe_no from %d to %llu in pr_devel() 'pe_no' hasn't been defined, it should be an typo error, it should be 'frozen_pe_no'. Also '__func__' has missed in IODA_EEH_DBG(), For safety reasons, use pr_devel() directly, instead of use IODA_EEH_DBG() Signed-off-by:
Mike Qiu <qiudayu@linux.vnet.ibm.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
This reverts commit c8db32c8. The commit breaks the build of all my 64-bit embedded configs. It looks like gcc-4.7.3 doesn't know about e5500. Additionally it incorrectly does -mcpu=e5500 on a config that has both e5500 and A2 support enabled. Signed-off-by:
-
Paul Mackerras authored
Some systems have an ibm,chip-id property in the cpu nodes in the device tree. On these systems, we now use that to compute the cpu_core_mask (i.e. the set of core siblings) rather than looking at cache properties. Signed-off-by:
Paul Mackerras <paulus@samba.org> Tested-by:
-
Paul Mackerras authored
This factors out the details of updating cpu_core_mask into a separate function, to make it easier to change how the mask is calculated later. This makes no functional change. Signed-off-by:
-
Paul Mackerras authored
The denormalized exception handler (denorm_exception_hv) has a couple of bugs. If the CONFIG_PPC_DENORMALISATION option is not selected, or the HSRR1_DENORM bit is not set in HSRR1, we don't test whether the interrupt occurred within a KVM guest. On the other hand, if the HSRR1_DENORM bit is set and CONFIG_PPC_DENORMALISATION is enabled, we corrupt the CFAR and PPR. To correct these problems, this replaces the open-coded version of EXCEPTION_PROLOG_1 that is there currently, and that is missing the saving of PPR and CFAR values to the PACA, with an instance of EXCEPTION_PROLOG_1. This adds an explicit KVMTEST after testing whether the exception is one we can handle, and adds code to restore the CFAR on exit. Signed-off-by:
-
