[git pull] Please pull powerpc.git merge branch
Hi Linus ! A few more 2.6.30 things for you... a defconfig update, and a couple of small fixes, either obvious enough or regression fixes. Cheers, Ben. The following changes since commit 86460103c412f9e11aeb7950cce64b9e51539d4d: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../rafael/suspend-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Benjamin Herrenschmidt (1): powerpc: Explicit alignment for .data.cacheline_aligned Geoff Levand (1): powerpc/ps3: Update ps3_defconfig Mel Gorman (1): powerpc: Do not assert pte_locked for hugepage PTE entries Michael Ellerman (1): powerpc/ftrace: Use pr_devel() in ftrace.c Steven Rostedt (1): powerpc/ftrace: Fix constraint to be early clobber arch/powerpc/configs/ps3_defconfig | 105 +--- arch/powerpc/kernel/ftrace.c | 22 arch/powerpc/kernel/vmlinux.lds.S |1 + arch/powerpc/mm/pgtable.c |3 +- 4 files changed, 76 insertions(+), 55 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Make the NR_CPUS max 8192
On Mon, 18 May 2009, Michael Neuling wrote: We can compile and boot with NR_CPUS=3D8192, so make this the max. 1024 was an arbitrary decision anyway. Is 8192 still arbitrary? Or does something break above that? Yeah, the compile breaks after that with 4K pages. In drivers/base/node.c we have: /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */ BUILD_BUG_ON((NR_CPUS/32 * 9) (PAGE_SIZE-1)); which causes: drivers/base/node.c: In function 'node_read_cpumap': drivers/base/node.c:31: error: size of array 'type name' is negative I can compile with 16384 CPUs with 64K pages, but it doesn't boot. sfr asked for size info for different builds, so I may as well repost them here: text data bss dec hex filename 9237767 3225768 4409996 16873531101783b vmlinux.1024 9247355 4769472 7373708 2139053514664c7 vmlinux.2048 9267239 7857032 13301132304254031d0413b vmlinux.4096 9302623 1403583225155980484944352e3f763 vmlinux.8192 9373283 26389360488656768462831950b535f vmlinux.16384 Will distros now start pushing NR_CPUS=8192-kernels on us? With kind regards, Geert Uytterhoeven Software Architect Techsoft Centre Technology and Software Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
fs_enet build breakage
Hi Kumar Commit 4484079d517c2b6521621be0b1ea246ccc55c7d7 from your next branch breaks my 8xx test config with the following error: /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: In function ‘setup_immap’: /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:947: error: ‘IMAP_ADDR’ undeclared (first use in this function) /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:947: error: (Each undeclared identifier is reported only once /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c:947: error: for each function it appears in.) I'm still pushing it with a bunch of other stuff to test so people get to find more breakage but it will need to be fixed for the actual next branch. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Make the NR_CPUS max 8192
In message alpine.lrh.2.00.0905180857060.16...@vixen.sonytel.be you wrote: On Mon, 18 May 2009, Michael Neuling wrote: We can compile and boot with NR_CPUS=3D8192, so make this the max. 102 4 was an arbitrary decision anyway. Is 8192 still arbitrary? Or does something break above that? Yeah, the compile breaks after that with 4K pages. In drivers/base/node.c we have: /* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */ BUILD_BUG_ON((NR_CPUS/32 * 9) (PAGE_SIZE-1)); which causes: drivers/base/node.c: In function 'node_read_cpumap': drivers/base/node.c:31: error: size of array 'type name' is negative I can compile with 16384 CPUs with 64K pages, but it doesn't boot. sfr asked for size info for different builds, so I may as well repost them here: textdata bss dec hex filenam e 9237767 3225768 4409996 16873531101783b vmlinux .1024 9247355 4769472 7373708 2139053514664c7 vmlinux .2048 9267239 7857032 13301132304254031d0413b vmlinux .4096 9302623 1403583225155980484944352e3f763 vmlinux .8192 9373283 26389360488656768462831950b535f vmlinux .16384 Will distros now start pushing NR_CPUS=8192-kernels on us? Yeah, that's a concern. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/pci: clean up direct access to sysdata by iseries platform
On Fri, 2009-05-15 at 07:50 -0500, Kumar Gala wrote: On May 15, 2009, at 7:47 AM, Kumar Gala wrote: We shouldn't directly access sysdata to get the device node. We should be calling pci_device_to_OF_node(). Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Updated based on sfr's iseries pci fix patch arch/powerpc/platforms/iseries/iommu.c |2 +- arch/powerpc/platforms/iseries/pci.c |8 2 files changed, 5 insertions(+), 5 deletions(-) Stephen if you can test this version that would be great. Fails with: /home/benh/linux-powerpc-test/arch/powerpc/platforms/iseries/iommu.c: In function ‘pci_dma_dev_setup_iseries’: /home/benh/linux-powerpc-test/arch/powerpc/platforms/iseries/iommu.c:180: error: ‘dev’ undeclared (first use in this function) /home/benh/linux-powerpc-test/arch/powerpc/platforms/iseries/iommu.c:180: error: (Each undeclared identifier is reported only once /home/benh/linux-powerpc-test/arch/powerpc/platforms/iseries/iommu.c:180: error: for each function it appears in.) (I suspect it should have been pdev instead of dev) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
test branch updates
Just a quick note before I leave the office... I've just pushed out a bunch of stuff to my test branch. There's a couple of known breakage (iseries and 8xx) which will have to be sorted out before that stuff goes into next. hopefully in a couple of days. Still... feel free to take a peek, test, etc... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] drivers/hvc: add missing __devexit_p()
The remove function uses __devexit, so the .remove assignment needs
__devexit_p() to fix a build error with hotplug disabled.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: linuxppc-dev@ozlabs.org
CC: linux-ker...@vger.kernel.org
---
drivers/char/hvc_iseries.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
index 449727b..936d05b 100644
--- a/drivers/char/hvc_iseries.c
+++ b/drivers/char/hvc_iseries.c
@@ -241,7 +241,7 @@ static int __devexit hvc_vio_remove(struct vio_dev *vdev)
static struct vio_driver hvc_vio_driver = {
.id_table = hvc_driver_table,
.probe = hvc_vio_probe,
- .remove = hvc_vio_remove,
+ .remove = __devexit_p(hvc_vio_remove),
.driver = {
.name = hvc_driver_name,
.owner = THIS_MODULE,
--
1.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] drivers/hvc: add missing __devexit_p()
The remove function uses __devexit, so the .remove assignment needs
__devexit_p() to fix a build error with hotplug disabled.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: linuxppc-dev@ozlabs.org
---
v2
- include all hvc files
drivers/char/hvc_iseries.c |2 +-
drivers/char/hvc_vio.c |2 +-
drivers/char/hvcs.c|2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
index 449727b..936d05b 100644
--- a/drivers/char/hvc_iseries.c
+++ b/drivers/char/hvc_iseries.c
@@ -241,7 +241,7 @@ static int __devexit hvc_vio_remove(struct vio_dev *vdev)
static struct vio_driver hvc_vio_driver = {
.id_table = hvc_driver_table,
.probe = hvc_vio_probe,
- .remove = hvc_vio_remove,
+ .remove = __devexit_p(hvc_vio_remove),
.driver = {
.name = hvc_driver_name,
.owner = THIS_MODULE,
diff --git a/drivers/char/hvc_vio.c b/drivers/char/hvc_vio.c
index bd62dc8..c72b994 100644
--- a/drivers/char/hvc_vio.c
+++ b/drivers/char/hvc_vio.c
@@ -113,7 +113,7 @@ static int __devexit hvc_vio_remove(struct vio_dev *vdev)
static struct vio_driver hvc_vio_driver = {
.id_table = hvc_driver_table,
.probe = hvc_vio_probe,
- .remove = hvc_vio_remove,
+ .remove = __devexit_p(hvc_vio_remove),
.driver = {
.name = hvc_driver_name,
.owner = THIS_MODULE,
diff --git a/drivers/char/hvcs.c b/drivers/char/hvcs.c
index c76bccf..2724d62 100644
--- a/drivers/char/hvcs.c
+++ b/drivers/char/hvcs.c
@@ -868,7 +868,7 @@ static int __devexit hvcs_remove(struct vio_dev *dev)
static struct vio_driver hvcs_vio_driver = {
.id_table = hvcs_driver_table,
.probe = hvcs_probe,
- .remove = hvcs_remove,
+ .remove = __devexit_p(hvcs_remove),
.driver = {
.name = hvcs_driver_name,
.owner = THIS_MODULE,
--
1.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[v1 PATCH 4/4] EDAC: INT mode support for AMD8131 driver
Support EDAC INT mode for AMD8131 EDAC driver, which may post upstream
NMI interrupt request messages that will latch MPIC INT0 pin.
Following aspects for this patch have been tested:
1, module initialization and deletion for NMI mode;
2, creation and deletion for the mapping between hwirq==0 to a virq;
Note, due to the difficulty and complexity to generate a real hardware
EDAC Errors, below aspects have not been tested yet:
1, code that controls the generation of the NMI Request Message;
2, the mapping from the NMI Request Messages to MPIC INT0 pin;
3, if EDAC isr methods could handle errors correctly.
Signed-off-by: Harry Ciao qingtao@windriver.com
---
drivers/edac/amd8131_edac.c | 169 ++-
drivers/edac/amd8131_edac.h | 20 +-
2 files changed, 170 insertions(+), 19 deletions(-)
diff --git a/drivers/edac/amd8131_edac.c b/drivers/edac/amd8131_edac.c
index b432d60..9b8217b 100644
--- a/drivers/edac/amd8131_edac.c
+++ b/drivers/edac/amd8131_edac.c
@@ -28,6 +28,7 @@
#include linux/bitops.h
#include linux/edac.h
#include linux/pci_ids.h
+#include linux/interrupt.h
#include edac_core.h
#include edac_module.h
@@ -36,6 +37,11 @@
#define AMD8131_EDAC_REVISION Ver: 1.0.0 __DATE__
#define AMD8131_EDAC_MOD_STR amd8131_edac
+static int amd8131_op_state = EDAC_OPSTATE_POLL;
+module_param(amd8131_op_state, int, 0444);
+MODULE_PARM_DESC(amd8131_op_state, EDAC Error Reporting state: 0=Poll,
1=NMI);
+static int amd8131_nmi_irq;
+
/* Wrapper functions for accessing PCI configuration space */
static void edac_pci_read_dword(struct pci_dev *dev, int reg, u32 *val32)
{
@@ -139,6 +145,17 @@ static void amd8131_pcix_init(struct amd8131_dev_info
*dev_info)
edac_pci_read_dword(dev, REG_LNK_CTRL_B, val32);
val32 |= LNK_CTRL_CRCFEN;
edac_pci_write_dword(dev, REG_LNK_CTRL_B, val32);
+
+ /* enable HT NMI messages generation on errors */
+ if (amd8131_op_state == EDAC_OPSTATE_NMI) {
+ edac_pci_read_dword(dev, REG_MISC_I, val32);
+ val32 = ~MISC_I_NIOAMODE;
+ edac_pci_write_dword(dev, REG_MISC_I, val32);
+
+ edac_pci_read_dword(dev, REG_MISC_II, val32);
+ val32 |= MISC_II_NMIEN;
+ edac_pci_write_dword(dev, REG_MISC_II, val32);
+ }
}
static void amd8131_pcix_exit(struct amd8131_dev_info *dev_info)
@@ -165,6 +182,17 @@ static void amd8131_pcix_exit(struct amd8131_dev_info
*dev_info)
edac_pci_read_dword(dev, REG_LNK_CTRL_B, val32);
val32 = ~LNK_CTRL_CRCFEN;
edac_pci_write_dword(dev, REG_LNK_CTRL_B, val32);
+
+ /* Disable HT NMI messages on errors*/
+ if (amd8131_op_state == EDAC_OPSTATE_NMI) {
+ edac_pci_read_dword(dev, REG_MISC_II, val32);
+ val32 = ~MISC_II_NMIEN;
+ edac_pci_write_dword(dev, REG_MISC_II, val32);
+
+ edac_pci_read_dword(dev, REG_MISC_I, val32);
+ val32 |= MISC_I_NIOAMODE;
+ edac_pci_write_dword(dev, REG_MISC_I, val32);
+ }
}
static void amd8131_pcix_check(struct edac_pci_ctl_info *edac_dev)
@@ -233,12 +261,33 @@ static void amd8131_pcix_check(struct edac_pci_ctl_info
*edac_dev)
}
}
+static irqreturn_t amd8131_pcix_isr(int irq, void *dev_id)
+{
+ struct edac_pci_ctl_info *edac_pci = dev_id;
+ struct amd8131_dev_info *dev_info = edac_pci-pvt_info;
+ struct pci_dev *dev = dev_info-dev;
+ u32 val32;
+
+ /*
+* Only a handful of errors in PCI-X Bridge Memory Base-Limit
+* Register could trigger NMI interrupt request message.
+*/
+ edac_pci_read_dword(dev, REG_MEM_LIM, val32);
+ if (!(val32 MEM_LIMIT_NMI_MASK))
+ return IRQ_NONE;
+
+ amd8131_pcix_check(edac_pci);
+
+ return IRQ_HANDLED;
+}
+
static struct amd8131_info amd8131_chipset = {
.err_dev = PCI_DEVICE_ID_AMD_8131_APIC,
.devices = amd8131_devices,
.init = amd8131_pcix_init,
.exit = amd8131_pcix_exit,
.check = amd8131_pcix_check,
+ .isr = amd8131_pcix_isr,
};
/*
@@ -249,6 +298,7 @@ static struct amd8131_info amd8131_chipset = {
static int amd8131_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
struct amd8131_dev_info *dev_info;
+ int ret = -ENODEV;
for (dev_info = amd8131_chipset.devices; dev_info-inst != NO_BRIDGE;
dev_info++)
@@ -256,7 +306,7 @@ static int amd8131_probe(struct pci_dev *dev, const struct
pci_device_id *id)
break;
if (dev_info-inst == NO_BRIDGE) /* should never happen */
- return -ENODEV;
+ goto out;
/*
* We can't call pci_get_device() as we are used to do because
@@ -265,12 +315,11 @@ static int amd8131_probe(struct pci_dev *dev, const
struct pci_device_id *id)
dev_info-dev = pci_dev_get(dev);
if
[v1 PATCH 2/4] EDAC: MCE INT mode support for CPC925 driver
Support EDAC INT mode and add a new EDAC MCE mode for CPC925 EDAC driver.
CPC925 Hypertransport hostbridge controller may trigger interrupt that
latches MPIC INT2 pin on Hypertransport Link Errors, and generate MCE on
memory ECC Errors and Processor Interface Errors.
The global variable edac_op_state defined by EDAC core will be
obsolete, not only different EDAC modules on the same machine may
operate in different EDAC modes, but further this could be the
case for different EDAC devices of the same EDAC module, for example,
each CPC925 EDAC device could work in the mode specified by their own
op_state member in their private structure.
A spinlock will be used to protect the EDAC MCE handler from being
silently unregistered, however, it also implies a constraint that
when EDAC MCE handler is called on one CPU, it will be bypassed by
another MCE event on other CPUs.
Following aspects for this patch have been tested:
1, module initialization and deletion;
2, creation and deletion for the mapping between hwirq==2 to a virq
for the Hypertransport Link Errors;
3, registration and unregistration for the EDAC MCE handler from the
generic MCE handler on PPC;
Note, due to the difficulty and complexity to generate a real hardware
ECC/HT Link/CPU Errors, below aspects have not been tested yet:
1, if ECC or CPU Errors would generate MCE event;
2, if HT Link Error will indeed latch MPIC INT2 pin;
3, if EDAC isr/mce methods could handle errors correctly.
Signed-off-by: Harry Ciao qingtao@windriver.com
---
arch/powerpc/kernel/traps.c | 16 +++
drivers/edac/cpc925_edac.c | 275 ---
drivers/edac/edac_stub.c|6 +
include/linux/edac.h|6 +
4 files changed, 284 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 678fbff..1ae3465 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -57,6 +57,10 @@
#include asm/dbell.h
#endif
+#ifdef CONFIG_EDAC
+#include linux/edac.h
+#endif
+
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
int (*__debugger)(struct pt_regs *regs);
int (*__debugger_ipi)(struct pt_regs *regs);
@@ -481,6 +485,18 @@ int machine_check_generic(struct pt_regs *regs)
default:
printk(Unknown values in msr\n);
}
+
+#ifdef CONFIG_EDAC
+ if (spin_trylock(edac_mce_lock)) {
+ if (edac_mce_handler) {
+ int ret = edac_mce_handler();
+ spin_unlock(edac_mce_lock);
+ return ret;
+ }
+ spin_unlock(edac_mce_lock);
+ }
+#endif
+
return 0;
}
#endif /* everything else */
diff --git a/drivers/edac/cpc925_edac.c b/drivers/edac/cpc925_edac.c
index 8c54196..36fc506 100644
--- a/drivers/edac/cpc925_edac.c
+++ b/drivers/edac/cpc925_edac.c
@@ -25,6 +25,8 @@
#include linux/edac.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/interrupt.h
+#include asm/reg.h
#include edac_core.h
#include edac_module.h
@@ -273,22 +275,29 @@ enum brgctrl_bits {
/* Private structure for edac memory controller */
struct cpc925_mc_pdata {
+ int op_state;
void __iomem *vbase;
unsigned long total_mem;
const char *name;
int edac_idx;
+ struct mem_ctl_info *mci;
+ int (*mce)(struct mem_ctl_info *mci);
};
/* Private structure for common edac device */
struct cpc925_dev_info {
+ int op_state;
void __iomem *vbase;
struct platform_device *pdev;
char *ctl_name;
int edac_idx;
struct edac_device_ctl_info *edac_dev;
+ int irq;
void (*init)(struct cpc925_dev_info *dev_info);
void (*exit)(struct cpc925_dev_info *dev_info);
void (*check)(struct edac_device_ctl_info *edac_dev);
+ int (*mce)(struct edac_device_ctl_info *edac_dev);
+ irqreturn_t (*isr)(int irq, void *dev_id);
};
/* Get total memory size from Open Firmware DTB */
@@ -382,6 +391,18 @@ static void cpc925_init_csrows(struct mem_ctl_info *mci)
}
}
+/* Set up HID0_EMCP bit if necessary, MSR[ME] has been set up */
+static void cpc925_mce_enable(void)
+{
+ unsigned long hid0 = mfspr(SPRN_HID0);
+
+ if ((hid0 HID0_EMCP) == 0)
+ mtspr(SPRN_HID0, hid0 | HID0_EMCP);
+
+ debugf0(%s: MSR[ME] = %d, HID0[EMCP] = %d\n, __func__,
+ mfmsr() MSR_ME, mfspr(SPRN_HID0));
+}
+
/* Enable memory controller ECC detection */
static void cpc925_mc_init(struct mem_ctl_info *mci)
{
@@ -402,6 +423,9 @@ static void cpc925_mc_init(struct mem_ctl_info *mci)
mccr |= MCCR_ECC_EN;
__raw_writel(mccr, pdata-vbase + REG_MCCR_OFFSET);
}
+
+ if (pdata-op_state == EDAC_OPSTATE_MCE)
+ cpc925_mce_enable();
}
/* Disable memory controller ECC detection */
@@ -520,7 +544,10 @@ static int cpc925_mc_find_channel(struct mem_ctl_info
[v1 PATCH 3/4] EDAC: INT mode support for AMD8111 driver
Support EDAC INT mode for AMD8111 EDAC driver, which may post upstream
NMI interrupt request messages that will latch MPIC INT0 pin.
Following aspects for this patch have been tested:
1, module initialization and deletion for NMI mode;
2, creation and deletion for the mapping between hwirq==0 to a virq;
Note, due to the difficulty and complexity to generate a real hardware
EDAC Errors, below aspects have not been tested yet:
1, code that controls the generation of the NMI Request Message;
2, the mapping from the NMI Request Messages to MPIC INT0 pin;
3, if EDAC isr methods could handle errors correctly.
Signed-off-by: Harry Ciao qingtao@windriver.com
---
drivers/edac/amd8111_edac.c | 348 +--
drivers/edac/amd8111_edac.h | 43 +-
2 files changed, 343 insertions(+), 48 deletions(-)
diff --git a/drivers/edac/amd8111_edac.c b/drivers/edac/amd8111_edac.c
index 35b78d0..10dc8ac 100644
--- a/drivers/edac/amd8111_edac.c
+++ b/drivers/edac/amd8111_edac.c
@@ -38,6 +38,11 @@
#define PCI_DEVICE_ID_AMD_8111_PCI 0x7460
+static int amd8111_op_state = EDAC_OPSTATE_POLL;
+module_param(amd8111_op_state, int, 0444);
+MODULE_PARM_DESC(amd8111_op_state, EDAC Error Reporting state: 0=Poll,
1=NMI);
+static int amd8111_nmi_irq;
+
enum amd8111_edac_devs {
LPC_BRIDGE = 0,
};
@@ -89,10 +94,9 @@ static void edac_pci_write_byte(struct pci_dev *dev, int
reg, u8 val8)
PCI Access Write Error at 0x%x\n, reg);
}
+/* device specific methods for AMD8111 PCI Bridge device */
/*
- * device-specific methods for amd8111 PCI Bridge Controller
- *
- * Error Reporting and Handling for amd8111 chipset could be found
+ * Error Reporting and Handling for AMD8111 chipset could be found
* in its datasheet 3.1.2 section, P37
*/
static void amd8111_pci_bridge_init(struct amd8111_pci_info *pci_info)
@@ -125,7 +129,7 @@ static void amd8111_pci_bridge_init(struct amd8111_pci_info
*pci_info)
edac_pci_write_dword(dev, REG_PCI_INTBRG_CTRL, val32);
/* Last enable error detections */
- if (edac_op_state == EDAC_OPSTATE_POLL) {
+ if (amd8111_op_state == EDAC_OPSTATE_POLL) {
/* Enable System Error reporting in global status register */
edac_pci_read_dword(dev, REG_PCI_STSCMD, val32);
val32 |= PCI_STSCMD_SERREN;
@@ -140,6 +144,11 @@ static void amd8111_pci_bridge_init(struct
amd8111_pci_info *pci_info)
edac_pci_read_dword(dev, REG_PCI_INTBRG_CTRL, val32);
val32 |= PCI_INTBRG_CTRL_POLL_MASK;
edac_pci_write_dword(dev, REG_PCI_INTBRG_CTRL, val32);
+ } else if (amd8111_op_state == EDAC_OPSTATE_NMI) {
+ /* Enable Parity Error detection on secondary PCI bus */
+ edac_pci_read_dword(dev, REG_PCI_INTBRG_CTRL, val32);
+ val32 |= PCI_INTBRG_CTRL_PEREN;
+ edac_pci_write_dword(dev, REG_PCI_INTBRG_CTRL, val32);
}
}
@@ -148,7 +157,7 @@ static void amd8111_pci_bridge_exit(struct amd8111_pci_info
*pci_info)
u32 val32;
struct pci_dev *dev = pci_info-dev;
- if (edac_op_state == EDAC_OPSTATE_POLL) {
+ if (amd8111_op_state == EDAC_OPSTATE_POLL) {
/* Disable System Error reporting */
edac_pci_read_dword(dev, REG_PCI_STSCMD, val32);
val32 = ~PCI_STSCMD_SERREN;
@@ -163,6 +172,11 @@ static void amd8111_pci_bridge_exit(struct
amd8111_pci_info *pci_info)
edac_pci_read_dword(dev, REG_PCI_INTBRG_CTRL, val32);
val32 = ~PCI_INTBRG_CTRL_POLL_MASK;
edac_pci_write_dword(dev, REG_PCI_INTBRG_CTRL, val32);
+ } else if (amd8111_op_state == EDAC_OPSTATE_NMI) {
+ /* Disable Parity Error detection on secondary PCI bus */
+ edac_pci_read_dword(dev, REG_PCI_INTBRG_CTRL, val32);
+ val32 = ~PCI_INTBRG_CTRL_PEREN;
+ edac_pci_write_dword(dev, REG_PCI_INTBRG_CTRL, val32);
}
}
@@ -238,11 +252,136 @@ static void amd8111_pci_bridge_check(struct
edac_pci_ctl_info *edac_dev)
}
}
+static irqreturn_t amd8111_pci_bridge_isr(int irq, void *dev_id)
+{
+ struct edac_pci_ctl_info *edac_dev = dev_id;
+ struct amd8111_pci_info *pci_info = edac_dev-pvt_info;
+ struct pci_dev *dev = pci_info-dev;
+ u32 stscmd, htlink, intbrg, memlim;
+
+ edac_pci_read_dword(dev, REG_PCI_STSCMD, stscmd);
+ edac_pci_read_dword(dev, REG_HT_LINK, htlink);
+ edac_pci_read_dword(dev, REG_PCI_INTBRG_CTRL, intbrg);
+ edac_pci_read_dword(dev, REG_MEM_LIM, memlim);
+
+ if (!((stscmd PCI_STSCMD_NMI_MASK) ||
+ (htlink HT_LINK_CRCERR) ||
+ (intbrg PCI_INTBRG_CTRL_DTSTAT) ||
+ (memlim MEM_LIMIT_CLEAR_MASK)))
+ return IRQ_NONE;
+
+ amd8111_pci_bridge_check(edac_dev);
+
+ return IRQ_HANDLED;
+}
+
+/* device specific
[v1 PATCH 1/4] EDAC: MPIC Hypertransport IRQ support
Collect the machine specific code that creates the hwirq2virq mapping
for the possible multiple EDAC modules on the same machine that supports
MPIC.
Multiple calling of irq_create_of_mapping() for the same hwirq will
always return the same virq, since the mapping won't be refcounted so
we just don't call irq_dispose_mapping() against it. This won't occupy
unnecessary resource since irq_map[] is of fixed size(==512).
The edac_mpic_irq.c is inert for EDAC drivers where related hardware
is not connecting to MPIC, so it should be controlled by CONFIG_MPIC.
Signed-off-by: Harry Ciao qingtao@windriver.com
---
drivers/edac/Makefile|4 ++
drivers/edac/edac_mpic_irq.c | 86 ++
include/linux/edac.h | 20 ++
3 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644 drivers/edac/edac_mpic_irq.c
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 07a31cf..62778ee 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -17,6 +17,10 @@ ifdef CONFIG_PCI
edac_core-objs += edac_pci.o edac_pci_sysfs.o
endif
+ifdef CONFIG_MPIC
+edac_core-objs += edac_mpic_irq.o
+endif
+
obj-$(CONFIG_EDAC_AMD76X) += amd76x_edac.o
obj-$(CONFIG_EDAC_CPC925) += cpc925_edac.o
obj-$(CONFIG_EDAC_I5000) += i5000_edac.o
diff --git a/drivers/edac/edac_mpic_irq.c b/drivers/edac/edac_mpic_irq.c
new file mode 100644
index 000..7486b15
--- /dev/null
+++ b/drivers/edac/edac_mpic_irq.c
@@ -0,0 +1,86 @@
+/*
+ * edac_mpic_irq.c -
+ * Collect the machine specific code that creates the hwirq2virq
+ * mapping for the possible multiple EDAC modules on the same
+ * machine that supports MPIC.
+ *
+ * Copyright (c) 2009 Wind River Systems, Inc.
+ *
+ * Authors:Cao Qingtao qingtao@windriver.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/of.h
+#include linux/edac.h
+
+#ifdef CONFIG_PPC_MAPLE
+static int edac_maple_get_irq(int hwirq)
+{
+ struct device_node *np, *mpic_node = NULL;
+ int irq = NO_IRQ;
+
+ /*
+* Locate MPIC in the device-tree. Note that there is a bug
+* in Maple device-tree where the type of the controller is
+* open-pic and not interrupt-controller
+*/
+ for_each_node_by_type(np, interrupt-controller) {
+ if (of_device_is_compatible(np, open-pic)) {
+ mpic_node = np;
+ break;
+ }
+ }
+
+ if (mpic_node == NULL) {
+ for_each_node_by_type(np, open-pic) {
+ mpic_node = np;
+ break;
+ }
+ }
+
+ if (mpic_node) {
+ irq = irq_create_of_mapping(mpic_node, hwirq, 1);
+ of_node_put(mpic_node);
+ } else
+ printk(KERN_ERR Failed to locate the MPIC DTB node\n);
+
+ return irq;
+}
+#endif
+
+/*
+ * NOTE:
+ * The EDAC driver should implement and register its machine-specific
+ * method to get a virtual IRQ here.
+ */
+int edac_get_mpic_irq(int hwirq)
+{
+ int virq = NO_IRQ;
+
+ if ((hwirq != MPIC_HWIRQ_HT_NMI)
+ (hwirq != MPIC_HWIRQ_INTERNAL_ERROR))
+ return NO_IRQ;
+
+#ifdef CONFIG_PPC_MAPLE
+ virq = edac_maple_get_irq(hwirq);
+#endif
+
+ return virq;
+
+}
+EXPORT_SYMBOL_GPL(edac_get_mpic_irq);
diff --git a/include/linux/edac.h b/include/linux/edac.h
index 7cf92e8..c122d22 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -38,4 +38,24 @@ static inline void opstate_init(void)
return;
}
+#ifdef CONFIG_MPIC
+enum {
+ /*
+* Vector carried in southbridge NMI Request Messages
+* posted through Hypertransport Channel
+*/
+ MPIC_HWIRQ_HT_NMI = 0,
+
+ /*
+* Vector for MPIC Internal Error
+*/
+ MPIC_HWIRQ_INTERNAL_ERROR = 2,
+
+ MPIC_HWIRQS,/* must be the very last */
+};
+
+/* Create a hwirq2virq mapping for the specified hwirq */
+extern int edac_get_mpic_irq(int hwirq);
+#endif
+
#endif
--
1.5.6.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[v1 PATCH 0/4] Add INT mode support for EDAC drivers on Maple
Hi Ben, This is the v2 patches that have integrated your suggestions to remove the refcount for a hwriq2virq mapping as long as we don't dispose it, the changes are mostly within the 1/4 patch where the unnecessary refcount and irqmap structure are removed, and callings to edac_put_mpic_irq() are also removed from the rest of patches. Since there are 3 EDAC modules on Maple will use one same copy of code to create hwirq2virq mappings, I perfer to preserve it in edac_mpic_irq.c. How do feel about the assumption that MPIC will latch INT 0 pin for the NMI Reqeust Messages whose vector is == 0? This is the thing that I have least confidence in, so far all I can get is the brief introduction in CPC925 user manual that This interrupt vector is used to set a corresponding interrupt latch, P111, so I think it imples that vector==0 will latch pin #0. Many thanks for all your comments! Best regards, Harry ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-mpc: generate START condition after STOP caused by read i2c_msg
Could we go forward with my initial patch, and then continue the work on this repeated START approach for future releases? Then could you please send another version of your patch with the CodingStyle issue removed and an updated description what this patch fixes and what still needs to be resolved? Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] powerpc: Keep track of emulated instructions
If CONFIG_PPC_EMULATED_STATS is enabled, make available counters for the
various classes of emulated instructions under
/sys/kernel/debug/powerpc/emulated_instructions/ (assumed debugfs is mounted on
/sys/kernel/debug). Optionally (controlled by
/sys/kernel/debug/powerpc/emulated_instructions/do_warn), rate-limited warnings
can be printed to the console when instructions are emulated.
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
---
Tested on ppc64 (ps3) and ppc32 (sequoia) using mfpvr.
v4:
- Introduce CONFIG_PPC_EMULATED_STATS
v3:
- Add generic unaligned
- Switch from sysfs + sysctl to debugfs. All virtual files now show up under
/sys/kernel/debug/powerpc/emulated_instructions (assumed debugfs mounted on
/sys/kernel/debug)
- Enable the printing of rate-limited warnings by writing a non-zero value to
/sys/kernel/debug/powerpc/emulated_instructions/do_warn
- Switch from per-CPU to system-wide counters
- Always use 32-bit counters (was 64-bit on ppc64)
- Counters are writable, i.e. can be reset (by root)
v2:
- arch/powerpc/kernel/sysfs.c is now compiled on ppc32, so we can provide
counters in sysfs on ppc32, too,
- WARN_EMULATED() is a no-op if CONFIG_SYSCTL is disabled,
- Add warnings for altivec,
- Add warnings for recently introduced emulation of vsx and isel
instructions.
arch/powerpc/Kconfig.debug | 13
arch/powerpc/include/asm/emulated_ops.h | 73 +++
arch/powerpc/kernel/align.c | 20 +-
arch/powerpc/kernel/traps.c | 96 ++-
4 files changed, 196 insertions(+), 6 deletions(-)
create mode 100644 arch/powerpc/include/asm/emulated_ops.h
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index a1098e2..d79a902 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -41,6 +41,19 @@ config HCALL_STATS
This option will add a small amount of overhead to all hypervisor
calls.
+config PPC_EMULATED_STATS
+ bool Emulated instructions tracking
+ depends on DEBUG_FS
+ help
+ Adds code to keep track of the number of instructions that are
+ emulated by the in-kernel emulator. Counters for the various classes
+ of emulated instructions are available under
+ powerpc/emulated_instructions/ in the root of the debugfs file
+ system. Optionally (controlled by
+ powerpc/emulated_instructions/do_warn in debugfs), rate-limited
+ warnings can be printed to the console when instructions are
+ emulated.
+
config CODE_PATCHING_SELFTEST
bool Run self-tests of the code-patching code.
depends on DEBUG_KERNEL
diff --git a/arch/powerpc/include/asm/emulated_ops.h
b/arch/powerpc/include/asm/emulated_ops.h
new file mode 100644
index 000..9154e85
--- /dev/null
+++ b/arch/powerpc/include/asm/emulated_ops.h
@@ -0,0 +1,73 @@
+/*
+ * Copyright 2007 Sony Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.
+ * If not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef _ASM_POWERPC_EMULATED_OPS_H
+#define _ASM_POWERPC_EMULATED_OPS_H
+
+#include asm/atomic.h
+
+
+#ifdef CONFIG_PPC_EMULATED_STATS
+
+struct ppc_emulated_entry {
+ const char *name;
+ atomic_t val;
+};
+
+extern struct ppc_emulated {
+#ifdef CONFIG_ALTIVEC
+ struct ppc_emulated_entry altivec;
+#endif
+ struct ppc_emulated_entry dcba;
+ struct ppc_emulated_entry dcbz;
+ struct ppc_emulated_entry fp_pair;
+ struct ppc_emulated_entry isel;
+ struct ppc_emulated_entry mcrxr;
+ struct ppc_emulated_entry mfpvr;
+ struct ppc_emulated_entry multiple;
+ struct ppc_emulated_entry popcntb;
+ struct ppc_emulated_entry spe;
+ struct ppc_emulated_entry string;
+ struct ppc_emulated_entry unaligned;
+#ifdef CONFIG_MATH_EMULATION
+ struct ppc_emulated_entry math;
+#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
+ struct ppc_emulated_entry 8xx;
+#endif
+#ifdef CONFIG_VSX
+ struct ppc_emulated_entry vsx;
+#endif
+} ppc_emulated;
+
+extern u32 ppc_warn_emulated;
+
+extern void ppc_warn_emulated_print(const char *type);
+
+#define PPC_WARN_EMULATED(type)
\
+ do { \
+ atomic_inc(ppc_emulated.type.val); \
+
[PATCH v3] powerpc/pci: clean up direct access to sysdata by iseries platform
We shouldn't directly access sysdata to get the device node. We should
be calling pci_device_to_OF_node().
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Fixed compile error (dev - pdev)
arch/powerpc/platforms/iseries/iommu.c |2 +-
arch/powerpc/platforms/iseries/pci.c |8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/iommu.c
b/arch/powerpc/platforms/iseries/iommu.c
index 4021982..6c1e101 100644
--- a/arch/powerpc/platforms/iseries/iommu.c
+++ b/arch/powerpc/platforms/iseries/iommu.c
@@ -177,7 +177,7 @@ static struct iommu_table *iommu_table_find(struct
iommu_table * tbl)
static void pci_dma_dev_setup_iseries(struct pci_dev *pdev)
{
struct iommu_table *tbl;
- struct device_node *dn = pdev-sysdata;
+ struct device_node *dn = pci_device_to_OF_node(pdev);
struct pci_dn *pdn = PCI_DN(dn);
const u32 *lsn = of_get_property(dn, linux,logical-slot-number, NULL);
diff --git a/arch/powerpc/platforms/iseries/pci.c
b/arch/powerpc/platforms/iseries/pci.c
index 21cddc3..175aac8 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -318,6 +318,7 @@ static void __init iomm_table_allocate_entry(struct pci_dev
*dev, int bar_num)
{
struct resource *bar_res = dev-resource[bar_num];
long bar_size = pci_resource_len(dev, bar_num);
+ struct device_node *dn = pci_device_to_OF_node(dev);
/*
* No space to allocate, quick exit, skip Allocation.
@@ -335,9 +336,9 @@ static void __init iomm_table_allocate_entry(struct pci_dev
*dev, int bar_num)
* Allocate the number of table entries needed for BAR.
*/
while (bar_size 0 ) {
- iomm_table[current_iomm_table_entry] = dev-sysdata;
+ iomm_table[current_iomm_table_entry] = dn;
ds_addr_table[current_iomm_table_entry] =
- iseries_ds_addr(dev-sysdata) | (bar_num 24);
+ iseries_ds_addr(dn) | (bar_num 24);
bar_size -= IOMM_TABLE_ENTRY_SIZE;
++current_iomm_table_entry;
}
@@ -410,7 +411,7 @@ void __init iSeries_pcibios_fixup_resources(struct pci_dev
*pdev)
struct device_node *node;
int i;
- node = find_device_node(bus, pdev-devfn);
+ node = pci_device_to_OF_node(pdev);
pr_debug(PCI: iSeries %s, pdev %p, node %p\n,
pci_name(pdev), pdev, node);
if (!node) {
@@ -441,7 +442,6 @@ void __init iSeries_pcibios_fixup_resources(struct pci_dev
*pdev)
}
}
- pdev-sysdata = node;
allocate_device_bars(pdev);
iseries_device_information(pdev, bus, *sub_bus);
}
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: fs_enet build breakage
On May 18, 2009, at 2:01 AM, Benjamin Herrenschmidt wrote: Hi Kumar Commit 4484079d517c2b6521621be0b1ea246ccc55c7d7 from your next branch breaks my 8xx test config with the following error: /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: In function ‘setup_immap’: /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: 947: error: ‘IMAP_ADDR’ undeclared (first use in this function) /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: 947: error: (Each undeclared identifier is reported only once /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: 947: error: for each function it appears in.) I'm still pushing it with a bunch of other stuff to test so people get to find more breakage but it will need to be fixed for the actual next branch. Cheers, Ben. I'm pretty sure the driver changes to address this are in dave's net- next tree. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
On May 17, 2009, at 11:49 PM, Benjamin Herrenschmidt wrote:
On Thu, 2009-05-14 at 17:42 -0500, Becky Bruce wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms. Probably the most interesting bit is the
addition of addr_needs_map to dma_ops - we need this as
a dma_op because the decision of whether or not an addr
can be mapped by a device is device-specific.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
Hi Becky !
Finally I got to look at your patch :-)
A few comments below...
#ifdef CONFIG_NOT_COHERENT_CACHE
/*
* DMA-consistent mapping functions for PowerPCs that don't support
@@ -76,6 +85,8 @@ struct dma_mapping_ops {
dma_addr_t dma_address, size_t size,
enum dma_data_direction direction,
struct dma_attrs *attrs);
+ int (*addr_needs_map)(struct device *dev, dma_addr_t addr,
+ size_t size);
What annoys me here is that we basically end up with two indirect
function calls for pretty much any DMA map. One was bad enough on low
end processors or very intensive networking, but this is getting real
bad don't you think ?
Granted, this is only used when swiotlb is used too, but still...
So the problem is that the region that can pass-through is somewhat
a mix of bus specific (incoming DMA window location size) and
device specific (device addressing limitations).
Now, if we can always reduce it to a single range though, which I
think is practically the case, can't we instead pre-calculate that
range and stick -that- in the struct dev archdata or similar thus
speeding up the decision for a given address as to whether it needs
a swiotlb mapping or not ? Or does it gets too messy ?
Part of this is how the generic swiotlb code works and part of it was
our desire not to bloat dev archdata by adding such info that as you
say is either bus specific or conveyed in the dma addr mask.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/12] mpc5121: Added I2C support.
Right. Furthermore, the i2c-mpc.c should be extened to support bus speed setting for the MPC512x, which has been merged recently (see commit id f2bd5efe). I have simple question about bus speed setting support. Existing implementation uses default safe speed if there is no 'clock-frequency' property in i2c node. Comments in code suggest that this behaviour is left for backward compatibility only. Should I make the 'clock-frequency' property mandatory for a new type of I2C controller (MPC5121) ? -- Best Regards. Piotr Zięcik ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/12] mpc5121: Added I2C support.
2009/5/18 Piotr Zięcik ko...@semihalf.com: Right. Furthermore, the i2c-mpc.c should be extened to support bus speed setting for the MPC512x, which has been merged recently (see commit id f2bd5efe). I have simple question about bus speed setting support. Existing implementation uses default safe speed if there is no 'clock-frequency' property in i2c node. Comments in code suggest that this behaviour is left for backward compatibility only. Should I make the 'clock-frequency' property mandatory for a new type of I2C controller (MPC5121) ? yes. At least in documentation, but I wouldn't do extra work to disable that behaviour for 5121 boards. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64hardware breakpoint usage
On Thu, May 14, 2009 at 04:21:48PM -0400, Alan Stern wrote: On Thu, 14 May 2009, K.Prasad wrote: Index: linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c === --- linux-2.6-tip.hbkpt.orig/samples/hw_breakpoint/data_breakpoint.c 2009-05-14 00:17:24.0 +0530 +++ linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c 2009-05-14 00:58:06.0 +0530 @@ -54,6 +54,10 @@ sample_hbp.info.type = HW_BREAKPOINT_WRITE; sample_hbp.info.len = HW_BREAKPOINT_LEN_4; #endif /* CONFIG_X86 */ +#ifdef CONFIG_PPC64 + sample_hbp.info.name = ksym_name; + sample_hbp.info.type = DABR_DATA_WRITE; This should be HW_BREAKPOINT_WRITE, not DABR_DATA_WRITE. Alan Stern Done. Thanks. -- K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure
On Mon, May 18, 2009 at 01:35:32PM +1000, Benjamin Herrenschmidt wrote: On Thu, 2009-05-14 at 19:13 +0530, K.Prasad wrote: plain text document attachment (ppc64_prepare_code_01) Prepare the PowerPC code for HW Breakpoint infrastructure patches by including relevant constant definitions and function declarations. Hi ! Some comments below... +#define HBP_NUM 1 /* Number of physical HW breakpoint registers */ Can you use a more verbose constant ? reg.h is included everywhere so the risk of collision is high. This constant is used by the generic HW Breakpoint code in kernel/hw_breakpoint.c too and renaming it here will require changes there too, while I don't see any existing name-space clashes. Instead the definition can be moved into arch/powerpc/include/asm/hw_breakpoint.h and in arch/power/include/asm/processor.h. What do you think? #define DABR_TRANSLATION (1UL 2) #define DABR_DATA_WRITE (1UL 1) #define DABR_DATA_READ (1UL 0) +#define DABR_DATA_RW (3UL 0) Do you really need that ? It's just DABR_DATA_WRITE | DABR_DATA_READ :-) Yes, it looks silly. I will remove it. The HW_BREAKPOINT_RW defined in arch/powerpc/include/asm/hw_breakpoint.h will instead be defined as: #define HW_BREAKPOINT_RW (DABR_DATA_READ | DABR_DATA_WRITE) Cheers, Ben. Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpointinterfaces
On Mon, 18 May 2009, K.Prasad wrote:
+int __kprobes hw_breakpoint_handler(struct die_args *args)
+{
+ int rc = NOTIFY_STOP;
+ struct hw_breakpoint *bp;
+ struct pt_regs *regs = args-regs;
+ unsigned long dar;
+ int cpu, stepped, is_kernel;
+
+ /* Disable breakpoints during exception handling */
+ set_dabr(0);
+
+ dar = regs-dar (~HW_BREAKPOINT_ALIGN);
+ is_kernel = (dar = TASK_SIZE) ? 1 : 0;
is_kernel_addr() ?
Ok.
Shouldn't this test hbp_kernel_pos instead?
Testing hbp_kernel_pos should be sufficient for PPC64 with just one
breakpoint register. However the above code is more extensible to other
PowerPC implementations which have more than one breakpoint register.
Then maybe you don't want to test this at all. Just compare the dar
value with each of the breakpoint addresses. That's more like what the
x86 code does.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Accessing NTFS Shares from Freescale MPC8313
On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote: Hi, (I haven't found any answers in the archives) How would I access a NTFS shared directory from a Freescale MPC8313? Will Samba run on a Freescale MPC8313? It should (and if it doesn't, file a bug with them). Userspace is pretty much the same at the source-code and user-interface level -- the answer to how do I do X on this PPC board is generally the same as the answer to how do I do X on Linux, other than that you may need to compile some packages manually if they don't come with whatever distribution you're using. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
On Fri, May 01, 2009 at 07:48:46AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2009-04-30 at 21:59 +0100, Mel Gorman wrote:
This patch fixes the problem by not asseting the PTE is locked for VMAs
backed by huge pages.
Thanks, will apply.
What's the story with this patch? I'm still hearing of failures with huge pages
that this patch fixes but I'm no seeing it upstream. Was the patch
rejected or did it just slip through the cracks?
To refresh, an assertion is being made on ppc64 that only makes sense for
base pages. Hugepages through a wobbly every time. For convenience, here is
the patch again.
Thanks.
CUT HERE
powerpc: Do not assert pte_locked for hugepage PTE entries
With DEBUG_VM enabled, an assertion is made when changing the protection
flags of a PTE that the PTE is locked. Huge pages use a different
pagetable format and the assertion is bogus and will always trigger with
a bug looking something like
Unable to handle kernel paging request for data at address 0xf1a0023586f8
Faulting instruction address: 0xc0034a80
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 NUMA Maple
Modules linked in: dm_snapshot dm_mirror dm_region_hash
dm_log dm_mod loop evdev ext3 jbd mbcache sg sd_mod ide_pci_generic
pata_amd ata_generic ipr libata tg3 libphy scsi_mod windfarm_pid
windfarm_smu_sat windfarm_max6690_sensor windfarm_lm75_sensor
windfarm_cpufreq_clamp windfarm_core i2c_powermac
NIP: c0034a80 LR: c0034b18 CTR: 0003
REGS: c3037600 TRAP: 0300 Not tainted (2.6.30-rc3-autokern1)
MSR: 90009032 EE,ME,IR,DR CR: 28002484 XER: 200f
DAR: f1a0023586f8, DSISR: 4001
TASK = c002e54cc740[2960] 'map_high_trunca' THREAD: c3034000 CPU: 2
GPR00: 4000 c3037880 c0895d30 c002e5a2e500
GPR04: a000 c002edc40880 00570393 0001
GPR08: f00011ac 01a0023586e8 00f5 f1a0023586e8
GPR12: 28000484 c08dd780 1000
GPR16: f000 a000 c3037a20
GPR20: c002e5f4ece8 1000 c002edc40880
GPR24: c002e5f4ece8 a000 c002e5f4ece8
GPR28: 00570393 c002e5a2e500 a000 c3037880
NIP [c0034a80] .assert_pte_locked+0xa4/0xd0
LR [c0034b18] .ptep_set_access_flags+0x6c/0xb4
Call Trace:
[c3037880] [c3037990] 0xc3037990 (unreliable)
[c3037910] [c0034b18] .ptep_set_access_flags+0x6c/0xb4
[c30379b0] [c014bef8] .hugetlb_cow+0x124/0x674
[c3037b00] [c014c930] .hugetlb_fault+0x4e8/0x6f8
[c3037c00] [c013443c] .handle_mm_fault+0xac/0x828
[c3037cf0] [c00340a8] .do_page_fault+0x39c/0x584
[c3037e30] [c00057b0] handle_page_fault+0x20/0x5c
Instruction dump:
7d29582a 7d200074 7800d182 0b00 3c004000 3960 780007c6 796b00c4
7d290214 7929a302 1d290068 7d6b4a14 800b0010 7c74 7800d182 0b00
This patch fixes the problem by not asseting the PTE is locked for VMAs
backed by huge pages.
Signed-off-by: Mel Gorman m...@csn.ul.ie
---
arch/powerpc/mm/pgtable.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index f5c6fd4..ae1d67c 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -219,7 +219,8 @@ int ptep_set_access_flags(struct vm_area_struct *vma,
unsigned long address,
entry = do_dcache_icache_coherency(entry);
changed = !pte_same(*(ptep), entry);
if (changed) {
- assert_pte_locked(vma-vm_mm, address);
+ if (!(vma-vm_flags VM_HUGETLB))
+ assert_pte_locked(vma-vm_mm, address);
__ptep_set_access_flags(ptep, entry);
flush_tlb_page_nohash(vma, address);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: fs_enet build breakage
On Mon, May 18, 2009 at 08:23:17AM -0500, Kumar Gala wrote: On May 18, 2009, at 2:01 AM, Benjamin Herrenschmidt wrote: Hi Kumar Commit 4484079d517c2b6521621be0b1ea246ccc55c7d7 from your next branch breaks my 8xx test config with the following error: /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: In function ‘setup_immap’: /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: 947: error: ‘IMAP_ADDR’ undeclared (first use in this function) /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: 947: error: (Each undeclared identifier is reported only once /home/benh/linux-powerpc-test/drivers/net/fs_enet/fs_enet-main.c: 947: error: for each function it appears in.) I'm still pushing it with a bunch of other stuff to test so people get to find more breakage but it will need to be fixed for the actual next branch. Cheers, Ben. I'm pretty sure the driver changes to address this are in dave's net- next tree. Won't this break git bisect? Not to mention anyone trying to use your tree now... -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
On Mon, 18 May 2009, Mel Gorman wrote: What's the story with this patch? I'm still hearing of failures with huge pages that this patch fixes but I'm no seeing it upstream. Was the patch rejected or did it just slip through the cracks? It didn't slip through the cracks, it was apparently just delayed. It's part of the merge requests I've gotten today (well, strictly speaking it seems to have hit my inbox just before midnight yesterday, but that's because those silly aussies stand upside down and sleep at odd hours). In fact, I just merged it, I haven't even had time to push that out. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
On Mon, May 18, 2009 at 01:24:49PM +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-05-15 at 20:18 +0200, Gabriel Paubert wrote: Since PPC_MUTIPLATFORM was removed, it was impossible to select the driver for mv643xx_eth on the Pegasos. Fix by allowing to select the driver on CHRP platforms; Pegasos is a CHRP platform and the driver will not work wihtout arch/powerpc/platforms/chrp/pegasos_eth. The patch also removes all references to MV64360 config option which no more exists. Signed-off-by: Gabriel Paubert paub...@iram.es Please break that up into 2 different patches. The arch/powerpc one that removes the reference from IRQ_ALL_CPUs and the drivers/net/ one which should be set to the netdev mailing list. Ok, but I have a doubt about the PPC one, should MV64360 be removed or changed to MV64X60? In any case, I can't test it. Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Allow selecting mv643xx_eth on Pegasos again
Since PPC_MUTIPLATFORM was removed, it was impossible to select the driver for mv643xx_eth on the Pegasos. Fix by allowing to select the driver on CHRP platforms; Pegasos is a CHRP platform and the driver will not work without arch/powerpc/platforms/chrp/pegasos_eth. Signed-off-by: Gabriel Paubert paub...@iram.es diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 214a92d..6fc0ff4 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND config MV643XX_ETH tristate Marvell Discovery (643XX) and Orion ethernet support - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM PPC32) || PLAT_ORION + depends on MV64X60 || PPC_CHRP || PLAT_ORION select INET_LRO select PHYLIB help ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Allow selecting mv643xx_eth on Pegasos again
-Original Message- From: linuxppc-dev-bounces+emilian.medve=freescale@ozlabs.org [mailto:linuxppc-dev- bounces+emilian.medve=freescale@ozlabs.org] On Behalf Of Gabriel Paubert Sent: Monday, May 18, 2009 12:38 PM To: Lennert Buytenhek Cc: t...@cyrius.com; LinuxPPC; pac...@kosh.dhis.org; net...@vger.kernel.org; David Miller Subject: [PATCH] Allow selecting mv643xx_eth on Pegasos again Since PPC_MUTIPLATFORM was removed, it was impossible to select the driver for mv643xx_eth on the Pegasos. Fix by allowing to select the driver on CHRP platforms; Pegasos is a CHRP platform and the driver will not work without arch/powerpc/platforms/chrp/pegasos_eth. Signed-off-by: Gabriel Paubert paub...@iram.es diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 214a92d..6fc0ff4 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND config MV643XX_ETH tristate Marvell Discovery (643XX) and Orion ethernet support - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM PPC32) || PLAT_ORION + depends on MV64X60 || PPC_CHRP || PLAT_ORION select INET_LRO select PHYLIB help This got fixed here: http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commi tdiff;h=952ee9df26c487f2d73b2dced58ec904f19ea0f8 Cheers, Emil. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Accessing NTFS Shares from Freescale MPC8313
Scott Wood wrote: On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote: Hi, (I haven't found any answers in the archives) How would I access a NTFS shared directory from a Freescale MPC8313? Will Samba run on a Freescale MPC8313? It should (and if it doesn't, file a bug with them). Userspace is pretty much the same at the source-code and user-interface level -- the answer to how do I do X on this PPC board is generally the same as the answer to how do I do X on Linux, other than that you may need to compile some packages manually if they don't come with whatever distribution you're using. Thanks Scott. I did some more reading on the board and it appears that it's not as limited as I thought. The custom Linux we're running is very limited (so it appears) and I interpreted the board to be so as well. I'm a Windows ASP.NET developer thrown off the deep end into Linux so please forgive the noob questions. After going through many post it appears my questions are pertinent to general Linux. Thank you! Chris Plasun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Accessing NTFS Shares from Freescale MPC8313
Hi Leon, Leon Woestenberg wrote: Hello Chris, On Mon, May 18, 2009 at 8:06 PM, Chris Plasun chrisp...@yahoo.com wrote: Scott Wood wrote: On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote: (I haven't found any answers in the archives) How would I access a NTFS shared directory from a Freescale MPC8313? Will Samba run on a Freescale MPC8313? It should (and if it doesn't, file a bug with them). Userspace is pretty much the same at the source-code and user-interface level -- the answer to how do I do X on this PPC board is generally the same as the answer to how do I do X on Linux, other than that you may need to compile some packages manually if they don't come with whatever distribution you're using. Thanks Scott. I did some more reading on the board and it appears that it's not as limited as I thought. The custom Linux we're running is very limited (so it appears) and I interpreted the board to be so as well. To build your own fully-open Linux for this board, I can recommend both these projects: LTIB (http://www.bitshrine.org/) OpenEmbedded (http://www.openembedded.org/) We use the latter in an industrial setting with much success, Thanks Leon. I'll definitely be back to ask for help to get these distributions running =) cp ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
On Mon, May 18, 2009 at 10:48:58AM -0700, Medve Emilian-EMMEDVE1 wrote: -Original Message- From: linuxppc-dev-bounces+emilian.medve=freescale@ozlabs.org [mailto:linuxppc-dev- bounces+emilian.medve=freescale@ozlabs.org] On Behalf Of Gabriel Paubert Sent: Monday, May 18, 2009 12:38 PM To: Lennert Buytenhek Cc: t...@cyrius.com; LinuxPPC; pac...@kosh.dhis.org; net...@vger.kernel.org; David Miller Subject: [PATCH] Allow selecting mv643xx_eth on Pegasos again Since PPC_MUTIPLATFORM was removed, it was impossible to select the driver for mv643xx_eth on the Pegasos. Fix by allowing to select the driver on CHRP platforms; Pegasos is a CHRP platform and the driver will not work without arch/powerpc/platforms/chrp/pegasos_eth. Signed-off-by: Gabriel Paubert paub...@iram.es diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 214a92d..6fc0ff4 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND config MV643XX_ETH tristate Marvell Discovery (643XX) and Orion ethernet support - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM PPC32) || PLAT_ORION + depends on MV64X60 || PPC_CHRP || PLAT_ORION select INET_LRO select PHYLIB help This got fixed here: http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commi tdiff;h=952ee9df26c487f2d73b2dced58ec904f19ea0f8 Ok, I was not aware of it, but the fact is that MV64360 no more exists and the only non MV64X60 platform that may need it is the Pegasos (to my knowledge) and it relies on some platform specific code enabled by PPC_CHRP. Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
Segher, what are we missing here ? The symbol name is misleading, and the help text is incorrect. With those things fixed, I won't oppose the patch; it would be nice if the logic here was cleaned up to avoid all the double negations, but I'm not going to do it, so I won't ask others to either. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Allow selecting mv643xx_eth on Pegasos again
Hello Gabriel, -Original Message- From: Gabriel Paubert [mailto:paub...@iram.es] Sent: Monday, May 18, 2009 1:48 PM To: Medve Emilian-EMMEDVE1 Cc: Lennert Buytenhek; t...@cyrius.com; LinuxPPC; pac...@kosh.dhis.org; net...@vger.kernel.org; David Miller Subject: Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again On Mon, May 18, 2009 at 10:48:58AM -0700, Medve Emilian-EMMEDVE1 wrote: -Original Message- From: linuxppc-dev-bounces+emilian.medve=freescale@ozlabs.org [mailto:linuxppc-dev- bounces+emilian.medve=freescale@ozlabs.org] On Behalf Of Gabriel Paubert Sent: Monday, May 18, 2009 12:38 PM To: Lennert Buytenhek Cc: t...@cyrius.com; LinuxPPC; pac...@kosh.dhis.org; net...@vger.kernel.org; David Miller Subject: [PATCH] Allow selecting mv643xx_eth on Pegasos again Since PPC_MUTIPLATFORM was removed, it was impossible to select the driver for mv643xx_eth on the Pegasos. Fix by allowing to select the driver on CHRP platforms; Pegasos is a CHRP platform and the driver will not work without arch/powerpc/platforms/chrp/pegasos_eth. Signed-off-by: Gabriel Paubert paub...@iram.es diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 214a92d..6fc0ff4 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND config MV643XX_ETH tristate Marvell Discovery (643XX) and Orion ethernet support - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM PPC32) || PLAT_ORION + depends on MV64X60 || PPC_CHRP || PLAT_ORION select INET_LRO select PHYLIB help This got fixed here: http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commi tdiff;h=952ee9df26c487f2d73b2dced58ec904f19ea0f8 Ok, I was not aware of it, but the fact is that MV64360 no more exists and the only non MV64X60 platform that may need it is the Pegasos (to my knowledge) and it relies on some platform specific code enabled by PPC_CHRP. You're correct. MV64360 seems to be stale. Do you want to re-spin your patch to get rid of it? (I wouldn't create a dependency between MV643XX_ETH and PPC_CHRP.) Cheers, Emil. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote: Part of this is how the generic swiotlb code works and part of it was our desire not to bloat dev archdata by adding such info that as you say is either bus specific or conveyed in the dma addr mask. Right but perf sucks :-) Maybe an option is to clamp the DMA mask when it's set by the driver to limit it to the available inbound window ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: fs_enet build breakage
On Mon, 2009-05-18 at 12:20 -0500, Scott Wood wrote: I'm pretty sure the driver changes to address this are in dave's net- next tree. Won't this break git bisect? Not to mention anyone trying to use your tree now... Right, though if you have the commit ID in DaveM tree, I can work with him to sort out that driver, for example by having the same commit in my tree. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
Hello Medve On Mon, May 18, 2009 at 01:15:12PM -0700, Medve Emilian-EMMEDVE1 wrote: You're correct. MV64360 seems to be stale. Do you want to re-spin your patch to get rid of it? No problem, bu should I respin in from the current official git or on top of yours? (I wouldn't create a dependency between MV643XX_ETH and PPC_CHRP.) Fine with me. Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
On Thu, 2009-05-14 at 08:00 -0600, Grant Likely wrote: All of this doesn't actually affect the driver code at all. It's all handled by the kernel and the DMA apis. What it does affect is multiplatform kernels. The DMA behaviour is set at compile time, not run time, depending on the setting of CONFIG_NON_COHERENT_CACHE (see arch/powerpc/platforms/Kconfig.cputype). A kernel which has it on won't run properly on a platform which has it off, and visa-versa. We are close to the point where we can make this a runtime option though, by just having a different set of dma_ops hooked in. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7] introduce macro spin_event_timeout()
On Thu, May 14, 2009 at 11:10 AM, Grant Likely grant.lik...@secretlab.ca wrote: In other words, write your patches which use it and submit the lot as a patch series with this patch as the first. That gives some evidence that this macro will actually be used and useful. This is going to be more difficult than you think. The problem is that I don't have access to much hardware that uses drivers which can take advantage of this macro. I can find one, maybe two examples, but if I put a timeout that's too short, I might break some other platform without knowing it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Allow selecting mv643xx_eth on Pegasos again
Hello Gabriel, -Original Message- From: Gabriel Paubert [mailto:paub...@iram.es] Sent: Monday, May 18, 2009 5:19 PM To: Medve Emilian-EMMEDVE1 Cc: Lennert Buytenhek; t...@cyrius.com; LinuxPPC; pac...@kosh.dhis.org; net...@vger.kernel.org; David Miller Subject: Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again Hello Medve On Mon, May 18, 2009 at 01:15:12PM -0700, Medve Emilian-EMMEDVE1 wrote: You're correct. MV64360 seems to be stale. Do you want to re-spin your patch to get rid of it? No problem, bu should I respin in from the current official git or on top of yours? Top of the tree should be good. Cheers, Emil. (I wouldn't create a dependency between MV643XX_ETH and PPC_CHRP.) Fine with me. Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] Allow selecting mv643xx_eth on Pegasos again
Since PPC_MUTIPLATFORM was removed, it was impossible to select the driver for mv643xx_eth on the Pegasos. Fix it and take the opportunity to remove the stale MV64360 config option. Signed-off-by: Gabriel Paubert paub...@iram.es diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 214a92d..aff4f8c 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND config MV643XX_ETH tristate Marvell Discovery (643XX) and Orion ethernet support - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM PPC32) || PLAT_ORION + depends on MV64X60 || PPC32 || PLAT_ORION select INET_LRO select PHYLIB help ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
the question about the DDR1_Rcomp code for INTEL IXP4XX CPU?
Hi,every one, I want to drive the Rcomp circuit for ixp460, because I found that the ixp460 could not power up on low temperature(-40 degree). I want to add those code on start.s, follow is the instruction from ixp460 developer's manual. Does anyone can help me realize those code from No.4 to No.6? Instrction: 1. The MCU applies the clock DDRI_CK[2:0] at power up along with system power (clock frequency unknown). 2. The MCU must stabilize DDRI_CK[2:0] within 100 μs after power stabilizes. 3. The MCU holds the following control inputs inactive: DDRI_RAS_N, DDRI_CAS_N, DDRI_WE_N, DDRI_CS_N[1:0] The MCU then places all of the following data outputs and strobes in the High-Z state: DDRI_DQS[4:0], DDRI_DQ[31:0], DDR_CB[7:0] 4. The MCU then performs sixteen RCOMP calibration cycles which take an additional 34 ms. Software MUST wait until this time has elapsed before continuing with DDRI SDRAM initialization. 5. Software overwrites the default value of register DDR_RCOMP_CSR3 (Hex Offset Address = 0x0CC00 F570) with a new value of 0x 1000. 6. Software overwrites the default value of register DDR_DRIVE3 (Hex Offset Address = 0x0CC00 F5AC) with a new value of 0x0002 08F0. 7. Software disables the refresh counter by setting the RFR to zero. 8. Software issues one NOP cycle after the 200 us device deselect. A NOP is accomplished by setting the SDIR to 00112. The MCU asserts DDRI_CKE[1:0] with the NOP. 9. Software issues a precharge-all command to the DDRI SDRAM interface by setting the SDIR to 00102. 10. Software issues an extended-mode-register-set command to enable the DLL by writing 01002 to the SDIR. The MCU supports the following DDRI SDRAM mode parameters: 11. After waiting Tmrd cycles, software issues a mode-register-set command by writing 00012 to the SDIR to program the DDRI SDRAM parameters and to reset the DLL. The MCU supports the following DDRI SDRAM mode parameters: 12. After waiting Tmrd cycles, software issues a precharge-all command to the DDRI SDRAM interface by setting the SDIR to 00102. 13. After waiting Trp cycles, software provides two auto-refresh cycles. An auto-refresh cycle is accomplished by setting the SDIR to 01102. Software must ensure at least Trfc cycles between each auto-refresh command. 14. Following the second auto-refresh cycle, software must wait Trfc cycles. Then, software issues a mode-register-set command by writing to the SDIR to program the DDRI SDRAM parameters without resetting the DLL by writing 2 to the SDIR. 15. The MCU may issue a row-activate command Tmrd cycles after the mode-register-set command. 16. Software re-enables the refresh counter by setting the RFR to the required value. The waveform in Figure 109 illustrates the DDRI SDRAM initialization sequence. 2009-05-18 郭 劲 13810607876 010-62771694 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mpc5200 fec error
Hello all, I am testing a 2.6.29.3 (with preempt_rt patches) kernel on a phytec pcm030 and am getting a kernel hang when testing the fec Ethernet controller. The error only occurs when running the preempt-patched kernel, an unmodified kernel works fine. Is anyone out there using preempt_rt on an MPC5200 successfully? Eric r...@rudolph-ui:/root iperf -c linux-5200bdevl01 -P 2 -i 1 -p 5001 -f k -t 600 Client connecting to linux-5200bdevl01, TCP port 5001 TCP window size: 36.2 KByte (default) [ 4] local 10.1.4.88 port 37872 connected with 10.1.5.234 port 5001 [ 3] local 10.1.4.88 port 37871 connected with 10.1.5.234 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 3824 KBytes 31326 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 0.0- 1.0 sec 3656 KBytes 29950 Kbits/sec [SUM] 0.0- 1.0 sec 7480 KBytes 61276 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 1.0- 2.0 sec 3760 KBytes 30802 Kbits/sec [ ID] Interval Transfer Bandwidth [ 3] 1.0- 2.0 sec 3752 KBytes 30736 Kbits/sec [SUM] 1.0- 2.0 sec 7512 KBytes 61538 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 2.0- 3.0 sec 3728 KBytes 30540 Kbits/sec [ ID] Interval Transfer Bandwidth [ 3] 2.0- 3.0 sec 3816 KBytes 31261 Kbits/sec [SUM] 2.0- 3.0 sec 7544 KBytes 61800 Kbits/sec [ ID] Interval Transfer Bandwidth [ 3] 3.0- 4.0 sec 3712 KBytes 30409 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 3.0- 4.0 sec 3824 KBytes 31326 Kbits/sec [SUM] 3.0- 4.0 sec 7536 KBytes 61735 Kbits/sec [ ID] Interval Transfer Bandwidth [ 3] 4.0- 5.0 sec 3968 KBytes 32506 Kbits/sec [ ID] Interval Transfer Bandwidth [ 4] 4.0- 5.0 sec 3624 KBytes 29688 Kbits/sec [SUM] 4.0- 5.0 sec 7592 KBytes 62194 Kbits/sec [ 5761.999175] net eth0: transmit queue overrun [ 5762.003591] net eth0: transmit queue overrun [ 5762.007948] net eth0: transmit queue overrun [ 5762.012302] net eth0: transmit queue overrun [ 5762.016658] net eth0: transmit queue overrun [ 5762.021013] net eth0: transmit queue overrun [ 5762.025381] net eth0: transmit queue overrun [ 5762.029735] net eth0: transmit queue overrun [ 5762.034090] net eth0: transmit queue overrun [ 5762.038445] net eth0: transmit queue overrun [ 5767.000928] net eth0: transmit queue overrun [ 5767.005278] net eth0: transmit queue overrun [ 5767.009634] net eth0: transmit queue overrun [ 5767.013990] net eth0: transmit queue overrun [ 5767.018345] net eth0: transmit queue overrun [ 5767.022701] net eth0: transmit queue overrun ... _ This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc/pci: clean up direct access to sysdata by iseries platform
Hi Kumar, On Mon, 18 May 2009 07:56:27 -0500 Kumar Gala ga...@kernel.crashing.org wrote: We shouldn't directly access sysdata to get the device node. We should be calling pci_device_to_OF_node(). Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Fixed compile error (dev - pdev) I tested the previous version with the typo fixed, so assuming that you changed nothing else, Tested-by: Stephen Rothwell s...@canb.auug.org.au Acked-by: Stephen Rothwell s...@canb.auug.org.au -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpcEmbcZCE5C.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert paub...@iram.es Date: Tue, 19 May 2009 01:21:13 +0200 Since PPC_MUTIPLATFORM was removed, it was impossible to select the driver for mv643xx_eth on the Pegasos. Fix it and take the opportunity to remove the stale MV64360 config option. Signed-off-by: Gabriel Paubert paub...@iram.es This patch doesn't even apply to net-next-2.6, please send me changes relative to that. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7] introduce macro spin_event_timeout()
On Mon, May 18, 2009 at 4:49 PM, Timur Tabi ti...@freescale.com wrote: On Thu, May 14, 2009 at 11:10 AM, Grant Likely grant.lik...@secretlab.ca wrote: In other words, write your patches which use it and submit the lot as a patch series with this patch as the first. That gives some evidence that this macro will actually be used and useful. This is going to be more difficult than you think. The problem is that I don't have access to much hardware that uses drivers which can take advantage of this macro. I can find one, maybe two examples, but if I put a timeout that's too short, I might break some other platform without knowing it. Then let it lie fallow on the list and in patchwork. It is published, and people know that it is available (I'll certainly consider it as I do driver work), but there must be real (not just theoretical) in kernel users of the interface. I someone wants to use it, then they can add it to their series or ping the list about getting it merged. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
CC'ed linux-kernel
On Thu, 14 May 2009 17:42:28 -0500
Becky Bruce bec...@kernel.crashing.org wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms. Probably the most interesting bit is the
addition of addr_needs_map to dma_ops - we need this as
a dma_op because the decision of whether or not an addr
can be mapped by a device is device-specific.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/Kconfig | 12 ++-
arch/powerpc/include/asm/dma-mapping.h | 11 ++
arch/powerpc/include/asm/swiotlb.h | 27 +
arch/powerpc/kernel/Makefile |1 +
arch/powerpc/kernel/dma-swiotlb.c | 163
arch/powerpc/kernel/dma.c |2 +-
arch/powerpc/kernel/setup_32.c |6 +
arch/powerpc/kernel/setup_64.c |6 +
8 files changed, 226 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/include/asm/swiotlb.h
create mode 100644 arch/powerpc/kernel/dma-swiotlb.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a0d1146..54e519a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -296,9 +296,19 @@ config IOMMU_VMERGE
config IOMMU_HELPER
def_bool PPC64
+config SWIOTLB
+ bool SWIOTLB support
+ default n
+ select IOMMU_HELPER
+ ---help---
+ Support for IO bounce buffering for systems without an IOMMU.
+ This allows us to DMA to the full physical address space on
+ platforms where the size of a physical address is larger
+ than the bus address. Not all platforms support this.
+
config PPC_NEED_DMA_SYNC_OPS
def_bool y
- depends on NOT_COHERENT_CACHE
+ depends on (NOT_COHERENT_CACHE || SWIOTLB)
config HOTPLUG_CPU
bool Support for enabling/disabling CPUs
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index c69f2b5..71bbc17 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -15,9 +15,18 @@
#include linux/scatterlist.h
#include linux/dma-attrs.h
#include asm/io.h
+#include asm/swiotlb.h
#define DMA_ERROR_CODE (~(dma_addr_t)0x0)
+/* Some dma direct funcs must be visible for use in other dma_ops */
+extern void *dma_direct_alloc_coherent(struct device *dev, size_t size,
+dma_addr_t *dma_handle, gfp_t flag);
+extern void dma_direct_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle);
+
+extern unsigned long get_dma_direct_offset(struct device *dev);
+
#ifdef CONFIG_NOT_COHERENT_CACHE
/*
* DMA-consistent mapping functions for PowerPCs that don't support
@@ -76,6 +85,8 @@ struct dma_mapping_ops {
dma_addr_t dma_address, size_t size,
enum dma_data_direction direction,
struct dma_attrs *attrs);
+ int (*addr_needs_map)(struct device *dev, dma_addr_t addr,
+ size_t size);
#ifdef CONFIG_PPC_NEED_DMA_SYNC_OPS
void(*sync_single_range_for_cpu)(struct device *hwdev,
dma_addr_t dma_handle, unsigned long offset,
diff --git a/arch/powerpc/include/asm/swiotlb.h
b/arch/powerpc/include/asm/swiotlb.h
new file mode 100644
index 000..30891d6
--- /dev/null
+++ b/arch/powerpc/include/asm/swiotlb.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef __ASM_SWIOTLB_H
+#define __ASM_SWIOTLB_H
+
+#include linux/swiotlb.h
+
+extern struct dma_mapping_ops swiotlb_dma_ops;
+extern struct dma_mapping_ops swiotlb_pci_dma_ops;
+
+int swiotlb_arch_address_needs_mapping(struct device *, dma_addr_t,
+size_t size);
+
+static inline void dma_mark_clean(void *addr, size_t size) {}
+
+extern unsigned int ppc_swiotlb_enable;
+int __init swiotlb_setup_bus_notifier(void);
+
+#endif /* __ASM_SWIOTLB_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 71901fb..34c0a95 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES)+= kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
+obj-$(CONFIG_SWIOTLB)+= dma-swiotlb.o
pci64-$(CONFIG_PPC64)+=
Please pull from 'next' branch
Ben, This is based on benh/next and fixes the cpm cruft patch to drop the removal of IMAP_ADDR from cpm1 so we still build on 8xx. Will deal with that when we get into the merge window for 2.6.31. - k Please pull from 'next' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next to receive the following updates: Documentation/powerpc/dts-bindings/ecm.txt | 64 + Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt |3 Documentation/powerpc/dts-bindings/fsl/esdhc.txt |5 Documentation/powerpc/dts-bindings/fsl/mcm.txt | 64 + arch/powerpc/boot/dts/gef_ppc9a.dts | 14 arch/powerpc/boot/dts/gef_sbc310.dts | 14 arch/powerpc/boot/dts/gef_sbc610.dts | 14 arch/powerpc/boot/dts/ksi8560.dts| 13 arch/powerpc/boot/dts/mpc832x_mds.dts|3 arch/powerpc/boot/dts/mpc832x_rdb.dts|3 arch/powerpc/boot/dts/mpc8349emitx.dts |2 arch/powerpc/boot/dts/mpc8349emitxgp.dts |1 arch/powerpc/boot/dts/mpc834x_mds.dts|2 arch/powerpc/boot/dts/mpc836x_mds.dts|3 arch/powerpc/boot/dts/mpc836x_rdk.dts|2 arch/powerpc/boot/dts/mpc8377_mds.dts|1 arch/powerpc/boot/dts/mpc8378_mds.dts|1 arch/powerpc/boot/dts/mpc8379_mds.dts|1 arch/powerpc/boot/dts/mpc8536ds.dts | 18 arch/powerpc/boot/dts/mpc8540ads.dts | 15 arch/powerpc/boot/dts/mpc8541cds.dts | 16 arch/powerpc/boot/dts/mpc8544ds.dts | 18 arch/powerpc/boot/dts/mpc8548cds.dts | 17 arch/powerpc/boot/dts/mpc8555cds.dts | 16 arch/powerpc/boot/dts/mpc8560ads.dts | 15 arch/powerpc/boot/dts/mpc8568mds.dts | 51 + arch/powerpc/boot/dts/mpc8569mds.dts | 583 +++ arch/powerpc/boot/dts/mpc8572ds.dts | 17 arch/powerpc/boot/dts/mpc8572ds_36b.dts | 39 - arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 16 arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts |2 arch/powerpc/boot/dts/mpc8610_hpcd.dts | 16 arch/powerpc/boot/dts/mpc8641_hpcn.dts | 16 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 609 arch/powerpc/boot/dts/p2020ds.dts| 704 +++ arch/powerpc/boot/dts/sbc8349.dts|1 arch/powerpc/boot/dts/sbc8548.dts| 16 arch/powerpc/boot/dts/sbc8560.dts| 15 arch/powerpc/boot/dts/sbc8641d.dts | 16 arch/powerpc/boot/dts/socrates.dts | 15 arch/powerpc/boot/dts/stx_gp3_8560.dts | 15 arch/powerpc/boot/dts/tqm8540.dts| 15 arch/powerpc/boot/dts/tqm8541.dts| 15 arch/powerpc/boot/dts/tqm8548-bigflash.dts | 16 arch/powerpc/boot/dts/tqm8548.dts| 16 arch/powerpc/boot/dts/tqm8555.dts| 15 arch/powerpc/boot/dts/tqm8560.dts| 15 arch/powerpc/include/asm/cpm2.h |4 arch/powerpc/include/asm/mpc86xx.h | 33 arch/powerpc/include/asm/pci-bridge.h|6 arch/powerpc/include/asm/qe.h| 21 arch/powerpc/oprofile/op_model_fsl_emb.c | 14 arch/powerpc/platforms/82xx/pq2ads.h | 13 arch/powerpc/platforms/85xx/Kconfig |1 arch/powerpc/platforms/85xx/mpc85xx_ds.c | 43 + arch/powerpc/platforms/85xx/mpc85xx_mds.c| 52 + arch/powerpc/platforms/86xx/gef_ppc9a.c |1 arch/powerpc/platforms/86xx/gef_sbc310.c |1 arch/powerpc/platforms/86xx/gef_sbc610.c |1 arch/powerpc/platforms/86xx/mpc8610_hpcd.c |1 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |1 arch/powerpc/platforms/86xx/mpc86xx_smp.c|8 arch/powerpc/platforms/86xx/sbc8641d.c |1 arch/powerpc/platforms/8xx/mpc885ads.h |4 arch/powerpc/platforms/fsl_uli1575.c | 24 arch/powerpc/sysdev/cpm2.c |2 arch/powerpc/sysdev/fsl_msi.c|9 arch/powerpc/sysdev/fsl_pci.c| 132 +++ arch/powerpc/sysdev/fsl_pci.h|6 arch/powerpc/sysdev/fsl_rio.c| 15 arch/powerpc/sysdev/fsl_soc.c| 14 arch/powerpc/sysdev/qe_lib/qe.c | 75 +- drivers/dma/fsldma.c | 13 drivers/net/ucc_geth.c | 24 drivers/net/ucc_geth.h |4
