public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Aristeu Rozanski <aris@redhat.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>,
	Doug Thompson <dougthompson@xmission.com>,
	Borislav Petkov <bp@alien8.de>,
	linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sb_edac: Add support for Broadwell-DE processor
Date: Fri, 21 Nov 2014 16:14:55 -0500	[thread overview]
Message-ID: <20141121211455.GN21208@redhat.com> (raw)
In-Reply-To: <546a37ab3156619eb3@agluck-desk.sc.intel.com>

Hi Tony,
On Mon, Nov 17, 2014 at 10:00:11AM -0800, Luck, Tony wrote:
> Broadwell-DE is the microserver version of next generation Xeon
> processors.  A whole bunch of new PCIe device ids, but otherwise
> pretty much the same as Haswell.
> 
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> 
> ---
> 
> Mauro: Naming of routines and #defines follows the existing
> convention of only making new functions where changes are
> needed, and using older functions with names from previous
> generations where no changes are needed.  Can you take this
> as-is for the next merge window and we can have a discussion
> about whether to have a massive re-naming to some "better"
> nomenclature in the coming months.  More changes will be
> needed for Broadwell-EP and Broadwell-EX
> 
> Also needs that Haswell TOLM fix I posted in October:
>   http://www.spinics.net/lists/linux-edac/msg04109.html#.VGo3FHW9_CI
> 
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index e9bb1af67c8d..5a140adb5191 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -261,6 +261,7 @@ enum type {
>  	SANDY_BRIDGE,
>  	IVY_BRIDGE,
>  	HASWELL,
> +	BROADWELL,
>  };
>  
>  struct sbridge_pvt;
> @@ -445,7 +446,7 @@ static const struct pci_id_table pci_dev_descr_ibridge_table[] = {
>   *	- each SMI channel interfaces with a scalable memory buffer
>   *	- each scalable memory buffer supports 4 DDR3/DDR4 channels, 3 DPC
>   */
> -#define HASWELL_DDRCRCLKCONTROLS 0xa10
> +#define HASWELL_DDRCRCLKCONTROLS 0xa10 /* Ditto on Broadwell */
>  #define HASWELL_HASYSDEFEATURE2 0x84
>  #define PCI_DEVICE_ID_INTEL_HASWELL_IMC_VTD_MISC 0x2f28
>  #define PCI_DEVICE_ID_INTEL_HASWELL_IMC_HA0	0x2fa0
> @@ -496,6 +497,44 @@ static const struct pci_id_table pci_dev_descr_haswell_table[] = {
>  	{0,}			/* 0 terminated list. */
>  };
>  
> +/* Broadwell support */
> +/* DE processor:
> + *	- 1 IMC
> + *	- 2 DDR3 channels, 2 DPC per channel
> + */
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_VTD_MISC 0x6f28
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0	0x6fa0
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TA	0x6fa8
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_THERMAL 0x6f71
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD0 0x6ffc
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD1 0x6ffd
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD0 0x6faa
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD1 0x6fab
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD2 0x6fac
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD3 0x6fad
> +#define PCI_DEVICE_ID_INTEL_BROADWELL_IMC_DDRIO0 0x6faf
> +
> +static const struct pci_id_descr pci_dev_descr_broadwell[] = {
> +	/* first item must be the HA */
> +	{ PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0, 0)		},
> +
> +	{ PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD0, 0)	},
> +	{ PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_CBO_SAD1, 0)	},
> +
> +	{ PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TA, 0)	},
> +	{ PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_THERMAL, 0)	},
> +	{ PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD0, 0)	},
> +	{ PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD1, 0)	},
> +	{ PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD2, 1)	},
> +	{ PCI_DESCR(PCI_DEVICE_ID_INTEL_BROADWELL_IMC_HA0_TAD3, 1)	},

You are marking TAD2 and TAD3 as optional here, but

> +	for (i = 0; i < NUM_CHANNELS; i++) {
> +		if (!pvt->pci_tad[i])
> +			goto enodev;
> +	}

It's not optional here.

Doesn't matter much and we should get rid of one of the checks anyway.

Acked-by: Aristeu Rozanski <aris@redhat.com>

-- 
Aristeu


  reply	other threads:[~2014-11-21 21:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-17 18:00 [PATCH] sb_edac: Add support for Broadwell-DE processor Luck, Tony
2014-11-21 21:14 ` Aristeu Rozanski [this message]
2014-11-21 21:21   ` Luck, Tony
2014-12-02 14:02 ` Mauro Carvalho Chehab
2014-12-02 17:27   ` [PATCHv2] " Tony Luck
2014-12-02 19:08     ` 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=20141121211455.GN21208@redhat.com \
    --to=aris@redhat.com \
    --cc=bp@alien8.de \
    --cc=dougthompson@xmission.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=tony.luck@intel.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