From: chenhui zhao <redacted>
The workarounds need to detect the cpu type. Add these macros
and inline routines to help cpu type detection in runtime.
Signed-off-by: Zhao Chenhui <redacted>
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/include/asm/mpc85xx.h | 72 ++++++++++++++++++++++++++++++++++++
1 files changed, 72 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/mpc85xx.h
From: chenhui zhao <redacted>
Issue:
As a master, the PCI IP block can combine a memory write to the last PCI double
word (4 bytes) of a cacheline with a 4 byte memory write to the first PCI double
word of the subsequent cacheline. This affects 32-bit PCI target devices that
blindly assert STOP on memory-write transactions, without detecting that the
data beat being transferred is the last data beat of the transaction. It can
cause a hang. PCI-X operation is not affected by this erratum.
Workaround:
Setting the bit MDS in the PCI Bus Function Register will disable the combining
of crossing cacheline boundary requests into one burst transaction. Therefore,
it can prevent the errata scenario from occurring.
Refer to PCI 5 in MPC8548 errata document.
Signed-off-by: Gong Chen <redacted>
Signed-off-by: Zhao Chenhui <redacted>
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/sysdev/fsl_pci.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
From: chenhui zhao <redacted>
Issue:
The register bits ERR_DR[OWMSV] and ERR_DR[ORMSV] can erroneously set and
may trigger an interrupt if capturing and reporting of these events are enabled.
Workaround:
Disable OWMSV, ORMSV error capture and disable OWMSV, ORMSV error reporting.
Do not affect the functionality of the controller when the checking is disabled.
Refer to PCI 6 in MPC8548 errata document.
Signed-off-by: Zhao Chenhui <redacted>
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/sysdev/fsl_pci.c | 16 ++++++++++++
arch/powerpc/sysdev/fsl_pci.h | 53 ++++++++++++++++++++++++++++++++++-------
2 files changed, 60 insertions(+), 9 deletions(-)
From: chenhui zhao <redacted>
Issue:
Applications using lwarx/stwcx instructions in the core to
compete for a software lock or semaphore with a device on
RapidIO using read atomic set, clr, inc, or dec in a similar
manner may falsely result in both masters seeing the lock
as "available". This could result in data corruption as
both masters try to modify the same piece of data protected
by the lock.
Workaround:
Set bits 13 and 29 of CCSR offset 0x01010 (EEBPCR register
of the ECM) during initialization and leave them set
indefinitely. This may slightly degrade overall system
performance.
Refer to SRIO39 in MPC8548 errata document.
Signed-off-by: Gong Chen <redacted>
Signed-off-by: Zhao Chenhui <redacted>
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/sysdev/fsl_rio.c | 44 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
@@ -358,6 +391,17 @@ int fsl_rio_setup(struct platform_device *dev)dev->dev.of_node->full_name);return-EFAULT;}++/* Fix erratum NMG_SRIO135 */+if(fsl_svr_is(SVR_8548)||fsl_svr_is(SVR_8548_E)){+rc=fixup_erratum_srio135(&dev->dev);+if(rc){+dev_err(&dev->dev,+"Failed to fix the erratum NMG_SRIO135.");+returnrc;+}+}+dev_info(&dev->dev,"Of-device full name %s\n",dev->dev.of_node->full_name);dev_info(&dev->dev,"Regs: %pR\n",®s);
From: David Laight <hidden> Date: 2012-03-06 09:57:24
=20
Issue:
Applications using lwarx/stwcx instructions in the core to
compete for a software lock or semaphore with a device on
RapidIO using read atomic set, clr, inc, or dec in a similar
manner may falsely result in both masters seeing the lock
as "available". This could result in data corruption as
both masters try to modify the same piece of data protected
by the lock.
=20
Workaround:
Set bits 13 and 29 of CCSR offset 0x01010 (EEBPCR register
of the ECM) during initialization and leave them set
indefinitely. This may slightly degrade overall system
performance.
Might be worth actually saying what these bits do, and
why/when overall performance is affected.
Is the problem trying to do locked read-write cycles
on a slow peripheral bus?
Might be a case for just 'not doing that'.
David
From: Scott Wood <hidden> Date: 2013-06-03 23:58:43
On Mon, Mar 05, 2012 at 11:10:53PM -0000, chenhui zhao wrote:
quoted hunk
From: chenhui zhao <redacted>
The workarounds need to detect the cpu type. Add these macros
and inline routines to help cpu type detection in runtime.
Signed-off-by: Zhao Chenhui <redacted>
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/include/asm/mpc85xx.h | 72 ++++++++++++++++++++++++++++++++++++
1 files changed, 72 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/mpc85xx.h
fsl_svr_is() and IS_SVR_REV() are confusingly similar, and the
upper/lower difference and word-order difference is jarring. I'm not
sure why you even need fsl_svr_is. This file is obviously patterned
after U-Boot code, but U-Boot doesn't have this. Why can't the caller do
the equality check?
quoted hunk
+/* Return true if current SOC revision is prior to (maj, min) */+static inline int fsl_svr_older_than(u8 maj, u8 min)+{+ u32 rev = SVR_REV(mfspr(SPRN_SVR));+ u32 cmp = (maj << 4) | min;++ return (rev < cmp);+}
Is this that much easier than the caller doing:
if (SVR_REV(svr) < 0x20)
?
-Scott
From: Scott Wood <hidden> Date: 2013-10-16 23:20:12
On Tue, Mar 06, 2012 at 05:10:56PM +0800, chenhui zhao wrote:
From: chenhui zhao <redacted>
Issue:
Applications using lwarx/stwcx instructions in the core to
compete for a software lock or semaphore with a device on
RapidIO using read atomic set, clr, inc, or dec in a similar
manner may falsely result in both masters seeing the lock
as "available". This could result in data corruption as
both masters try to modify the same piece of data protected
by the lock.
Workaround:
Set bits 13 and 29 of CCSR offset 0x01010 (EEBPCR register
of the ECM) during initialization and leave them set
indefinitely. This may slightly degrade overall system
performance.
Refer to SRIO39 in MPC8548 errata document.
Signed-off-by: Gong Chen <redacted>
Signed-off-by: Zhao Chenhui <redacted>
Signed-off-by: Li Yang <redacted>
---
arch/powerpc/sysdev/fsl_rio.c | 44 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
[snip]
quoted hunk
@@ -358,6 +391,17 @@ int fsl_rio_setup(struct platform_device *dev) dev->dev.of_node->full_name); return -EFAULT; }++ /* Fix erratum NMG_SRIO135 */+ if (fsl_svr_is(SVR_8548) || fsl_svr_is(SVR_8548_E)) {+ rc = fixup_erratum_srio135(&dev->dev);+ if (rc) {+ dev_err(&dev->dev,+ "Failed to fix the erratum NMG_SRIO135.");+ return rc;+ }+ }
This needs to be respun based on the current tree.
-Scott
=0A=
OK. I will do.=0A=
=0A=
-Chenhui=0A=
=0A=
________________________________________=0A=
From: Wood Scott-B07421=0A=
Sent: Thursday, October 17, 2013 7:20=0A=
To: Zhao Chenhui-B35336=0A=
Cc: linuxppc-dev@lists.ozlabs.org=0A=
Subject: Re: [4/4] powerpc/mpc8548: Add workaround for erratum NMG_SRIO135=
=0A=
=0A=
On Tue, Mar 06, 2012 at 05:10:56PM +0800, chenhui zhao wrote:=0A=
From: chenhui zhao <redacted>=0A=
=0A=
Issue:=0A=
Applications using lwarx/stwcx instructions in the core to=0A=
compete for a software lock or semaphore with a device on=0A=
RapidIO using read atomic set, clr, inc, or dec in a similar=0A=
manner may falsely result in both masters seeing the lock=0A=
as "available". This could result in data corruption as=0A=
both masters try to modify the same piece of data protected=0A=
by the lock.=0A=
=0A=
Workaround:=0A=
Set bits 13 and 29 of CCSR offset 0x01010 (EEBPCR register=0A=
of the ECM) during initialization and leave them set=0A=
indefinitely. This may slightly degrade overall system=0A=
performance.=0A=
=0A=
Refer to SRIO39 in MPC8548 errata document.=0A=
=0A=
Signed-off-by: Gong Chen <redacted>=0A=
Signed-off-by: Zhao Chenhui <redacted>=0A=
Signed-off-by: Li Yang <redacted>=0A=
=0A=
---=0A=
arch/powerpc/sysdev/fsl_rio.c | 44 ++++++++++++++++++++++++++++++++++++=