Re: Help!Some memory doesn't work on PPC405Ex based board!
On 4/14/09 4:08 AM, SunNeo wrote: My platform uses the MICRON MT47H256M8THN DDRII SDRAM and the DDRII SDRAM is soldered on the board. As I said, my board was similar with Kilauea evb, so I created my configuration header file from Kilauea's at U-Boot. In the configuration file, register value for the DDR SDRAM controller is defined. But I have removed DDR autocalibraton related configuration from the configuration file, do you think this will cause any issues? Sun: Does your board have ECC? While it seems like simply following the static, non-auto-calibrating configuration of the Kilauea or Haleakala board would be sufficient, my experience is that it is not, especially if your design has ECC. Should you decide to escalate the issue with AMCC, I suspect auto-calibration will be the first thing they ask you to enable and re-check your design with. Per Stefan's comments, unless you use an intensive and comprehensive memory test of some sort, just running u-boot is not necessarily a sufficient validation that memory works as it, in many configurations, touches and uses little of the overall RAM during its operation. Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] edac: new ppc4xx driver module
On 1/30/09 2:05 PM, Andrew Morton wrote:
On Fri, 30 Jan 2009 09:54:42 -0700 dougthomp...@xmission.com wrote:
From: Grant Erickson gerick...@nuovations.com
Perhaps a powerpc mailing list should have been cc'ed?
The first round patch went to Doug, the BlueSmoke (EDAC) mailing list and
the Linux/PowerPC mailing list. However, because the original patch was
split in two, subsequent revisions of just the EDAC piece went to Doug and
BlueSmoke. Doug then forwarded it to linux-kernel.
What's the preferred sign-off, ACK chain for this subsystem? Through
PowerPC/4xx or PowerPC GIT upstream or through you and -mm upstream?
These comments try really hard to be in kerneldoc form, but don't quite
succeed.
And I don't think that kerneldoc understands `...@return'? It should :(
Aye. I was mistakenly under the impression that Doxygen == kernel-doc;
however, that's clearly not the case. The next revision of the patch will
have these rectified.
+static int
+ppc4xx_edac_generate_bank_message(const struct mem_ctl_info *mci,
+ const struct ppc4xx_ecc_status *status,
+ char *buffer,
+ size_t size)
+{
+ int n, total = 0;
+ size_t row, rows;
It seems strange to use a size_t here.
Stylistically, I tend to use 'size_t' for 'unsigned type where I am counting
things'. However, I can see where this usage might be confusing and
surprising for some.
The next revision of the patch will use 'unsigned int'.
+static void
+ppc4xx_edac_handle_ce(struct mem_ctl_info *mci,
+const struct ppc4xx_ecc_status *status)
+{
+ int row;
+ char message[PPC4XX_EDAC_MESSAGE_SIZE];
256 bytes on the stack is getting a bit large.
Would you characterize this as a getting a bit large, but still OK or
getting a bit large, this MUST be changed?
I took my guidance from drivers/edac/i5[04]000_edac.c which allocate around
200 bytes on the stack for a similar use.
However, Josh Boyer had suggested that given all the snprintf going on in
the interrupt handler, a work queue might be a better way to go. ISR timings
for a sample population of 300 events are/were:
Ticks Time / us
Minimum 4150 10.38
Maximum 9075 22.69
Mean8024 20.06
Median 8297 20.74
Mode8869 22.17
Std. Dev.8642.16
In short, if this is a MUST rather than a SHOULD, reworking the driver to
pull the message buffers off the stack and implementing a work loop might be
a two-for-one rework opportunity.
+static void
+ppc4xx_edac_handle_ue(struct mem_ctl_info *mci,
+const struct ppc4xx_ecc_status *status)
+{
+ const u64 bear = ((u64)status-bearh 32 | status-bearl);
+ const unsigned long pfn = bear PAGE_SHIFT;
The term `pfn' has a specific meaining in-kernel, and I have a
suspicion that this variable doesn't match it.
I changed 'pfn' and 'poff' to 'page' and 'offset' respectively, in the next
revision of the patch.
Thanks for your feedback!
Regards,
Grant
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5] Add PPC/4xx ibm,sdram-4xx-ddr2 EDAC MC Driver
This adds support for an EDAC memory controller adaptation driver for the ibm,sdram-4xx-ddr2 ECC controller realized in the AMCC PowerPC 405EX[r]. Signed-off-by: Grant Erickson gerick...@nuovations.com --- At present, this driver has been developed and tested against the controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and a proprietary board based on those designs (128 MiB ECC memory, also soldered onto the board). In the future, dynamic feature detection and handling needs to be added for the other realizations of this controller found in the 440SP, 440SPe, 460EX, 460GT and 460SX. Eventually, this driver will likely be evolved and adapted to the above variant realizations of this controller as well as broken apart to handle the other known ECC-capable controllers prevalent in other PPC4xx processors: - IBM SDRAM (405GP, 405CR and 405EP) ibm,sdram-4xx - IBM DDR1 (440GP, 440GX, 440EP and 440GR) ibm,sdram-4xx-ddr - Denali DDR1/DDR2 (440EPX and 440GRX) denali,sdram-4xx-ddr2 Patch v2 removes the 'type' field from the of_device_id match structure to reflect the corresponding removal of the 'device_type' field from the device tree node. Patch v3 incorporates feedback from Josh Boyer regarding compliance of switch statements with Linux coding style, removing gratuitous printk wrappers, and using the DCR mapping from the device tree rather than using a fixed mapping. Patch v4 resync's the patch against the top-of-tree as 'git apply' was reporting fatal: new file drivers/edac/ppc4xx_edac.h depends on old contents. Patch v5 incorporates feedback from Andrew Morton, including changing the comment style from Doxygen to kernel-doc, reducing gratuitous parameter checking in ppc4xx_edac_mc_init, eliminated an unneeded void * cast in the ISR, changed pfn/poff to page/offset and use unsigned int rather than size_t for loop counters with associated printf format specifier changes. drivers/edac/Kconfig |9 + drivers/edac/Makefile |2 +- drivers/edac/ppc4xx_edac.c | 1448 drivers/edac/ppc4xx_edac.h | 172 ++ 4 files changed, 1630 insertions(+), 1 deletions(-) diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index eee47fd..ad3e753 100644 --- a/drivers/edac/Kconfig +++ b/drivers/edac/Kconfig @@ -174,4 +174,13 @@ config EDAC_CELL Cell Broadband Engine internal memory controller on platform without a hypervisor +config EDAC_PPC4XX + tristate PPC4xx IBM DDR2 Memory Controller + depends on EDAC_MM_EDAC 4xx + help + This enables support for EDAC on the ECC memory used + with the IBM DDR2 memory controller found in various + PowerPC 4xx embedded processors such as the 405EX[r], + 440SP, 440SPe, 460EX, 460GT and 460SX. + endif # EDAC diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile index b751969..a5fdcf0 100644 --- a/drivers/edac/Makefile +++ b/drivers/edac/Makefile @@ -34,4 +34,4 @@ obj-$(CONFIG_EDAC_PASEMI) += pasemi_edac.o obj-$(CONFIG_EDAC_MPC85XX) += mpc85xx_edac.o obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o obj-$(CONFIG_EDAC_CELL)+= cell_edac.o - +obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c new file mode 100644 index 000..d244f24 --- /dev/null +++ b/drivers/edac/ppc4xx_edac.c @@ -0,0 +1,1448 @@ +/* + * Copyright (c) 2008 Nuovation System Designs, LLC + * Grant Erickson gerick...@nuovations.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; version 2 of the + * License. + * + */ + +#include linux/edac.h +#include linux/interrupt.h +#include linux/irq.h +#include linux/kernel.h +#include linux/mm.h +#include linux/module.h +#include linux/of_device.h +#include linux/of_platform.h +#include linux/types.h + +#include asm/dcr.h + +#include edac_core.h +#include ppc4xx_edac.h + +/* + * This file implements a driver for monitoring and handling events + * associated with the IMB DDR2 ECC controller found in the AMCC/IBM + * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX. + * + * As realized in the 405EX[r], this controller features: + * + * - Support for registered- and non-registered DDR1 and DDR2 memory. + * - 32-bit or 16-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 4-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Two (2) memory banks/ranks. + * - Up to 1 GiB per bank/rank in 32-bit mode and up to 512 MiB per + * bank/rank in 16-bit mode. + * + * As realized in the 440SP and 440SPe, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o
Re: toolchain for building linux-2.6.27.8 or 2.6.28.1 ...
On 1/29/09 11:52 AM, Mike Timmons wrote: Questions: 1) if I want to cross-compile a kernel later than 2.6.24 to hopefully get better WAN device support (and clearer options for fw loading), which kernel should I try, and which toolchain? the ltib repository does not appear to have a toolchain newer than gcc-3.4.3-glibc-2.3.6 (for 603e) Admissions, disclaimers, etc 1) I'm using the same ltib script I have used for the 2.6.24 build with toolchain gcc-3.4.3-glibc-2.3.6 (for 603e). I'm simply modifying the kernel spec file to use 2.6.28.1 (and specifyin a custom toolchain). I've also tried to compile 2.6.27.8. I get the same error. Mike: Denx's ELDK 4.1 or 4.2 make a great It Just Works solution. I've used 4.1 running from 2.6.23 up to 2.6.27.11 and 4.2 from 2.6.26 to 2.6.27.11 with zero problems or issues. Regards, Grant Erickson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] Add PPC/4xx ibm,sdram-4xx-ddr2 EDAC MC Driver
This adds support for an EDAC memory controller adaptation driver for the ibm,sdram-4xx-ddr2 ECC controller realized in the AMCC PowerPC 405EX[r]. Signed-off-by: Grant Erickson gerick...@nuovations.com --- At present, this driver has been developed and tested against the controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and a proprietary board based on those designs (128 MiB ECC memory, also soldered onto the board). In the future, dynamic feature detection and handling needs to be added for the other realizations of this controller found in the 440SP, 440SPe, 460EX, 460GT and 460SX. Eventually, this driver will likely be evolved and adapted to the above variant realizations of this controller as well as broken apart to handle the other known ECC-capable controllers prevalent in other PPC4xx processors: - IBM SDRAM (405GP, 405CR and 405EP) ibm,sdram-4xx - IBM DDR1 (440GP, 440GX, 440EP and 440GR) ibm,sdram-4xx-ddr - Denali DDR1/DDR2 (440EPX and 440GRX) denali,sdram-4xx-ddr2 Patch v2 removes the 'type' field from the of_device_id match structure to reflect the corresponding removal of the 'device_type' field from the device tree node. Patch v3 incorporates feedback from Josh Boyer regarding compliance of switch statements with Linux coding style, removing gratuitous printk wrappers, and using the DCR mapping from the device tree rather than using a fixed mapping. Patch v4 resync's the patch against the top-of-tree as 'git apply' was reporting fatal: new file drivers/edac/ppc4xx_edac.h depends on old contents. drivers/edac/Kconfig |9 + drivers/edac/Makefile |2 +- drivers/edac/ppc4xx_edac.c | 1414 drivers/edac/ppc4xx_edac.h | 172 ++ 4 files changed, 1596 insertions(+), 1 deletions(-) diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index e2667a8..ae1ec6a 100644 --- a/drivers/edac/Kconfig +++ b/drivers/edac/Kconfig @@ -167,4 +167,13 @@ config EDAC_CELL Cell Broadband Engine internal memory controller on platform without a hypervisor +config EDAC_PPC4XX + tristate PPC4xx IBM DDR2 Memory Controller + depends on EDAC_MM_EDAC 4xx + help + This enables support for EDAC on the ECC memory used + with the IBM DDR2 memory controller found in various + PowerPC 4xx embedded processors such as the 405EX[r], + 440SP, 440SPe, 460EX, 460GT and 460SX. + endif # EDAC diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile index 62c2d9b..de8d4c1 100644 --- a/drivers/edac/Makefile +++ b/drivers/edac/Makefile @@ -33,4 +33,4 @@ obj-$(CONFIG_EDAC_PASEMI) += pasemi_edac.o obj-$(CONFIG_EDAC_MPC85XX) += mpc85xx_edac.o obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o obj-$(CONFIG_EDAC_CELL)+= cell_edac.o - +obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c new file mode 100644 index 000..5dc77c9 --- /dev/null +++ b/drivers/edac/ppc4xx_edac.c @@ -0,0 +1,1414 @@ +/* + * Copyright (c) 2008 Nuovation System Designs, LLC + * Grant Erickson gerick...@nuovations.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; version 2 of the + * License. + * + */ + +#include linux/edac.h +#include linux/interrupt.h +#include linux/irq.h +#include linux/kernel.h +#include linux/mm.h +#include linux/module.h +#include linux/of_device.h +#include linux/of_platform.h +#include linux/types.h + +#include asm/dcr.h + +#include edac_core.h +#include ppc4xx_edac.h + +/* + * This file implements a driver for monitoring and handling events + * associated with the IMB DDR2 ECC controller found in the AMCC/IBM + * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX. + * + * As realized in the 405EX[r], this controller features: + * + * - Support for registered- and non-registered DDR1 and DDR2 memory. + * - 32-bit or 16-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 4-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Two (2) memory banks/ranks. + * - Up to 1 GiB per bank/rank in 32-bit mode and up to 512 MiB per + * bank/rank in 16-bit mode. + * + * As realized in the 440SP and 440SPe, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Up to 4 GiB per bank/rank in 64-bit mode and up to 2 GiB + * per bank/rank in 32-bit mode. + * + * As realized in the 460EX and 460GT, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On 1/6/09 4:04 PM, Benjamin Herrenschmidt wrote: On Tue, 2008-11-25 at 10:34 -0800, Grant Erickson wrote: This merges support for the previously DENX-only kernel feature of specifying an alternative, external buffer for kernel printk messages and their associated metadata. In addition, this ports architecture support for this feature from arch/ppc to arch/powerpc. Signed-off-by: Grant Erickson gerick...@nuovations.com Considering the extensive changes to generic code, this patch will have to be submitted via the linux-kernel mailing list. I suggest you split the generic core change from the powerpc specific implementation. I'm not sure whether I like the idea myself or not there, so you'll have to convince the powers that be to take it. Ben: Thanks for the feedback. Matt Sealey had some good feedback http://ozlabs.org/pipermail/linuxppc-dev/2008-November/065594.html which I have on my to-do list to evaluate. In the interim, I'll hold off on pushing up to linux-kernel until I've done that. Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] Add PPC/4xx ibm,sdram-4xx-ddr2 EDAC MC Driver
This adds support for an EDAC memory controller adaptation driver for the ibm,sdram-4xx-ddr2 ECC controller realized in the AMCC PowerPC 405EX[r]. Signed-off-by: Grant Erickson gerick...@nuovations.com --- At present, this driver has been developed and tested against the controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and a proprietary board based on those designs (128 MiB ECC memory, also soldered onto the board). In the future, dynamic feature detection and handling needs to be added for the other realizations of this controller found in the 440SP, 440SPe, 460EX, 460GT and 460SX. Eventually, this driver will likely be evolved and adapted to the above variant realizations of this controller as well as broken apart to handle the other known ECC-capable controllers prevalent in other PPC4xx processors: - IBM SDRAM (405GP, 405CR and 405EP) ibm,sdram-4xx - IBM DDR1 (440GP, 440GX, 440EP and 440GR) ibm,sdram-4xx-ddr - Denali DDR1/DDR2 (440EPX and 440GRX) denali,sdram-4xx-ddr2 Patch v2 removes the 'type' field from the of_device_id match structure to reflect the corresponding removal of the 'device_type' field from the device tree node. Patch v3 incorporates feedback from Josh Boyer regarding compliance of switch statements with Linux coding style, removing gratuitous printk wrappers, and using the DCR mapping from the device tree rather than using a fixed mapping. drivers/edac/Kconfig |9 + drivers/edac/Makefile |2 +- drivers/edac/ppc4xx_edac.c | 1414 drivers/edac/ppc4xx_edac.h | 172 ++ 4 files changed, 1596 insertions(+), 1 deletions(-) diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index e0dbd38..ae950d7 100644 --- a/drivers/edac/Kconfig +++ b/drivers/edac/Kconfig @@ -167,4 +167,13 @@ config EDAC_CELL Cell Broadband Engine internal memory controller on platform without a hypervisor +config EDAC_PPC4XX + tristate PPC4xx IBM DDR2 Memory Controller + depends on EDAC_MM_EDAC 4xx + help + This enables support for EDAC on the ECC memory used + with the IBM DDR2 memory controller found in various + PowerPC 4xx embedded processors such as the 405EX[r], + 440SP, 440SPe, 460EX, 460GT and 460SX. + endif # EDAC diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile index 62c2d9b..de8d4c1 100644 --- a/drivers/edac/Makefile +++ b/drivers/edac/Makefile @@ -33,4 +33,4 @@ obj-$(CONFIG_EDAC_PASEMI) += pasemi_edac.o obj-$(CONFIG_EDAC_MPC85XX) += mpc85xx_edac.o obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o obj-$(CONFIG_EDAC_CELL)+= cell_edac.o - +obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c new file mode 100644 index 000..ea3edea --- /dev/null +++ b/drivers/edac/ppc4xx_edac.c @@ -0,0 +1,1414 @@ +/* + * Copyright (c) 2008 Nuovation System Designs, LLC + * Grant Erickson gerick...@nuovations.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; version 2 of the + * License. + * + */ + +#include linux/edac.h +#include linux/interrupt.h +#include linux/irq.h +#include linux/kernel.h +#include linux/mm.h +#include linux/module.h +#include linux/of_device.h +#include linux/of_platform.h +#include linux/types.h + +#include asm/dcr.h + +#include edac_core.h +#include ppc4xx_edac.h + +/* + * This file implements a driver for monitoring and handling events + * associated with the IMB DDR2 ECC controller found in the AMCC/IBM + * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX. + * + * As realized in the 405EX[r], this controller features: + * + * - Support for registered- and non-registered DDR1 and DDR2 memory. + * - 32-bit or 16-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 4-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Two (2) memory banks/ranks. + * - Up to 1 GiB per bank/rank in 32-bit mode and up to 512 MiB per + * bank/rank in 16-bit mode. + * + * As realized in the 440SP and 440SPe, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Up to 4 GiB per bank/rank in 64-bit mode and up to 2 GiB + * per bank/rank in 32-bit mode. + * + * As realized in the 460EX and 460GT, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Four (4
Re: [PATCH v2] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On 12/18/08 9:56 AM, Josh Boyer wrote:
On Thu, Dec 18, 2008 at 09:04:23AM +0100, Stefan Roese wrote:
On Thursday 18 December 2008, Grant Erickson wrote:
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts index 513bc43..64880ab 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,14 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405exr;
+ compatible = ibm,sdram-405exr, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ #interrupt-cells = 1;
+ interrupt-parent = SDRAM0;
+ interrupts = 0x0 0x1;
+ interrupt-map = /* ECCDED Error */ 0x0 UIC2 0x5 0x4
+ /* ECCSEC Error */ 0x1 UIC2 0x6 0x4;
+ interrupt-map-mask = 0x;
When all interrupts are mapped the same parent, this should do as well:
interrupt-parent = UIC2;
interrupts = 0x5 0x4 /* ECCDED Error */
0x6 0x4; /* ECCSEC Error */
Other than this:
Acked-by: Stefan Roese s...@denx.de
Yeah, I agree. Adding an interrupt map when it's not needed is
just complexity that doesn't need to be there.
Stefan and Josh:
From a programmatic perspective, does the above still allow the code to
index virtual interrupt indices 0 and 1 rather than 5 and 6 when calling
irq_of_parse_and_map()?
Regards,
Grant
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Add PPC/4xx ibm,sdram-4xx-ddr2 EDAC MC Driver
On 12/18/08 9:56 AM, Josh Boyer wrote:
On Wed, Dec 17, 2008 at 05:42:21PM -0800, Grant Erickson wrote:
This adds support for an EDAC memory controller adaptation driver for
the ibm,sdram-4xx-ddr2 ECC controller realized in the AMCC PowerPC
405EX[r].
Signed-off-by: Grant Erickson gerick...@nuovations.com
---
drivers/edac/Kconfig|9 +
drivers/edac/Makefile |2 +-
drivers/edac/ppc4xx_edac.c | 1332
+++
drivers/edac/ppc4xx_edac.h | 179 +
4 files changed, 1521 insertions(+), 1 deletions(-)
diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c
new file mode 100644
index 000..5caadc6
--- /dev/null
+++ b/drivers/edac/ppc4xx_edac.c
@@ -0,0 +1,1332 @@
[ ... ]
+/*
+ * This file implements a driver for monitoring and handling events
+ * associated with the IMB DDR2 ECC controller found in the AMCC/IBM
+ * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX.
+ *
+ * As realized in the 405EX[r], this controller features:
+ *
[ ... ]
+ *
+ * As realized in the 440SP and 440SPe, this controller changes/adds:
+ *
[ ... ]
+ *
+ * As realized in the 460EX and 460GT, this controller changes/adds:
+ *
[ ... ]
+ *
+ * At present, this driver has ONLY been tested against the controller
+ * realization in the 405EX[r] on the AMCC Kilauea and Haleakala
+ * boards (256 MiB w/o ECC memory soldered onto the board) and a
+ * proprietary board based on those designs (128 MiB ECC memory, also
+ * soldered onto the board).
+ *
+ * Dynamic feature detection and handling needs to be added for the
+ * other realizations of this controller listed above.
Then I think you should omit anything about 440SP and 460 until it works.
I'd like to include as many breadcrumbs as possible--in the form of
comments, so that in days, weeks, months or years when I or someone else
come along to implement support for said controller realizations, there's
some information to get started in the right direction.
+#define PPC4XX_EDAC_MODULE_REVISION v1.0.0 __DATE__
Do you really want __DATE__ there? It's sort of meaningless.
I'd agree; however, this seems to be the prevailing convention for this
driver:
% grep '__DATE__' *
amd76x_edac.c:#define AMD76X_REVISIONVer: 2.0.2 __DATE__
e752x_edac.c:#define E752X_REVISION Ver: 2.0.2 __DATE__
e7xxx_edac.c:#defineE7XXX_REVISION Ver: 2.0.2 __DATE__
edac_module.c:#define EDAC_VERSION Ver: 2.1.0 __DATE__
i5000_edac.c:#define I5000_REVISION Ver: 2.0.12 __DATE__
i82860_edac.c:#define I82860_REVISION Ver: 2.0.2 __DATE__
i82875p_edac.c:#define I82875P_REVISION Ver: 2.0.2 __DATE__
i82975x_edac.c:#define I82975X_REVISION Ver: 1.0.0 __DATE__
mpc85xx_edac.h:#define MPC85XX_REVISION Ver: 2.0.0 __DATE__
mv64x60_edac.h:#define MV64x60_REVISION Ver: 2.0.0 __DATE__
r82600_edac.c:#define R82600_REVISIONVer: 2.0.2 __DATE__
When in Rome or do the right thing?
+/*
+ * Convenience macros to support indirect DCR read and write access to
+ * the SDRAM controller registers.
+ *
+ * TODO: If in the future the indirect address and data windows for
+ * this controller are not the same across realizations, the windows
+ * will have to be read from the device tree and these mnemonic
+ * accessors will have to become programmatic in a manner similar to
+ * the existing dcr_{map,unmap,read,write} functions.
+ */
+#define mfsdram(reg) mfdcri(SDRAM0, SDRAM_ ## reg)
+#define mtsdram(reg, value) mtdcri(SDRAM0, SDRAM_ ## reg, value)
I have no general problems with using this, but others might want you to
use dcr_read and dcr_write. They get the DCR offsets from the device
tree. It would be a cleaner way to handle that.
I covered this thread at
http://ozlabs.org/pipermail/linuxppc-dev/2008-December/066055.html.
Provided you're OK with this as-is, I'll leave it as-is.
I'd prefer more perspective across a broader set of IDCR address/data window
usage cases before I proposed a dcri_read/dcri_write implementation.
+/*
+ * PPC4xx SDRAM memory controller private instance data
+ */
+struct ppc4xx_edac_pdata {
+ struct {
+ int sec; /* Single-bit correctable error IRQ assigned */
+ int ded; /* Double-bit detectable error IRQ assigned */
+ } irqs;
+};
Is the sub-structure for irqs really needed? This could just be
struct ppc4xx_edac_irqs {
int sec;
int ded;
};
Were I to implement feature flags and other things to further parameterize
the driver to handle the aforementioned controller realizations, I'd have
defined this structure as:
struct ppc4xx_edac_pdata {
u32 features;
unsigned int banks;
size_t width;
struct {
int sec;/* Single-bit correctable error IRQ assigned */
int ded;/* Double-bit detectable error IRQ assigned */
} irqs;
};
or some such. Consequently, I would prefer leaving
[PATCH v3] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new ibm,sdram-4xx-ddr2 EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson gerick...@nuovations.com
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this ibm,sdram-4xx-ddr2 controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
Patch v2, based on review from David Gibson, removes the 'device_type'
field because it is only used for legacy OpenFirmware method
interfaces and no such compatibility is warranted here. In addition,
removed address- and size-cells as this node has no children.
Patch v3, based on review from Josh Boyer and Stefan Roese, simplifies
the interrupt specification because both the SEC and DED interrupts
are mapped to the same interrupt parent.
arch/powerpc/boot/dts/haleakala.dts |5 +-
arch/powerpc/boot/dts/kilauea.dts |5 +-
arch/powerpc/boot/dts/makalu.dts|5 +-
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..09522f3 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,11 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405exr;
+ compatible = ibm,sdram-405exr, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ interrupt-parent = UIC2;
+ interrupt-map = 0x5 0x4/* ECC DED Error */
+0x6 0x4; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..68c88e2 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,11 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ interrupt-parent = UIC2;
+ interrupt-map = 0x5 0x4/* ECC DED Error */
+0x6 0x4; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..537d21f 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,9 +90,11 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ interrupt-parent = UIC2;
+ interrupt-map = 0x5 0x4/* ECC DED Error */
+0x6 0x4; /* ECC SEC Error */
};
MAL0: mcmal {
--
1.6.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new ibm,sdram-4xx-ddr2 EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson gerick...@nuovations.com
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this ibm,sdram-4xx-ddr2 controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
Patch v2, based on review from David Gibson, removes the 'device_type'
field because it is only used for legacy OpenFirmware method
interfaces and no such compatibility is warranted here. In addition,
removed address- and size-cells as this node has no children.
Patch v3, based on review from Josh Boyer and Stefan Roese, simplifies
the interrupt specification because both the SEC and DED interrupts
are mapped to the same interrupt parent.
Patch v4 corrects a typo: 'interrupt-map' should be 'interrupts'.
arch/powerpc/boot/dts/haleakala.dts |5 -
arch/powerpc/boot/dts/kilauea.dts |5 -
arch/powerpc/boot/dts/makalu.dts|5 -
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..9384da6 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,11 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405exr;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ interrupt-parent = UIC2;
+ interrupts = 0x5 0x4 /* ECC DED Error */
+ 0x6 0x4; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..280 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,11 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ interrupt-parent = UIC2;
+ interrupts = 0x5 0x4 /* ECC DED Error */
+ 0x6 0x4; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..b2e0bf6 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,9 +90,11 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ interrupt-parent = UIC2;
+ interrupts = 0x5 0x4 /* ECC DED Error */
+ 0x6 0x4; /* ECC SEC Error */
};
MAL0: mcmal {
--
1.6.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new ibm,sdram-4xx-ddr2 EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson gerick...@nuovations.com
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this ibm,sdram-4xx-ddr2 controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
Patch v2, based on review from David Gibson, removes the 'device_type'
field because it is only used for legacy OpenFirmware method
interfaces and no such compatibility is warranted here. In addition,
removed address- and size-cells as this node has no children.
Patch v3, based on review from Josh Boyer and Stefan Roese, simplifies
the interrupt specification because both the SEC and DED interrupts
are mapped to the same interrupt parent.
Patch v4 corrects a typo: 'interrupt-map' should be 'interrupts'.
Patch v5 corrects a copy-and-paste error, Haleakala is a 405exr.
arch/powerpc/boot/dts/haleakala.dts |5 -
arch/powerpc/boot/dts/kilauea.dts |5 -
arch/powerpc/boot/dts/makalu.dts|5 -
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..9384da6 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,11 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405exr;
+ compatible = ibm,sdram-405exr, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ interrupt-parent = UIC2;
+ interrupts = 0x5 0x4 /* ECC DED Error */
+ 0x6 0x4; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..280 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,11 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ interrupt-parent = UIC2;
+ interrupts = 0x5 0x4 /* ECC DED Error */
+ 0x6 0x4; /* ECC SEC Error */
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..b2e0bf6 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,9 +90,11 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ interrupt-parent = UIC2;
+ interrupts = 0x5 0x4 /* ECC DED Error */
+ 0x6 0x4; /* ECC SEC Error */
};
MAL0: mcmal {
--
1.6.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Add PPC/4xx ibm,sdram-4xx-ddr2 EDAC MC Driver
On 12/18/08 11:13 AM, Grant Erickson wrote: On 12/18/08 9:56 AM, Josh Boyer wrote: So, I am not an expert at the EDAC subsystem. Just looking at the number of functions that get call from this interrupt handler, I'm wondering if a significant amount of time could be spent here. With all the message building and such, it seems like it could be error prone. The message building functions are really best-effort, straight-through, so there should be little room if any for error-proneness. Though, snprintf contained therein is fairly costly as functions go. Do you have an idea of the duration of one of these events? Could this schedule a work queue to handle it outside of the hard IRQ context? I'll take some measurements for the worst case message length time. I certainly thought about a work queue; however, my gut feeling was that it wasn't warranted. Stay tuned for measurement data. In general, correctable and uncorrectable ECC errors in and of themselves should be rare events. So, by extension, the generation of these ECC error messages should be rare as well. When one of these CE or UE ECC events occurs, the time required to build the driver-unique log message is as shown below for a run of ~300 forced CEs at at a processor frequency of 400 MHz: Ticks Time / us Minimum 4150 10.38 Maximum 9075 22.69 Mean8024 20.06 Median 8297 20.74 Mode8869 22.17 Std. Dev.8642.16 Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new ibm,sdram-4xx-ddr2 EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson gerick...@nuovations.com
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this ibm,sdram-4xx-ddr2 controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
arch/powerpc/boot/dts/haleakala.dts | 11 ++-
arch/powerpc/boot/dts/kilauea.dts | 11 ++-
arch/powerpc/boot/dts/makalu.dts| 11 ++-
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..e45ce7e 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,17 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405exr;
+ device_type = memory-controller;
+ compatible = ibm,sdram-405exr, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-parent = SDRAM0;
+ interrupts = 0x0 0x1;
+ interrupt-map = /* ECCDED Error */ 0x0 UIC2 0x5 0x4
+/* ECCSEC Error */ 0x1 UIC2 0x6 0x4;
+ interrupt-map-mask = 0x;
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..d492ead 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,17 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ device_type = memory-controller;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-parent = SDRAM0;
+ interrupts = 0x0 0x1;
+ interrupt-map = /* ECCDED Error */ 0x0 UIC2 0x5 0x4
+/* ECCSEC Error */ 0x1 UIC2 0x6 0x4;
+ interrupt-map-mask = 0x;
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..52b9f32 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,8 +90,17 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ device_type = memory-controller;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-parent = SDRAM0;
+ interrupts = 0x0 0x1;
+ interrupt-map = /* ECCDED Error */ 0x0 UIC2 0x5 0x4
+/* ECCSEC Error */ 0x1 UIC2 0x6 0x4;
+ interrupt-map-mask = 0x;
};
MAL0: mcmal {
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add PPC/4xx ibm,sdram-4xx-ddr2 EDAC MC Driver
This adds support for an EDAC memory controller adaptation driver for the ibm,sdram-4xx-ddr2 ECC controller realized in the AMCC PowerPC 405EX[r]. Signed-off-by: Grant Erickson gerick...@nuovations.com --- At present, this driver has been developed and tested against the controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and a proprietary board based on those designs (128 MiB ECC memory, also soldered onto the board). In the future, dynamic feature detection and handling needs to be added for the other realizations of this controller found in the 440SP, 440SPe, 460EX, 460GT and 460SX. Eventually, this driver will likely be evolved and adapted to the above variant realizations of this controller as well as broken apart to handle the other known ECC-capable controllers prevalent in other PPC4xx processors: - IBM SDRAM (405GP, 405CR and 405EP) ibm,sdram-4xx - IBM DDR1 (440GP, 440GX, 440EP and 440GR) ibm,sdram-4xx-ddr - Denali DDR1/DDR2 (440EPX and 440GRX) denali,sdram-4xx-ddr2 drivers/edac/Kconfig |9 + drivers/edac/Makefile |2 +- drivers/edac/ppc4xx_edac.c | 1333 drivers/edac/ppc4xx_edac.h | 179 ++ 4 files changed, 1522 insertions(+), 1 deletions(-) diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index e0dbd38..2690946 100644 --- a/drivers/edac/Kconfig +++ b/drivers/edac/Kconfig @@ -167,4 +167,13 @@ config EDAC_CELL Cell Broadband Engine internal memory controller on platform without a hypervisor +config EDAC_PPC4XX + tristate PPC4xx IBM DDR2 Memory Controller + depends on EDAC_MM_EDAC 4xx + help + This enables support for EDAC on the ECC memory used + with the IBM DDR2 memory controller found in various + PowerPC 4xx embedded processors such as the 405EX[r], + 440SP, 440SPe, 460EX,460GT and 460SX. + endif # EDAC diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile index 62c2d9b..de8d4c1 100644 --- a/drivers/edac/Makefile +++ b/drivers/edac/Makefile @@ -33,4 +33,4 @@ obj-$(CONFIG_EDAC_PASEMI) += pasemi_edac.o obj-$(CONFIG_EDAC_MPC85XX) += mpc85xx_edac.o obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o obj-$(CONFIG_EDAC_CELL)+= cell_edac.o - +obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c new file mode 100644 index 000..493c273 --- /dev/null +++ b/drivers/edac/ppc4xx_edac.c @@ -0,0 +1,1333 @@ +/* + * Copyright (c) 2008 Nuovation System Designs, LLC + * Grant Erickson gerick...@nuovations.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; version 2 of the + * License. + * + */ + +#include linux/edac.h +#include linux/interrupt.h +#include linux/irq.h +#include linux/kernel.h +#include linux/mm.h +#include linux/module.h +#include linux/of_device.h +#include linux/of_platform.h +#include linux/types.h + +#include asm/dcr.h + +#include edac_core.h +#include ppc4xx_edac.h + +/* + * This file implements a driver for monitoring and handling events + * associated with the IMB DDR2 ECC controller found in the AMCC/IBM + * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX. + * + * As realized in the 405EX[r], this controller features: + * + * - Support for registered- and non-registered DDR1 and DDR2 memory. + * - 32-bit or 16-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 4-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Two (2) memory banks/ranks. + * - Up to 1 GiB per bank/rank in 32-bit mode and up to 512 MiB per + * bank/rank in 16-bit mode. + * + * As realized in the 440SP and 440SPe, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Up to 4 GiB per bank/rank in 64-bit mode and up to 2 GiB + * per bank/rank in 32-bit mode. + * + * As realized in the 460EX and 460GT, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Four (4) memory banks/ranks. + * - Up to 16 GiB per bank/rank in 64-bit mode and up to 8 GiB + * per bank/rank in 32-bit mode. + * + * At present, this driver has ONLY been tested against the controller + * realization in the 405EX[r] on the AMCC Kilauea and Haleakala + * boards (256 MiB w/o ECC memory soldered onto the board) and a + * proprietary board based on those designs (128 MiB ECC memory, also
Re: [PATCH] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On 12/17/08 3:46 PM, David Gibson wrote:
On Wed, Dec 17, 2008 at 11:56:07AM -0800, Grant Erickson wrote:
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new ibm,sdram-4xx-ddr2 EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson gerick...@nuovations.com
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this ibm,sdram-4xx-ddr2 controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
arch/powerpc/boot/dts/haleakala.dts | 11 ++-
arch/powerpc/boot/dts/kilauea.dts | 11 ++-
arch/powerpc/boot/dts/makalu.dts| 11 ++-
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..e45ce7e 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,17 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405exr;
+ device_type = memory-controller;
This should not have a device_type.
I'm still growing my device tree expertise. Can you elaborate on why SDRAM0
shouldn't be described generically as a memory-controller device in the
same way the EMAC0 is generically described as a network device? A URL to
said elaboration would be sufficient.
+ compatible = ibm,sdram-405exr, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ #address-cells = 0;
+ #size-cells = 0;
This seems odd. These should only be present if the node does, or at
least can, have subnodes - I don't see that it would.
See above qualifier; will remove.
Thanks for the prompt review!
Regards,
Grant
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new ibm,sdram-4xx-ddr2 EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson gerick...@nuovations.com
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this ibm,sdram-4xx-ddr2 controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
Patch v2, based on review from David Gibson, removes the 'device_type'
field because it is only used for legacy OpenFirmware method
interfaces and no such compatibility is warranted here. In addition,
removed address- and size-cells as this node has no children.
arch/powerpc/boot/dts/haleakala.dts |8 +-
arch/powerpc/boot/dts/kilauea.dts |8 +-
arch/powerpc/boot/dts/makalu.dts|8 +-
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..64880ab 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,14 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405exr;
+ compatible = ibm,sdram-405exr, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ #interrupt-cells = 1;
+ interrupt-parent = SDRAM0;
+ interrupts = 0x0 0x1;
+ interrupt-map = /* ECCDED Error */ 0x0 UIC2 0x5 0x4
+/* ECCSEC Error */ 0x1 UIC2 0x6 0x4;
+ interrupt-map-mask = 0x;
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..bc32b60 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,14 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ #interrupt-cells = 1;
+ interrupt-parent = SDRAM0;
+ interrupts = 0x0 0x1;
+ interrupt-map = /* ECCDED Error */ 0x0 UIC2 0x5 0x4
+/* ECCSEC Error */ 0x1 UIC2 0x6 0x4;
+ interrupt-map-mask = 0x;
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..472d22d 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,8 +90,14 @@
clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = ibm,sdram-405ex;
+ compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
+ #interrupt-cells = 1;
+ interrupt-parent = SDRAM0;
+ interrupts = 0x0 0x1;
+ interrupt-map = /* ECCDED Error */ 0x0 UIC2 0x5 0x4
+/* ECCSEC Error */ 0x1 UIC2 0x6 0x4;
+ interrupt-map-mask = 0x;
};
MAL0: mcmal {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] Add PPC/4xx ibm,sdram-4xx-ddr2 EDAC MC Driver
This adds support for an EDAC memory controller adaptation driver for the ibm,sdram-4xx-ddr2 ECC controller realized in the AMCC PowerPC 405EX[r]. Signed-off-by: Grant Erickson gerick...@nuovations.com --- At present, this driver has been developed and tested against the controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and a proprietary board based on those designs (128 MiB ECC memory, also soldered onto the board). In the future, dynamic feature detection and handling needs to be added for the other realizations of this controller found in the 440SP, 440SPe, 460EX, 460GT and 460SX. Eventually, this driver will likely be evolved and adapted to the above variant realizations of this controller as well as broken apart to handle the other known ECC-capable controllers prevalent in other PPC4xx processors: - IBM SDRAM (405GP, 405CR and 405EP) ibm,sdram-4xx - IBM DDR1 (440GP, 440GX, 440EP and 440GR) ibm,sdram-4xx-ddr - Denali DDR1/DDR2 (440EPX and 440GRX) denali,sdram-4xx-ddr2 Patch v2 removes the 'type' field from the of_device_id match structure to reflect the corresponding removal of the 'device_type' field from the device tree node. drivers/edac/Kconfig|9 + drivers/edac/Makefile |2 +- drivers/edac/ppc4xx_edac.c | 1332 +++ drivers/edac/ppc4xx_edac.h | 179 + 4 files changed, 1521 insertions(+), 1 deletions(-) diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index e0dbd38..ae950d7 100644 --- a/drivers/edac/Kconfig +++ b/drivers/edac/Kconfig @@ -167,4 +167,13 @@ config EDAC_CELL Cell Broadband Engine internal memory controller on platform without a hypervisor +config EDAC_PPC4XX + tristate PPC4xx IBM DDR2 Memory Controller + depends on EDAC_MM_EDAC 4xx + help + This enables support for EDAC on the ECC memory used + with the IBM DDR2 memory controller found in various + PowerPC 4xx embedded processors such as the 405EX[r], + 440SP, 440SPe, 460EX, 460GT and 460SX. + endif # EDAC diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile index 62c2d9b..de8d4c1 100644 --- a/drivers/edac/Makefile +++ b/drivers/edac/Makefile @@ -33,4 +33,4 @@ obj-$(CONFIG_EDAC_PASEMI) += pasemi_edac.o obj-$(CONFIG_EDAC_MPC85XX) += mpc85xx_edac.o obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o obj-$(CONFIG_EDAC_CELL)+= cell_edac.o - +obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c new file mode 100644 index 000..5caadc6 --- /dev/null +++ b/drivers/edac/ppc4xx_edac.c @@ -0,0 +1,1332 @@ +/* + * Copyright (c) 2008 Nuovation System Designs, LLC + * Grant Erickson gerick...@nuovations.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; version 2 of the + * License. + * + */ + +#include linux/edac.h +#include linux/interrupt.h +#include linux/irq.h +#include linux/kernel.h +#include linux/mm.h +#include linux/module.h +#include linux/of_device.h +#include linux/of_platform.h +#include linux/types.h + +#include asm/dcr.h + +#include edac_core.h +#include ppc4xx_edac.h + +/* + * This file implements a driver for monitoring and handling events + * associated with the IMB DDR2 ECC controller found in the AMCC/IBM + * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX. + * + * As realized in the 405EX[r], this controller features: + * + * - Support for registered- and non-registered DDR1 and DDR2 memory. + * - 32-bit or 16-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 4-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Two (2) memory banks/ranks. + * - Up to 1 GiB per bank/rank in 32-bit mode and up to 512 MiB per + * bank/rank in 16-bit mode. + * + * As realized in the 440SP and 440SPe, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Up to 4 GiB per bank/rank in 64-bit mode and up to 2 GiB + * per bank/rank in 32-bit mode. + * + * As realized in the 460EX and 460GT, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Four (4) memory banks/ranks. + * - Up to 16 GiB per bank/rank in 64-bit mode and up to 8 GiB + * per bank/rank in 32-bit mode. + * + * At present, this driver has ONLY been tested against the controller
Indirect DCR Access
Josh: In working through the PPC4XX memory-controller,ibm,sdram-4xx-ddr2 adapter driver for the EDAC MC driver, there are a substantial number of indirect DCR accesses. Ideally, I would use the address and data DCRs implied from the SDRAM0 dcr-reg device tree property; however, the mtdcri and mfdcri are mnemonic-only at present. Consequently, I've done: #define DCRN_SDRAM0_BASE0x010 #define DCRN_SDRAM0_CONFIG_ADDR (DCRN_SDRAM0_BASE+0x0) #define DCRN_SDRAM0_CONFIG_DATA (DCRN_SDRAM0_BASE+0x1) #define mfsdram(reg)mfdcri(SDRAM0, SDRAM_ ## reg) #define mtsdram(reg, value) mtdcri(SDRAM0, SDRAM_ ## reg, value) for the short-term. Is there a long-term strategy or set of options under discussion about expanding the DCR accessors in dcr.h to include indirect access from a device tree property as in the case above? It appears that the processors that use this memory controller core all have the same DCR address and data registers, so this isn't a huge portability issue for the immediate future; however, I endeavor to get things as close to best practices as possible up front. Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PPC4xx ECC Configs, Defines and Source
Does anyone have any strong preferences on where configurations, definitions
and sources for a PPC4xx ECC monitoring and reporting driver should go?
Specifically, this concerns ECC handling code for the IBM DDR2 ECC
controller found in the 405EX[r], 440SP, 440SPe, 460EX and 460GT. However,
I'd like to do this in a way that other ECC contributors and maintainers can
build on.
Static Configs
--
I thought I might leverage the definitions Stefan Roese came up with for
u-boot for the base memory controller:
CONFIG_PPC4xx_IBM_SDRAM: Applicable to 405GP, 405CR, 405EP, AP1000,
and ML2
CONFIG_PPC4xx_IBM_DDR: Applicable to 440GP, 440GX, 440EP, and 440GR
CONFIG_PPC4xx_DENALI_DDR2: Applicable to 440EPX and 440GRX
CONFIG_PPC4xx_IBM_DDR2:Applicable to 405EX[r], 440SP, 440SPe, 460EX
and 460GT.
Controlling whether ECC monitoring and reporting support should be compiled
in or a module:
CONFIG_PPC_ECC or CONFIG_ECC
Dynamic Configs
---
It seems as though the DTS entries for SDRAM0: sdram { compatible = ... }
would need to be expanded to include the above information as well were any
such ECC driver going to attempt to bind to the runtime DTS information.
Perhaps:
compatible = ..., ibm,sdram-4xx-sdram;
compatible = ..., ibm,sdram-4xx-ddr;
compatible = ..., ibm,sdram-4xx-ddr2;
compatible = ..., denali,sdram-4xx-ddr2;
Though, it appears that rainier.dts and sequioia.dts are already evolving in
this direction with:
compatible = ibm,sdram-440grx, ibm,sdram-44x-ddr2denali;
compatible = ibm,sdram-440epx, ibm,sdram-44x-ddr2denali;
In light of that, perhaps then:
compatible = ..., ibm,sdram-4xx;
compatible = ..., ibm,sdram-4xx-ddr;
compatible = ..., ibm,sdram-4xx-ddr2;
compatible = ..., ibm,sdram-4xx-ddr2denali;
Source
--
arch/powerpc/sysdev/
ppc4xx_ibm_sdram_ecc.c [future]
ppc4xx_ibm_ddr_ecc.c [future]
ppc4xx_ibm_ddr2_ecc.c
ppc4xx_ibm_ddr2denali_ecc.c [future]
Headers and Defines
---
arch/powerpc/include/asm/ppc4xx_ibm_ddr2.h
OR
arch/powerpc/sysdev/ppc4xx_ibm_ddr2.h
Thoughts? Comments?
Regards,
Grant
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC4xx ECC Configs, Defines and Source
On 12/8/08 12:21 PM, Josh Boyer wrote: On Mon, Dec 08, 2008 at 11:28:15AM -0800, Grant Erickson wrote: Does anyone have any strong preferences on where configurations, definitions and sources for a PPC4xx ECC monitoring and reporting driver should go? Specifically, this concerns ECC handling code for the IBM DDR2 ECC controller found in the 405EX[r], 440SP, 440SPe, 460EX and 460GT. However, I'd like to do this in a way that other ECC contributors and maintainers can build on. Static Configs -- I thought I might leverage the definitions Stefan Roese came up with for u-boot for the base memory controller: CONFIG_PPC4xx_IBM_SDRAM: Applicable to 405GP, 405CR, 405EP, AP1000, and ML2 CONFIG_PPC4xx_IBM_DDR: Applicable to 440GP, 440GX, 440EP, and 440GR CONFIG_PPC4xx_DENALI_DDR2: Applicable to 440EPX and 440GRX CONFIG_PPC4xx_IBM_DDR2:Applicable to 405EX[r], 440SP, 440SPe, 460EX and 460GT. Config options for what? Enabling certain function? Not sure that's needed if we can get away with it by just binding to the appropriate controller. A good clarifying question. The configs would cover enabling compiled-in or module support for the ECC monitoring and reporting code under discussion. I suspect embedded platforms that do not have ECC would not want to compile support for this. Controlling whether ECC monitoring and reporting support should be compiled in or a module: CONFIG_PPC_ECC or CONFIG_ECC That's a bit too generic, unless you are trying to make a menu list under that which would be used to allow people to enable things like: CONFIG_4XX_ECC, CONFIG_FSL_ECC, etc. I'll have to think about this some more. More elaboration below. Today, we can choose CONFIG_405EX. That nails down CONFIG_PPC4xx_IBM_DDR2 leaving the only open question at that point as to whether CONFIG_ECC is 'y', 'n' or 'm'. That said, I am sure I am thinking too statically about compile-time configuration, however. Source -- arch/powerpc/sysdev/ ppc4xx_ibm_sdram_ecc.c [future] ppc4xx_ibm_ddr_ecc.c [future] ppc4xx_ibm_ddr2_ecc.c ppc4xx_ibm_ddr2denali_ecc.c [future] Why is there a need to have so many files? I would think you could have a single file with all the ECC monitoring implementations in it called ppc4xx_ecc.c (or such). Surely they would share some amount of code? Based on my foggy memory of the 405GP (ibm_sdram_ecc) roughly ten years ago, a cursory look at today's Denali controller (from u-boot code), and the 405EX[r], the ECC handling code for these is all quite different. There will likely be some common, shared code and that could go in something like ppc4xx_ecc.c. My focus is only on the 405EX[r] and the associated DDR2 controller, so further abstraction will probably occur once another controller is integrated. Headers and Defines --- arch/powerpc/include/asm/ppc4xx_ibm_ddr2.h OR arch/powerpc/sysdev/ppc4xx_ibm_ddr2.h That depends on the contents of the file. If it's DCR defines, etc it should be in the dcr-regs.h file. Otherwise, I would think having the header in sysdev should be sufficient unless there is some other facility that would need whatever the contents there are. Thanks for the confirmation. That was my operating assumption. They would be DCR sub-definitions, such as: /* * Macro for generating register field mnemonics */ #define PPC_REG_BITS32 #define PPC_REG_VAL(bit, val) ((val) ((PPC_REG_BITS - 1) - (bit))) /* * Memory controller registers */ #define SDRAM_BESR 0x00/* PLB bus error status (read/clear) */ #define SDRAM_BESRT0x01/* PLB bus error status (test/set) */ #define SDRAM_BEARL0x02/* PLB bus error address low */ #define SDRAM_BEARH0x03/* PLB bus error address high*/ #if !defined(CONFIG_405EX) #define SDRAM_MCSTAT 0x14/* memory controller status */ #else #define SDRAM_MCSTAT 0x1F/* memory controller status */ #endif #define SDRAM_MCOPT1 0x20/* memory controller options 1 */ #define SDRAM_MCOPT2 0x21/* memory controller options 2 */ #define SDRAM_ECCCR0x98/* ECC error status */ #define SDRAM_ECCESSDRAM_ECCCR /* * Memory Controller Bus Error Status */ #define SDRAM_BESR_MASKPPC_REG_VAL(7, 0xFF) #define SDRAM_BESR_M0ID_MASK PPC_REG_VAL(3, 0xF) #define SDRAM_BESR_M0ID_ICUPPC_REG_VAL(3, 0x0) #define SDRAM_BESR_M0ID_PCIE0 PPC_REG_VAL(3, 0x1) #define SDRAM_BESR_M0ID_PCIE1 PPC_REG_VAL(3, 0x2) #define SDRAM_BESR_M0ID_DMAPPC_REG_VAL(3, 0x3) #define SDRAM_BESR_M0ID_DCUPPC_REG_VAL(3, 0x4) #define SDRAM_BESR_M0ID_OPBPPC_REG_VAL(3, 0x5) #define SDRAM_BESR_M0ID_MAL
Re: PPC4xx ECC Configs, Defines and Source
On 12/8/08 3:10 PM, Josh Boyer wrote:
On Mon, 08 Dec 2008 14:08:01 -0800
Grant Erickson [EMAIL PROTECTED] wrote:
Well, at the moment CONFIG_PPC4xx_IBM_DDR2 doesn't exist, and has no
meaning. Adding a Kconfig option for it just so you can select an ECC
option seems superfluous. Because if you select no for ECC, then you
have a Kconfig option that does nothing. You could simply have:
CONFIG_4xx_IBM_DDR2_ECC
or something like that.
Reasonable enough.
I'll buy that. Just start with ppc4xx_ecc.c with your initial support
and then we can refactor as other implementations get added (if they
do).
Sounds good.
SDRAM0: memory-controller {
compatible = ibm,sdram-405ex, ibm,sdram-4xx-ddr2;
dcr-reg = 0x010 0x002;
...
interrupt-parent = SDRAM0;
interrupts = 0x0 0x1;
interrupt-map = /* ECCDED Error */ 0x0 UIC2 0x5 0x4
/* ECCSEC Error */ 0x1 UIC2 0x6 0x4;
...
};
More like this one.
or some such. My DTS expertise is near zero and growing.
That's pretty darn good so far.
Great, thanks.
Just to make sure, are you planning on just implementing a driver to
deal with whatever settings the bootloader configured? E.g., if ECC is
enabled deal with correctable/uncorrectable errors and if not, do
nothing? Basically you are looking to implement a scrub driver, yes?
I ask because since ECC is memory module specific and memory controller
setup is pretty tricky, I think it's best to leave whatever
configuration the bootloader set and work with that. Having to redo
memory controller setups in Linux to enable ECC isn't something I'd
look forward to.
Precisely. The driver will basically check if ECC is enabled (as was set/not
set by u-boot) and, if so, will take ECC SEC/DED interrupts, log SEC errors
to some data structure fetchable by a proc entry or some device node. For
DED errors, execute on some policy, at its simplest, generating a panic.
At no point will the driver/code attempt to change the controller
configuration beyond reading/clearing ECC event/interrupt status.
Regards,
Grant
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC4xx ECC Configs, Defines and Source
On 12/8/08 9:57 PM, Stefan Roese wrote: On Tuesday 09 December 2008, Grant Erickson wrote: Just to make sure, are you planning on just implementing a driver to deal with whatever settings the bootloader configured? E.g., if ECC is enabled deal with correctable/uncorrectable errors and if not, do nothing? Basically you are looking to implement a scrub driver, yes? I ask because since ECC is memory module specific and memory controller setup is pretty tricky, I think it's best to leave whatever configuration the bootloader set and work with that. Having to redo memory controller setups in Linux to enable ECC isn't something I'd look forward to. Precisely. The driver will basically check if ECC is enabled (as was set/not set by u-boot) and, if so, will take ECC SEC/DED interrupts, log SEC errors to some data structure fetchable by a proc entry or some device node. For DED errors, execute on some policy, at its simplest, generating a panic. At no point will the driver/code attempt to change the controller configuration beyond reading/clearing ECC event/interrupt status. Seems that such a driver should be implemented in the Linux EDAC subsystem (see drivers/edac and Documentation/edac.txt) to me. Did you take a look at this? Stefan: Thanks for the reference. I will give this a closer examination. At first glance, this looks promising. Somehow, this managed to escape my Google search dragnet. Their project team may need to work on their page keywords. Thanks again, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
This merges support for the previously DENX-only kernel feature of
specifying an alternative, external buffer for kernel printk
messages and their associated metadata. In addition, this ports
architecture support for this feature from arch/ppc to arch/powerpc.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
When this option is enabled, an architecture- or machine-specific log
buffer is used for all printk messages. This allows entities such as
boot loaders (e.g. U-Boot) to place printk-compatible messages into
this buffer and for the kernel to coalesce them with its normal
messages.
The code has historically been used and proven to work on the LWMON5
platform under arch/ppc and is now used (by me) successfully on the
AMCC Haleakala and Kilauea platforms.
As implemented for arch/powerpc, two suboptions for the alternative
log buffer are supported. The buffer may be contiguous with the
metadata and message data colocated or the metadata and message
storage may be in discontiguous regions of memory (e.g. a set of
scratch registers and an SRAM buffer). On Kilauea and Haleakala, I
have used the former; whereas LWMON5 has traditionally used the latter.
The code here is, more or less, as-is from the DENX GIT tree. Comments
welcome.
arch/powerpc/kernel/prom.c | 93 +++
include/linux/logbuff.h| 56
init/Kconfig | 25 +++
init/main.c|4 +
kernel/printk.c| 149 +++-
5 files changed, 324 insertions(+), 3 deletions(-)
create mode 100644 include/linux/logbuff.h
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 3a2dc7e..60282f1 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include linux/debugfs.h
#include linux/irq.h
#include linux/lmb.h
+#include linux/logbuff.h
#include asm/prom.h
#include asm/rtas.h
@@ -61,6 +62,15 @@
#define DBG(fmt...)
#endif
+#ifdef CONFIG_LOGBUFFER
+#ifdef CONFIG_ALT_LB_LOCATION
+# if !defined(BOARD_ALT_LH_ADDR) || !defined(BOARD_ALT_LB_ADDR)
+# error Please specify BOARD_ALT_LH_ADDR BOARD_ALT_LB_ADDR.
+# endif
+#else /* !CONFIG_ALT_LB_LOCATION */
+static phys_addr_t ext_logbuff;
+#endif /* CONFIG_ALT_LB_LOCATION */
+#endif /* CONFIG_LOGBUFFER */
static int __initdata dt_root_addr_cells;
static int __initdata dt_root_size_cells;
@@ -1018,6 +1028,85 @@ static int __init early_init_dt_scan_memory(unsigned
long node,
return 0;
}
+#ifdef CONFIG_LOGBUFFER
+#ifdef CONFIG_ALT_LB_LOCATION
+/* Alternative external log buffer mapping: log metadata header the
+ * character buffer are separated and allocated not in RAM but in some
+ * other memory-mapped I/O region (e.g. log head in unused registers,
+ * and log buffer in OCM memory)
+ */
+int __init setup_ext_logbuff_mem(volatile logbuff_t **lhead, char **lbuf)
+{
+ void *h, *b;
+
+ if (unlikely(!lhead) || unlikely(!lbuf))
+ return -EINVAL;
+
+ /* map log head */
+ h = ioremap(BOARD_ALT_LH_ADDR, sizeof(logbuff_t));
+ if (unlikely(!h))
+ return -EFAULT;
+
+ /* map log buffer */
+ b = ioremap(BOARD_ALT_LB_ADDR, LOGBUFF_LEN);
+ if (unlikely(!b)) {
+ iounmap(h);
+ return -EFAULT;
+ }
+
+ *lhead = h;
+ *lbuf = b;
+
+ return 0;
+}
+#else /* !CONFIG_ALT_LB_LOCATION */
+/* Usual external log-buffer mapping: log metadata header the character
+ * buffer are both contiguous in system RAM.
+ */
+int __init setup_ext_logbuff_mem(logbuff_t **lhead, char **lbuf)
+{
+ void *p;
+
+ if (unlikely(!lhead) || unlikely(!lbuf))
+ return -EINVAL;
+
+ if (unlikely(!ext_logbuff) || !lmb_is_reserved(ext_logbuff))
+ return -EFAULT;
+
+ p = ioremap(ext_logbuff, LOGBUFF_RESERVE);
+
+ if (unlikely(!p))
+ return -EFAULT;
+
+ *lhead = (logbuff_t *)(p + LOGBUFF_OVERHEAD -
+ sizeof(logbuff_t) +
+ sizeof(((logbuff_t *)0)-buf));
+ *lbuf = (*lhead)-buf;
+
+ return 0;
+}
+
+/* When the external log buffer configuration is used with the
+ * non-alternate location, the log head metadata and character buffer
+ * lie in the LOGBUFF_RESERVE bytes at the end of system RAM. Add this
+ * block of memory to the reserved memory pool so that it is not
+ * allocated for other purposes.
+ */
+static void __init reserve_ext_logbuff_mem(void)
+{
+ phys_addr_t top = lmb_end_of_DRAM();
+ phys_addr_t size = LOGBUFF_RESERVE;
+ phys_addr_t base = top - size;
+
+ if (top base) {
+ ext_logbuff = base;
+ DBG(reserving: %x - %x\n, base, size);
+ lmb_reserve(base, size);
+ }
+}
+#endif /* CONFIG_ALT_LB_LOCATION */
+#endif /* CONFIG_LOGBUFFER */
+
static void __init early_reserve_mem(void)
{
u64 base, size
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On 11/25/08 10:55 AM, Josh Boyer wrote: On Tue, 25 Nov 2008 12:53:12 -0600 Matt Sealey [EMAIL PROTECTED] wrote: Nitpick, really.. shouldn't the logbuffer location(s) be some device tree property(ies), perhaps something in the /chosen node that U-Boot etc. can then fill out? I don't think that's a nitpick. It's a fundamental change in how this would all work. However, I do think you're generally right. Perhaps not /chosen, but maybe something like /rtas or /firmware, etc. I'm inclined to agree with you both; however, the submitted implementation was a choice of expediency given the existing DENX implementation and a customer that needed the feature yesterday. ARM, MIPS, et al have not yet adopted device trees, correct? If so, is there value in providing the submitted implementation and adding support for getting said information from the device tree as another option if such information exists? Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PPC40x: Limit Allocable RAM During Early Mapping
On 10/30/08 7:03 AM, Josh Boyer wrote: On Wed, 29 Oct 2008 14:41:14 -0700 Grant Erickson [EMAIL PROTECTED] wrote: If the size of RAM is not an exact power of two, we may not have covered RAM in its entirety with large 16 and 4 MiB pages. Consequently, restrict the top end of RAM currently allocable by updating '__initial_memory_limit_addr' so that calls to the LMB to allocate PTEs for tail coverage with normal-sized pages (or other reasons) do not attempt to allocate outside the allowed range. Nice catch. I was looking to see if 44x had the same problem, but I don't think it does because we simply over-map DRAM there. Does that seem correct to you, or am I missing something on 44x that would cause this same problem? Josh, Because I do not have 44x hardware to validate against and because this particular fix was localized to the 40x path, I did not take the time to walk through the 44x path. Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PPC40x: Limit Allocable RAM During Early Mapping
If the size of RAM is not an exact power of two, we may not have
covered RAM in its entirety with large 16 and 4 MiB
pages. Consequently, restrict the top end of RAM currently allocable
by updating '__initial_memory_limit_addr' so that calls to the LMB to
allocate PTEs for tail coverage with normal-sized pages (or other
reasons) do not attempt to allocate outside the allowed range.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
This bug was discovered in the course of working on CONFIG_LOGBUFFER support
(see http://ozlabs.org/pipermail/linuxppc-dev/2008-October/064685.html).
However, the bug is triggered quite easily independent of that feature
by placing a memory limit via the 'mem=' kernel command line that results in
a memory size that is not equal to an exact power of two.
For example, on the AMCC PowerPC 405EXr Haleakala board with 256 MiB
of RAM, mmu_mapin_ram() normally covers RAM with precisely 16 16 MiB
large pages. However, if a memory limit of 256 MiB - 20 KiB (as might
be the case for CONFIG_LOGBUFFER) is put in place with
mem=268414976, then large pages only cover (16 MiB * 15) + (4 MiB *
3) = 252 MiB with a 4 MiB - 20 KiB tail to cover with normal, 4 KiB
pages via map_page().
Unfortunately, if __initial_memory_limit_addr is not updated from its
initial value of 0x1000 (256 MiB) to reflect what was actually
mapped via mmu_mapin_ram(), the following happens during the tail
mapping when the first PTE is allocated at 0xFFF A000 (rather than the
desired 0xFBF F000):
mapin_ram
mmu_mapin_ram
map_page
pte_alloc_kernel
pte_alloc_one_kernel
early_get_page
lmb_alloc_base
clear_page
clear_pages
dcbz0,page -- BOOM!
a non-recoverable page fault.
arch/powerpc/mm/40x_mmu.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/40x_mmu.c b/arch/powerpc/mm/40x_mmu.c
index cecbbc7..29954dc 100644
--- a/arch/powerpc/mm/40x_mmu.c
+++ b/arch/powerpc/mm/40x_mmu.c
@@ -93,7 +93,7 @@ void __init MMU_init_hw(void)
unsigned long __init mmu_mapin_ram(void)
{
- unsigned long v, s;
+ unsigned long v, s, mapped;
phys_addr_t p;
v = KERNELBASE;
@@ -130,5 +130,17 @@ unsigned long __init mmu_mapin_ram(void)
s -= LARGE_PAGE_SIZE_4M;
}
- return total_lowmem - s;
+ mapped = total_lowmem - s;
+
+ /* If the size of RAM is not an exact power of two, we may not
+* have covered RAM in its entirety with 16 and 4 MiB
+* pages. Consequently, restrict the top end of RAM currently
+* allocable so that calls to the LMB to allocate PTEs for tail
+* coverage with normal-sized pages (or other reasons) do not
+* attempt to allocate outside the allowed range.
+*/
+
+ __initial_memory_limit_addr = memstart_addr + mapped;
+
+ return mapped;
}
--
1.6.0.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Reserving Early RAM Regions and Porting Denx's CONFIG_LOGBUFFER to arch/powerpc
I am working on attempting to migrate the Denx CONFIG_LOGBUFFER feature from arch/ppc: http://git.denx.de/?p=linux-2.6-denx.git;a=blob_plain;f=arch/ppc/mm/init.c;h b=3df65660bbfa769b10b141351b0ea10427b0b709 http://git.denx.de/?p=linux-2.6-denx.git;a=blob_plain;f=kernel/printk.c;hb=3 df65660bbfa769b10b141351b0ea10427b0b709 In the historical implementation, basically, u-boot (if so configured) allocates 16 KiB + 4 KiB of memory at the end of physical RAM to store log messages that are compatible with the Linux kernel's printk. When Linux (if so configured with CONFIG_LOGBUFFER) starts up, it redirects the normal log_buf to this external log buffer and appends any existing printk messages to those already pushed by u-boot. Future printk messages are then sent off to this new external log buffer. What is the preferred method for hiding/reserving chunks of memory such as this during early boot? The device tree? The 'mem=' parameter? Adding an lmb_reserve() in prom.c:early_reserve_mem()? Twiddling things auto-magically such as the historical implementation? Some combination thereof? The arch/ppc historical implementation simply twiddled total_memory and total_lowmem and then ioremap'd the 20 KiB off the end of memory. However, such an approach in arch/powerpc falters because an attempt to prematurely reduce total_lowmem results in mapin_ram(), via mmu_mapin_ram(), only covering part of the total, say 128 MiB or 256 MiB, RAM with 16 MiB and 4 MiB large pages, leaving a residual, of say 4 MiB, to cover with smaller 4 KiB map_page() pages. However, when map_page() runs, it eventually calls lmb_alloc_base() which returns a page in that 4 MiB tail unmapped region. This then explodes due to a page fault when clear_page() is called on the page in unmapped RAM at the dcbz instruction in clear_pages(). Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
This patch adds support to the RGMII handler in the EMAC driver for
the MII PHY mode such that device tree entries of the form `phy-mode = mii;'
are recognized and handled appropriately.
While logically, in software, gmii and mii modes are the same,
they are wired differently, so it makes sense to allow DTS authors to
specify each explicitly.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/rgmii.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index e32da3d..5acb006 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -39,6 +39,7 @@
#define RGMII_FER_RGMII(idx) (0x5 ((idx) * 4))
#define RGMII_FER_TBI(idx) (0x6 ((idx) * 4))
#define RGMII_FER_GMII(idx)(0x7 ((idx) * 4))
+#define RGMII_FER_MII(idx) RGMII_FER_GMII(idx)
/* RGMIIx_SSR */
#define RGMII_SSR_MASK(idx)(0x7 ((idx) * 8))
@@ -49,6 +50,7 @@
static inline int rgmii_valid_mode(int phy_mode)
{
return phy_mode == PHY_MODE_GMII ||
+ phy_mode == PHY_MODE_MII ||
phy_mode == PHY_MODE_RGMII ||
phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
@@ -63,6 +65,8 @@ static inline const char *rgmii_mode_name(int mode)
return TBI;
case PHY_MODE_GMII:
return GMII;
+ case PHY_MODE_MII:
+ return MII;
case PHY_MODE_RTBI:
return RTBI;
default:
@@ -79,6 +83,8 @@ static inline u32 rgmii_mode_mask(int mode, int input)
return RGMII_FER_TBI(input);
case PHY_MODE_GMII:
return RGMII_FER_GMII(input);
+ case PHY_MODE_MII:
+ return RGMII_FER_MII(input);
case PHY_MODE_RTBI:
return RGMII_FER_RTBI(input);
default:
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5] ibm_newemac: Parameterize EMAC Multicast Match Handling
On 7/7/08 12:50 PM, Valentine Barshak wrote: Grant Erickson wrote: snip -reg = ef600a00 70; +reg = ef600900 c4; Should be reg = ef600a00 c4 snip -reg = ef600a00 70; +reg = ef600900 c4; Should be reg = ef600a00 c4 Good catch; amended patch forthcoming. Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v6] ibm_newemac: Parameterize EMAC Multicast Match Handling
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs have 4 IAHT and
GAHT 32-bit registers, starting at offset 0x30 from the register base,
with only 16-bits of each used for a total of 64 match slots.
The 405EX(r) and 460EX now use the EMAC4SYNC core rather than the EMAC4
core. This core has 8 IAHT and GAHT registers, starting at offset 0x80
from the register base, with ALL 32-bits of each used for a total of
256 match slots.
This adds a new compatible device tree entry emac4sync and a new,
related feature flag EMAC_FTR_EMAC4SYNC along with a series of macros
and inlines which supply the appropriate parameterized value based on
the presence or absence of the EMAC4SYNC feature.
The code has further been reworked where appropriate to use those macros
and inlines.
In addition, the register size passed to ioremap is now taken from the
device tree:
c4 for EMAC4SYNC cores
74 for EMAC4 cores
70 for EMAC cores
rather than sizeof (emac_regs).
Finally, the device trees have been updated with the appropriate compatible
entries and resource sizes.
This has been tested on an AMCC Haleakala board such that: 1) inbound
ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11
and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from
'haleakala.local' to those same systems in the '.local' domain via MDNS
now work.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/canyonlands.dts |8 +-
arch/powerpc/boot/dts/glacier.dts |8 +-
arch/powerpc/boot/dts/haleakala.dts |4 +-
arch/powerpc/boot/dts/katmai.dts |2 +-
arch/powerpc/boot/dts/kilauea.dts |8 +-
arch/powerpc/boot/dts/makalu.dts |8 +-
arch/powerpc/boot/dts/rainier.dts |4 +-
arch/powerpc/boot/dts/sequoia.dts |4 +-
arch/powerpc/boot/dts/taishan.dts |8 +-
drivers/net/ibm_newemac/core.c| 61 ++--
drivers/net/ibm_newemac/core.h| 83 ++-
drivers/net/ibm_newemac/debug.c | 52 +
drivers/net/ibm_newemac/emac.h| 101 ++--
13 files changed, 259 insertions(+), 92 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 3963412..8b82d47 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -264,7 +264,7 @@
EMAC0: [EMAIL PROTECTED] {
device_type = network;
- compatible = ibm,emac-460ex, ibm,emac4;
+ compatible = ibm,emac-460ex, ibm,emac4sync;
interrupt-parent = EMAC0;
interrupts = 0 1;
#interrupt-cells = 1;
@@ -272,7 +272,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4;
- reg = ef600e00 70;
+ reg = ef600e00 c4;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 0;
@@ -293,7 +293,7 @@
EMAC1: [EMAIL PROTECTED] {
device_type = network;
- compatible = ibm,emac-460ex, ibm,emac4;
+ compatible = ibm,emac-460ex, ibm,emac4sync;
interrupt-parent = EMAC1;
interrupts = 0 1;
#interrupt-cells = 1;
@@ -301,7 +301,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 11 4
/*Wake*/ 1 UIC2 15 4;
- reg = ef600f00 70;
+ reg = ef600f00 c4;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 1;
diff --git a/arch/powerpc/boot/dts/glacier.dts
b/arch/powerpc/boot/dts/glacier.dts
index 0f2fc07..8ffde9b 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -281,7 +281,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4
[PATCH] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
This patch adds support to the RGMII handler in the EMAC driver for
the MII PHY mode such that device tree entries of the form `phy-mode = mii;'
are recognized and handled appropriately.
While logically, in software, gmii and mii modes are the same,
they are wired differently, so it makes sense to allow DTS authors to
specify each explicitly.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/rgmii.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index e32da3d..5acb006 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -39,6 +39,7 @@
#define RGMII_FER_RGMII(idx) (0x5 ((idx) * 4))
#define RGMII_FER_TBI(idx) (0x6 ((idx) * 4))
#define RGMII_FER_GMII(idx)(0x7 ((idx) * 4))
+#define RGMII_FER_MII(idx) (0x7 ((idx) * 4))
/* RGMIIx_SSR */
#define RGMII_SSR_MASK(idx)(0x7 ((idx) * 8))
@@ -49,6 +50,7 @@
static inline int rgmii_valid_mode(int phy_mode)
{
return phy_mode == PHY_MODE_GMII ||
+ phy_mode == PHY_MODE_MII ||
phy_mode == PHY_MODE_RGMII ||
phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
@@ -63,6 +65,8 @@ static inline const char *rgmii_mode_name(int mode)
return TBI;
case PHY_MODE_GMII:
return GMII;
+ case PHY_MODE_MII:
+ return MII;
case PHY_MODE_RTBI:
return RTBI;
default:
@@ -79,6 +83,8 @@ static inline u32 rgmii_mode_mask(int mode, int input)
return RGMII_FER_TBI(input);
case PHY_MODE_GMII:
return RGMII_FER_GMII(input);
+ case PHY_MODE_MII:
+ return RGMII_FER_MII(input);
case PHY_MODE_RTBI:
return RGMII_FER_RTBI(input);
default:
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
On 7/7/08 4:40 PM, Benjamin Herrenschmidt wrote: On Mon, 2008-07-07 at 16:31 -0700, Grant Erickson wrote: #define RGMII_FER_GMII(idx)(0x7 ((idx) * 4)) +#define RGMII_FER_MII(idx) (0x7 ((idx) * 4)) Hrm... the setting of the register is exactly the same right ? Do we -really- need that ? Would you prefer? +#define RGMII_FER_MII(idx) RGMII_FER_GMII(idx) Having the extra mnemonic makes the code end up looking less like a typo and more like a conscious decision: Yes, we know MII and GMII are the same setting, but we're being explicit about it. -Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5] ibm_newemac: Parameterize EMAC Multicast Match Handling
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs have 4 IAHT and
GAHT 32-bit registers, starting at offset 0x30 from the register base,
with only 16-bits of each used for a total of 64 match slots.
The 405EX(r) and 460EX now use the EMAC4SYNC core rather than the EMAC4
core. This core has 8 IAHT and GAHT registers, starting at offset 0x80
from the register base, with ALL 32-bits of each used for a total of
256 match slots.
This adds a new compatible device tree entry emac4sync and a new,
related feature flag EMAC_FTR_EMAC4SYNC along with a series of macros
and inlines which supply the appropriate parameterized value based on
the presence or absence of the EMAC4SYNC feature.
The code has further been reworked where appropriate to use those macros
and inlines.
In addition, the register size passed to ioremap is now taken from the
device tree:
c4 for EMAC4SYNC cores
74 for EMAC4 cores
70 for EMAC cores
rather than sizeof (emac_regs).
Finally, the device trees have been updated with the appropriate compatible
entries and resource sizes.
This has been tested on an AMCC Haleakala board such that: 1) inbound
ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11
and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from
'haleakala.local' to those same systems in the '.local' domain via MDNS
now work.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/canyonlands.dts |8 +-
arch/powerpc/boot/dts/glacier.dts |8 +-
arch/powerpc/boot/dts/haleakala.dts |4 +-
arch/powerpc/boot/dts/katmai.dts |2 +-
arch/powerpc/boot/dts/kilauea.dts |8 +-
arch/powerpc/boot/dts/makalu.dts |8 +-
arch/powerpc/boot/dts/rainier.dts |4 +-
arch/powerpc/boot/dts/sequoia.dts |4 +-
arch/powerpc/boot/dts/taishan.dts |8 +-
drivers/net/ibm_newemac/core.c| 61 ++--
drivers/net/ibm_newemac/core.h| 83 ++-
drivers/net/ibm_newemac/debug.c | 52 +
drivers/net/ibm_newemac/emac.h| 101 ++--
13 files changed, 259 insertions(+), 92 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 3963412..8b82d47 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -264,7 +264,7 @@
EMAC0: [EMAIL PROTECTED] {
device_type = network;
- compatible = ibm,emac-460ex, ibm,emac4;
+ compatible = ibm,emac-460ex, ibm,emac4sync;
interrupt-parent = EMAC0;
interrupts = 0 1;
#interrupt-cells = 1;
@@ -272,7 +272,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4;
- reg = ef600e00 70;
+ reg = ef600e00 c4;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 0;
@@ -293,7 +293,7 @@
EMAC1: [EMAIL PROTECTED] {
device_type = network;
- compatible = ibm,emac-460ex, ibm,emac4;
+ compatible = ibm,emac-460ex, ibm,emac4sync;
interrupt-parent = EMAC1;
interrupts = 0 1;
#interrupt-cells = 1;
@@ -301,7 +301,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 11 4
/*Wake*/ 1 UIC2 15 4;
- reg = ef600f00 70;
+ reg = ef600f00 c4;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 1;
diff --git a/arch/powerpc/boot/dts/glacier.dts
b/arch/powerpc/boot/dts/glacier.dts
index 0f2fc07..8ffde9b 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -281,7 +281,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4
[PATCH v3] ibm_newemac: Parameterize EMAC Multicast Match Handling
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs have 4 IAHT and
GAHT 32-bit registers, starting at offset 0x30 from the register base,
with only 16-bits of each used for a total of 64 match slots.
The 405EX(r) and 460EX now use the EMAC4SYNC core rather than the EMAC4
core. This core has 8 IAHT and GAHT registers, starting at offset 0x80
from the register base, with ALL 32-bits of each used for a total of
256 match slots.
This adds a new compatible device tree entry emac4sync and a new,
related feature flag EMAC_FTR_EMAC4SYNC along with a series of macros
and inlines which supply the appropriate parameterized value based on
the presence or absence of the EMAC4SYNC feature.
The code has further been reworked where appropriate to use those macros
and inlines.
In addition, the register size passed to ioremap is now taken from the
device tree:
c0 for EMAC4SYNC cores
74 for EMAC4 cores
70 for EMAC cores
rather than sizeof (emac_regs).
Finally, the device trees have been updated with the appropriate compatible
entries and resource sizes.
This has been tested on an AMCC Haleakala board such that: 1) inbound
ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11
and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from
'haleakala.local' to those same systems in the '.local' domain via MDNS
now work.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/canyonlands.dts |8 ++--
arch/powerpc/boot/dts/glacier.dts |8 ++--
arch/powerpc/boot/dts/haleakala.dts |4 +-
arch/powerpc/boot/dts/katmai.dts |2 +-
arch/powerpc/boot/dts/kilauea.dts |8 ++--
arch/powerpc/boot/dts/makalu.dts |8 ++--
arch/powerpc/boot/dts/rainier.dts |4 +-
arch/powerpc/boot/dts/sequoia.dts |4 +-
arch/powerpc/boot/dts/taishan.dts |8 ++--
drivers/net/ibm_newemac/core.c| 60 +---
drivers/net/ibm_newemac/core.h| 83 -
drivers/net/ibm_newemac/debug.c | 32 -
drivers/net/ibm_newemac/emac.h| 15 +--
13 files changed, 172 insertions(+), 72 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 3963412..b2811ea 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -264,7 +264,7 @@
EMAC0: [EMAIL PROTECTED] {
device_type = network;
- compatible = ibm,emac-460ex, ibm,emac4;
+ compatible = ibm,emac-460ex, ibm,emac4sync;
interrupt-parent = EMAC0;
interrupts = 0 1;
#interrupt-cells = 1;
@@ -272,7 +272,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4;
- reg = ef600e00 70;
+ reg = ef600e00 c0;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 0;
@@ -293,7 +293,7 @@
EMAC1: [EMAIL PROTECTED] {
device_type = network;
- compatible = ibm,emac-460ex, ibm,emac4;
+ compatible = ibm,emac-460ex, ibm,emac4sync;
interrupt-parent = EMAC1;
interrupts = 0 1;
#interrupt-cells = 1;
@@ -301,7 +301,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 11 4
/*Wake*/ 1 UIC2 15 4;
- reg = ef600f00 70;
+ reg = ef600f00 c0;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 1;
diff --git a/arch/powerpc/boot/dts/glacier.dts
b/arch/powerpc/boot/dts/glacier.dts
index 0f2fc07..8ffde9b 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -281,7 +281,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4
[PATCH v4] ibm_newemac: Parameterize EMAC Multicast Match Handling
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs have 4 IAHT and
GAHT 32-bit registers, starting at offset 0x30 from the register base,
with only 16-bits of each used for a total of 64 match slots.
The 405EX(r) and 460EX now use the EMAC4SYNC core rather than the EMAC4
core. This core has 8 IAHT and GAHT registers, starting at offset 0x80
from the register base, with ALL 32-bits of each used for a total of
256 match slots.
This adds a new compatible device tree entry emac4sync and a new,
related feature flag EMAC_FTR_EMAC4SYNC along with a series of macros
and inlines which supply the appropriate parameterized value based on
the presence or absence of the EMAC4SYNC feature.
The code has further been reworked where appropriate to use those macros
and inlines.
In addition, the register size passed to ioremap is now taken from the
device tree:
c4 for EMAC4SYNC cores
74 for EMAC4 cores
70 for EMAC cores
rather than sizeof (emac_regs).
Finally, the device trees have been updated with the appropriate compatible
entries and resource sizes.
This has been tested on an AMCC Haleakala board such that: 1) inbound
ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11
and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from
'haleakala.local' to those same systems in the '.local' domain via MDNS
now work.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/canyonlands.dts |8 ++--
arch/powerpc/boot/dts/glacier.dts |8 ++--
arch/powerpc/boot/dts/haleakala.dts |4 +-
arch/powerpc/boot/dts/katmai.dts |2 +-
arch/powerpc/boot/dts/kilauea.dts |8 ++--
arch/powerpc/boot/dts/makalu.dts |8 ++--
arch/powerpc/boot/dts/rainier.dts |4 +-
arch/powerpc/boot/dts/sequoia.dts |4 +-
arch/powerpc/boot/dts/taishan.dts |8 ++--
drivers/net/ibm_newemac/core.c| 60 ++--
drivers/net/ibm_newemac/core.h| 83 -
drivers/net/ibm_newemac/debug.c | 30 +++
drivers/net/ibm_newemac/emac.h| 96
13 files changed, 230 insertions(+), 93 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 3963412..8b82d47 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -264,7 +264,7 @@
EMAC0: [EMAIL PROTECTED] {
device_type = network;
- compatible = ibm,emac-460ex, ibm,emac4;
+ compatible = ibm,emac-460ex, ibm,emac4sync;
interrupt-parent = EMAC0;
interrupts = 0 1;
#interrupt-cells = 1;
@@ -272,7 +272,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4;
- reg = ef600e00 70;
+ reg = ef600e00 c4;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 0;
@@ -293,7 +293,7 @@
EMAC1: [EMAIL PROTECTED] {
device_type = network;
- compatible = ibm,emac-460ex, ibm,emac4;
+ compatible = ibm,emac-460ex, ibm,emac4sync;
interrupt-parent = EMAC1;
interrupts = 0 1;
#interrupt-cells = 1;
@@ -301,7 +301,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 11 4
/*Wake*/ 1 UIC2 15 4;
- reg = ef600f00 70;
+ reg = ef600f00 c4;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 1;
diff --git a/arch/powerpc/boot/dts/glacier.dts
b/arch/powerpc/boot/dts/glacier.dts
index 0f2fc07..8ffde9b 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -281,7 +281,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4
Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
On 6/30/08 11:37 PM, Stefan Roese wrote: On Tuesday 01 July 2008, Benjamin Herrenschmidt wrote: Stefan and/or Ben: Any thoughts on this? I was hesitating a bit... do we really need to be -that- flexible ? That is, either that or use some new compatible entry to detect the new reg layout and whack that as a feature bit instead ? The advantage of the later is that we have the possibility of doing conditional compile for kernels that support only a given processor or set of processors (not that we have implemented much of it, but it just becomes Kconfig mumbo jumbo and a little bit of defines in the .h by turning the feature test into a compile-time 0 or 1. But this isn't a hot path and not a lot of code so maybe not worth bothering... however, it does add 3 properties to the DT and I know embedded people (especially Xilinx) are a bit concerned about the size of the DT when they try to fit it in block RAM... Yes, this was my feeling too. Not the size of the dtb but more the increased complexity of the EMAC device node. I would prefer Ben's idea with this new compatible entry too. In terms of the device tree expression, you would both favor something akin to the following? - compatible = ibm,emac-405exr, ibm,emac4; + compatible = ibm,emac-405exr, ibm,emac4, ibm,emac4sync; Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
On 6/24/08 5:08 PM, Grant Erickson wrote: Various instances of the EMAC core have varying: 1) number of address match slots, 2) width of the registers for handling address match slots, 3) number of registers for handling address match slots and 4) base offset for those registers. As the driver stands today, it assumes that all EMACs have 4 IAHT and GAHT 32-bit registers, starting at offset 0x30 from the register base, with only 16-bits of each used for a total of 64 match slots. The 405EX(r) and 460 now use the EMAC4SYNC core rather than the EMAC4 core. This core has 8 IAHT and GAHT registers, starting at offset 0x80 from the register base, with ALL 32-bits of each used for a total of 256 match slots. This adds macros and inlines for handling these differences based on three parameters parsed from the device tree: xaht-slots-shift xaht-width-shift xaht-base-offset and reworks the code, where appropriate to use those macros and inlines. EMAC/EMAC4 values are defaulted for these keys if missing, resulting in a driver that works as today's does for all cores. In addition the register size passed to ioremap is now taken from the device tree: c0 for EMAC4SYNC cores 74 for EMAC4 cores 70 for EMAC cores rathaer than sizeof (emac_regs). Finally, the device trees have been updated with the appropriate xaht-* keys and values. This has been tested on an AMCC Haleakala board such that: 1) inbound ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11 and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from 'haleakala.local' to those same systems in the '.local' domain via MDNS now work. Signed-off-by: Grant Erickson [EMAIL PROTECTED] --- arch/powerpc/boot/dts/bamboo.dts |6 +++ arch/powerpc/boot/dts/canyonlands.dts | 10 - arch/powerpc/boot/dts/ebony.dts |6 +++ arch/powerpc/boot/dts/ep405.dts |3 ++ arch/powerpc/boot/dts/glacier.dts | 20 +-- arch/powerpc/boot/dts/haleakala.dts |5 ++- arch/powerpc/boot/dts/katmai.dts |5 ++- arch/powerpc/boot/dts/kilauea.dts | 10 - arch/powerpc/boot/dts/makalu.dts | 10 - arch/powerpc/boot/dts/rainier.dts | 10 - arch/powerpc/boot/dts/sequoia.dts | 10 - arch/powerpc/boot/dts/taishan.dts | 20 +-- arch/powerpc/boot/dts/walnut.dts |3 ++ arch/powerpc/boot/dts/warp.dts|3 ++ drivers/net/ibm_newemac/core.c| 55 +++-- drivers/net/ibm_newemac/core.h| 61 + drivers/net/ibm_newemac/debug.c | 32 +++-- drivers/net/ibm_newemac/emac.h| 15 +--- 18 files changed, 219 insertions(+), 65 deletions(-) Stefan and/or Ben: Any thoughts on this? Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Parameterize EMAC Multicast Match Handling
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs have 4 IAHT and
GAHT 32-bit registers, starting at offset 0x30 from the register base,
with only 16-bits of each used for a total of 64 match slots.
The 405EX(r) and 460 now use the EMAC4SYNC core rather than the EMAC4
core. This core has 8 IAHT and GAHT registers, starting at offset 0x80
from the register base, with ALL 32-bits of each used for a total of
256 match slots.
This adds macros and inlines for handling these differences based on
three parameters parsed from the device tree:
xaht-slots-shift
xaht-width-shift
xaht-base-offset
and reworks the code, where appropriate to use those macros and inlines.
EMAC/EMAC4 values are defaulted for these keys if missing, resulting in
a driver that works as today's does for all cores.
In addition the register size passed to ioremap is now taken from the
device tree:
c0 for EMAC4SYNC cores
74 for EMAC4 cores
70 for EMAC cores
rathaer than sizeof (emac_regs).
Finally, the device trees have been updated with the appropriate xaht-*
keys and values.
This has been tested on an AMCC Haleakala board such that: 1) inbound
ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11
and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from
'haleakala.local' to those same systems in the '.local' domain via MDNS
now work.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/bamboo.dts |6 +++
arch/powerpc/boot/dts/canyonlands.dts | 10 -
arch/powerpc/boot/dts/ebony.dts |6 +++
arch/powerpc/boot/dts/ep405.dts |3 ++
arch/powerpc/boot/dts/glacier.dts | 20 +--
arch/powerpc/boot/dts/haleakala.dts |5 ++-
arch/powerpc/boot/dts/katmai.dts |5 ++-
arch/powerpc/boot/dts/kilauea.dts | 10 -
arch/powerpc/boot/dts/makalu.dts | 10 -
arch/powerpc/boot/dts/rainier.dts | 10 -
arch/powerpc/boot/dts/sequoia.dts | 10 -
arch/powerpc/boot/dts/taishan.dts | 20 +--
arch/powerpc/boot/dts/walnut.dts |3 ++
arch/powerpc/boot/dts/warp.dts|3 ++
drivers/net/ibm_newemac/core.c| 55 +++--
drivers/net/ibm_newemac/core.h| 61 +
drivers/net/ibm_newemac/debug.c | 32 +++--
drivers/net/ibm_newemac/emac.h| 15 +---
18 files changed, 219 insertions(+), 65 deletions(-)
diff --git a/arch/powerpc/boot/dts/bamboo.dts b/arch/powerpc/boot/dts/bamboo.dts
index ba2521b..200a4ec 100644
--- a/arch/powerpc/boot/dts/bamboo.dts
+++ b/arch/powerpc/boot/dts/bamboo.dts
@@ -221,6 +221,9 @@
phy-map = ;
zmii-device = ZMII0;
zmii-channel = 0;
+ xaht-base-offset = 30;
+ xaht-slots-shift = 6;
+ xaht-width-shift = 4;
};
EMAC1: [EMAIL PROTECTED] {
@@ -241,6 +244,9 @@
phy-map = ;
zmii-device = ZMII0;
zmii-channel = 1;
+ xaht-base-offset = 30;
+ xaht-slots-shift = 6;
+ xaht-width-shift = 4;
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 3963412..75ff768 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -272,7 +272,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4;
- reg = ef600e00 70;
+ reg = ef600e00 74;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 0;
@@ -287,6 +287,9 @@
rgmii-channel = 0;
tah-device = TAH0;
tah-channel = 0;
+ xaht-base-offset = 80;
+ xaht-slots-shift = 8;
+ xaht-width-shift = 5;
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
@@ -301,7 +304,7
[PATCH v2] Parameterize EMAC Multicast Match Handling
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs have 4 IAHT and
GAHT 32-bit registers, starting at offset 0x30 from the register base,
with only 16-bits of each used for a total of 64 match slots.
The 405EX(r) and 460 now use the EMAC4SYNC core rather than the EMAC4
core. This core has 8 IAHT and GAHT registers, starting at offset 0x80
from the register base, with ALL 32-bits of each used for a total of
256 match slots.
This adds macros and inlines for handling these differences based on
three parameters parsed from the device tree:
xaht-slots-shift
xaht-width-shift
xaht-base-offset
and reworks the code, where appropriate to use those macros and inlines.
EMAC/EMAC4 values are defaulted for these keys if missing, resulting in
a driver that works as today's does for all cores.
In addition the register size passed to ioremap is now taken from the
device tree:
c0 for EMAC4SYNC cores
74 for EMAC4 cores
70 for EMAC cores
rathaer than sizeof (emac_regs).
Finally, the device trees have been updated with the appropriate xaht-*
keys and values.
This has been tested on an AMCC Haleakala board such that: 1) inbound
ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11
and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from
'haleakala.local' to those same systems in the '.local' domain via MDNS
now work.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/bamboo.dts |6 +++
arch/powerpc/boot/dts/canyonlands.dts | 10 -
arch/powerpc/boot/dts/ebony.dts |6 +++
arch/powerpc/boot/dts/ep405.dts |3 ++
arch/powerpc/boot/dts/glacier.dts | 20 +--
arch/powerpc/boot/dts/haleakala.dts |5 ++-
arch/powerpc/boot/dts/katmai.dts |5 ++-
arch/powerpc/boot/dts/kilauea.dts | 10 -
arch/powerpc/boot/dts/makalu.dts | 10 -
arch/powerpc/boot/dts/rainier.dts | 10 -
arch/powerpc/boot/dts/sequoia.dts | 10 -
arch/powerpc/boot/dts/taishan.dts | 20 +--
arch/powerpc/boot/dts/walnut.dts |3 ++
arch/powerpc/boot/dts/warp.dts|3 ++
drivers/net/ibm_newemac/core.c| 55 +++--
drivers/net/ibm_newemac/core.h| 61 +
drivers/net/ibm_newemac/debug.c | 32 +++--
drivers/net/ibm_newemac/emac.h| 15 +---
18 files changed, 219 insertions(+), 65 deletions(-)
diff --git a/arch/powerpc/boot/dts/bamboo.dts b/arch/powerpc/boot/dts/bamboo.dts
index ba2521b..200a4ec 100644
--- a/arch/powerpc/boot/dts/bamboo.dts
+++ b/arch/powerpc/boot/dts/bamboo.dts
@@ -221,6 +221,9 @@
phy-map = ;
zmii-device = ZMII0;
zmii-channel = 0;
+ xaht-base-offset = 30;
+ xaht-slots-shift = 6;
+ xaht-width-shift = 4;
};
EMAC1: [EMAIL PROTECTED] {
@@ -241,6 +244,9 @@
phy-map = ;
zmii-device = ZMII0;
zmii-channel = 1;
+ xaht-base-offset = 30;
+ xaht-slots-shift = 6;
+ xaht-width-shift = 4;
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 3963412..75ff768 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -272,7 +272,7 @@
#size-cells = 0;
interrupt-map = /*Status*/ 0 UIC2 10 4
/*Wake*/ 1 UIC2 14 4;
- reg = ef600e00 70;
+ reg = ef600e00 74;
local-mac-address = []; /* Filled
in by U-Boot */
mal-device = MAL0;
mal-tx-channel = 0;
@@ -287,6 +287,9 @@
rgmii-channel = 0;
tah-device = TAH0;
tah-channel = 0;
+ xaht-base-offset = 80;
+ xaht-slots-shift = 8;
+ xaht-width-shift = 5;
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
@@ -301,7 +304,7
[PATCH] [POWERPC] 40X: Add Default Restart Machdep Method to 40X Platforms
This patch restores the reset on restart functionality to 40x-based
platforms that was formerly provided--but not used in arch/powerpc--by
abort() in head_40x.S. This functionality is now provided by
ppc40x_reset_system(char *) in a fashion similar to that of the 44x-based
platforms.
Compiled, linked and tested against the AMCC Haleakala board.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/kernel/head_40x.S
linux-2.6.25-rc2-git1.N/arch/powerpc/kernel/head_40x.S
--- linux-2.6.25-rc2-git1/arch/powerpc/kernel/head_40x.S2008-01-24
14:58:37.0 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/kernel/head_40x.S2008-02-22
11:02:56.0 -0800
@@ -961,11 +961,6 @@
blr
-_GLOBAL(abort)
-mfspr r13,SPRN_DBCR0
-orisr13,r13,[EMAIL PROTECTED]
-mtspr SPRN_DBCR0,r13
-
_GLOBAL(set_context)
#ifdef CONFIG_BDI_SWITCH
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/40x.h
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/40x.h
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/40x.h1969-12-31
16:00:00.0 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/40x.h2008-02-22
11:02:56.0 -0800
@@ -0,0 +1,6 @@
+#ifndef __POWERPC_PLATFORMS_40X_40X_H
+#define __POWERPC_PLATFORMS_40X_40X_H
+
+extern void ppc40x_reset_system(char *cmd);
+
+#endif /* __POWERPC_PLATFORMS_40X_40X_H */
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/ep405.c
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/ep405.c
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/ep405.c2008-02-22
11:07:53.0 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/ep405.c2008-02-22
11:02:56.0 -0800
@@ -30,6 +30,8 @@
#include asm/uic.h
#include asm/pci-bridge.h
+#include 40x.h
+
static struct device_node *bcsr_node;
static void __iomem *bcsr_regs;
@@ -119,5 +121,6 @@
.progress= udbg_progress,
.init_IRQ= uic_init_tree,
.get_irq= uic_get_irq,
-.calibrate_decr= generic_calibrate_decr,
+.restart= ppc40x_reset_system,
+.calibrate_decr= generic_calibrate_decr,
};
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/kilauea.c
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/kilauea.c
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/kilauea.c2008-02-22
11:07:53.0 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/kilauea.c
2008-02-22 11:02:56.0 -0800
@@ -21,6 +21,8 @@
#include asm/uic.h
#include asm/pci-bridge.h
+#include 40x.h
+
static __initdata struct of_device_id kilauea_of_bus[] = {
{ .compatible = ibm,plb4, },
{ .compatible = ibm,opb, },
@@ -54,5 +56,6 @@
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
-.calibrate_decr= generic_calibrate_decr,
+.restart= ppc40x_reset_system,
+.calibrate_decr= generic_calibrate_decr,
};
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/makalu.c
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/makalu.c
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/makalu.c2008-02-22
11:07:53.0 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/makalu.c
2008-02-22 11:02:56.0 -0800
@@ -21,6 +21,8 @@
#include asm/uic.h
#include asm/pci-bridge.h
+#include 40x.h
+
static __initdata struct of_device_id makalu_of_bus[] = {
{ .compatible = ibm,plb4, },
{ .compatible = ibm,opb, },
@@ -54,5 +56,6 @@
.progress = udbg_progress,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
-.calibrate_decr= generic_calibrate_decr,
+.restart= ppc40x_reset_system,
+.calibrate_decr= generic_calibrate_decr,
};
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/Makefile
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/Makefile
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/Makefile2008-02-22
11:07:53.0 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/Makefile
2008-02-22 11:02:56.0 -0800
@@ -1,3 +1,4 @@
+obj-$(CONFIG_40x)+= misc_40x.o
obj-$(CONFIG_KILAUEA)+= kilauea.o
obj-$(CONFIG_MAKALU)+= makalu.o
obj-$(CONFIG_WALNUT)+= walnut.o
diff -rauN linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/misc_40x.S
linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/misc_40x.S
--- linux-2.6.25-rc2-git1/arch/powerpc/platforms/40x/misc_40x.S
1969-12-31 16:00:00.0 -0800
+++ linux-2.6.25-rc2-git1.N/arch/powerpc/platforms/40x/misc_40x.S
2008-02-22 15:19:14.0 -0800
@@ -0,0 +1,30 @@
+/*
+ * This file contains miscellaneous low-level functions for PPC 40x.
+ *
+ *Copyright (c) 1999 Grant Erickson [EMAIL PROTECTED]
+ *Copyright 2007 David Gibson [EMAIL PROTECTED
Re: [PATCH] [POWERPC] add target for building .dtb files
On 2/21/08 11:19 AM, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] Signed-off-by: Grant Likely [EMAIL PROTECTED] --- Josh, is this what your were looking for? Cheers, g. --- arch/powerpc/Makefile |2 +- arch/powerpc/boot/Makefile |4 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index ab5cfe8..dd80825 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -164,7 +164,7 @@ boot := arch/$(ARCH)/boot $(BOOT_TARGETS): vmlinux $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) -bootwrapper_install: +bootwrapper_install %.dtb: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) define archhelp diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index d57a67d..fb29f10 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -311,6 +311,10 @@ $(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits) $(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits) $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts) +# Rule to build device tree blobs +$(obj)/%.dtb: $(dtstree)/%.dts $(obj)/dtc + $(obj)/dtc -O dtb -o $(obj)/$*.dtb -b 0 $(dtstree)/$*.dts + Grant, Would it be beneficial to provide a way to have environment- or command-line-provided DTC arguments/flags such that the oft-required '-S size' and '-R reserved' flags can be specified? Or, are there reasonable size and reserved defaults appropriate for all platforms that can be specified? FWIW, generating a blob for Haleakala/Kilauea on the PPC405EX[r] using the above command in the patch results in complaints about lack of space for the CHOSEN node in u-boot. Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
