From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753873AbdFVVnN (ORCPT ); Thu, 22 Jun 2017 17:43:13 -0400 Received: from gate2.alliedtelesis.co.nz ([202.36.163.20]:59608 "EHLO gate2.alliedtelesis.co.nz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753379AbdFVVnM (ORCPT ); Thu, 22 Jun 2017 17:43:12 -0400 From: Chris Packham To: =?iso-8859-1?Q?Jan_L=FCbbe?= CC: "bp@alien8.de" , "linux-arm-kernel@lists.infradead.org" , "linux-edac@vger.kernel.org" , Mauro Carvalho Chehab , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 1/4] EDAC: mvebu: Add driver for Marvell Armada SoCs Thread-Topic: [RFC PATCH 1/4] EDAC: mvebu: Add driver for Marvell Armada SoCs Thread-Index: AQHS4A1SaAGhpKz8JUKL1XuS2Mm6yg== Date: Thu, 22 Jun 2017 21:43:05 +0000 Message-ID: <36d9010c9f3f45f2a2bfeda3c0cc2716@svr-chch-ex1.atlnz.lc> References: <20170608041124.4624-1-chris.packham@alliedtelesis.co.nz> <20170608041124.4624-2-chris.packham@alliedtelesis.co.nz> <1497014062.3536.52.camel@pengutronix.de> <1498140695.2533.76.camel@pengutronix.de> Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:df5:b000:22:17d:b43b:e662:49e3] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v5MLhIax013926 On 23/06/17 02:37, Jan Lübbe wrote: > Hi Chris, > > On Fr, 2017-06-09 at 15:14 +0200, Jan Lübbe wrote: >>> +static void mvebu_init_csrows(struct mem_ctl_info *mci, >>> + struct mvebu_mc_pdata *pdata) >> [...] >>> + devtype = (ctl >> 20) & 0x3; >>> + switch (devtype) { >>> + case 0x0: >>> + dimm->dtype = DEV_X32; >>> + break; >>> + case 0x2: /* could be X8 too, but no way to tell >> */ >>> + dimm->dtype = DEV_X16; >>> + break; >>> + case 0x3: >>> + dimm->dtype = DEV_X4; >>> + break; >>> + default: >>> + dimm->dtype = DEV_UNKNOWN; >>> + break; >>> + } >> This register is documented as reserved? I pulled the X8/X16 >> information from the Address Control Register (CSnStruct bits). > > Do you have more information on how to decode the Bus width? > > It's not clear from the MV78230/78x60 docs: > - The SDRAM Configuration Register, offset 15 bit is: > 0 = Half (32 bit data bus) > 1 = Full (64 bit data bus) For the integrated version it still is just half and full but half == 16 and full == 32. > - The SDRAM Address Control Register, offsets 0-1, 4-5, 8-9 and 12-13 > (for CS 0, 1, 3 and 4): > 0 = X8 > 1 = X16 > 2 and 3 are not documented This definition is the same for the integrated version. > Is this clearer in your documentation, so that we can have the same code > handle both variants? Otherwise, we'd probably need separate DT > compatibles. I think we do need to use the compatible string to decide how to interpret full/half. 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: [RFC,1/4] EDAC: mvebu: Add driver for Marvell Armada SoCs From: Chris Packham Message-Id: <36d9010c9f3f45f2a2bfeda3c0cc2716@svr-chch-ex1.atlnz.lc> Date: Thu, 22 Jun 2017 21:43:05 +0000 To: =?iso-8859-1?Q?Jan_L=FCbbe?= Cc: "bp@alien8.de" , "linux-arm-kernel@lists.infradead.org" , "linux-edac@vger.kernel.org" , Mauro Carvalho Chehab , "linux-kernel@vger.kernel.org" List-ID: T24gMjMvMDYvMTcgMDI6MzcsIEphbiBMw7xiYmUgd3JvdGU6Cj4gSGkgQ2hyaXMsCj4gCj4gT24g RnIsIDIwMTctMDYtMDkgYXQgMTU6MTQgKzAyMDAsIEphbiBMw7xiYmUgd3JvdGU6Cj4+PiArc3Rh dGljIHZvaWQgbXZlYnVfaW5pdF9jc3Jvd3Moc3RydWN0IG1lbV9jdGxfaW5mbyAqbWNpLAo+Pj4g KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IG12ZWJ1X21jX3BkYXRhICpwZGF0 YSkKPj4gWy4uLl0KPj4+ICsgICAgIGRldnR5cGUgPSAoY3RsID4+IDIwKSAmIDB4MzsKPj4+ICsg ICAgIHN3aXRjaCAoZGV2dHlwZSkgewo+Pj4gKyAgICAgY2FzZSAweDA6Cj4+PiArICAgICAgICAg ICAgIGRpbW0tPmR0eXBlID0gREVWX1gzMjsKPj4+ICsgICAgICAgICAgICAgYnJlYWs7Cj4+PiAr ICAgICBjYXNlIDB4MjogICAgICAgICAgICAgICAvKiBjb3VsZCBiZSBYOCB0b28sIGJ1dCBubyB3 YXkgdG8gdGVsbAo+PiAqLwo+Pj4gKyAgICAgICAgICAgICBkaW1tLT5kdHlwZSA9IERFVl9YMTY7 Cj4+PiArICAgICAgICAgICAgIGJyZWFrOwo+Pj4gKyAgICAgY2FzZSAweDM6Cj4+PiArICAgICAg ICAgICAgIGRpbW0tPmR0eXBlID0gREVWX1g0Owo+Pj4gKyAgICAgICAgICAgICBicmVhazsKPj4+ ICsgICAgIGRlZmF1bHQ6Cj4+PiArICAgICAgICAgICAgIGRpbW0tPmR0eXBlID0gREVWX1VOS05P V047Cj4+PiArICAgICAgICAgICAgIGJyZWFrOwo+Pj4gKyAgICAgfQo+PiBUaGlzIHJlZ2lzdGVy IGlzIGRvY3VtZW50ZWQgYXMgcmVzZXJ2ZWQ/IEkgcHVsbGVkIHRoZSBYOC9YMTYKPj4gaW5mb3Jt YXRpb24gZnJvbSB0aGUgQWRkcmVzcyBDb250cm9sIFJlZ2lzdGVyIChDU25TdHJ1Y3QgYml0cyku Cj4gCj4gRG8geW91IGhhdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cgdG8gZGVjb2RlIHRoZSBC dXMgd2lkdGg/Cj4gCj4gSXQncyBub3QgY2xlYXIgZnJvbSB0aGUgTVY3ODIzMC83OHg2MCBkb2Nz Ogo+IC0gVGhlIFNEUkFNIENvbmZpZ3VyYXRpb24gUmVnaXN0ZXIsIG9mZnNldCAxNSBiaXQgaXM6 Cj4gICAgMCA9IEhhbGYgKDMyIGJpdCBkYXRhIGJ1cykKPiAgICAxID0gRnVsbCAoNjQgYml0IGRh dGEgYnVzKQoKRm9yIHRoZSBpbnRlZ3JhdGVkIHZlcnNpb24gaXQgc3RpbGwgaXMganVzdCBoYWxm IGFuZCBmdWxsIGJ1dCBoYWxmID09IDE2IAphbmQgZnVsbCA9PSAzMi4KCj4gLSBUaGUgU0RSQU0g QWRkcmVzcyBDb250cm9sIFJlZ2lzdGVyLCBvZmZzZXRzIDAtMSwgNC01LCA4LTkgYW5kIDEyLTEz Cj4gKGZvciBDUyAwLCAxLCAzIGFuZCA0KToKPiAgICAwID0gWDgKPiAgICAxID0gWDE2Cj4gICAg MiBhbmQgMyBhcmUgbm90IGRvY3VtZW50ZWQKClRoaXMgZGVmaW5pdGlvbiBpcyB0aGUgc2FtZSBm b3IgdGhlIGludGVncmF0ZWQgdmVyc2lvbi4KCj4gSXMgdGhpcyBjbGVhcmVyIGluIHlvdXIgZG9j dW1lbnRhdGlvbiwgc28gdGhhdCB3ZSBjYW4gaGF2ZSB0aGUgc2FtZSBjb2RlCj4gaGFuZGxlIGJv dGggdmFyaWFudHM/IE90aGVyd2lzZSwgd2UnZCBwcm9iYWJseSBuZWVkIHNlcGFyYXRlIERUCj4g Y29tcGF0aWJsZXMuCgpJIHRoaW5rIHdlIGRvIG5lZWQgdG8gdXNlIHRoZSBjb21wYXRpYmxlIHN0 cmluZyB0byBkZWNpZGUgaG93IHRvIAppbnRlcnByZXQgZnVsbC9oYWxmLgotLS0KVG8gdW5zdWJz Y3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LWVk YWMiIGluCnRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3Jn Ck1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21v LWluZm8uaHRtbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris.Packham@alliedtelesis.co.nz (Chris Packham) Date: Thu, 22 Jun 2017 21:43:05 +0000 Subject: [RFC PATCH 1/4] EDAC: mvebu: Add driver for Marvell Armada SoCs References: <20170608041124.4624-1-chris.packham@alliedtelesis.co.nz> <20170608041124.4624-2-chris.packham@alliedtelesis.co.nz> <1497014062.3536.52.camel@pengutronix.de> <1498140695.2533.76.camel@pengutronix.de> Message-ID: <36d9010c9f3f45f2a2bfeda3c0cc2716@svr-chch-ex1.atlnz.lc> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 23/06/17 02:37, Jan L?bbe wrote: > Hi Chris, > > On Fr, 2017-06-09 at 15:14 +0200, Jan L?bbe wrote: >>> +static void mvebu_init_csrows(struct mem_ctl_info *mci, >>> + struct mvebu_mc_pdata *pdata) >> [...] >>> + devtype = (ctl >> 20) & 0x3; >>> + switch (devtype) { >>> + case 0x0: >>> + dimm->dtype = DEV_X32; >>> + break; >>> + case 0x2: /* could be X8 too, but no way to tell >> */ >>> + dimm->dtype = DEV_X16; >>> + break; >>> + case 0x3: >>> + dimm->dtype = DEV_X4; >>> + break; >>> + default: >>> + dimm->dtype = DEV_UNKNOWN; >>> + break; >>> + } >> This register is documented as reserved? I pulled the X8/X16 >> information from the Address Control Register (CSnStruct bits). > > Do you have more information on how to decode the Bus width? > > It's not clear from the MV78230/78x60 docs: > - The SDRAM Configuration Register, offset 15 bit is: > 0 = Half (32 bit data bus) > 1 = Full (64 bit data bus) For the integrated version it still is just half and full but half == 16 and full == 32. > - The SDRAM Address Control Register, offsets 0-1, 4-5, 8-9 and 12-13 > (for CS 0, 1, 3 and 4): > 0 = X8 > 1 = X16 > 2 and 3 are not documented This definition is the same for the integrated version. > Is this clearer in your documentation, so that we can have the same code > handle both variants? Otherwise, we'd probably need separate DT > compatibles. I think we do need to use the compatible string to decide how to interpret full/half.