From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Date: Thu, 27 Dec 2018 16:09:06 -0600 Subject: [PATCH 2/2] dt-bindings: edac: Aspeed AST2500 In-Reply-To: <1545026517-64069-3-git-send-email-schaecsn@gmx.net> References: <1545026517-64069-1-git-send-email-schaecsn@gmx.net> <1545026517-64069-3-git-send-email-schaecsn@gmx.net> Message-ID: <20181227220906.GA14320@bogus> List-Id: To: linux-aspeed@lists.ozlabs.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, Dec 16, 2018 at 10:01:57PM -0800, Stefan Schaeckeler wrote: > From: Stefan M Schaeckeler > > Add support for the Aspeed AST2500 SoC EDAC driver. > > Signed-off-by: Stefan M Schaeckeler > --- > .../bindings/edac/aspeed-sdram-edac.txt | 34 +++++++++++++++++++ > 1 file changed, 34 insertions(+) > create mode 100644 Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > > diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > new file mode 100644 > index 000000000000..57ba852883c7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > @@ -0,0 +1,34 @@ > +Aspeed AST2500 SoC EDAC device driver Bindings are for h/w, not drivers > + > +The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC (error > +correction check). > + > +The memory controller supports SECDED (single bit error correction, double bit > +error detection) and single bit error auto scrubbing by reserving 8 bits for > +every 64 bit word (effectively reducing available memory to 8/9). > + > +First, ECC must be configured in u-boot. Then, this driver will expose error > +counters via the edac kernel framework. Please reword this to not be u-boot or kernel specific. Maybe this node is enabled in the bootloader or the OS can just read the registers to see if ECC is enabled. The latter is more future proof if you need to access the DDR ctrl registers for other reasons. > + > +A note on memory organization in ECC mode: every 512 bytes are followed by 64 > +bytes of ECC codes. That sounds strange. Normally, the memory would be 72-bits wide to hold the ECC byte for each 64-bit chunk. It would be inefficient to access the ECC byte in a discontiguous location. In any case, none of this is really important for the binding. > The address remapping is done in hardware and is fully > +transparent to firmware and software. Because of this, ECC mode must be > +configured in u-boot as part of the memory initialization as one can not switch > +from one mode to another when executing in memory. > + > + > + > +Required properties: > +- compatible: should be "aspeed,ast2500-sdram-edac" > +- reg: sdram controller register set should be <0x1e6e0000 0x174> > +- interrupts: should be AVIC interrupt #0 > + > + > +Example: > + > + edac: sdram at 1e6e0000 { > + compatible = "aspeed,ast2500-sdram-edac"; > + reg = <0x1e6e0000 0x174>; > + interrupts = <0>; > + status = "okay"; Don't show status in examples. > + }; > -- > 2.19.1 > From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [2/2] dt-bindings: edac: Aspeed AST2500 From: Rob Herring Message-Id: <20181227220906.GA14320@bogus> Date: Thu, 27 Dec 2018 16:09:06 -0600 To: Stefan Schaeckeler Cc: Mark Rutland , Joel Stanley , Andrew Jeffery , Borislav Petkov , Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-edac@vger.kernel.org, Stefan M Schaeckeler List-ID: T24gU3VuLCBEZWMgMTYsIDIwMTggYXQgMTA6MDE6NTdQTSAtMDgwMCwgU3RlZmFuIFNjaGFlY2tl bGVyIHdyb3RlOgo+IEZyb206IFN0ZWZhbiBNIFNjaGFlY2tlbGVyIDxzc2NoYWVja0BjaXNjby5j b20+Cj4gCj4gQWRkIHN1cHBvcnQgZm9yIHRoZSBBc3BlZWQgQVNUMjUwMCBTb0MgRURBQyBkcml2 ZXIuCj4gCj4gU2lnbmVkLW9mZi1ieTogU3RlZmFuIE0gU2NoYWVja2VsZXIgPHNzY2hhZWNrQGNp c2NvLmNvbT4KPiAtLS0KPiAgLi4uL2JpbmRpbmdzL2VkYWMvYXNwZWVkLXNkcmFtLWVkYWMudHh0 ICAgICAgIHwgMzQgKysrKysrKysrKysrKysrKysrKwo+ICAxIGZpbGUgY2hhbmdlZCwgMzQgaW5z ZXJ0aW9ucygrKQo+ICBjcmVhdGUgbW9kZSAxMDA2NDQgRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVl L2JpbmRpbmdzL2VkYWMvYXNwZWVkLXNkcmFtLWVkYWMudHh0Cj4gCj4gZGlmZiAtLWdpdCBhL0Rv Y3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9lZGFjL2FzcGVlZC1zZHJhbS1lZGFjLnR4 dCBiL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9lZGFjL2FzcGVlZC1zZHJhbS1l ZGFjLnR4dAo+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0Cj4gaW5kZXggMDAwMDAwMDAwMDAwLi41N2Jh ODUyODgzYzcKPiAtLS0gL2Rldi9udWxsCj4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVl L2JpbmRpbmdzL2VkYWMvYXNwZWVkLXNkcmFtLWVkYWMudHh0Cj4gQEAgLTAsMCArMSwzNCBAQAo+ ICtBc3BlZWQgQVNUMjUwMCBTb0MgRURBQyBkZXZpY2UgZHJpdmVyCgpCaW5kaW5ncyBhcmUgZm9y IGgvdywgbm90IGRyaXZlcnMKCj4gKwo+ICtUaGUgQXNwZWVkIEFTVDI1MDAgU29DIHN1cHBvcnRz IEREUjMgYW5kIEREUjQgbWVtb3J5IHdpdGggYW5kIHdpdGhvdXQgRUNDIChlcnJvcgo+ICtjb3Jy ZWN0aW9uIGNoZWNrKS4KPiArCj4gK1RoZSBtZW1vcnkgY29udHJvbGxlciBzdXBwb3J0cyBTRUNE RUQgKHNpbmdsZSBiaXQgZXJyb3IgY29ycmVjdGlvbiwgZG91YmxlIGJpdAo+ICtlcnJvciBkZXRl Y3Rpb24pIGFuZCBzaW5nbGUgYml0IGVycm9yIGF1dG8gc2NydWJiaW5nIGJ5IHJlc2VydmluZyA4 IGJpdHMgZm9yCj4gK2V2ZXJ5IDY0IGJpdCB3b3JkIChlZmZlY3RpdmVseSByZWR1Y2luZyBhdmFp bGFibGUgbWVtb3J5IHRvIDgvOSkuCj4gKwo+ICtGaXJzdCwgRUNDIG11c3QgYmUgY29uZmlndXJl ZCBpbiB1LWJvb3QuIFRoZW4sIHRoaXMgZHJpdmVyIHdpbGwgZXhwb3NlIGVycm9yCj4gK2NvdW50 ZXJzIHZpYSB0aGUgZWRhYyBrZXJuZWwgZnJhbWV3b3JrLgoKUGxlYXNlIHJld29yZCB0aGlzIHRv IG5vdCBiZSB1LWJvb3Qgb3Iga2VybmVsIHNwZWNpZmljLgoKTWF5YmUgdGhpcyBub2RlIGlzIGVu YWJsZWQgaW4gdGhlIGJvb3Rsb2FkZXIgb3IgdGhlIE9TIGNhbiBqdXN0IHJlYWQgdGhlIApyZWdp c3RlcnMgdG8gc2VlIGlmIEVDQyBpcyBlbmFibGVkLiBUaGUgbGF0dGVyIGlzIG1vcmUgZnV0dXJl IHByb29mIGlmIAp5b3UgbmVlZCB0byBhY2Nlc3MgdGhlIEREUiBjdHJsIHJlZ2lzdGVycyBmb3Ig b3RoZXIgcmVhc29ucy4KCj4gKwo+ICtBIG5vdGUgb24gbWVtb3J5IG9yZ2FuaXphdGlvbiBpbiBF Q0MgbW9kZTogZXZlcnkgNTEyIGJ5dGVzIGFyZSBmb2xsb3dlZCBieSA2NAo+ICtieXRlcyBvZiBF Q0MgY29kZXMuIAoKVGhhdCBzb3VuZHMgc3RyYW5nZS4gTm9ybWFsbHksIHRoZSBtZW1vcnkgd291 bGQgYmUgNzItYml0cyB3aWRlIHRvIGhvbGQgCnRoZSBFQ0MgYnl0ZSBmb3IgZWFjaCA2NC1iaXQg Y2h1bmsuIEl0IHdvdWxkIGJlIGluZWZmaWNpZW50IHRvIGFjY2VzcyAKdGhlIEVDQyBieXRlIGlu IGEgZGlzY29udGlndW91cyBsb2NhdGlvbi4gSW4gYW55IGNhc2UsIG5vbmUgb2YgdGhpcyBpcyAK cmVhbGx5IGltcG9ydGFudCBmb3IgdGhlIGJpbmRpbmcuCgo+IFRoZSBhZGRyZXNzIHJlbWFwcGlu ZyBpcyBkb25lIGluIGhhcmR3YXJlIGFuZCBpcyBmdWxseQo+ICt0cmFuc3BhcmVudCB0byBmaXJt d2FyZSBhbmQgc29mdHdhcmUuIEJlY2F1c2Ugb2YgdGhpcywgRUNDIG1vZGUgbXVzdCBiZQo+ICtj b25maWd1cmVkIGluIHUtYm9vdCBhcyBwYXJ0IG9mIHRoZSBtZW1vcnkgaW5pdGlhbGl6YXRpb24g YXMgb25lIGNhbiBub3Qgc3dpdGNoCj4gK2Zyb20gb25lIG1vZGUgdG8gYW5vdGhlciB3aGVuIGV4 ZWN1dGluZyBpbiBtZW1vcnkuCj4gKwo+ICsKPiArCj4gK1JlcXVpcmVkIHByb3BlcnRpZXM6Cj4g Ky0gY29tcGF0aWJsZTogc2hvdWxkIGJlICJhc3BlZWQsYXN0MjUwMC1zZHJhbS1lZGFjIgo+ICst IHJlZzogICAgICAgIHNkcmFtIGNvbnRyb2xsZXIgcmVnaXN0ZXIgc2V0IHNob3VsZCBiZSA8MHgx ZTZlMDAwMCAweDE3ND4KPiArLSBpbnRlcnJ1cHRzOiBzaG91bGQgYmUgQVZJQyBpbnRlcnJ1cHQg IzAKPiArCj4gKwo+ICtFeGFtcGxlOgo+ICsKPiArCWVkYWM6IHNkcmFtQDFlNmUwMDAwIHsKPiAr CQljb21wYXRpYmxlID0gImFzcGVlZCxhc3QyNTAwLXNkcmFtLWVkYWMiOwo+ICsJCXJlZyA9IDww eDFlNmUwMDAwIDB4MTc0PjsKPiArCQlpbnRlcnJ1cHRzID0gPDA+Owo+ICsJCXN0YXR1cyA9ICJv a2F5IjsKCkRvbid0IHNob3cgc3RhdHVzIGluIGV4YW1wbGVzLgoKPiArCX07Cj4gLS0gCj4gMi4x OS4xCj4K From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58618C43387 for ; Thu, 27 Dec 2018 22:09:27 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2703520811 for ; Thu, 27 Dec 2018 22:09:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Ezoz00H9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2703520811 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2hzWWc18wz2ys0ArlRj8e80pTGESGr+aZnC4H/055Tk=; b=Ezoz00H9svIYnN 3ZXv9dLZi7AoBSpMoZd2nVlUNjrh9rB35pAlpHZfiTON9n60igBNBeHgM8/z74HwgzavWjDx7dm1n Ufp/YTUTg1N7lfpIMxojzS2u/d0NDyegGSPwRlt9Z8Fn2X0t4NKlEKUym+TTcJG7KpJvzuWSX5n4o aYkeeYLEnJtYuz4E/bSr9dVweWVWOpZLVQHp0MEBA/wSBMV3oZGwbFsE7ECcxclmX5BdM3Vt/O7PZ VB/v+IX5x3SsHcywyt6G96qi6GyluoIi82d0om3t4292VInOp6VvtJKlXDKgI22f9mV6LF24afWcd nmpteGYgws906TIMM75Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gcdqH-0000AT-K2; Thu, 27 Dec 2018 22:09:25 +0000 Received: from mail-it1-f193.google.com ([209.85.166.193]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gcdqD-00006I-Kq for linux-arm-kernel@lists.infradead.org; Thu, 27 Dec 2018 22:09:23 +0000 Received: by mail-it1-f193.google.com with SMTP id z7so26246651iti.0 for ; Thu, 27 Dec 2018 14:09:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Z2ZjfZha2uDoYBpSDCAZu8yTreOdNaRPpM3WOoiacdw=; b=ARRftbcpB9/HHIQnUSN9ylktSV1+g13wziCCEpT+FgfWwmJ4Y6uYgfRyCYYHnoZ2ZJ 8gOxxMK3dMkqny1+xnu/XXmnlnO6Ir/uL34w6zVUndqZI7x7ngFYzSPuMb62rPLNMkND t8CViGGuVExaMgFjFOZ0rnxHmdJFNpLuez6Ow4MI3slff0K/HRG99Jga2ckdKWIveaFD 6XKWTKekScXX1KDqKKRaPGZANq6iPEWI2mM+OtysObiMAWxOxUu6NQ9QubZYLTiasUK8 Tc+Y8FJItUSaYMBrw57fHppKrvaaua7oVxwi9zPpkCWNLyGrJMR8lxuNNfH/Xhf6sfrx IcsQ== X-Gm-Message-State: AA+aEWbZmzM7kcMrapUqhc3JZLPIo81pF7GtF74F+hOdC3FKguch+hD6 v0hlKZpZsrCynmusp2zvMA== X-Google-Smtp-Source: AFSGD/WKyXgNIL/5HZwFM6AqatrUjH1FRad+dRfOLMCaelaT95BP9DbsEO9dL393oo8xCsPHyIRQfw== X-Received: by 2002:a02:b70c:: with SMTP id g12mr16228757jam.60.1545948548150; Thu, 27 Dec 2018 14:09:08 -0800 (PST) Received: from localhost ([24.51.61.172]) by smtp.gmail.com with ESMTPSA id w3sm349102ior.28.2018.12.27.14.09.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 27 Dec 2018 14:09:07 -0800 (PST) Date: Thu, 27 Dec 2018 16:09:06 -0600 From: Rob Herring To: Stefan Schaeckeler Subject: Re: [PATCH 2/2] dt-bindings: edac: Aspeed AST2500 Message-ID: <20181227220906.GA14320@bogus> References: <1545026517-64069-1-git-send-email-schaecsn@gmx.net> <1545026517-64069-3-git-send-email-schaecsn@gmx.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1545026517-64069-3-git-send-email-schaecsn@gmx.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20181227_140921_685885_B3790003 X-CRM114-Status: GOOD ( 24.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, linux-aspeed@lists.ozlabs.org, Andrew Jeffery , linux-kernel@vger.kernel.org, Borislav Petkov , Joel Stanley , Stefan M Schaeckeler , Mauro Carvalho Chehab , linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Dec 16, 2018 at 10:01:57PM -0800, Stefan Schaeckeler wrote: > From: Stefan M Schaeckeler > > Add support for the Aspeed AST2500 SoC EDAC driver. > > Signed-off-by: Stefan M Schaeckeler > --- > .../bindings/edac/aspeed-sdram-edac.txt | 34 +++++++++++++++++++ > 1 file changed, 34 insertions(+) > create mode 100644 Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > > diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > new file mode 100644 > index 000000000000..57ba852883c7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > @@ -0,0 +1,34 @@ > +Aspeed AST2500 SoC EDAC device driver Bindings are for h/w, not drivers > + > +The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC (error > +correction check). > + > +The memory controller supports SECDED (single bit error correction, double bit > +error detection) and single bit error auto scrubbing by reserving 8 bits for > +every 64 bit word (effectively reducing available memory to 8/9). > + > +First, ECC must be configured in u-boot. Then, this driver will expose error > +counters via the edac kernel framework. Please reword this to not be u-boot or kernel specific. Maybe this node is enabled in the bootloader or the OS can just read the registers to see if ECC is enabled. The latter is more future proof if you need to access the DDR ctrl registers for other reasons. > + > +A note on memory organization in ECC mode: every 512 bytes are followed by 64 > +bytes of ECC codes. That sounds strange. Normally, the memory would be 72-bits wide to hold the ECC byte for each 64-bit chunk. It would be inefficient to access the ECC byte in a discontiguous location. In any case, none of this is really important for the binding. > The address remapping is done in hardware and is fully > +transparent to firmware and software. Because of this, ECC mode must be > +configured in u-boot as part of the memory initialization as one can not switch > +from one mode to another when executing in memory. > + > + > + > +Required properties: > +- compatible: should be "aspeed,ast2500-sdram-edac" > +- reg: sdram controller register set should be <0x1e6e0000 0x174> > +- interrupts: should be AVIC interrupt #0 > + > + > +Example: > + > + edac: sdram@1e6e0000 { > + compatible = "aspeed,ast2500-sdram-edac"; > + reg = <0x1e6e0000 0x174>; > + interrupts = <0>; > + status = "okay"; Don't show status in examples. > + }; > -- > 2.19.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH 2/2] dt-bindings: edac: Aspeed AST2500 Date: Thu, 27 Dec 2018 16:09:06 -0600 Message-ID: <20181227220906.GA14320@bogus> References: <1545026517-64069-1-git-send-email-schaecsn@gmx.net> <1545026517-64069-3-git-send-email-schaecsn@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1545026517-64069-3-git-send-email-schaecsn@gmx.net> Sender: linux-kernel-owner@vger.kernel.org To: Stefan Schaeckeler Cc: Mark Rutland , Joel Stanley , Andrew Jeffery , Borislav Petkov , Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-edac@vger.kernel.org, Stefan M Schaeckeler List-Id: devicetree@vger.kernel.org On Sun, Dec 16, 2018 at 10:01:57PM -0800, Stefan Schaeckeler wrote: > From: Stefan M Schaeckeler > > Add support for the Aspeed AST2500 SoC EDAC driver. > > Signed-off-by: Stefan M Schaeckeler > --- > .../bindings/edac/aspeed-sdram-edac.txt | 34 +++++++++++++++++++ > 1 file changed, 34 insertions(+) > create mode 100644 Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > > diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > new file mode 100644 > index 000000000000..57ba852883c7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > @@ -0,0 +1,34 @@ > +Aspeed AST2500 SoC EDAC device driver Bindings are for h/w, not drivers > + > +The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC (error > +correction check). > + > +The memory controller supports SECDED (single bit error correction, double bit > +error detection) and single bit error auto scrubbing by reserving 8 bits for > +every 64 bit word (effectively reducing available memory to 8/9). > + > +First, ECC must be configured in u-boot. Then, this driver will expose error > +counters via the edac kernel framework. Please reword this to not be u-boot or kernel specific. Maybe this node is enabled in the bootloader or the OS can just read the registers to see if ECC is enabled. The latter is more future proof if you need to access the DDR ctrl registers for other reasons. > + > +A note on memory organization in ECC mode: every 512 bytes are followed by 64 > +bytes of ECC codes. That sounds strange. Normally, the memory would be 72-bits wide to hold the ECC byte for each 64-bit chunk. It would be inefficient to access the ECC byte in a discontiguous location. In any case, none of this is really important for the binding. > The address remapping is done in hardware and is fully > +transparent to firmware and software. Because of this, ECC mode must be > +configured in u-boot as part of the memory initialization as one can not switch > +from one mode to another when executing in memory. > + > + > + > +Required properties: > +- compatible: should be "aspeed,ast2500-sdram-edac" > +- reg: sdram controller register set should be <0x1e6e0000 0x174> > +- interrupts: should be AVIC interrupt #0 > + > + > +Example: > + > + edac: sdram@1e6e0000 { > + compatible = "aspeed,ast2500-sdram-edac"; > + reg = <0x1e6e0000 0x174>; > + interrupts = <0>; > + status = "okay"; Don't show status in examples. > + }; > -- > 2.19.1 >