Skip to contentSkip to conversation

driver/ddr/fsl: Force enabling parity for A-009803

PATCH New Shengzhou Liu 2 participants 6 messages May 20, 2016 – May 24, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 driver/ddr/fsl: Force enabling parity for A-009803

Default address parity is disabled for DDR4 UDIMM for considing performance, it needs to enable parity for A-009803 workaround.

---
 drivers/ddr/fsl/options.c | 3 +++
 1 file changed, 3 insertions(+)
drivers/ddr/fsl/options.c +3 -0
index d0075ff..dcef0bb 100644
@@ -1016,6 +1016,9 @@ unsigned int populate_memctl_options(const common_timing_params_t *common_dimm,
 		}
 	}
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009803
+	popts->ap_en = 1;
+#endif
 	/*
 	 * BSTTOPRE precharge interval
 	 *
Signature · 1 line
2.1.0.27.g96db324
#1 lore raw

PATCH 1/1 driver/ddr/fsl: Force enabling parity for A-009803

Quoted 14 lines · Shengzhou Liu

Default address parity is disabled for DDR4 UDIMM for considing performance, it needs to enable parity for A-009803 workaround.

---
 drivers/ddr/fsl/options.c | 3 +++
 1 file changed, 3 insertions(+)
drivers/ddr/fsl/options.c +0 -0
index d0075ff..dcef0bb 100644

drivers/ddr/fsl/options.c unsigned int populate_memctl_options(const common_timing_params_t *common_dimm, · line 1024

Quoted 9 lines
drivers/ddr/fsl/options.c +3 -0
@@ -1016,6 +1016,9 @@ unsigned int populate_memctl_options(const common_timing_params_t *common_dimm,
 		}
 	}
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009803
+	popts->ap_en = 1;
+#endif
 	/*
 	 * BSTTOPRE precharge interval
 	 *

Shengzhou,

It looks backward. You should detect if the condition is right before applying the workaround, not by forcing the condition.

York

#2 lore raw

PATCH 1/1 driver/ddr/fsl: Force enabling parity for A-009803

Quoted 7 lines

-----Original Message-----
From: York Sun [mailto:york.sun at nxp.com]
Sent: Friday, May 20, 2016 11:29 PM
To: Shengzhou Liu <[email protected]>; u-boot at lists.denx.de
Subject: Re: [PATCH] driver/ddr/fsl: Force enabling parity for A-009803

Quoted 1 line
Quoted 6 lines

Shengzhou,

It looks backward. You should detect if the condition is right before applying the workaround, not by forcing the condition.

York

If ERRATUM_A009803 is defined, ap_en should always be enabled whatever user configures parity=on in hwconfig. As ERRATUM_A009803 is enabled only in arch-fsl-layerscape/config.h for LS2 SoC, I don't think we need to check anything other. What condition do you mean?

-Shengzhou

#3 lore raw

PATCH 1/1 driver/ddr/fsl: Force enabling parity for A-009803

Quoted 9 lines · Shengzhou Liu
Quoted 9 lines

-----Original Message-----
From: York Sun [mailto:york.sun at nxp.com]
Sent: Friday, May 20, 2016 11:29 PM
To: Shengzhou Liu <[email protected]>; u-boot at lists.denx.de
Subject: Re: [PATCH] driver/ddr/fsl: Force enabling parity for A-009803

Quoted 1 line

Shengzhou,

Quoted 9 lines
Quoted 4 lines

It looks backward. You should detect if the condition is right before applying the workaround, not by forcing the condition.

York

If ERRATUM_A009803 is defined, ap_en should always be enabled whatever user configures parity=on in hwconfig. As ERRATUM_A009803 is enabled only in arch-fsl-layerscape/config.h for LS2 SoC, I don't think we need to check anything other. What condition do you mean?

Shengzhou,

My point is you should force ap=1. Do you mean if ERRATUM_A009803 is enabled, users are forced to use address parity? That doesn't sound right. We have been running UDIMM without address parity for a long time.

York

#4 lore raw

PATCH 1/1 driver/ddr/fsl: Force enabling parity for A-009803

Quoted 8 lines

-----Original Message-----
From: York Sun [mailto:york.sun at nxp.com]
Sent: Monday, May 23, 2016 11:33 PM
To: Shengzhou Liu <[email protected]>; u-boot at lists.denx.de
Subject: Re: [PATCH] driver/ddr/fsl: Force enabling parity for A-009803 Shengzhou,

Quoted 6 lines

My point is you should force ap=1. Do you mean if ERRATUM_A009803 is enabled, users are forced to use address parity? That doesn't sound right. We have been running UDIMM without address parity for a long time.

York

York,
My understanding is that ERRATUM_A009803 may still happen whatever ap_en is enabled or disabled. To apply the workaround of A009803, it requires ap_en is enabled. Is your understanding that if we disable ap_en, ERRATUM_A009803 will never happen? The CE document doesn't explain clearly this. In last mail, did you mean we should force ap_en = 0 in case of A-009803?

Shengzhou

#5 lore raw

PATCH 1/1 driver/ddr/fsl: Force enabling parity for A-009803

Quoted 12 lines · Shengzhou Liu
Quoted 12 lines

-----Original Message-----
From: York Sun [mailto:york.sun at nxp.com]
Sent: Monday, May 23, 2016 11:33 PM
To: Shengzhou Liu <[email protected]>; u-boot at lists.denx.de
Subject: Re: [PATCH] driver/ddr/fsl: Force enabling parity for A-009803 Shengzhou,

My point is you should force ap=1. Do you mean if ERRATUM_A009803 is enabled, users are forced to use address parity? That doesn't sound right. We have been running UDIMM without address parity for a long time.

Quoted 8 lines
Quoted 2 lines

York

York,
My understanding is that ERRATUM_A009803 may still happen whatever ap_en is enabled or disabled. To apply the workaround of A009803, it requires ap_en is enabled. Is your understanding that if we disable ap_en, ERRATUM_A009803 will never happen? The CE document doesn't explain clearly this. In last mail, did you mean we should force ap_en = 0 in case of A-009803?

Sorry I had a typo. I meant you should NOT force ap=1. Let me explain. The erratum tells you _if_ address parity is used, for either UDIMM or RDIMM, you need to implement the workaround, as step 1, 2, 3, ... We understand users don't have a choice for RDIMM, the address parity is always enabled. But for UDIMM, users can choose not to enable it. Your _this_ patch forces the address parity to be true, regardless of user's choice. I think this is wrong.

The erratum always applies to affected SoCs, but the address parity is not always enabled. That's what I meant for "condition".

York