public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <borislav.petkov@amd.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: greg@kroah.com, linux-kernel@vger.kernel.org, dougthompson@xmission.com
Subject: Re: [PATCH 02/21] amd64_edac: add driver structs
Date: Tue, 28 Apr 2009 21:02:49 +0200	[thread overview]
Message-ID: <20090428190249.GA2215@aftab> (raw)
In-Reply-To: <20090428111349.d7a6a770.akpm@linux-foundation.org>

On Tue, Apr 28, 2009 at 11:13:49AM -0700, Andrew Morton wrote:
> On Tue, 28 Apr 2009 17:05:54 +0200
> Borislav Petkov <borislav.petkov@amd.com> wrote:
> 
> > From: Doug Thompson <dougthompson@xmission.com>
> > 
> > Signed-off-by: Doug Thompson <dougthompson@xmission.com>
> > Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
> >
> > ...
> >
> > +/**
> > + * popcnt - count the set bits in a bit vector.
> > + * @vec - bit vector
> > + *
> > + * This instruction is supported only on F10h and later CPUs.
> > + */
> > +#define popcnt(x)						\
> > +({								\
> > +	typeof(x) __ret;					\
> > +	__asm__("popcnt %1, %0" : "=r" (__ret) : "r" (x));	\
> > +	__ret;							\
> > +})
> 
> We kinda already have this, in bitmap_weight().  Your popcnt() looks
> more efficient.
> 
> I'm scratching my head at the types.  I'd have thought that I could do
> 
> 	char foo[32];
> 	int n;
> 	...
> 	n = popcnt(foo);
> 
> but obviosuly not, because a) popcnt() doesn't take a length argumetn
> and b) returning a char* is silly.
> 
> Some of this would be clearer if popcnt() wasn't implemented as a sucky
> macro.
> 
> <googles the popcnt instruction>
> 
> hm, it seems to operate on a 64-bit operand.  You just reinvented
> hweight64()?

Yep, exactly. However, this is done in hardware and thus faster.
Actually, popcnt operates on 16, 32 and 64 bit reg/mem operands, here
are the mnemonics:

Mnemonic                  Opcode       Description
POPCNT   reg16, reg/mem16  F3 0F B8 /r  Count the 1s in reg/mem16.
POPCNT   reg32, reg/mem32  F3 0F B8 /r  Count the 1s in reg/mem32.
POPCNT   reg64, reg/mem64  F3 0F B8 /r  Count the 1s in reg/mem64.

> Still, returning the same type as the input argument seems peculiar.

and the destination operand has the same width as the source. That's
why it is easier to have a single macro for all bitwidths instead of
hweight{16,32,64} per source operand width.

I have here somewhere patches which replaced those hweight* library
calls with hardware instructions on CPUs which support popcnt but our
poorman's kernel compile measurements showed little speedup since this
is used mainly in sched code but not often enough to make a noticeable
difference.

By the way, u8 src operands will get caught by gas saying something in
the likes of:

