1. 08 Jan, 2014 8 commits
    • 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
    • Joseph Myers's avatar
      math-emu: fix floating-point to integer overflow detection · d06b3326
      Joseph Myers authored
      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: default avatarJoseph Myers <joseph@codesourcery.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      d06b3326
    • Joseph Myers's avatar
      math-emu: fix floating-point to integer unsigned saturation · 4f6db5ef
      Joseph Myers authored
      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: default avatarJoseph Myers <joseph@codesourcery.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      4f6db5ef
    • Joseph Myers's avatar
      powerpc: fix e500 SPE float rounding inexactness detection · 28414a6d
      Joseph Myers authored
      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: default avatarJoseph Myers <joseph@codesourcery.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      28414a6d
    • Joseph Myers's avatar
      powerpc: fix exception clearing in e500 SPE float emulation · 640e9225
      Joseph Myers authored
      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: default avatarJoseph Myers <joseph@codesourcery.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      640e9225
    • Mihai Caraman's avatar
      powerpc/booke64: Add LRAT error exception handler · 228b1a47
      Mihai Caraman authored
      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: default avatarMihai Caraman <mihai.caraman@freescale.com>
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      228b1a47
  2. 30 Dec, 2013 15 commits
  3. 20 Dec, 2013 1 commit
  4. 18 Dec, 2013 1 commit
    • Gerhard Sittig's avatar
      powerpc/512x: dts: remove misplaced IRQ spec from 'soc' node (5125) · bbca4d39
      Gerhard Sittig authored
      the 'soc' node in the MPC5125 "tower" board .dts has an '#interrupt-cells'
      property although this node is not an interrupt controller
      
      remove this erroneously placed property because starting with v3.13-rc1
      lookup and resolution of 'interrupts' specs for peripherals gets misled
      (tries to use the 'soc' as the interrupt parent which fails), emits
      'no irq domain found' WARN() messages and breaks the boot process
      
      [ best viewed with 'git diff -U5' to have DT node names in the context ]
      
      Cc: Anatolij Gustschin <agust@denx.de>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarGerhard Sittig <gsi@denx.de>
      Signed-off-by: default avatarAnatolij Gustschin <agust@denx.de>
      bbca4d39
  5. 13 Dec, 2013 10 commits
  6. 10 Dec, 2013 5 commits