From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Borislav Petkov <bp@amd64.org>
Cc: "Shaohui Xie" <Shaohui.Xie@freescale.com>,
"Jason Uhlenkott" <juhlenko@akamai.com>,
"Hitoshi Mitake" <h.mitake@gmail.com>,
"Mark Gross" <mark.gross@intel.com>,
"Dmitry Eremin-Solenikov" <dbaryshkov@gmail.com>,
"Ranganathan Desikan" <ravi@jetztechnologies.com>,
"Egor Martovetsky" <egor@pasemi.com>,
"Niklas Söderlund" <niklas.soderlund@ericsson.com>,
"Tim Small" <tim@buttersideup.com>,
"Arvind R." <arvino55@gmail.com>,
"Chris Metcalf" <cmetcalf@tilera.com>,
"Olof Johansson" <olof@lixom.net>,
"Doug Thompson" <norsk5@yahoo.com>,
"Linux Edac Mailing List" <linux-edac@vger.kernel.org>,
"Michal Marek" <mmarek@suse.cz>, "Jiri Kosina" <jkosina@suse.cz>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Joe Perches" <joe@perches.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
Date: Tue, 17 Apr 2012 16:28:49 -0300 [thread overview]
Message-ID: <4F8DC471.3050809@redhat.com> (raw)
In-Reply-To: <20120417184808.GD13989@aftab>
Em 17-04-2012 15:48, Borislav Petkov escreveu:
> On Mon, Apr 16, 2012 at 05:12:10PM -0300, Mauro Carvalho Chehab wrote:
>> The number of pages is a dimm property. Move it to the dimm struct.
>>
>> After this change, it is possible to add sysfs nodes for the DIMM's that
>
> Minor nitpick:
>
> DIMMs
>
> Please go over the rest of the commit messages because they have similar
> typos.
>
>> will properly represent the DIMM stick properties, including its size.
>>
>> A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
>> the memory controller represents the memory via chip select rows.
>>
>> Reviewed-by: Aristeu Rozanski <arozansk@redhat.com>
>> Cc: Doug Thompson <norsk5@yahoo.com>
>> Cc: Borislav Petkov <borislav.petkov@amd.com>
>> Cc: Mark Gross <mark.gross@intel.com>
>> Cc: Jason Uhlenkott <juhlenko@akamai.com>
>> Cc: Tim Small <tim@buttersideup.com>
>> Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
>> Cc: "Arvind R." <arvino55@gmail.com>
>> Cc: Olof Johansson <olof@lixom.net>
>> Cc: Egor Martovetsky <egor@pasemi.com>
>> Cc: Chris Metcalf <cmetcalf@tilera.com>
>> Cc: Michal Marek <mmarek@suse.cz>
>> Cc: Jiri Kosina <jkosina@suse.cz>
>> Cc: Joe Perches <joe@perches.com>
>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Hitoshi Mitake <h.mitake@gmail.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
>> Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
>> Cc: Josh Boyer <jwboyer@gmail.com>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>> ---
>> drivers/edac/amd64_edac.c | 12 +++------
>> drivers/edac/amd76x_edac.c | 6 ++--
>> drivers/edac/cell_edac.c | 8 ++++--
>> drivers/edac/cpc925_edac.c | 8 ++++--
>> drivers/edac/e752x_edac.c | 6 +++-
>> drivers/edac/e7xxx_edac.c | 5 ++-
>> drivers/edac/edac_mc.c | 16 ++++++++-----
>> drivers/edac/edac_mc_sysfs.c | 47 ++++++++++++++++++++++++++++------------
>> drivers/edac/i3000_edac.c | 6 +++-
>> drivers/edac/i3200_edac.c | 3 +-
>> drivers/edac/i5000_edac.c | 14 ++++++-----
>> drivers/edac/i5100_edac.c | 22 +++++++++++-------
>> drivers/edac/i5400_edac.c | 9 ++-----
>> drivers/edac/i7300_edac.c | 22 +++++-------------
>> drivers/edac/i7core_edac.c | 10 ++------
>> drivers/edac/i82443bxgx_edac.c | 2 +-
>> drivers/edac/i82860_edac.c | 2 +-
>> drivers/edac/i82875p_edac.c | 5 ++-
>> drivers/edac/i82975x_edac.c | 11 ++++++--
>> drivers/edac/mpc85xx_edac.c | 3 +-
>> drivers/edac/mv64x60_edac.c | 3 +-
>> drivers/edac/pasemi_edac.c | 14 ++++++------
>> drivers/edac/ppc4xx_edac.c | 5 ++-
>> drivers/edac/r82600_edac.c | 3 +-
>> drivers/edac/sb_edac.c | 8 +-----
>> drivers/edac/tile_edac.c | 2 +-
>> drivers/edac/x38_edac.c | 4 +-
>> include/linux/edac.h | 8 ++++--
>> 28 files changed, 144 insertions(+), 120 deletions(-)
>>
>> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
>> index 0be3f29..8804ac8 100644
>> --- a/drivers/edac/amd64_edac.c
>> +++ b/drivers/edac/amd64_edac.c
>> @@ -2126,12 +2126,6 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
>>
>> nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
>>
>> - /*
>> - * If dual channel then double the memory size of single channel.
>> - * Channel count is 1 or 2
>> - */
>> - nr_pages <<= (pvt->channel_count - 1);
>
> This changes DEBUG output from:
>
> EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
> EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
> EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 1048576 channel-count = 2
> EDAC amd64: CS0: Registered DDR3 RAM
> EDAC DEBUG: init_csrows: for MC node 0 csrow 0:
> EDAC DEBUG: init_csrows: nr_pages: 1048576
>
> to
>
> EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
> EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
> EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 524288 channel-count = 2
>
> which is only half the pages.
>
>> -
>> debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
>> debugf0(" nr_pages= %u channel-count = %d\n",
>> nr_pages, pvt->channel_count);
Ok. well, we can either multiply nr_pages by channel_count or to let it
clear that this is per channel. I prefer the last option (see the enclosed
patch).
>> @@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
>> int i, j, empty = 1;
>> enum mem_type mtype;
>> enum edac_type edac_mode;
>> + int nr_pages;
>>
>> amd64_read_pci_cfg(pvt->F3, NBCFG, &val);
>>
>> @@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
>> i, pvt->mc_node_id);
>>
>> empty = 0;
>> - csrow->nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
>> + nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
>> get_cs_base_and_mask(pvt, i, 0, &base, &mask);
>> /* 8 bytes of resolution */
>>
>> mtype = amd64_determine_memory_type(pvt, i);
>>
>> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
>> - debugf1(" nr_pages: %u\n", csrow->nr_pages);
>> + debugf1(" nr_pages: %u\n", nr_pages);
>>
>> /*
>> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
>> @@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
>> for (j = 0; j < pvt->channel_count; j++) {
>> csrow->channels[j].dimm->mtype = mtype;
>> csrow->channels[j].dimm->edac_mode = edac_mode;
>> + csrow->channels[j].dimm->nr_pages = nr_pages;
>
> I'm guessing you want to accumulate the nr_pages for all channels here
> and dump it properly?
>
As you've requested to not move the debugf0() to be after the loop, it is
easier to just multiply it at the printk. As an advantage, when the kernel
is compiled without debug, no code will be produced.
IMO, the best way to solve it is with this small patch. If you're ok, I'll
fold it with this one and add your ack.
Regards,
Mauro
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 8804ac8..6d6ec68 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2127,7 +2127,7 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
- debugf0(" nr_pages= %u channel-count = %d\n",
+ debugf0(" nr_pages/channel= %u channel-count = %d\n",
nr_pages, pvt->channel_count);
return nr_pages;
@@ -2176,7 +2176,7 @@ static int init_csrows(struct mem_ctl_info *mci)
mtype = amd64_determine_memory_type(pvt, i);
debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
- debugf1(" nr_pages: %u\n", nr_pages);
+ debugf1(" nr_pages: %u\n", nr_pages * pvt->channel_count);
/*
* determine whether CHIPKILL or JUST ECC or NO ECC is operating
next prev parent reply other threads:[~2012-04-17 19:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1333039546-5590-1-git-send-email-mchehab@redhat.com>
[not found] ` <1334607133-30039-1-git-send-email-mchehab@redhat.com>
2012-04-16 20:12 ` [EDAC PATCH v13 2/7] edac: move dimm properties to struct dimm_info Mauro Carvalho Chehab
2012-04-26 14:26 ` Borislav Petkov
2012-04-16 20:12 ` [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct Mauro Carvalho Chehab
2012-04-17 18:48 ` Borislav Petkov
2012-04-17 19:28 ` Mauro Carvalho Chehab [this message]
2012-04-17 21:40 ` Borislav Petkov
2012-04-18 12:58 ` Mauro Carvalho Chehab
2012-04-18 17:53 ` [PATCH] " Mauro Carvalho Chehab
2012-04-16 20:12 ` [EDAC PATCH v13 7/7] edac: Change internal representation to work with layers Mauro Carvalho Chehab
2012-04-18 18:22 ` [PATCH] " Mauro Carvalho Chehab
[not found] ` <1334607705-30320-1-git-send-email-mchehab@redhat.com>
2012-04-16 20:21 ` [EDAC_ABI PATCH v13 20/26] pasemi_edac: convert driver to use the new edac ABI Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F8DC471.3050809@redhat.com \
--to=mchehab@redhat.com \
--cc=Shaohui.Xie@freescale.com \
--cc=akpm@linux-foundation.org \
--cc=arvino55@gmail.com \
--cc=bp@amd64.org \
--cc=cmetcalf@tilera.com \
--cc=dbaryshkov@gmail.com \
--cc=egor@pasemi.com \
--cc=h.mitake@gmail.com \
--cc=jkosina@suse.cz \
--cc=joe@perches.com \
--cc=juhlenko@akamai.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.gross@intel.com \
--cc=mmarek@suse.cz \
--cc=niklas.soderlund@ericsson.com \
--cc=norsk5@yahoo.com \
--cc=olof@lixom.net \
--cc=ravi@jetztechnologies.com \
--cc=tim@buttersideup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).