Skip to content

L
linux
Switch branch/tag
  1. 10 Jan, 2014 4 commits
  3. 09 Jan, 2014 20 commits
  5. 08 Jan, 2014 16 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
    • 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7