From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Tue, 24 May 2016 09:13:06 -0700 Subject: [U-Boot] [PATCH] driver/ddr/fsl: Force enabling parity for A-009803 In-Reply-To: References: <1463731546-15232-1-git-send-email-Shengzhou.Liu@nxp.com> <573F2D49.9050102@nxp.com> <574322B7.1030508@nxp.com> Message-ID: <57447D92.4060303@nxp.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 05/23/2016 10:15 PM, Shengzhou Liu wrote: > >> -----Original Message----- >> From: York Sun [mailto:york.sun at nxp.com] >> Sent: Monday, May 23, 2016 11:33 PM >> To: Shengzhou Liu ; 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. >> >> 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