summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'scott/next' into nextBenjamin Herrenschmidt2014-01-1581-614/+3154
|\ | | | | | | | | | | | | | | | | | | Freescale updates from Scott: << Highlights include 32-bit booke relocatable support, e6500 hardware tablewalk support, various e500 SPE fixes, some new/revived boards, and e6500 deeper idle and altivec powerdown modes. >>
| * powerpc/fsl_pci: add versionless pci compatibleShengzhou Liu2014-01-101-0/+1
| | | | | | | | | | | | | | | | | | | | There are much pci compatible with version on existing platforms. To stop putting version numbers in device tree later, we add a generic compatible 'fsl,qoriq-pcie'. The version number is readable directly from a register. Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/85xx/dts: add third elo3 dma componentShengzhou Liu2014-01-101-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add elo3-dma-2.dtsi to support the third DMA controller. This is used on T2080, T4240, B4860, etc. FSL MPIC v4.3 adds a new discontiguous address range for internal interrupts, e.g. internal interrupt 0 is at offset 0x200 and thus interrupt number is: 0x200 >> 5 = 16 in the device tree. DMA controller 3 channel 0 internal interrupt 240 is at offset 0x3a00, and thus the corresponding interrupt number is: 0x3a00 >> 5 = 464, it's similar for other 7 interrupt numbers of DMA 3 channels. Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc: Replaced tlbilx with tlbwe in the initialization codeDiana Craciun2014-01-101-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Freescale e6500 cores EPCR[DGTMI] controls whether guest supervisor state can execute TLB management instructions. If EPCR[DGTMI]=0 tlbwe and tlbilx are allowed to execute normally in the guest state. A hypervisor may choose to virtualize TLB1 and for this purpose it may use IPROT to protect the entries for being invalidated by the guest. However, because tlbwe and tlbilx execution in the guest state are sharing the same bit, it is not possible to have a scenario where tlbwe is allowed to be executed in guest state and tlbilx traps. When guest TLB management instructions are allowed to be executed in guest state the guest cannot use tlbilx to invalidate TLB1 guest entries. Linux is using tlbilx in the boot code to invalidate the temporary entries it creates when initializing the MMU. The patch is replacing the usage of tlbilx in initialization code with tlbwe with VALID bit cleared. Linux is also using tlbilx in other contexts (like huge pages or indirect entries) but removing the tlbilx from the initialization code offers the possibility to have scenarios under hypervisor which are not using huge pages or indirect entries. Signed-off-by: Diana Craciun <Diana.Craciun@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/booke-64: fix tlbsrx. path in bolted tlb handlerScott Wood2014-01-101-1/+2
| | | | | | | | | | | | | | | | It was branching to the cleanup part of the non-bolted handler, which would have been bad if there were any chips with tlbsrx. that use the bolted handler. Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc: fix 8xx and 6xx final link failuresPaul Gortmaker2014-01-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As of commit b81f18e55e9f4ea81759bcb00fea295de679bbe8 ("powerpc/boot: Only build board support files when required.") the two defconfigs ep88xc_defconfig and storcenter_defconfig would fail final link as follows: WRAP arch/powerpc/boot/dtbImage.ep88xc arch/powerpc/boot/wrapper.a(mpc8xx.o): In function `mpc885_get_clock': arch/powerpc/boot/mpc8xx.c:30: undefined reference to `fsl_get_immr' make[1]: *** [arch/powerpc/boot/dtbImage.ep88xc] Error 1 ...and... WRAP arch/powerpc/boot/cuImage.storcenter arch/powerpc/boot/cuboot-pq2.o: In function `pq2_platform_fixups': cuboot-pq2.c:(.text+0x324): undefined reference to `fsl_get_immr' make[1]: *** [arch/powerpc/boot/cuImage.storcenter] Error 1 We need the fsl-soc board files built for these two platforms. Cc: Tony Breeds <tony@bakeyournoodle.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Fixes: b81f18e55e9f ("powerpc/boot: Only build board support files when required.") Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/85xx: handle the eLBC error interrupt if it exists in dtsShaohui Xie2014-01-102-7/+26
| | | | | | | | | | | | | | | | | | | | | | | | On P1020, P1021, P1022, and P1023, eLBC event interrupts are routed to internal interrupt 3 while ELBC error interrupts are routed to internal interrupt 0. We need to call request_irq for each. Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> [scottwood@freescale.com: reworded commit message and fixed author] Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/dts: fix lbc lack of error interruptWang Dongsheng2014-01-104-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | P1020, P1021, P1022, P1023 when the lbc get error, the error interrupt will be triggered. The corresponding interrupt is internal IRQ0. So system have to process the lbc IRQ0 interrupt. The corresponding lbc general interrupt is internal IRQ3. Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> [scottwood@freescale.com: bracketed individual list elements] Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100Stephen Chivers2014-01-098-2/+596
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the Motorola/Emerson MVME5100 Single Board Computer. The MVME5100 is a 6U form factor VME64 computer with: - A single MPC7410 or MPC750 CPU - A HAWK Processor Host Bridge (CPU to PCI) and MultiProcessor Interrupt Controller (MPIC) - Up to 500Mb of onboard memory - A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip - Two 16550 compatible UARTS - Two Intel E100 Fast Ethernets - Two PCI Mezzanine Card (PMC) Slots - PPCBug Firmware The HAWK PHB/MPIC is compatible with the MPC10x devices. There is no onboard disk support. This is usually provided by installing a PMC in first PMC slot. This patch revives the board support, it was present in early 2.6 series kernels. The board support in those days was by Matt Porter of MontaVista Software. CSC Australia has around 31 of these boards in service. The kernel in use for the boards is based on 2.6.31. The boards are operated without disks from a file server. This patch is based on linux-3.13-rc2 and has been boot tested. Only boards with 512 Mb of memory are known to work. Signed-off-by: Stephen Chivers <schivers@csc.com> Tested-by: Alessio Igor Bogani <alessio.bogani@elettra.eu> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl-book3e-64: Use paca for hugetlb TLB1 entry selectionScott Wood2014-01-091-10/+41
| | | | | | | | | | | | | | | | This keeps usage coordinated for hugetlb and indirect entries, which should make entry selection more predictable and probably improve overall performance when mixing the two. Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/e6500: TLB miss handler with hardware tablewalk supportScott Wood2014-01-0910-36/+326
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a few things that make the existing hw tablewalk handlers unsuitable for e6500: - Indirect entries go in TLB1 (though the resulting direct entries go in TLB0). - It has threads, but no "tlbsrx." -- so we need a spinlock and a normal "tlbsx". Because we need this lock, hardware tablewalk is mandatory on e6500 unless we want to add spinlock+tlbsx to the normal bolted TLB miss handler. - TLB1 has no HES (nor next-victim hint) so we need software round robin (TODO: integrate this round robin data with hugetlb/KVM) - The existing tablewalk handlers map half of a page table at a time, because IBM hardware has a fixed 1MiB indirect page size. e6500 has variable size indirect entries, with a minimum of 2MiB. So we can't do the half-page indirect mapping, and even if we could it would be less efficient than mapping the full page. - Like on e5500, the linear mapping is bolted, so we don't need the overhead of supporting nested tlb misses. Note that hardware tablewalk does not work in rev1 of e6500. We do not expect to support e6500 rev1 in mainline Linux. Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Mihai Caraman <mihai.caraman@freescale.com>
| * powerpc: add barrier after writing kernel PTEScott Wood2014-01-092-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no barrier between something like ioremap() writing to a PTE, and returning the value to a caller that may then store the pointer in a place that is visible to other CPUs. Such callers generally don't perform barriers of their own. Even if callers of ioremap() and similar things did use barriers, the most logical choise would be smp_wmb(), which is not architecturally sufficient when BookE hardware tablewalk is used. A full sync is specified by the architecture. For userspace mappings, OTOH, we generally already have an lwsync due to locking, and if we occasionally take a spurious fault due to not having a full sync with hardware tablewalk, it will not be fatal because we will retry rather than oops. Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl_booke: enable the relocatable for the kdump kernelKevin Hao2014-01-091-2/+1
| | | | | | | | | | | | | | | | | | The RELOCATABLE is more flexible and without any alignment restriction. And it is a superset of DYNAMIC_MEMSTART. So use it by default for a kdump kernel. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl_booke: smp support for booting a relocatable kernel above 64MKevin Hao2014-01-094-17/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When booting above the 64M for a secondary cpu, we also face the same issue as the boot cpu that the PAGE_OFFSET map two different physical address for the init tlb and the final map. So we have to use switch_to_as1/restore_to_as0 between the conversion of these two maps. When restoring to as0 for a secondary cpu, we only need to return to the caller. So add a new parameter for function restore_to_as0 for this purpose. Use LOAD_REG_ADDR_PIC to get the address of variables which may be used before we set the final map in cams for the secondary cpu. Move the setting of cams a bit earlier in order to avoid the unnecessary using of LOAD_REG_ADDR_PIC. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl_booke: make sure PAGE_OFFSET map to memstart_addr for ↵Kevin Hao2014-01-093-12/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | relocatable kernel This is always true for a non-relocatable kernel. Otherwise the kernel would get stuck. But for a relocatable kernel, it seems a little complicated. When booting a relocatable kernel, we just align the kernel start addr to 64M and map the PAGE_OFFSET from there. The relocation will base on this virtual address. But if this address is not the same as the memstart_addr, we will have to change the map of PAGE_OFFSET to the real memstart_addr and do another relocation again. Signed-off-by: Kevin Hao <haokexin@gmail.com> [scottwood@freescale.com: make offset long and non-negative in simple case] Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl_booke: introduce map_mem_in_cams_addrKevin Hao2014-01-091-3/+10
| | | | | | | | | | | | | | | | Introduce this function so we can set both the physical and virtual address for the map in cams. This will be used by the relocation code. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc: introduce early_get_first_memblock_infoKevin Hao2014-01-092-1/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | For a relocatable kernel since it can be loaded at any place, there is no any relation between the kernel start addr and the memstart_addr. So we can't calculate the memstart_addr from kernel start addr. And also we can't wait to do the relocation after we get the real memstart_addr from device tree because it is so late. So introduce a new function we can use to get the first memblock address and size in a very early stage (before machine_init). Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl_booke: set the tlb entry for the kernel address in AS1Kevin Hao2014-01-093-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | We use the tlb1 entries to map low mem to the kernel space. In the current code, it assumes that the first tlb entry would cover the kernel image. But this is not true for some special cases, such as when we run a relocatable kernel above the 64M or set CONFIG_KERNEL_START above 64M. So we choose to switch to address space 1 before setting these tlb entries. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc: enable the relocatable support for the fsl booke 32bit kernelKevin Hao2014-01-094-1/+65
| | | | | | | | | | | | | | | | | | | | This is based on the codes in the head_44x.S. The difference is that the init tlb size we used is 64M. With this patch we can only load the kernel at address between memstart_addr ~ memstart_addr + 64M. We will fix this restriction in the following patches. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc: introduce macro LOAD_REG_ADDR_PICKevin Hao2014-01-091-0/+13
| | | | | | | | | | | | | | | | This is used to get the address of a variable when the kernel is not running at the linked or relocated address. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl_booke: introduce get_phys_addr functionKevin Hao2014-01-091-20/+30
| | | | | | | | | | | | | | | | Move the codes which translate a effective address to physical address to a separate function. So it can be reused by other code. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl_booke: protect the access to MAS7Kevin Hao2014-01-092-1/+4
| | | | | | | | | | | | | | | | | | | | | | The e500v1 doesn't implement the MAS7, so we should avoid to access this register on that implementations. In the current kernel, the access to MAS7 are protected by either CONFIG_PHYS_64BIT or MMU_FTR_BIG_PHYS. Since some code are executed before the code patching, we have to use CONFIG_PHYS_64BIT in these cases. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/mpic_timer: fix convert ticks to time subtraction overflowWang Dongsheng2014-01-091-2/+5
| | | | | | | | | | | | | | | | In some cases tmp_sec may be greater than ticks, because in the process of calculation ticks and tmp_sec will be rounded. Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/mpic_timer: fix the time is not accurate caused by GTCRR toggle bitWang Dongsheng2014-01-091-0/+3
| | | | | | | | | | | | | | | | When the timer GTCCR toggle bit is inverted, we calculated the rest of the time is not accurate. So we need to ignore this bit. Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/p1022ds: add a interrupt for rtc nodeWang Dongsheng2014-01-091-0/+1
| | | | | | | | | | | | | | Add an external interrupt for rtc node. Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/p1022ds: fix rtc compatible stringWang Dongsheng2014-01-091-1/+1
| | | | | | | | | | | | | | | | RTC Hardware(ds3232) and rtc compatible string does not match. Change "dallas,ds1339" to "dallas,ds3232". Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * drivers/tty: ehv_bytechan fails to build as a moduleAnton Blanchard2014-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | ehv_bytechan is marked tristate but fails to build as a module: drivers/tty/ehv_bytechan.c:363:1: error: type defaults to ‘int’ in declaration of ‘console_initcall’ [-Werror=implicit-int] It doesn't make much sense for a console driver to be built as a module, so change it to a bool. Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/85xx: add sysfs for pw20 state and altivec idleWang Dongsheng2014-01-091-0/+316
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a sys interface to enable/diable pw20 state or altivec idle, and control the wait entry time. Enable/Disable interface: 0, disable. 1, enable. /sys/devices/system/cpu/cpuX/pw20_state /sys/devices/system/cpu/cpuX/altivec_idle Set wait time interface:(Nanosecond) /sys/devices/system/cpu/cpuX/pw20_wait_time /sys/devices/system/cpu/cpuX/altivec_idle_wait_time Example: Base on TBfreq is 41MHZ. 1~48(ns): TB[63] 49~97(ns): TB[62] 98~195(ns): TB[61] 196~390(ns): TB[60] 391~780(ns): TB[59] 781~1560(ns): TB[58] ... Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> [scottwood@freescale.com: change ifdef] Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/85xx: add hardware automatically enter pw20 stateWang Dongsheng2014-01-071-0/+21
| | | | | | | | | | | | | | | | | | | | | | Using hardware features make core automatically enter PW20 state. Set a TB count to hardware, the effective count begins when PW10 is entered. When the effective period has expired, the core will proceed from PW10 to PW20 if no exit conditions have occurred during the period. Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/85xx: add hardware automatically enter altivec idle stateWang Dongsheng2014-01-071-0/+21
| | | | | | | | | | | | | | | | | | | | Each core's AltiVec unit may be placed into a power savings mode by turning off power to the unit. Core hardware will automatically power down the AltiVec unit after no AltiVec instructions have executed in N cycles. The AltiVec power-control is triggered by hardware. Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 defineWang Dongsheng2014-01-072-0/+11
| | | | | | | | | | | | | | | | E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec idle patches. Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/sysdev: Fix a pci section mismatch for Book EChristian Engelmayer2014-01-072-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Moved the following functions out of the __init section: arch/powerpc/sysdev/fsl_pci.c : fsl_add_bridge() arch/powerpc/sysdev/indirect_pci.c : setup_indirect_pci() Those are referenced by arch/powerpc/sysdev/fsl_pci.c : fsl_pci_probe() when compiling for Book E support. Signed-off-by: Christian Engelmayer <cengelma@gmx.at> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/p1010rdb-pa: modify phy interrupt.Zhao Qiang2014-01-071-2/+2
| | | | | | | | | | | | | | | | It is not correct according to p1010rdb-pa user guide. So modify it. Signed-off-by: Zhao Qiang <B45475@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc 8xx: defconfig: slice by 4 is more efficient than the default slice ↵LEROY Christophe2014-01-075-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | by 8 on Powerpc 8xx. On PPC_8xx, CRC32_SLICEBY4 is more efficient (almost twice) than CRC32_SLICEBY8, as shown below: With CRC32_SLICEBY8: [ 1.109204] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64 [ 1.114401] crc32: self tests passed, processed 225944 bytes in 15118910 nsec [ 1.130655] crc32c: CRC_LE_BITS = 64 [ 1.134235] crc32c: self tests passed, processed 225944 bytes in 4479879 nsec With CRC32_SLICEBY4: [ 1.097129] crc32: CRC_LE_BITS = 32, CRC_BE BITS = 32 [ 1.101878] crc32: self tests passed, processed 225944 bytes in 8616242 nsec [ 1.116298] crc32c: CRC_LE_BITS = 32 [ 1.119607] crc32c: self tests passed, processed 225944 bytes in 3289576 nsec Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/85xx: Add TWR-P1025 board supportXie Xiaobo2014-01-076-0/+542
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TWR-P1025 Overview ----------------- 512Mbyte DDR3 (on board DDR) 64MB Nor Flash eTSEC1: Connected to RGMII PHY AR8035 eTSEC3: Connected to RGMII PHY AR8035 Two USB2.0 Type A One microSD Card slot One mini-PCIe slot One mini-USB TypeB dual UART Signed-off-by: Michael Johnston <michael.johnston@freescale.com> Signed-off-by: Xie Xiaobo <X.Xie@freescale.com> [scottwood@freescale.com: use pr_info rather than KERN_INFO] Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/85xx: Add QE common init functionXie Xiaobo2014-01-074-50/+48
| | | | | | | | | | | | | | | | Define a QE init function in common file, and avoid the same codes being duplicated in board files. Signed-off-by: Xie Xiaobo <X.Xie@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp and mpc85xxLijun Pan2014-01-073-188/+6
| | | | | | | | | | | | | | | | | | mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/fsl-booke: Use SPRN_SPRGn rather than mfsprg/mtsprgScott Wood2014-01-071-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | This fixes a build break that was probably introduced with the removal of -Wa,-me500 (commit f49596a4cf4753d13951608f24f939a59fdcc653), where the assembler refuses to recognize SPRG4-7 with a generic PPC target. Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Dongsheng Wang <dongsheng.wang@freescale.com> Cc: Anton Vorontsov <avorontsov@mvista.com> Reviewed-by: Wang Dongsheng <dongsheng.wang@freescale.com> Tested-by: Wang Dongsheng <dongsheng.wang@freescale.com>
| * powerpc/85xx: don't init the mpic ipi for the SoC which has doorbell supportKevin Hao2014-01-071-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | It makes no sense to initialize the mpic ipi for the SoC which has doorbell support. So set the smp_85xx_ops.probe to NULL for this case. Since the smp_85xx_ops.probe is also used in function smp_85xx_setup_cpu() to check if we need to invoke mpic_setup_this_cpu(), we introduce a new setup_cpu function smp_85xx_basic_setup() to remove this dependency. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/p1010rdb:update mtd of nand to adapt to both old and new p1010rdbZhao Qiang2014-01-074-65/+88
| | | | | | | | | | | | | | | | | | | | | | | | P1010rdb-pa and p1010rdb-pb have different mtd of nand. So update dts to adapt to both p1010rdb-pa and p1010rdb-pb. Move the nand-mtd from p1010rdb.dtsi to p1010rdb-pa*.dts. Remove nand-mtd for p1010rdb-pb, whick will use mtdparts from u-boot instead of nand-mtd in device tree. Signed-off-by: Zhao Qiang <B45475@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/p1010rdb:update dts to adapt to both old and new p1010rdbZhao Qiang2014-01-078-111/+297
| | | | | | | | | | | | | | | | | | P1010rdb-pa and p1010rdb-pb have different phy interrupts. So update dts to adapt to both p1010rdb-pa and p1010rdb-pb. Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by: Zhao Qiang <B45475@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc: fix e500 SPE float SIGFPE generationJoseph Myers2014-01-071-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The e500 SPE floating-point emulation code is called from SPEFloatingPointException and SPEFloatingPointRoundException in arch/powerpc/kernel/traps.c. Those functions have support for generating SIGFPE, but do_spe_mathemu and speround_handler don't generate a return value to indicate that this should be done. Such a return value should depend on whether an exception is raised that has been set via prctl to generate SIGFPE. This patch adds the relevant logic in these functions so that SIGFPE is generated as expected by the glibc testsuite. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc: fix e500 SPE float to integer and fixed-point conversionsJoseph Myers2014-01-071-75/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The e500 SPE floating-point emulation code has several problems in how it handles conversions to integer and fixed-point fractional types. There are the following 20 relevant instructions. These can convert to signed or unsigned 32-bit integers, either rounding towards zero (as correct for C casts from floating-point to integer) or according to the current rounding mode, or to signed or unsigned 32-bit fixed-point values (values in the range [-1, 1) or [0, 1)). For conversion from double precision there are also instructions to convert to 64-bit integers, rounding towards zero, although as far as I know those instructions are completely theoretical (they are only defined for implementations that support both SPE and classic 64-bit, and I'm not aware of any such hardware even though the architecture definition permits that combination). #define EFSCTUI 0x2d4 #define EFSCTSI 0x2d5 #define EFSCTUF 0x2d6 #define EFSCTSF 0x2d7 #define EFSCTUIZ 0x2d8 #define EFSCTSIZ 0x2da #define EVFSCTUI 0x294 #define EVFSCTSI 0x295 #define EVFSCTUF 0x296 #define EVFSCTSF 0x297 #define EVFSCTUIZ 0x298 #define EVFSCTSIZ 0x29a #define EFDCTUIDZ 0x2ea #define EFDCTSIDZ 0x2eb #define EFDCTUI 0x2f4 #define EFDCTSI 0x2f5 #define EFDCTUF 0x2f6 #define EFDCTSF 0x2f7 #define EFDCTUIZ 0x2f8 #define EFDCTSIZ 0x2fa The emulation code, for the instructions that come in variants rounding either towards zero or according to the current rounding direction, uses "if (func & 0x4)" as a condition for using _FP_ROUND (otherwise _FP_ROUND_ZERO is used). The condition is correct, but the code it controls isn't. Whether _FP_ROUND or _FP_ROUND_ZERO is used makes no difference, as the effect of those soft-fp macros is to round an intermediate floating-point result using the low three bits (the last one sticky) of the working format. As these operations are dealing with a freshly unpacked floating-point input, those low bits are zero and no rounding occurs. The emulation code then uses the FP_TO_INT_* macros for the actual integer conversion, with the effect of always rounding towards zero; for rounding according to the current rounding direction, it should be using FP_TO_INT_ROUND_*. The instructions in question have semantics defined (in the Power ISA documents) for out-of-range values and NaNs: out-of-range values saturate and NaNs are converted to zero. The emulation does nothing to follow those semantics for NaNs (the soft-fp handling is to treat them as infinities), and messes up the saturation semantics. For single-precision conversion to integers, (((func & 0x3) != 0) || SB_s) is the condition used for doing a signed conversion. The first part is correct, but the second isn't: negative numbers should result in saturation to 0 when converted to unsigned. Double-precision conversion to 64-bit integers correctly uses ((func & 0x1) == 0). Double-precision conversion to 32-bit integers uses (((func & 0x3) != 0) || DB_s), with correct first part and incorrect second part. And vector float conversion to integers uses (((func & 0x3) != 0) || SB0_s) (and similar for the other vector element), where the sign bit check is again wrong. The incorrect handling of negative numbers converted to unsigned was introduced in commit afc0a07d4a283599ac3a6a31d7454e9baaeccca0. The rationale given there was a C testcase with cast from float to unsigned int. Conversion of out-of-range floating-point numbers to integer types in C is undefined behavior in the base standard, defined in Annex F to produce an unspecified value. That is, the C testcase used to justify that patch is incorrect - there is no ISO C requirement for a particular value resulting from this conversion - and in any case, the correct semantics for such emulation are the semantics for the instruction (unsigned saturation, which is what it does in hardware when the emulation is disabled). The conversion to fixed-point values has its own problems. That code doesn't try to do a full emulation; it relies on the trap handler only being called for arguments that are infinities, NaNs, subnormal or out of range. That's fine, but the logic ((vb.wp[1] >> 23) == 0xff && ((vb.wp[1] & 0x7fffff) > 0)) for NaN detection won't detect negative NaNs as being NaNs (the same applies for the double-precision case), and subnormals are mapped to 0 rather than respecting the rounding mode; the code should also explicitly raise the "invalid" exception. The code for vectors works by executing the scalar float instruction with the trapping disabled, meaning at least subnormals won't be handled correctly. As well as all those problems in the main emulation code, the rounding handler - used to emulate rounding upward and downward when not supported in hardware and when no higher priority exception occurred - has its own problems. * It gets called in some cases even for the instructions rounding to zero, and then acts according to the current rounding mode when it should just leave alone the truncated result provided by hardware. * It presumes that the result is a single-precision, double-precision or single-precision vector as appropriate for the instruction type, determines the sign of the result accordingly, and then adjusts the result based on that sign and the rounding mode. - In the single-precision cases at least the sign determination for an integer result is the same as for a floating-point result; in the double-precision case, converted to 32-bit integer or fixed point, the sign of a double-precision value is in the high part of the register but it's the low part of the register that has the result of the conversion. - If the result is unsigned fixed-point, its sign may be wrongly determined as negative (does not actually cause problems, because inexact unsigned fixed-point results with the high bit set can only appear when converting from double, in which case the sign determination is instead wrongly using the high part of the register). - If the sign of the result is correctly determined as negative, any adjustment required to change the truncated result to one correct for the rounding mode should be in the opposite direction for two's-complement integers as for sign-magnitude floating-point values. - And if the integer result is zero, the correct sign can only be determined by examining the original operand, and not at all (as far as I can tell) if the operand and result are the same register. This patch fixes all these problems (as far as possible, given the inability to determine the correct sign in the rounding handler when the truncated result is 0, the conversion is to a signed type and the truncated result has overwritten the original operand). Conversion to fixed-point now uses full emulation, and does not use "asm" in the vector case; the semantics are exactly those of converting to integer according to the current rounding direction, once the exponent has been adjusted, so the code makes such an adjustment then uses the FP_TO_INT_ROUND macros. The testcase I used for verifying that the instructions (other than the theoretical conversions to 64-bit integers) produce the correct results is at <http://lkml.org/lkml/2013/10/8/708>. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * math-emu: fix floating-point to integer overflow detectionJoseph Myers2014-01-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On overflow, the math-emu macro _FP_TO_INT_ROUND tries to saturate its result (subject to the value of rsigned specifying the desired overflow semantics). However, if the rounding step has the effect of increasing the exponent so as to cause overflow (if the rounded result is 1 larger than the largest positive value with the given number of bits, allowing for signedness), the overflow does not get detected, meaning that for unsigned results 0 is produced instead of the maximum unsigned integer with the give number of bits, without an exception being raised for overflow, and that for signed results the minimum (negative) value is produced instead of the maximum (positive) value, again without an exception. This patch makes the code check for rounding increasing the exponent and adjusts the exponent value as needed for the overflow check. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * math-emu: fix floating-point to integer unsigned saturationJoseph Myers2014-01-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The math-emu macros _FP_TO_INT and _FP_TO_INT_ROUND are supposed to saturate their results for out-of-range arguments, except in the case rsigned == 2 (when instead the low bits of the result are taken). However, in the case rsigned == 0 (converting to unsigned integers), they mistakenly produce 0 for positive results and the maximum unsigned integer for negative results, the opposite of correct unsigned saturation. This patch fixes the logic. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc: fix e500 SPE float rounding inexactness detectionJoseph Myers2014-01-071-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The e500 SPE floating-point emulation code for the rounding modes rounding to positive or negative infinity (which may not be implemented in hardware) tries to avoid emulating rounding if the result was inexact. However, it tests inexactness using the sticky bit with the cumulative result of previous operations, rather than with the non-sticky bits relating to the operation that generated the interrupt. Furthermore, when a vector operation generates the interrupt, it's possible that only one of the low and high parts is inexact, and so only that part should have rounding emulated. This results in incorrect rounding of exact results in these modes when the sticky bit is set from a previous operation. (I'm not sure why the rounding interrupts are generated at all when the result is exact, but empirically the hardware does generate them.) This patch checks for inexactness using the correct bits of SPEFSCR, and ensures that rounding only occurs when the relevant part of the result was actually inexact. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc: fix exception clearing in e500 SPE float emulationJoseph Myers2014-01-073-4/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The e500 SPE floating-point emulation code clears existing exceptions (__FPU_FPSCR &= ~FP_EX_MASK;) before ORing in the exceptions from the emulated operation. However, these exception bits are the "sticky", cumulative exception bits, and should only be cleared by the user program setting SPEFSCR, not implicitly by any floating-point instruction (whether executed purely by the hardware or emulated). The spurious clearing of these bits shows up as missing exceptions in glibc testing. Fixing this, however, is not as simple as just not clearing the bits, because while the bits may be from previous floating-point operations (in which case they should not be cleared), the processor can also set the sticky bits itself before the interrupt for an exception occurs, and this can happen in cases when IEEE 754 semantics are that the sticky bit should not be set. Specifically, the "invalid" sticky bit is set in various cases with non-finite operands, where IEEE 754 semantics do not involve raising such an exception, and the "underflow" sticky bit is set in cases of exact underflow, whereas IEEE 754 semantics are that this flag is set only for inexact underflow. Thus, for correct emulation the kernel needs to know the setting of these two sticky bits before the instruction being emulated. When a floating-point operation raises an exception, the kernel can note the state of the sticky bits immediately afterwards. Some <fenv.h> functions that affect the state of these bits, such as fesetenv and feholdexcept, need to use prctl with PR_GET_FPEXC and PR_SET_FPEXC anyway, and so it is natural to record the state of those bits during that call into the kernel and so avoid any need for a separate call into the kernel to inform it of a change to those bits. Thus, the interface I chose to use (in this patch and the glibc port) is that one of those prctl calls must be made after any userspace change to those sticky bits, other than through a floating-point operation that traps into the kernel anyway. feclearexcept and fesetexceptflag duly make those calls, which would not be required were it not for this issue. The previous EGLIBC port, and the uClibc code copied from it, is fundamentally broken as regards any use of prctl for floating-point exceptions because it didn't use the PR_FP_EXC_SW_ENABLE bit in its prctl calls (and did various worse things, such as passing a pointer when prctl expected an integer). If you avoid anything where prctl is used, the clearing of sticky bits still means it will never give anything approximating correct exception semantics with existing kernels. I don't believe the patch makes things any worse for existing code that doesn't try to inform the kernel of changes to sticky bits - such code may get incorrect exceptions in some cases, but it would have done so anyway in other cases. Signed-off-by: Joseph Myers <joseph@codesourcery.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
| * powerpc/booke64: Add LRAT error exception handlerMihai Caraman2014-01-075-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | LRAT (Logical to Real Address Translation) present in MMU v2 provides hardware translation from a logical page number (LPN) to a real page number (RPN) when tlbwe is executed by a guest or when a page table translation occurs from a guest virtual address. Add LRAT error exception handler to Booke3E 64-bit kernel and the basic KVM handler to avoid build breakage. This is a prerequisite for KVM LRAT support that will follow. Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
* | powerpc: Fix transactional FP/VMX/VSX unavailable handlersPaul Mackerras2014-01-151-9/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, if a process starts a transaction and then takes an exception because the FPU, VMX or VSX unit is unavailable to it, we end up corrupting any FP/VMX/VSX state that was valid before the interrupt. For example, if the process starts a transaction with the FPU available to it but VMX unavailable, and then does a VMX instruction inside the transaction, the FP state gets corrupted. Loading up the desired state generally involves doing a reclaim and a recheckpoint. To avoid corrupting already-valid state, we have to be careful not to reload that state from the thread_struct between the reclaim and the recheckpoint (since the thread_struct values are stale by now), and we have to reload that state from the transact_fp/vr arrays after the recheckpoint to get back the current transactional values saved there by the reclaim. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* | powerpc: Don't corrupt transactional state when using FP/VMX in kernelPaul Mackerras2014-01-1511-47/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, when we have a process using the transactional memory facilities on POWER8 (that is, the processor is in transactional or suspended state), and the process enters the kernel and the kernel then uses the floating-point or vector (VMX/Altivec) facility, we end up corrupting the user-visible FP/VMX/VSX state. This happens, for example, if a page fault causes a copy-on-write operation, because the copy_page function will use VMX to do the copy on POWER8. The test program below demonstrates the bug. The bug happens because when FP/VMX state for a transactional process is stored in the thread_struct, we store the checkpointed state in .fp_state/.vr_state and the transactional (current) state in .transact_fp/.transact_vr. However, when the kernel wants to use FP/VMX, it calls enable_kernel_fp() or enable_kernel_altivec(), which saves the current state in .fp_state/.vr_state. Furthermore, when we return to the user process we return with FP/VMX/VSX disabled. The next time the process uses FP/VMX/VSX, we don't know which set of state (the current register values, .fp_state/.vr_state, or .transact_fp/.transact_vr) we should be using, since we have no way to tell if we are still in the same transaction, and if not, whether the previous transaction succeeded or failed. Thus it is necessary to strictly adhere to the rule that if FP has been enabled at any point in a transaction, we must keep FP enabled for the user process with the current transactional state in the FP registers, until we detect that it is no longer in a transaction. Similarly for VMX; once enabled it must stay enabled until the process is no longer transactional. In order to keep this rule, we add a new thread_info flag which we test when returning from the kernel to userspace, called TIF_RESTORE_TM. This flag indicates that there is FP/VMX/VSX state to be restored before entering userspace, and when it is set the .tm_orig_msr field in the thread_struct indicates what state needs to be restored. The restoration is done by restore_tm_state(). The TIF_RESTORE_TM bit is set by new giveup_fpu/altivec_maybe_transactional helpers, which are called from enable_kernel_fp/altivec, giveup_vsx, and flush_fp/altivec_to_thread instead of giveup_fpu/altivec. The other thing to be done is to get the transactional FP/VMX/VSX state from .fp_state/.vr_state when doing reclaim, if that state has been saved there by giveup_fpu/altivec_maybe_transactional. Having done this, we set the FP/VMX bit in the thread's MSR after reclaim to indicate that that part of the state is now valid (having been reclaimed from the processor's checkpointed state). Finally, in the signal handling code, we move the clearing of the transactional state bits in the thread's MSR a bit earlier, before calling flush_fp_to_thread(), so that we don't unnecessarily set the TIF_RESTORE_TM bit. This is the test program: /* Michael Neuling 4/12/2013 * * See if the altivec state is leaked out of an aborted transaction due to * kernel vmx copy loops. * * gcc -m64 htm_vmxcopy.c -o htm_vmxcopy * */ /* We don't use all of these, but for reference: */ int main(int argc, char *argv[]) { long double vecin = 1.3; long double vecout; unsigned long pgsize = getpagesize(); int i; int fd; int size = pgsize*16; char tmpfile[] = "/tmp/page_faultXXXXXX"; char buf[pgsize]; char *a; uint64_t aborted = 0; fd = mkstemp(tmpfile); assert(fd >= 0); memset(buf, 0, pgsize); for (i = 0; i < size; i += pgsize) assert(write(fd, buf, pgsize) == pgsize); unlink(tmpfile); a = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0); assert(a != MAP_FAILED); asm __volatile__( "lxvd2x 40,0,%[vecinptr] ; " // set 40 to initial value TBEGIN "beq 3f ;" TSUSPEND "xxlxor 40,40,40 ; " // set 40 to 0 "std 5, 0(%[map]) ;" // cause kernel vmx copy page TABORT TRESUME TEND "li %[res], 0 ;" "b 5f ;" "3: ;" // Abort handler "li %[res], 1 ;" "5: ;" "stxvd2x 40,0,%[vecoutptr] ; " : [res]"=r"(aborted) : [vecinptr]"r"(&vecin), [vecoutptr]"r"(&vecout), [map]"r"(a) : "memory", "r0", "r3", "r4", "r5", "r6", "r7"); if (aborted && (vecin != vecout)){ printf("FAILED: vector state leaked on abort %f != %f\n", (double)vecin, (double)vecout); exit(1); } munmap(a, size); close(fd); printf("PASSED!\n"); return 0; } Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-10 05:29:44 +0000