Error: suffix or operands invalid for `popcnt'


> >
> > ...
> >
> > +struct amd64_pvt {
> > +	/* pci_device handles which we utilize */
> > +	struct pci_dev *addr_f1_ctl;
> > +	struct pci_dev *dram_f2_ctl;
> > +	struct pci_dev *misc_f3_ctl;
> > +
> > +	int mc_node_id;		/* MC index of this MC node */
> > +	int ext_model;		/* extended model value of this node */
> > +
> > +	struct low_ops	*ops;	/* pointer to per PCI Device ID func table */
> > +
> > +	int channel_count;	/* Count of 'channels' */
> > +
> > +	/* Raw registers */
> > +	u32 dclr0;		/* DRAM Configuration Low DCT0 reg */
> > +	u32 dclr1;		/* DRAM Configuration Low DCT1 reg */
> > +	u32 dchr0;		/* DRAM Configuration High DCT0 reg */
> > +	u32 dchr1;		/* DRAM Configuration High DCT1 reg */
> > +	u32 nbcap;		/* North Bridge Capabilities */
> > +	u32 nbcfg;		/* F10 North Bridge Configuration */
> > +	u32 ext_nbcfg;		/* Extended F10 North Bridge Configuration */
> > +	u32 dhar;		/* DRAM Hoist reg */
> > +	u32 dbam0;		/* DRAM Base Address Mapping reg for DCT0 */
> > +	u32 dbam1;		/* DRAM Base Address Mapping reg for DCT1 */
> > +
> > +	/* DRAM CS Base Address Registers
> > +	 *   F2x[1,0][5C:40]
> > +	 */
> > +	u32 dcsb0[CHIPSELECT_COUNT];    /* DRAM CS Base Registers */
> > +	u32 dcsb1[CHIPSELECT_COUNT];    /* DRAM CS Base Registers */
> > +
> > +	/* DRAM CS Mask Registers
> > +	 *   F2x[1,0][6C:60]
> > +	 */
> > +	u32 dcsm0[CHIPSELECT_COUNT];    /* DRAM CS Mask Registers */
> > +	u32 dcsm1[CHIPSELECT_COUNT];    /* DRAM CS Mask Registers */
> > +
> > +	/* Decoded parts of DRAM BASE and LIMIT Registers
> > +	 * F1x[78,70,68,60,58,50,48,40]
> > +	 */
> > +	u64 dram_base[DRAM_REG_COUNT];/* DRAM Base Reg */
> > +	u64 dram_limit[DRAM_REG_COUNT];/* DRAM Limit Reg */
> > +	u8 dram_IntlvSel[DRAM_REG_COUNT];
> > +	u8 dram_IntlvEn[DRAM_REG_COUNT];
> > +	u8 dram_DstNode[DRAM_REG_COUNT];
> > +	u8 dram_rw_en[DRAM_REG_COUNT];
> > +
> > +	/* The following fields are set at (load) run time, after Revision has
> > +	 * been determined, since the dct_base and dct_mask registers vary
> > +	 * by CPU Revsion
> > +	 */
> > +	u32 dcsb_base;		/* DCSB base bits */
> > +	u32 dcsm_mask;		/* DCSM mask bits */
> > +	u32 num_dcsm;		/* Number of DCSM registers */
> > +	u32 dcs_mask_notused;	/* DCSM notused mask bits */
> > +	u32 dcs_shift;		/* DCSB and DCSM shift value */
> > +
> > +	u64 top_mem;		/* top of memory below 4GB */
> > +	u64 top_mem2;		/* top of memory above 4GB */
> > +
> > +	/* F10 registers */
> > +	u32 dram_ctl_select_low;	/* DRAM Controller Select Low Reg */
> > +	u32 dram_ctl_select_high;	/* DRAM Controller Select High Reg */
> > +	u32 online_spare;               /* On-Line spare Reg */
> > +
> > +	/* sysfs storage area: Temp storage for when input
> > +	 * is received from sysfs
> > +	 */
> > +	struct amd64_error_info_regs ctl_error_info;
> > +
> > +	/* Place to store error injection parameters prior to issue */
> > +	struct error_injection injection;
> > +
> > +	/* Save old hw registers' values before we modified them */
> > +	u32 nbctl_mcgctl_saved;		/* When true, following 2 are valid */
> > +	u32 old_nbctl;
> > +	u32 old_mcgctl;
> > +
> > +	/* MC Type Index value: socket F vs Family 10h */
> > +	u32 mc_type_index;
> > +
> > +	/* misc settings */
> > +	struct flags {
> > +		unsigned long cf8_extcfg :1;
> 
> checkpatch correctly warns here.

will fix.

> > +	} flags;
> > +};
> > +
> > +/*
> > + * See F2x80 for K8 and F2x[1,0]80 for Fam10 and later. The table below is only
> > + * for DDR2 DRAM mapping.
> > + */
> > +static u32 revf_quad_ddr2_shift[] =
> > +{
> 
> static u32 revf_quad_ddr2_shift[] = {
> 
> would be more typical.

patch coming up...

> > +	0,	/* 0000b NULL DIMM (128mb) */
> > +	28,	/* 0001b 256mb */
> > +	29,	/* 0010b 512mb */
> > +	29,	/* 0011b 512mb */
> > +	29,	/* 0100b 512mb */
> > +	30,	/* 0101b 1gb */
> > +	30,	/* 0110b 1gb */
> > +	31,	/* 0111b 2gb */
> > +	31,	/* 1000b 2gb */
> > +	32,	/* 1001b 4gb */
> > +	32,	/* 1010b 4gb */
> > +	33,	/* 1011b 8gb */
> > +	0,	/* 1100b future */
> > +	0,	/* 1101b future */
> > +	0,	/* 1110b future */
> > +	0	/* 1111b future */
> > +};
> > +
> >
> > ...
> >
> 
> 

-- 
Regards/Gruss,
Boris.

Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632


  reply	other threads:[~2009-04-28 19:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-28 15:05 [RFC PATCH 00/21] amd64_edac: EDAC module for AMD64 Borislav Petkov
2009-04-28 15:05 ` [PATCH 01/21] amd64_edac: add PCI config register defines Borislav Petkov
2009-04-28 15:05 ` [PATCH 02/21] amd64_edac: add driver structs Borislav Petkov
2009-04-28 18:13   ` Andrew Morton
2009-04-28 19:02     ` Borislav Petkov [this message]
2009-04-28 15:05 ` [PATCH 03/21] amd64_edac: add memory scrubber interface Borislav Petkov
2009-04-28 15:05 ` [PATCH 04/21] amd64_edac: add sys addr to memory controller mapping helpers Borislav Petkov
2009-04-28 15:05 ` [PATCH 05/21] amd64_edac: add functionality to compute the DRAM hole Borislav Petkov
2009-04-28 15:05 ` [PATCH 06/21] amd64_edac: add DRAM address type conversion facilities Borislav Petkov
2009-04-28 15:05 ` [PATCH 07/21] amd64_edac: add helper to dump relevant registers Borislav Petkov
2009-04-28 15:06 ` [PATCH 08/21] amd64_edac: assign DRAM chip select base and mask in a family-specific way Borislav Petkov
2009-04-28 15:06 ` [PATCH 09/21] amd64_edac: add k8-specific methods Borislav Petkov
2009-04-28 15:06 ` [PATCH 10/21] amd64_edac: add f10-and-later methods-p1 Borislav Petkov
2009-04-28 15:06 ` [PATCH 11/21] amd64_edac: add f10-and-later methods-p2 Borislav Petkov
2009-04-28 15:06 ` [PATCH 12/21] amd64_edac: add f10-and-later methods-p3 Borislav Petkov
2009-04-28 15:06 ` [PATCH 13/21] amd64_edac: add per-family descriptors Borislav Petkov
2009-04-28 15:06 ` [PATCH 14/21] amd64_edac: add msr accessors operating on all cpus Borislav Petkov
2009-04-28 18:21   ` Andrew Morton
2009-04-28 18:31     ` H. Peter Anvin
2009-04-28 19:23     ` Borislav Petkov
2009-04-28 15:06 ` [PATCH 15/21] amd64_edac: add x4 chipkill syndrome mapping table Borislav Petkov
2009-04-28 15:06 ` [PATCH 16/21] amd64_edac: add error decoding logic Borislav Petkov
2009-04-28 15:06 ` [PATCH 17/21] amd64_edac: add EDAC core-related initializers Borislav Petkov
2009-04-28 15:06 ` [PATCH 18/21] amd64_edac: add ECC reporting initializers Borislav Petkov
2009-04-28 15:06 ` [PATCH 19/21] amd64_edac: add debugging/testing code Borislav Petkov
2009-04-28 18:30   ` Andrew Morton
2009-04-28 15:06 ` [PATCH 20/21] amd64_edac: add DRAM error injection logic using sysfs Borislav Petkov
2009-04-28 15:06 ` [PATCH 21/21] amd64_edac: add module registration routines Borislav Petkov
2009-04-28 15:58 ` [RFC PATCH 00/21] amd64_edac: EDAC module for AMD64 Greg KH
2009-04-28 16:06   ` Borislav Petkov
2009-04-28 18:34     ` Andrew Morton
2009-04-28 19:58       ` Greg KH

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=20090428190249.GA2215@aftab \
    --to=borislav.petkov@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=dougthompson@xmission.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /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