1. 10 Jan, 2014 5 commits
    • Diana Craciun's avatar
      powerpc: Replaced tlbilx with tlbwe in the initialization code · ed2ddc56
      Diana Craciun authored
      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: default avatarDiana Craciun <Diana.Craciun@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      ed2ddc56
    • Scott Wood's avatar
      powerpc/booke-64: fix tlbsrx. path in bolted tlb handler · 1149e8a7
      Scott Wood authored
      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: default avatarScott Wood <scottwood@freescale.com>
      1149e8a7
    • Paul Gortmaker's avatar
      powerpc: fix 8xx and 6xx final link failures · 78f3d050
      Paul Gortmaker authored
      As of commit b81f18e5 ("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: b81f18e5 ("powerpc/boot: Only build board support files when required.")
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      78f3d050
    • Shaohui Xie's avatar
      powerpc/85xx: handle the eLBC error interrupt if it exists in dts · a655f724
      Shaohui Xie authored
      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: default avatarShaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: default avatarWang Dongsheng <dongsheng.wang@freescale.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      [scottwood@freescale.com: reworded commit message and fixed author]
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      a655f724
    • Wang Dongsheng's avatar
      powerpc/dts: fix lbc lack of error interrupt · 297649b9
      Wang Dongsheng authored
      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: default avatarWang Dongsheng <dongsheng.wang@freescale.com>
      [scottwood@freescale.com: bracketed individual list elements]
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      297649b9
  2. 09 Jan, 2014 20 commits
  3. 08 Jan, 2014 15 commits
    • Wang Dongsheng's avatar
      powerpc/85xx: add hardware automatically enter pw20 state · 1d47ddf7
      Wang Dongsheng authored
      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: default avatarWang Dongsheng <dongsheng.wang@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      1d47ddf7
    • Wang Dongsheng's avatar
      powerpc/85xx: add hardware automatically enter altivec idle state · 202e059c
      Wang Dongsheng authored
      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: default avatarWang Dongsheng <dongsheng.wang@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      202e059c
    • Wang Dongsheng's avatar
      powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define · 71a6fa17
      Wang Dongsheng authored
      E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec
      idle patches.
      Signed-off-by: default avatarWang Dongsheng <dongsheng.wang@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      71a6fa17
    • Christian Engelmayer's avatar
      powerpc/sysdev: Fix a pci section mismatch for Book E · 1e83bf87
      Christian Engelmayer authored
      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: default avatarChristian Engelmayer <cengelma@gmx.at>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      1e83bf87
    • Zhao Qiang's avatar
      powerpc/p1010rdb-pa: modify phy interrupt. · 8b523128
      Zhao Qiang authored
      It is not correct according to p1010rdb-pa user guide.
      So modify it.
      Signed-off-by: default avatarZhao Qiang <B45475@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      8b523128
    • LEROY Christophe's avatar
      powerpc 8xx: defconfig: slice by 4 is more efficient than the default slice by 8 on Powerpc 8xx. · 18904698
      LEROY Christophe authored
      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: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      18904698
    • Xie Xiaobo's avatar
      powerpc/85xx: Add TWR-P1025 board support · 8a6be2bd
      Xie Xiaobo authored
      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: default avatarMichael Johnston <michael.johnston@freescale.com>
      Signed-off-by: default avatarXie Xiaobo <X.Xie@freescale.com>
      [scottwood@freescale.com: use pr_info rather than KERN_INFO]
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      8a6be2bd
    • Xie Xiaobo's avatar
      powerpc/85xx: Add QE common init function · 72c916ae
      Xie Xiaobo authored
      Define a QE init function in common file, and avoid
      the same codes being duplicated in board files.
      Signed-off-by: default avatarXie Xiaobo <X.Xie@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      72c916ae
    • Lijun Pan's avatar
      powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp and mpc85xx · 3d73eb69
      Lijun Pan authored
      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: default avatarLijun Pan <Lijun.Pan@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      3d73eb69
    • Scott Wood's avatar
      powerpc/fsl-booke: Use SPRN_SPRGn rather than mfsprg/mtsprg · b58a7bd6
      Scott Wood authored
      This fixes a build break that was probably introduced with the removal
      of -Wa,-me500 (commit f49596a4), where
      the assembler refuses to recognize SPRG4-7 with a generic PPC target.
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      Cc: Dongsheng Wang <dongsheng.wang@freescale.com>
      Cc: Anton Vorontsov <avorontsov@mvista.com>
      Reviewed-by: default avatarWang Dongsheng <dongsheng.wang@freescale.com>
      Tested-by: default avatarWang Dongsheng <dongsheng.wang@freescale.com>
      b58a7bd6
    • Kevin Hao's avatar
      powerpc/85xx: don't init the mpic ipi for the SoC which has doorbell support · 455d23a8
      Kevin Hao authored
      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: default avatarKevin Hao <haokexin@gmail.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      455d23a8
    • Zhao Qiang's avatar
      powerpc/p1010rdb:update mtd of nand to adapt to both old and new p1010rdb · 0ff649ca
      Zhao Qiang authored
      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: default avatarZhao Qiang <B45475@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      0ff649ca
    • Zhao Qiang's avatar
      powerpc/p1010rdb:update dts to adapt to both old and new p1010rdb · 9667a364
      Zhao Qiang authored
      P1010rdb-pa and p1010rdb-pb have different phy interrupts.
      So update dts to adapt to both p1010rdb-pa and p1010rdb-pb.
      Signed-off-by: default avatarShengzhou Liu <Shengzhou.Liu@freescale.com>
      Signed-off-by: default avatarZhao Qiang <B45475@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      9667a364
    • Joseph Myers's avatar
      powerpc: fix e500 SPE float SIGFPE generation · 01c9ccee
      Joseph Myers authored
      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: default avatarJoseph Myers <joseph@codesourcery.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      01c9ccee
    • Joseph Myers's avatar
      powerpc: fix e500 SPE float to integer and fixed-point conversions · 28fbf1d5
      Joseph Myers authored
      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 afc0a07d.  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: default avatarJoseph Myers <joseph@codesourcery.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      28fbf1d5