Re[4]: [PATCH][v4] powerpc 44x: support for 256KB PAGE_SIZE
On Sunday, January 18, 2009 you wrote: Ok I tried this out in menuconfig. You are right that the depends on makes sense as it removes the option from the config file as not relevant. But right now to enable 256K pages one has to go to platform setup to find this dependency, then has to go to general setup to find the shmem option at the bottom of the list in the embedded/expert section, then finally go to the kernel options menu to finally choose the page size. Moving this question just before the page size choice removes one of those hidden menu, so I suggest that it be moved to just before the option that it allow be selected. Right, it'll me more convenient. My [v5] patch addresses this. Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PowerPC: MPC85xx: TQM85xx: add i2c device nodes for LM75
Automatic I2C device probing is not done any more. Therefore we need
proper DTS device node definitions for the I2C LM75 thermal sensor on
the TQM85xx modules.
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
---
arch/powerpc/boot/dts/tqm8540.dts |5 +
arch/powerpc/boot/dts/tqm8541.dts |5 +
arch/powerpc/boot/dts/tqm8548-bigflash.dts |5 +
arch/powerpc/boot/dts/tqm8548.dts |5 +
arch/powerpc/boot/dts/tqm8555.dts |5 +
arch/powerpc/boot/dts/tqm8560.dts |5 +
6 files changed, 30 insertions(+)
Index: linux-2.6/arch/powerpc/boot/dts/tqm8548.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8548.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8548.dts
@@ -85,6 +85,11 @@
interrupt-parent = mpic;
dfsrr;
+ d...@50 {
+ compatible = national,lm75;
+ reg = 0x50;
+ };
+
r...@68 {
compatible = dallas,ds1337;
reg = 0x68;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8540.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8540.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8540.dts
@@ -84,6 +84,11 @@
interrupt-parent = mpic;
dfsrr;
+ d...@50 {
+ compatible = national,lm75;
+ reg = 0x50;
+ };
+
r...@68 {
compatible = dallas,ds1337;
reg = 0x68;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8541.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8541.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8541.dts
@@ -83,6 +83,11 @@
interrupt-parent = mpic;
dfsrr;
+ d...@50 {
+ compatible = national,lm75;
+ reg = 0x50;
+ };
+
r...@68 {
compatible = dallas,ds1337;
reg = 0x68;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8548-bigflash.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -85,6 +85,11 @@
interrupt-parent = mpic;
dfsrr;
+ d...@50 {
+ compatible = national,lm75;
+ reg = 0x50;
+ };
+
r...@68 {
compatible = dallas,ds1337;
reg = 0x68;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8555.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8555.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8555.dts
@@ -83,6 +83,11 @@
interrupt-parent = mpic;
dfsrr;
+ d...@50 {
+ compatible = national,lm75;
+ reg = 0x50;
+ };
+
r...@68 {
compatible = dallas,ds1337;
reg = 0x68;
Index: linux-2.6/arch/powerpc/boot/dts/tqm8560.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8560.dts
@@ -85,6 +85,11 @@
interrupt-parent = mpic;
dfsrr;
+ d...@50 {
+ compatible = national,lm75;
+ reg = 0x50;
+ };
+
r...@68 {
compatible = dallas,ds1337;
reg = 0x68;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PowerPC: MPC85xx: TQM85xx: fix sensitivity of CAN interrupts
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts |4 ++--
arch/powerpc/boot/dts/tqm8548.dts |4 ++--
arch/powerpc/boot/dts/tqm8560.dts |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6/arch/powerpc/boot/dts/tqm8548-bigflash.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -370,14 +370,14 @@
c...@2,0 {
compatible = intel,82527; // Bosch CC770
reg = 2 0x0 0x100;
- interrupts = 4 0;
+ interrupts = 4 1;
interrupt-parent = mpic;
};
c...@2,100 {
compatible = intel,82527; // Bosch CC770
reg = 2 0x100 0x100;
- interrupts = 4 0;
+ interrupts = 4 1;
interrupt-parent = mpic;
};
Index: linux-2.6/arch/powerpc/boot/dts/tqm8548.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8548.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8548.dts
@@ -370,14 +370,14 @@
c...@2,0 {
compatible = intel,82527; // Bosch CC770
reg = 2 0x0 0x100;
- interrupts = 4 0;
+ interrupts = 4 1;
interrupt-parent = mpic;
};
c...@2,100 {
compatible = intel,82527; // Bosch CC770
reg = 2 0x100 0x100;
- interrupts = 4 0;
+ interrupts = 4 1;
interrupt-parent = mpic;
};
Index: linux-2.6/arch/powerpc/boot/dts/tqm8560.dts
===
--- linux-2.6.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6/arch/powerpc/boot/dts/tqm8560.dts
@@ -340,14 +340,14 @@
c...@2,0 {
compatible = intel,82527; // Bosch CC770
reg = 2 0x0 0x100;
- interrupts = 4 0;
+ interrupts = 4 1;
interrupt-parent = mpic;
};
c...@2,100 {
compatible = intel,82527; // Bosch CC770
reg = 2 0x100 0x100;
- interrupts = 4 0;
+ interrupts = 4 1;
interrupt-parent = mpic;
};
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] add gpio to mpc837X rdb
Signed-off-by: Philippe Reynes philippe.rey...@isismpp.fr
---
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 165463f..45c9f03 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -109,6 +109,24 @@
reg = 0x200 0x100;
};
+ gpio1: gpio-control...@c00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
+ reg = 0xc00 0x100;
+ interrupts = 74 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
+
+ gpio2: gpio-control...@d00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
+ reg = 0xd00 0x100;
+ interrupts = 75 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
+
i...@3000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts
b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index f9830ae..7863d11 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -109,6 +109,24 @@
reg = 0x200 0x100;
};
+ gpio1: gpio-control...@c00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
+ reg = 0xc00 0x100;
+ interrupts = 74 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
+
+ gpio2: gpio-control...@d00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
+ reg = 0xd00 0x100;
+ interrupts = 75 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
+
i...@3000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts
b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index 2c06d39..485d28b 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -107,6 +107,24 @@
reg = 0x200 0x100;
};
+ gpio1: gpio-control...@c00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
+ reg = 0xc00 0x100;
+ interrupts = 74 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
+
+ gpio2: gpio-control...@d00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
+ reg = 0xd00 0x100;
+ interrupts = 75 0x8;
+ interrupt-parent = ipic;
+ gpio-controller;
+ };
+
i...@3000 {
#address-cells = 1;
#size-cells = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Broken PCI on Sequoia
Hi Ben, Josh, I did some background bisecting to find out when PCI stopped working on the AMCC EV-440EPX `Sequoia' Reference Board. With ppc44x_defconfig + CONFIG_USB=y + CONFIG_USB_EHCI_HCD=y and a USB 2.0 PCI card in one of the PCI slots, I get: | ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver | ehci_hcd :00:0a.2: enabling device ( - 0002) | ehci_hcd :00:0a.2: EHCI Host Controller | ehci_hcd :00:0a.2: new USB bus registered, assigned bus number 1 | Machine check in kernel mode. | Data Read PLB Error | Oops: Machine check, sig: 7 [#1] | PowerPC 44x Platform | Modules linked in: | NIP: c01acf24 LR: c019a2e0 CTR: c01ace34 | REGS: cfff7f10 TRAP: 0214 Not tainted (2.6.29-rc3) | MSR: 00029000 EE,ME,CE CR: 28002224 XER: 2000 | TASK = cf818400[1] 'swapper' THREAD: cf828000 | GPR00: cf829d80 cf818400 cf9a8a00 002f c024dd9c fffd | GPR08: d10a8000 d10a8000 48002242 1001b1cc 0ffb2400 0001 | GPR16: 007fff13 00400458 0080 007fff00 0ffadd68 0001 | GPR24: c0322a88 0010 00a0 cf9fd000 cf83a800 cf9a8ab8 cf9a8a00 | NIP [c01acf24] ehci_pci_setup+0xf0/0x5f0 | LR [c019a2e0] usb_add_hcd+0x1a8/0x5e8 | Call Trace: | [cf829d80] [cf9a8a00] 0xcf9a8a00 (unreliable) | [cf829db0] [c019a2e0] usb_add_hcd+0x1a8/0x5e8 | [cf829de0] [c01a59c4] usb_hcd_pci_probe+0x158/0x2e4 | [cf829e10] [c015c0cc] local_pci_probe+0x24/0x34 | [cf829e20] [c015c2f4] pci_device_probe+0x84/0xa8 | [cf829e50] [c017b388] driver_probe_device+0xb4/0x1e8 | [cf829e70] [c017b560] __driver_attach+0xa4/0xa8 | [cf829e90] [c017ab2c] bus_for_each_dev+0x5c/0xb0 | [cf829ec0] [c017b1a4] driver_attach+0x24/0x34 | [cf829ed0] [c017a44c] bus_add_driver+0x1d0/0x244 | [cf829ef0] [c017b780] driver_register+0x70/0x160 | [cf829f10] [c015c59c] __pci_register_driver+0x4c/0xac | [cf829f30] [c02fb514] ehci_hcd_init+0xb0/0xf0 | [cf829f50] [c00013d8] do_one_initcall+0x34/0x1b0 | [cf829fc0] [c02e1178] kernel_init+0x94/0x100 | [cf829ff0] [c000da64] kernel_thread+0x50/0x6c | Instruction dump: | 2f8001b5 409eff68 801e00e0 64002000 901e00e0 74082000 813f008c 7d2b4b78 | 913f00b8 40a2ff60 7c0004ac 7c004c2c 0c00 4c00012c 5400063e 7c0b0214 | ---[ end trace 1bac7a35c80d2df5 ]--- I get a similar crash with a Sym53c876 SCSI card. PCI seems to have stopped working between 2.6.28 and 2.6.29-rc1, due to the following commit: | commit 84d727a109081684c2e01b811cb0d6dc3b9380ca | Author: Benjamin Herrenschmidt b...@kernel.crashing.org | Date: Thu Oct 9 16:58:19 2008 + | | powerpc/4xx: Add support for ISA holes on 4xx PCI/X/E | | This adds support for ISA memory holes on the PCI, PCI-X and | PCI-E busses of the 4xx platforms. The patch includes changes | to the Bamboo and Canyonlands device-trees to add such a hole, | others can be updated separately. | | The ISA memory hole is an additional outbound window configured | in the bridge to generate PCI cycles in the low memory addresses, | thus allowing to access things such as the hard-decoded VGA | aperture at 0xa..0xb or other similar things. It's made | accessible to userspace via the new legacy_mem file in sysfs for | which support was added by a previous patch. | | Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org | Signed-off-by: Josh Boyer jwbo...@linux.vnet.ibm.com | | boot/dts/bamboo.dts |3 | boot/dts/canyonlands.dts |3 | sysdev/ppc4xx_pci.c | 306 ++--- | 3 files changed, 213 insertions(+), 99 deletions(-) Git-reverting this commit on top of 2.6.29-rc3 makes the crash go away. Perhaps sequoia.dts (and other 44x DTS files) had to be changed, too? With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft 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
Re: [RFC/example] powerpc: add the mpic global timer support
Thanks for this. Regards Kumar Gala wrote: From: Dave Liu dave...@freescale.com The mpic timer works as wake up source for power management, the max timer period is 336 seconds when the CCB freq is 400MHz. to setup timer, type echo 30 /sys/devices/ffe0.soc8572/ffe41100.timer/timeout before the system enter to sleep mode. Signed-off-by: Dave Liu dave...@freescale.com --- Posting this both as a example of timer code for Regis as well as code for partial review.. need to clean up a number of things. - k -- Régis ODEYE Kontron Modular Computers SA 150, rue M. Berthelot / ZI Toulon Est / BP 244 / Fr 83078 TOULON Cedex 9 Phone: (33) 4 98 16 34 86 Fax: (33) 4 98 16 34 01 E-mail: regis.od...@kontron.com Web : www.kontron.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/example] powerpc: add the mpic global timer support
Kumar Gala wrote:
+ ti...@41100 {
+ compatible = fsl,mpic-global-timer;
+ reg = 0x41100 0x204;
+ interrupts = 0xf7 0x2;
+ interrupt-parent = mpic;
+ };
Why is this a separate node from the MPIC? Seems like it should at
least be a child node, if not just implied by one of the compatibles on
the mpic node.
+static ssize_t mpic_tm_timeout_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct mpic_tm_priv *priv = dev_get_drvdata(dev);
+ unsigned long interval = simple_strtoul(buf, NULL, 0);
+ unsigned long temp;
+
+ if (interval 0x7fff) {
+ dev_dbg(dev, mpic_tm: interval %lu (in ns) too long\n,
interval);
+ return -EINVAL;
+ }
+
+ interval *= priv-ticks_per_sec;
In nanoseconds, or seconds?
+static DEVICE_ATTR(timeout, 0660, mpic_tm_timeout_show, mpic_tm_timeout_store);
+
+static int __devinit mpic_tm_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ struct device_node *np = dev-node;
+ struct resource res;
+ struct mpic_tm_priv *priv;
+ struct mpic_type *type = match-data;
+ int has_tcr = type-has_tcr;
+ u32 busfreq = fsl_get_sys_freq();
+ int ret = 0;
+
+ if (busfreq == 0) {
+ dev_err(dev-dev, mpic_tm: No bus frequency in device
tree.\n);
+ return -ENODEV;
+ }
Maybe put clock-frequency in the timer (or mpic) node itself?
This seems to try to support non-FSL MPIC timers, but fsl_get_sys_freq()
wouldn't be appropriate in such a case.
+ priv = kmalloc(sizeof(struct mpic_tm_priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ spin_lock_init(priv-lock);
+ dev_set_drvdata(dev-dev, priv);
+
+ ret = of_address_to_resource(np, 0, res);
+ if (ret)
+ goto out;
of_iomap()?
+ ret = request_irq(priv-irq, mpic_tm_isr, 0, mpic timer 0, priv);
+ if (ret)
+ goto out;
Hardcoded zero in string?
+ printk(MPIC global timer init done.\n);
KERN_DEBUG?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
Nathan,
Thanks for the patch. Looks good, see some comments below.
(disclaimer: I'm not very familiar with ppc architecture)
Nathan Lynch wrote:
The only thing of significance here is that the checkpointed task's
pt_regs and fp state are saved and restored (see cr_write_cpu and
cr_read_cpu); the rest of the code consists of dummy implementations
of the APIs the arch needs to provide to the checkpoint/restart core.
What works:
* self and external checkpoint of simple (single thread, one open
file) 32- and 64-bit processes on a ppc64 kernel
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
Untested:
* ppc32 (but it builds)
Signed-off-by: Nathan Lynch n...@pobox.com
---
arch/powerpc/include/asm/checkpoint_hdr.h | 40 +
arch/powerpc/mm/Makefile |1 +
arch/powerpc/mm/checkpoint.c | 261
+
3 files changed, 302 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/checkpoint_hdr.h
create mode 100644 arch/powerpc/mm/checkpoint.c
diff --git a/arch/powerpc/include/asm/checkpoint_hdr.h
b/arch/powerpc/include/asm/checkpoint_hdr.h
new file mode 100644
index 000..752c53f
--- /dev/null
+++ b/arch/powerpc/include/asm/checkpoint_hdr.h
@@ -0,0 +1,40 @@
+#ifndef __ASM_PPC_CKPT_HDR_H
+#define __ASM_PPC_CKPT_HDR_H
+/*
+ * Checkpoint/restart - architecture specific headers ppc
+ *
+ * Copyright (C) 2008 Oren Laadan
+ *
+ * This file is subject to the terms and conditions of the GNU General
Public
+ * License. See the file COPYING in the main directory of the Linux
+ * distribution for more details.
+ */
+
+#include linux/types.h
+#include asm/ptrace.h
+#include asm/mmu.h
+#include asm/processor.h
+
+struct cr_hdr_head_arch {
+ __u32 unimplemented;
+};
+
+struct cr_hdr_thread {
+ __u32 unimplemented;
+};
+
+struct cr_hdr_cpu {
+ struct pt_regs pt_regs;
It has been suggested (as done in x86/32 code) not to use 'struct pt_regs'
because it can (and has) changed on x86 and because it only container
the registers that the kernel trashes, not all usermode registers.
https://lists.linux-foundation.org/pipermail/containers/2008-August/012355.html
+ /* relevant fields from thread_struct */
+ double fpr[32][TS_FPRWIDTH];
Can TS_FPRWIDTH change between sub-archs or kernel versions ? If so, it
needs to be stated explicitly.
+ unsigned int fpscr;
+ int fpexc_mode;
+ /* unsigned int align_ctl; this is never updated? */
+ unsigned long dabr;
Are these fields always guarantee to compile to the same number of bytes
regardless of 32/64 bit choice of compiler (or sub-arch?) ?
In the x86(32/64) architecture we use types with explicit size such as
__u32 and the like to ensure that it always compiled to the same size.
+};
+
+struct cr_hdr_mm_context {
+ __u32 unimplemented;
+};
+
+#endif /* __ASM_PPC_CKPT_HDR__H */
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index e7392b4..8a523a0 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_NEED_MULTIPLE_NODES) += numa.o
obj-$(CONFIG_PPC_MM_SLICES) += slice.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
+obj-$(CONFIG_CHECKPOINT_RESTART) += checkpoint.o
diff --git a/arch/powerpc/mm/checkpoint.c b/arch/powerpc/mm/checkpoint.c
new file mode 100644
index 000..8cdff24
--- /dev/null
+++ b/arch/powerpc/mm/checkpoint.c
@@ -0,0 +1,261 @@
+/*
+ * Checkpoint/restart - architecture specific support for powerpc.
+ * Based on x86 implementation.
+ *
+ * Copyright (C) 2008 Oren Laadan
+ * Copyright 2009 IBM Corp.
+ *
+ * This file is subject to the terms and conditions of the GNU General
Public
+ * License. See the file COPYING in the main directory of the Linux
+ * distribution for more details.
+ */
+
+#define DEBUG 1 /* for pr_debug */
+
+#include linux/checkpoint.h
+#include linux/checkpoint_hdr.h
+#include linux/kernel.h
+#include asm/processor.h
+
+static void cr_hdr_init(struct cr_hdr *hdr, __s16 type, __s16 len, __u32
parent)
+{
+ hdr-type = type;
+ hdr-len = len;
+ hdr-parent = parent;
+}
+
This function is rather generic and useful to non-arch-dependent and other
architectures code. Perhaps put in a separate patch ?
+/* dump the thread_struct of a given task */
+int cr_write_thread(struct cr_ctx *ctx, struct task_struct *t)
+{
+ struct cr_hdr_thread *thread_hdr;
+ struct cr_hdr cr_hdr;
+ u32 parent;
+ int ret;
+
+ thread_hdr = cr_hbuf_get(ctx, sizeof(*thread_hdr));
+ if (!thread_hdr)
+ return -ENOMEM;
+
+ parent = task_pid_vnr(t);
+
+ cr_hdr_init(cr_hdr, CR_HDR_THREAD, sizeof(*thread_hdr), parent);
+
+ thread_hdr-unimplemented
Re: R: R: USB on lite5200 does not work.
Hi, Did you get any solution for this problem. We are also facing this issue... This problem does not happen in our board on every reboot but happens occationaly. If you have got any solution please let me know. Thanks, Velumani Jon Smirl wrote: If you are using a 33.333Mz crystal it is not possible to generate exactly 48Mhz for USB. Best you can do is 48.11Mz. With a 33Mhz crystal you can make 48Mhz exactly. But that's probably not your problem, that just results in errors on the USB bus. Some USB devices don't care and others will get errors. On Sat, Nov 22, 2008 at 7:15 AM, Gianfranco Casanova gianfranco.casan...@alice.it wrote: Grant Likely ha scritto: On Fri, Nov 21, 2008 at 1:36 AM, gianfranco.casan...@alice.it wrote: The main HW difference between our board and lite5200 is: console on PSC3 and [...] on our HW defined as: /* Radionav configuration */ port_config = 0x0C712E66; You've got quite a bit of difference than just console on PSC3. USB is on the Ethernet pin group instead of on the USB pin group. Does the kernel change the value of port_config when it boots, or does it leave the value setup by U-Boot intact? As far as I sow from debugger no. We are able to boot with a mini operating system (see previous post). Plugging USB the system get frozen. We have got the same version of kernel compiled on PPC ARCH and USB, in this case, works. Between PPC and PowerPC from debugger there is only one difference the label for USB interrupt, in PPC is 50 in PowerPC is 134. I've already checked CDM register and GPIO register and all are the same. From USB register only one difference on HDDC values (not important from my point of view). Our processor frequency is different from lite5200. We are thinking that scaling frequency processor to determine frequency of USB bus is different in PPC and PowerPC. Other street we are looking for is some WR patchs from lite5200 on PowerPC that are not accepted from our HW. I still do not understand our bug with USB. Have you got some suggestions or some test to be performed in order to find out a solutions? Not over a quick exchange via email. Yes of course :) Your kernel is too old and USB debugging can be complex. I'd need to be working with your hardware to figure out what is going on. I see. We also wont debug USB. Thaks J ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- View this message in context: http://www.nabble.com/USB-on-lite5200-does-not-work.-tp20601948p21723361.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ucc_geth: Change uec phy id to the same format as gianfar's
The commit b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4 changes the gianfar's phy
id to
the format like m...@:xx, but uec still uses the old format like
:xx.
For the board whose UEC uses gianfar-mdio like MPC8568MDS, the phy can not be
attached
because of the incompatible phy id format. This patch changes uec's phy id to
the same
format as gianfar's.
Signed-off-by: Haiying Wang haiying.w...@freescale.com
---
drivers/net/ucc_geth.c | 20 ++--
drivers/net/ucc_geth.h |2 ++
drivers/net/ucc_geth_mii.c | 12 +++-
drivers/net/ucc_geth_mii.h |1 +
4 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 1144122..6ffeffa 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1536,6 +1536,11 @@ static void adjust_link(struct net_device *dev)
static int init_phy(struct net_device *dev)
{
struct ucc_geth_private *priv = netdev_priv(dev);
+ struct device_node *np = priv-node;
+ struct device_node *phy, *mdio;
+ const phandle *ph;
+ char bus_name[MII_BUS_ID_SIZE];
+ const unsigned int *id;
struct phy_device *phydev;
char phy_id[BUS_ID_SIZE];
@@ -1543,9 +1548,19 @@ static int init_phy(struct net_device *dev)
priv-oldspeed = 0;
priv-oldduplex = -1;
- snprintf(phy_id, sizeof(phy_id), PHY_ID_FMT, priv-ug_info-mdio_bus,
-priv-ug_info-phy_address);
+ ph = of_get_property(np, phy-handle, NULL);
+ phy = of_find_node_by_phandle(*ph);
+ mdio = of_get_parent(phy);
+
+ id = of_get_property(phy, reg, NULL);
+
+ of_node_put(phy);
+ of_node_put(mdio);
+ uec_mdio_bus_name(bus_name, mdio);
+ snprintf(phy_id, sizeof(phy_id), %s:%02x,
+bus_name, *id);
+
phydev = phy_connect(dev, phy_id, adjust_link, 0, priv-phy_interface);
if (IS_ERR(phydev)) {
@@ -3748,6 +3763,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const
struct of_device_id *ma
ugeth-ug_info = ug_info;
ugeth-dev = dev;
+ ugeth-node = np;
return 0;
}
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 8f699cb..16cbe42 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1186,6 +1186,8 @@ struct ucc_geth_private {
int oldspeed;
int oldduplex;
int oldlink;
+
+ struct device_node *node;
};
void uec_set_ethtool_ops(struct net_device *netdev);
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index c001d26..5463591 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -156,7 +156,7 @@ static int uec_mdio_probe(struct of_device *ofdev, const
struct of_device_id *ma
if (err)
goto reg_map_fail;
- snprintf(new_bus-id, MII_BUS_ID_SIZE, %x, res.start);
+ uec_mdio_bus_name(new_bus-id, np);
new_bus-irq = kmalloc(32 * sizeof(int), GFP_KERNEL);
@@ -283,3 +283,13 @@ void uec_mdio_exit(void)
{
of_unregister_platform_driver(uec_mdio_driver);
}
+
+void uec_mdio_bus_name(char *name, struct device_node *np)
+{
+const u32 *reg;
+
+reg = of_get_property(np, reg, NULL);
+
+snprintf(name, MII_BUS_ID_SIZE, %...@%x, np-name, reg ? *reg : 0);
+}
+
diff --git a/drivers/net/ucc_geth_mii.h b/drivers/net/ucc_geth_mii.h
index 1e45b20..840cf80 100644
--- a/drivers/net/ucc_geth_mii.h
+++ b/drivers/net/ucc_geth_mii.h
@@ -97,4 +97,5 @@ int uec_mdio_read(struct mii_bus *bus, int mii_id, int
regnum);
int uec_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value);
int __init uec_mdio_init(void);
void uec_mdio_exit(void);
+void uec_mdio_bus_name(char *name, struct device_node *np);
#endif /* __UEC_MII_H */
--
1.6.0.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ucc_geth: Change uec phy id to the same format as gianfar's
On Jan 29, 2009, at 12:39 PM, Haiying Wang wrote: The commit b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4 changes the gianfar's phy id to the format like m...@:xx, but uec still uses the old format like :xx. For the board whose UEC uses gianfar-mdio like MPC8568MDS, the phy can not be attached because of the incompatible phy id format. This patch changes uec's phy id to the same format as gianfar's. Signed-off-by: Haiying Wang haiying.w...@freescale.com --- drivers/net/ucc_geth.c | 20 ++-- drivers/net/ucc_geth.h |2 ++ drivers/net/ucc_geth_mii.c | 12 +++- drivers/net/ucc_geth_mii.h |1 + 4 files changed, 32 insertions(+), 3 deletions(-) David, Can you look at this for 2.6.29. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpio to mpc837X rdb
Reynes == Reynes Philippe philippe.rey...@isismpp.fr writes:
Hi,
Reynes Signed-off-by: Philippe Reynes philippe.rey...@isismpp.fr
Reynes + gpio1: gpio-control...@c00 {
Reynes + #gpio-cells = 2;
Reynes + compatible = fsl,mpc8347-gpio,
Reynes fsl,mpc8349-gpio;
The patch is wordwrapped, and you should use fsl,mpc8377-gpio, not
mpc8347 (E.G. actual platform, mpc8349)
--
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpio to mpc837X rdb
On Thu, Jan 29, 2009 at 06:37:15PM +0100, Reynes Philippe wrote:
Signed-off-by: Philippe Reynes philippe.rey...@isismpp.fr
---
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 165463f..45c9f03 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -109,6 +109,24 @@
reg = 0x200 0x100;
};
+ gpio1: gpio-control...@c00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
I think this should be fsl,mpc8377-gpio, fsl,mpc8349-gpio.
[...]
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -109,6 +109,24 @@
reg = 0x200 0x100;
};
+ gpio1: gpio-control...@c00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
fsl,mpc8378-gpio, fsl,mpc8349-gpio.
[...]
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -107,6 +107,24 @@
reg = 0x200 0x100;
};
+ gpio1: gpio-control...@c00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
fsl,mpc8379-gpio, fsl,mpc8349-gpio.
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] add gpio to mpc837X rdb
On Jan 29, 2009, at 1:20 PM, Anton Vorontsov wrote:
On Thu, Jan 29, 2009 at 06:37:15PM +0100, Reynes Philippe wrote:
Signed-off-by: Philippe Reynes philippe.rey...@isismpp.fr
---
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 165463f..45c9f03 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -109,6 +109,24 @@
reg = 0x200 0x100;
};
+ gpio1: gpio-control...@c00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
I think this should be fsl,mpc8377-gpio, fsl,mpc8349-gpio.
[...]
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -109,6 +109,24 @@
reg = 0x200 0x100;
};
+ gpio1: gpio-control...@c00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
fsl,mpc8378-gpio, fsl,mpc8349-gpio.
[...]
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -107,6 +107,24 @@
reg = 0x200 0x100;
};
+ gpio1: gpio-control...@c00 {
+ #gpio-cells = 2;
+ compatible = fsl,mpc8347-gpio,
fsl,mpc8349-gpio;
fsl,mpc8379-gpio, fsl,mpc8349-gpio.
Agreed w/Anton here.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/1 v2] AMCC PPC 460SX redwood SoC platform initial framework
From: Madhulika Madishetty mmadishe...@amcc.com
This patch contains initial framework for the AMCC Redwood board.
Signed-off-by: Madhulika Madishetty mmadishe...@amcc.com
Signed-off-by: Tirumala Marri tma...@amcc.com
Signed-off-by: Feng Kan f...@amcc.com
Signed-off-by: Vidhyananth Venkatasamy vvenkatas...@amcc.com
Signed-off-by: Preetesh Parekh ppar...@amcc.com
Acked-by: Loc Ho l...@amcc.com
Acked-by: Feng Kan f...@amcc.com
---
arch/powerpc/boot/dts/redwood.dts | 245 ++
arch/powerpc/configs/44x/redwood_defconfig | 1174
arch/powerpc/kernel/cpu_setup_44x.S|1 +
arch/powerpc/kernel/cputable.c | 13 +
arch/powerpc/platforms/44x/Kconfig | 19 +
arch/powerpc/platforms/44x/ppc44x_simple.c |1 +
6 files changed, 1453 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/redwood.dts
create mode 100644 arch/powerpc/configs/44x/redwood_defconfig
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
new file mode 100644
index 000..1c525ee
--- /dev/null
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -0,0 +1,245 @@
+/*
+ * Device Tree Source for AMCC Redwood(460SX)
+ *
+ * Copyright 2008 AMCC tma...@amcc.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = amcc,redwood;
+ compatible = amcc,redwood;
+ dcr-parent = {/cpus/c...@0};
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ c...@0 {
+ device_type = cpu;
+ model = PowerPC,460SX;
+ reg = 0x;
+ clock-frequency = 0; /* Filled in by U-Boot */
+ timebase-frequency = 0; /* Filled in by U-Boot */
+ i-cache-line-size = 32;
+ d-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x 0x; /* Filled in by
U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0x0c0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0x0d0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0x1e 0x4 0x1f 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 2;
+ dcr-reg = 0x0e0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0xa 0x4 0xb 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 3;
+ dcr-reg = 0x0f0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0x10 0x4 0x11 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ SDR0: sdr {
+ compatible = ibm,sdr-460sx;
+ dcr-reg = 0x00e 0x002;
+ };
+
+ CPR0: cpr {
+ compatible = ibm,cpr-460sx;
+ dcr-reg = 0x00c 0x002;
+ };
+
+ plb {
+ compatible = ibm,plb-460sx, ibm,plb4;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+ clock-frequency = 0; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = ibm,sdram-460sx, ibm,sdram-405gp;
+ dcr-reg = 0x010 0x002;
+ };
+
+ MAL0: mcmal {
+ compatible = ibm,mcmal-460sx, ibm,mcmal2;
+ dcr-reg = 0x180 0x62;
+ num-tx-chans = 4;
+
toolchain for building linux-2.6.27.8 or 2.6.28.1 ...
I wrote a couple days ago needing advice on USB wi fi. I made some progress but then I hit a snag loading the USB wi fi adapter firmware. Jon schooled me on the firmware topic (thanks Jon), and advised me to select the following Kconfig options Kconfig Device drivers generic driver options user space firmware support check - include in-kernel firmware blobs in kernel binary My 2.6.24 kernel didn't offer these options, and I also suspected that since 2.6.24 some progress on the ralink drivers I need has been made I figured I'd just try a new kernel build and try to get my ralink-equipped Linksys WUSB54GC to work. Trouble: -I was using Ltib Toolchain (gcc-3.4.3-glibc-2.3.6 (for 603e)) to build my 2.6.24 kernel. -It looks like somewhere after 2.6.24 this toolchain stopped successfully compiling the kernel. So, -I used crosstool and built 4.1.0 and 4.1.1 toolchains. Both produce the following error: OBJCOPY arch/powerpc/kernel/vdso32/vdso32.so objcopy: Unable to recognise the format of the input file `arch/powerpc/kernel/vdso32/vdso32.so.dbg' make[3]: *** [arch/powerpc/kernel/vdso32/vdso32.so] Error 1 make[2]: *** [arch/powerpc/kernel/vdso32] Error 2 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. I think I'm slipping into version compatibility hell at this point. Please throw me a rope if you can by way of advice if you can. Thanks! -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/1 v2] AMCC PPC 460SX redwood SoC platform initial framework
Hi, I again see the confidentiality notice in the patch I submitted. It was not supposed to be there. I'll fix it and resubmit the patch. Thanks, Madhulika Madishetty -Original Message- From: linuxppc-dev-bounces+mmadishetty=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+mmadishetty=amcc@ozlabs.org] On Behalf Of linuxppc-dev-requ...@ozlabs.org Sent: Thursday, January 29, 2009 11:47 AM To: linuxppc-dev@ozlabs.org Subject: Linuxppc-dev Digest, Vol 53, Issue 168 Send Linuxppc-dev mailing list submissions to linuxppc-dev@ozlabs.org To subscribe or unsubscribe via the World Wide Web, visit https://ozlabs.org/mailman/listinfo/linuxppc-dev or, via email, send a message with subject or body 'help' to linuxppc-dev-requ...@ozlabs.org You can reach the person managing the list at linuxppc-dev-ow...@ozlabs.org When replying, please edit your Subject line so it is more specific than Re: Contents of Linuxppc-dev digest... Today's Topics: 1. Re: R: R: USB on lite5200 does not work. (velumani) 2. [PATCH] ucc_geth: Change uec phy id to the same format as gianfar's (Haiying Wang) 3. Re: [PATCH] ucc_geth: Change uec phy id to the same format as gianfar's (Kumar Gala) 4. Re: [PATCH] add gpio to mpc837X rdb (Kumar Gala) 5. Re: [PATCH] add gpio to mpc837X rdb (Peter Korsgaard) 6. Re: [PATCH] add gpio to mpc837X rdb (Anton Vorontsov) 7. Re: [PATCH] add gpio to mpc837X rdb (Kumar Gala) 8. [PATCH 1/1 v2] AMCC PPC 460SX redwood SoC platform initial framework (mmadishe...@amcc.com) -- Message: 1 Date: Thu, 29 Jan 2009 01:38:20 -0800 (PST) From: velumani veluman...@gmail.com Subject: Re: R: R: USB on lite5200 does not work. To: linuxppc-dev@ozlabs.org Message-ID: 21723361.p...@talk.nabble.com Content-Type: text/plain; charset=us-ascii Hi, Did you get any solution for this problem. We are also facing this issue... This problem does not happen in our board on every reboot but happens occationaly. If you have got any solution please let me know. Thanks, Velumani Jon Smirl wrote: If you are using a 33.333Mz crystal it is not possible to generate exactly 48Mhz for USB. Best you can do is 48.11Mz. With a 33Mhz crystal you can make 48Mhz exactly. But that's probably not your problem, that just results in errors on the USB bus. Some USB devices don't care and others will get errors. On Sat, Nov 22, 2008 at 7:15 AM, Gianfranco Casanova gianfranco.casan...@alice.it wrote: Grant Likely ha scritto: On Fri, Nov 21, 2008 at 1:36 AM, gianfranco.casan...@alice.it wrote: The main HW difference between our board and lite5200 is: console on PSC3 and [...] on our HW defined as: /* Radionav configuration */ port_config = 0x0C712E66; You've got quite a bit of difference than just console on PSC3. USB is on the Ethernet pin group instead of on the USB pin group. Does the kernel change the value of port_config when it boots, or does it leave the value setup by U-Boot intact? As far as I sow from debugger no. We are able to boot with a mini operating system (see previous post). Plugging USB the system get frozen. We have got the same version of kernel compiled on PPC ARCH and USB, in this case, works. Between PPC and PowerPC from debugger there is only one difference the label for USB interrupt, in PPC is 50 in PowerPC is 134. I've already checked CDM register and GPIO register and all are the same. From USB register only one difference on HDDC values (not important from my point of view). Our processor frequency is different from lite5200. We are thinking that scaling frequency processor to determine frequency of USB bus is different in PPC and PowerPC. Other street we are looking for is some WR patchs from lite5200 on PowerPC that are not accepted from our HW. I still do not understand our bug with USB. Have you got some suggestions or some test to be performed in order to find out a solutions? Not over a quick exchange via email. Yes of course :) Your kernel is too old and USB debugging can be complex. I'd need to be working with your hardware to figure out what is going on. I see. We also wont debug USB. Thaks J ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- View this message in context: http://www.nabble.com/USB-on-lite5200-does-not-work.-tp20601948p21723361 .html Sent from the linuxppc-dev mailing list archive at Nabble.com. -- Message: 2 Date: Thu, 29 Jan 2009 13:39:02 -0500 From: Haiying Wang haiying.w...@freescale.com Subject: [PATCH] ucc_geth: Change
RE: [QUESTION] PPC4xx SPI mode
Actually SPI_IOC_WR_MODE changes are not used for file I/O read() and write(). SPI_IOC_MESSAGE uses modified SPI parameters only when ioctl() argument struct spio_ioc_transfer fields: speed_hz and bits_per_word are non-zero. This mechanism is enforced by spi_bitbang.c function bitbang_work() that calls setup_transfer function (in my case spi_ppc4xx_setupxfer()) only when the above condition is true. On the other hand, read() and write() queue their messages with struct spi_transfer fields speed_hz and bits_per_word set to 0. IMHO all three cases should behave similarly. Regards, Luis -Original Message- From: linuxppc-dev-bounces+lherrera=harris@ozlabs.org [mailto:linuxppc-dev-bounces+lherrera=harris@ozlabs.org] On Behalf Of Herrera-Bendezu, Luis Sent: Wednesday, January 28, 2009 7:08 PM To: linuxppc-dev@ozlabs.org Subject: [QUESTION] PPC4xx SPI mode I am using PPC440EPx SPI driver to access devices with different clock polarities (SPI_MODE_0 and SPI_MODE_2), but otherwise similar SPI parameters (max clock frequency, bits per word, etc.) If spidev is used to modify clock polarity via ioctl SPI_IOC_WR_MODE, it does not have any effect on the controller. This list has dicussed a related issue: http://ozlabs.org/pipermail/linuxppc-dev/2009-January/066749.html that explains why SPI_IOC_WR_MODE does not work, function spi_ppc4xx_setupxfer() is called only once by spi_ppc4xx_setup() function. Any subsequent call just ignores request to change SPI configuration and does not report any error. Is this how the driver is supposed to work? Can the above usage be acommodated into the driver? Thanks, Luis ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
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 1/1 v2] AMCC PPC 460SX redwood SoC platform initial framework
Resubmitting patch without the confidentiality notice.
From: Madhulika Madishetty mmadishe...@amcc.com
This patch contains initial framework for the AMCC Redwood board.
Signed-off-by: Madhulika Madishetty mmadishe...@amcc.com
Signed-off-by: Tirumala Marri tma...@amcc.com
Signed-off-by: Feng Kan f...@amcc.com
Signed-off-by: Vidhyananth Venkatasamy vvenkatas...@amcc.com
Signed-off-by: Preetesh Parekh ppar...@amcc.com
Acked-by: Loc Ho l...@amcc.com
Acked-by: Feng Kan f...@amcc.com
---
arch/powerpc/boot/dts/redwood.dts | 245 ++
arch/powerpc/configs/44x/redwood_defconfig | 1174
arch/powerpc/kernel/cpu_setup_44x.S|1 +
arch/powerpc/kernel/cputable.c | 13 +
arch/powerpc/platforms/44x/Kconfig | 19 +
arch/powerpc/platforms/44x/ppc44x_simple.c |1 +
6 files changed, 1453 insertions(+), 0 deletions(-) create mode 100644
arch/powerpc/boot/dts/redwood.dts create mode 100644
arch/powerpc/configs/44x/redwood_defconfig
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
new file mode 100644
index 000..1c525ee
--- /dev/null
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -0,0 +1,245 @@
+/*
+ * Device Tree Source for AMCC Redwood(460SX)
+ *
+ * Copyright 2008 AMCC tma...@amcc.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = amcc,redwood;
+ compatible = amcc,redwood;
+ dcr-parent = {/cpus/c...@0};
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ c...@0 {
+ device_type = cpu;
+ model = PowerPC,460SX;
+ reg = 0x;
+ clock-frequency = 0; /* Filled in by U-Boot */
+ timebase-frequency = 0; /* Filled in by U-Boot
*/
+ i-cache-line-size = 32;
+ d-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x 0x; /* Filled in
by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0x0c0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0x0d0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0x1e 0x4 0x1f 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 2;
+ dcr-reg = 0x0e0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0xa 0x4 0xb 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 3;
+ dcr-reg = 0x0f0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0x10 0x4 0x11 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ SDR0: sdr {
+ compatible = ibm,sdr-460sx;
+ dcr-reg = 0x00e 0x002;
+ };
+
+ CPR0: cpr {
+ compatible = ibm,cpr-460sx;
+ dcr-reg = 0x00c 0x002;
+ };
+
+ plb {
+ compatible = ibm,plb-460sx, ibm,plb4;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+ clock-frequency = 0; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = ibm,sdram-460sx,
ibm,sdram-405gp;
+ dcr-reg = 0x010 0x002;
+ };
+
+ MAL0: mcmal {
+ compatible = ibm,mcmal-460sx, ibm,mcmal2;
+ dcr-reg = 0x180 0x62;
+
Re: [PATCH 1/8] powerpc/5200: update device tree binding documentation
Hello Grant, On Wed, Jan 21, 2009 at 01:55:07PM -0700, Grant Likely wrote: From: Grant Likely grant.lik...@secretlab.ca This patch updates the mpc5200 binding documentation to match actual usage conventions, to remove incorrect information, and to remove topics which are more thoroughly described elsewhere. Signed-off-by: Grant Likely grant.lik...@secretlab.ca CC: devtree-disc...@ozlabs.org CC: Wolfram Sang w.s...@pengutronix.de Can you please send the updated version so I could add an reviewed-by? Regards, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/8] powerpc/5200: Stop using device_type and port-number properties
On Wed, Jan 21, 2009 at 01:55:13PM -0700, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
There is no reason for the PSC UART driver or the Ethernet driver
to require a device_type property. The compatible value is sufficient
to uniquely identify the device. Remove it from the driver.
The whole 'port-number' scheme for assigning numbers to PSC uarts was
always rather half baked and just adds complexity. Remove it from the
driver. After this patch is applied, PSC UART numbers are simply
assigned from the order they are found in the device tree (just like
all the other devices). Userspace can query sysfs to determine what
ttyPSC number is assigned to each PSC instance.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
CC: Wolfram Sang w.s...@pengutronix.de
I like it. One more optimization below, but it's also good for now...
Reviewed-by: Wolfram Sang w.s...@pengutronix.de
---
drivers/net/fec_mpc52xx.c |6 +++---
drivers/serial/mpc52xx_uart.c | 38 ++
2 files changed, 13 insertions(+), 31 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cd8e98b..049b0a7 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -1123,9 +1123,9 @@ static int mpc52xx_fec_of_resume(struct of_device *op)
#endif
static struct of_device_id mpc52xx_fec_match[] = {
- { .type = network, .compatible = fsl,mpc5200b-fec, },
- { .type = network, .compatible = fsl,mpc5200-fec, },
- { .type = network, .compatible = mpc5200-fec, },
+ { .compatible = fsl,mpc5200b-fec, },
+ { .compatible = fsl,mpc5200-fec, },
+ { .compatible = mpc5200-fec, },
{ }
};
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 0c3a2ab..d73d7da 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -50,8 +50,8 @@
/* OF Platform device Usage :
*
* This driver is only used for PSCs configured in uart mode. The device
- * tree will have a node for each PSC in uart mode w/ device_type = serial
- * and mpc52xx-psc-uart in the compatible string
+ * tree will have a node for each PSC with mpc52xx-psc-uart in the
compatible
+ * list.
*
* By default, PSC devices are enumerated in the order they are found.
However
* a particular PSC number can be forces by adding 'device_no = port#'
@@ -1212,30 +1212,18 @@ mpc52xx_uart_of_resume(struct of_device *op)
#endif
static void
-mpc52xx_uart_of_assign(struct device_node *np, int idx)
+mpc52xx_uart_of_assign(struct device_node *np)
{
- int free_idx = -1;
int i;
- /* Find the first free node */
+ /* Find the first free PSC number */
for (i = 0; i MPC52xx_PSC_MAXNUM; i++) {
if (mpc52xx_uart_nodes[i] == NULL) {
- free_idx = i;
- break;
+ of_node_get(np);
+ mpc52xx_uart_nodes[i] = np;
+ return;
}
}
-
- if ((idx 0) || (idx = MPC52xx_PSC_MAXNUM))
- idx = free_idx;
-
- if (idx 0)
- return; /* No free slot; abort */
-
- of_node_get(np);
- /* If the slot is already occupied, then swap slots */
- if (mpc52xx_uart_nodes[idx] (free_idx != -1))
- mpc52xx_uart_nodes[free_idx] = mpc52xx_uart_nodes[idx];
- mpc52xx_uart_nodes[idx] = np;
}
static void
@@ -1243,23 +1231,17 @@ mpc52xx_uart_of_enumerate(void)
{
static int enum_done;
struct device_node *np;
- const unsigned int *devno;
const struct of_device_id *match;
int i;
if (enum_done)
return;
- for_each_node_by_type(np, serial) {
+ /* Assign index to each PSC in device tree */
+ for_each_matching_node(np, mpc52xx_uart_of_match) {
match = of_match_node(mpc52xx_uart_of_match, np);
- if (!match)
- continue;
-
psc_ops = match-data;
-
- /* Is a particular device number requested? */
- devno = of_get_property(np, port-number, NULL);
- mpc52xx_uart_of_assign(np, devno ? *devno : -1);
+ mpc52xx_uart_of_assign(np);
}
enum_done = 1;
You could drop the for-loop which follows here and put its dev_dbg into
uart_of_assign when a node was found. Would also get rid of 'i' here.
Regards,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/8] powerpc/5200: Trim cruft from device trees
On Wed, Jan 21, 2009 at 01:55:18PM -0700, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
Trim out obsolete/extraneous properties and tighten up some usage
conventions. Changes include:
- removal of device_type properties
- removal of cell-index properties
- Addition of gpio-controller and #gpio-cells properties to gpio
nodes
- Move common interrupt-parent property out of device nodes and
into top level parent node.
This patch also include what looks to be just trivial editorial
whitespace/format changes, but there is real method in this
madness. Editorial changes were made to keep the all the
mpc5200 board device trees as similar as possible so that diffs
between them only show the real differences between the boards.
The pcm030 device tree was most affected by this because many
of the comments had been changed from // to /* */ style and
some cell values where changed from decimal to hex format when
it was cloned from one of the other 5200 device trees.
Thanks for this and especially for fixing the wrong interrupt in one of
the pcm030 PSCs! My phyCORE-MPC5200B-tiny still works fine with the new
dts. The other changes were only audited, not tested on real hardware.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Reviewed-by: Wolfram Sang w.s...@pengutronix.de
CC: Wolfram Sang w.s...@pengutronix.de
CC: Wolfgang Grandegger w...@grandegger.com
CC: Sascha Hauer s.ha...@pengutronix.de
CC: Marian Balakowicz m...@semihalf.com
---
arch/powerpc/boot/dts/cm5200.dts| 45 ++---
arch/powerpc/boot/dts/lite5200.dts | 52 --
arch/powerpc/boot/dts/lite5200b.dts | 63 ++--
arch/powerpc/boot/dts/motionpro.dts | 42 ++--
arch/powerpc/boot/dts/pcm030.dts| 182
+--
arch/powerpc/boot/dts/tqm5200.dts | 32 +-
6 files changed, 104 insertions(+), 312 deletions(-)
diff --git a/arch/powerpc/boot/dts/cm5200.dts
b/arch/powerpc/boot/dts/cm5200.dts
index 2f74cc4..11ada32 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -17,6 +17,7 @@
compatible = schindler,cm5200;
#address-cells = 1;
#size-cells = 1;
+ interrupt-parent = mpc5200_pic;
cpus {
#address-cells = 1;
@@ -66,7 +67,6 @@
compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
reg = 0x600 0x10;
interrupts = 1 9 0;
- interrupt-parent = mpc5200_pic;
fsl,has-wdt;
};
@@ -74,84 +74,76 @@
compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
reg = 0x610 0x10;
interrupts = 1 10 0;
- interrupt-parent = mpc5200_pic;
};
ti...@620 { // General Purpose Timer
compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
reg = 0x620 0x10;
interrupts = 1 11 0;
- interrupt-parent = mpc5200_pic;
};
ti...@630 { // General Purpose Timer
compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
reg = 0x630 0x10;
interrupts = 1 12 0;
- interrupt-parent = mpc5200_pic;
};
ti...@640 { // General Purpose Timer
compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
reg = 0x640 0x10;
interrupts = 1 13 0;
- interrupt-parent = mpc5200_pic;
};
ti...@650 { // General Purpose Timer
compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
reg = 0x650 0x10;
interrupts = 1 14 0;
- interrupt-parent = mpc5200_pic;
};
ti...@660 { // General Purpose Timer
compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
reg = 0x660 0x10;
interrupts = 1 15 0;
- interrupt-parent = mpc5200_pic;
};
ti...@670 { // General Purpose Timer
compatible = fsl,mpc5200b-gpt,fsl,mpc5200-gpt;
reg = 0x670 0x10;
interrupts = 1 16 0;
- interrupt-parent = mpc5200_pic;
};
r...@800 { // Real time clock
compatible = fsl,mpc5200b-rtc,fsl,mpc5200-rtc;
reg = 0x800 0x100;
interrupts = 1 5 0 1 6 0;
- interrupt-parent = mpc5200_pic;
};
- g...@b00 {
+ gpio_simple: g...@b00 {
compatible =
Re: [PATCH 5/8] powerpc/5200: Don't specify IRQF_SHARED in PSC UART driver
On Wed, Jan 21, 2009 at 01:55:29PM -0700, Grant Likely wrote: From: Grant Likely grant.lik...@secretlab.ca The MPC5200 PSC device is wired up to a dedicated interrupt line which is never shared. This patch removes the IRQF_SHARED flag from the request_irq() call which eliminates the IRQF_DISABLED is not guaranteed on shared IRQs warning message from the console output. Signed-off-by: Grant Likely grant.lik...@secretlab.ca What do I give here? Acked-by? Reviewed? Tested? :D I'll make a guess: Reviewed-by: Wolfram Sang w.s...@pengutronix.de --- drivers/serial/mpc52xx_uart.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c index d73d7da..7f72f8c 100644 --- a/drivers/serial/mpc52xx_uart.c +++ b/drivers/serial/mpc52xx_uart.c @@ -522,7 +522,7 @@ mpc52xx_uart_startup(struct uart_port *port) /* Request IRQ */ ret = request_irq(port-irq, mpc52xx_uart_int, - IRQF_DISABLED | IRQF_SAMPLE_RANDOM | IRQF_SHARED, + IRQF_DISABLED | IRQF_SAMPLE_RANDOM, mpc52xx_psc_uart, port); if (ret) return ret; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] powerpc/5200: Remove pr_debug() from hot paths in irq driver
On Wed, Jan 21, 2009 at 01:55:35PM -0700, Grant Likely wrote: From: Grant Likely grant.lik...@secretlab.ca pr_debug() calls in the 'hot' *_mask(), *_unmask(), *_ack() and get_irq() makes adding #define DEBUG pretty much useless. Remove these calls because they completely swamp the output. Signed-off-by: Grant Likely grant.lik...@secretlab.ca Yup! Reviewed-by: Wolfram Sang w.s...@pengutronix.de --- arch/powerpc/platforms/52xx/mpc52xx_pic.c | 23 --- 1 files changed, 0 insertions(+), 23 deletions(-) diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c b/arch/powerpc/platforms/52xx/mpc52xx_pic.c index 0a093f0..c0a9559 100644 --- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c +++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c @@ -163,8 +163,6 @@ static void mpc52xx_extirq_mask(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - io_be_clrbit(intr-ctrl, 11 - l2irq); } @@ -176,8 +174,6 @@ static void mpc52xx_extirq_unmask(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - io_be_setbit(intr-ctrl, 11 - l2irq); } @@ -189,8 +185,6 @@ static void mpc52xx_extirq_ack(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - io_be_setbit(intr-ctrl, 27-l2irq); } @@ -255,8 +249,6 @@ static void mpc52xx_main_mask(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - io_be_setbit(intr-main_mask, 16 - l2irq); } @@ -268,8 +260,6 @@ static void mpc52xx_main_unmask(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - io_be_clrbit(intr-main_mask, 16 - l2irq); } @@ -291,8 +281,6 @@ static void mpc52xx_periph_mask(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - io_be_setbit(intr-per_mask, 31 - l2irq); } @@ -304,8 +292,6 @@ static void mpc52xx_periph_unmask(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - io_be_clrbit(intr-per_mask, 31 - l2irq); } @@ -327,8 +313,6 @@ static void mpc52xx_sdma_mask(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - io_be_setbit(sdma-IntMask, l2irq); } @@ -340,8 +324,6 @@ static void mpc52xx_sdma_unmask(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - io_be_clrbit(sdma-IntMask, l2irq); } @@ -353,8 +335,6 @@ static void mpc52xx_sdma_ack(unsigned int virq) irq = irq_map[virq].hwirq; l2irq = irq MPC52xx_IRQ_L2_MASK; - pr_debug(%s: irq=%x. l2=%d\n, __func__, irq, l2irq); - out_be32(sdma-IntPend, 1 l2irq); } @@ -613,8 +593,5 @@ unsigned int mpc52xx_get_irq(void) } } - pr_debug(%s: irq=%x. virq=%d\n, __func__, irq, - irq_linear_revmap(mpc52xx_irqhost, irq)); - return irq_linear_revmap(mpc52xx_irqhost, irq); } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/8] powerpc/5200: Refactor mpc5200 interrupt controller driver
On Wed, Jan 21, 2009 at 01:55:41PM -0700, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
Rework the mpc5200-pic driver to simplify it and fix up the setting
of desc-status when set_type is called for internal IRQs (so they
are reported as level, not edge). The simplification is due to
splitting off the handling of external IRQs into a separate block
so they don't need to be handled as exceptions in the normal
CRIT, MAIN and PERP paths.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
CC: Wolfram Sang w.s...@pengutronix.de
Can't say much about this one as I have never dealt with the PIC
directly so far. Yet, my phyCORE-MPC5200B-tiny behaves normal, so
Tested-by: Wolfram Sang w.s...@pengutronix.de
---
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 145
-
1 files changed, 58 insertions(+), 87 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
index c0a9559..277c9c5 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -190,10 +190,10 @@ static void mpc52xx_extirq_ack(unsigned int virq)
static int mpc52xx_extirq_set_type(unsigned int virq, unsigned int flow_type)
{
- struct irq_desc *desc = get_irq_desc(virq);
u32 ctrl_reg, type;
int irq;
int l2irq;
+ void *handler = handle_level_irq;
irq = irq_map[virq].hwirq;
l2irq = irq MPC52xx_IRQ_L2_MASK;
@@ -201,32 +201,21 @@ static int mpc52xx_extirq_set_type(unsigned int virq,
unsigned int flow_type)
pr_debug(%s: irq=%x. l2=%d flow_type=%d\n, __func__, irq, l2irq,
flow_type);
switch (flow_type) {
- case IRQF_TRIGGER_HIGH:
- type = 0;
- break;
- case IRQF_TRIGGER_RISING:
- type = 1;
- break;
- case IRQF_TRIGGER_FALLING:
- type = 2;
- break;
- case IRQF_TRIGGER_LOW:
- type = 3;
- break;
+ case IRQF_TRIGGER_HIGH: type = 0; break;
+ case IRQF_TRIGGER_RISING: type = 1; handler = handle_edge_irq; break;
+ case IRQF_TRIGGER_FALLING: type = 2; handler = handle_edge_irq; break;
+ case IRQF_TRIGGER_LOW: type = 3; break;
default:
type = 0;
}
- desc-status = ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
- desc-status |= flow_type IRQ_TYPE_SENSE_MASK;
- if (flow_type (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW))
- desc-status |= IRQ_LEVEL;
-
ctrl_reg = in_be32(intr-ctrl);
ctrl_reg = ~(0x3 (22 - (l2irq * 2)));
ctrl_reg |= (type (22 - (l2irq * 2)));
out_be32(intr-ctrl, ctrl_reg);
+ __set_irq_handler_unlocked(virq, handler);
+
return 0;
}
@@ -241,6 +230,11 @@ static struct irq_chip mpc52xx_extirq_irqchip = {
/*
* Main interrupt irq_chip
*/
+static int mpc52xx_null_set_type(unsigned int virq, unsigned int flow_type)
+{
+ return 0; /* Do nothing so that the sense mask will get updated */
+}
+
static void mpc52xx_main_mask(unsigned int virq)
{
int irq;
@@ -268,6 +262,7 @@ static struct irq_chip mpc52xx_main_irqchip = {
.mask = mpc52xx_main_mask,
.mask_ack = mpc52xx_main_mask,
.unmask = mpc52xx_main_unmask,
+ .set_type = mpc52xx_null_set_type,
};
/*
@@ -300,6 +295,7 @@ static struct irq_chip mpc52xx_periph_irqchip = {
.mask = mpc52xx_periph_mask,
.mask_ack = mpc52xx_periph_mask,
.unmask = mpc52xx_periph_unmask,
+ .set_type = mpc52xx_null_set_type,
};
/*
@@ -343,9 +339,19 @@ static struct irq_chip mpc52xx_sdma_irqchip = {
.mask = mpc52xx_sdma_mask,
.unmask = mpc52xx_sdma_unmask,
.ack = mpc52xx_sdma_ack,
+ .set_type = mpc52xx_null_set_type,
};
/**
+ * mpc52xx_is_extirq - Returns true if hwirq number is for an external IRQ
+ */
+static int mpc52xx_is_extirq(int l1, int l2)
+{
+ return ((l1 == 0) (l2 == 0)) ||
+((l1 == 1) (l2 = 1) (l2 = 3));
+}
+
+/**
* mpc52xx_irqhost_xlate - translate virq# from device tree interrupts
property
*/
static int mpc52xx_irqhost_xlate(struct irq_host *h, struct device_node *ct,
@@ -363,38 +369,23 @@ static int mpc52xx_irqhost_xlate(struct irq_host *h,
struct device_node *ct,
intrvect_l1 = (int)intspec[0];
intrvect_l2 = (int)intspec[1];
- intrvect_type = (int)intspec[2];
+ intrvect_type = (int)intspec[2] 0x3;
intrvect_linux = (intrvect_l1 MPC52xx_IRQ_L1_OFFSET)
MPC52xx_IRQ_L1_MASK;
intrvect_linux |= intrvect_l2 MPC52xx_IRQ_L2_MASK;
- pr_debug(return %x, l1=%d, l2=%d\n, intrvect_linux, intrvect_l1,
- intrvect_l2);
-
*out_hwirq = intrvect_linux;
- *out_flags = mpc52xx_map_senses[intrvect_type];
+ *out_flags = IRQ_TYPE_LEVEL_LOW;
+ if (mpc52xx_is_extirq(intrvect_l1,
2.6.28-rt on PowerPC
Hi Steven,
I know 2.6.28-rt isn't yet ready, but I could not resist to try
it anyway. ;-)
Here are few issues and ways to solve them:
Currently the -rt tree doesn't link for arch/powerpc:
LD .tmp_vmlinux1
arch/powerpc/kernel/built-in.o: In function `show_interrupts':
(.text+0x27bc): undefined reference to `__call_bad_lock_func'
arch/powerpc/kernel/built-in.o: In function `show_interrupts':
(.text+0x28b0): undefined reference to `__call_bad_lock_func'
make: *** [.tmp_vmlinux1] Error 1
This can be trivially fixed:
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 838857f..cc7dd12 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -183,7 +183,7 @@ int show_interrupts(struct seq_file *p, void *v)
if (i NR_IRQS) {
desc = get_irq_desc(i);
- acquire_lock_irqsave(desc-lock, flags);
+ spin_lock_irqsave(desc-lock, flags);
action = desc-action;
if (!action || !action-handler)
goto skip;
@@ -204,7 +204,7 @@ int show_interrupts(struct seq_file *p, void *v)
seq_printf(p, , %s, action-name);
seq_putc(p, '\n');
skip:
- release_lock_irqrestore(desc-lock, flags);
+ spin_unlock_irqrestore(desc-lock, flags);
} else if (i == NR_IRQS) {
#if defined(CONFIG_PPC32) defined(CONFIG_TAU_INT)
if (tau_initialized){
--
While booting, this bug appears:
BUG: sleeping function called from invalid context at kernel/rtmutex.c:683
in_atomic(): 1 [00010001], irqs_disabled(): 1, pid: 1, name: swapper
Call Trace:
[cf82f9a0] [c0008be8] show_stack+0x4c/0x16c (unreliable)
[cf82f9e0] [c001c184] __might_sleep+0xd8/0xf8
[cf82f9f0] [c02b7758] rt_spin_lock+0x30/0x78
[cf82fa00] [c001853c] ipic_mask_irq+0x3c/0xb0
[cf82fa20] [c0054064] handle_level_irq+0x40/0x178
[cf82fa40] [c00068ec] do_IRQ+0x68/0xe0
[cf82fa50] [c0012924] ret_from_except+0x0/0x14
--- Exception: 501 at internal_add_timer+0x4/0xe0
This is trivially solved by converting arch/powerpc/sysdev/ipic.c
back to spinlocks (ipic_lock).
Assuming that converting-back is automatic, there are few other
chained interrupt controllers you might want to convert-back:
arch/powerpc/sysdev/i8259.c (i8259_lock)
arch/powerpc/sysdev/mpic.c (mpic_lock)
arch/powerpc/sysdev/qe_lib/qe_ic.c (qe_ic_lock)
After this, kernel boots up to the userspace, but then bugs in the
middle (note: this is NFS boot, network activity etc.)...
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Activating swap...done.
Remounting root filesystem...done.
Checking all file systems: fsck
fsck 1.40 (29-Jun-2007)
Checking SELinux contexts: selinux-basics.
Starting network interfaces: done.
Starting portmap daemon
Cleaning: /tmp /var/lock /var/run done.
Setting pseudo-terminal access permissions...done.
Updating /etc/motd...done.
INIT: Entering runlevel: 3
Starting irqbalance.
Starting system log daemon: syslogd
BUG: sleeping function called from invalid context at kernel/rtmutex.c:683
in_atomic(): 1 [0100], irqs_disabled(): 0, pid: 7, name: sirq-net-rx/0
Call Trace:
[cf84bc20] [c0008be8] show_stack+0x4c/0x16c (unreliable)
[cf84bc60] [c001c194] __might_sleep+0xd8/0xf8
[cf84bc70] [c02b7768] rt_spin_lock+0x30/0x78
[cf84bc80] [c00800e0] kmem_cache_alloc+0x50/0x17c
[cf84bcb0] [c02568a4] ip_append_data+0x974/0x978
[cf84bd30] [c027aa0c] icmp_push_reply+0x54/0x128
[cf84bd50] [c027b59c] icmp_send+0x284/0x380
[cf84be40] [c0277328] __udp4_lib_rcv+0x3d4/0x5a0
[cf84bea0] [c0253208] ip_local_deliver_finish+0x74/0x128
[cf84bec0] [c0252fd0] ip_rcv_finish+0x148/0x30c
[cf84bf00] [c0236774] netif_receive_skb+0x21c/0x2e8
[cf84bf30] [c0238ecc] process_backlog+0x98/0x138
[cf84bf60] [c0238b24] net_rx_action+0xd4/0x198
[cf84bf90] [c002989c] ksoftirqd+0x108/0x23c
[cf84bfd0] [c003c918] kthread+0x48/0x84
[cf84bff0] [c00120b0] kernel_thread+0x4c/0x68
BUG: scheduling while atomic: sirq-net-rx/0/7/0x1101, CPU#0
Modules linked in:
Call Trace:
[cf84bee0] [c0008be8] show_stack+0x4c/0x16c (unreliable)
[cf84bf20] [c001e418] __schedule_bug+0x6c/0x80
[cf84bf30] [c02b5fdc] schedule+0x2e8/0x31c
[cf84bf70] [c001e460] __cond_resched+0x34/0x60
[cf84bf80] [c02b6348] _cond_resched+0x50/0x58
[cf84bf90] [c00298b8] ksoftirqd+0x124/0x23c
[cf84bfd0] [c003c918] kthread+0x48/0x84
[cf84bff0] [c00120b0] kernel_thread+0x4c/0x68
And now this looks like not PowerPC specific... Converting mm/slab.c
back to spinlocks results in another, but similar bug in anther mm
routine:
BUG: sleeping function called from invalid context at kernel/rtmutex.c:683
in_atomic(): 1 [0001], irqs_disabled(): 0, pid: 1003, name: net.agent
Call Trace:
[cf057c40] [c0008be8] show_stack+0x4c/0x16c (unreliable)
[cf057c80] [c001c194] __might_sleep+0xd8/0xf8
[cf057c90] [c02b7768] rt_spin_lock+0x30/0x78
[cf057ca0]
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
Hey Oren, thanks for taking a look.
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
No, but I'll add one if it looks too hard to fix for the next round.
+struct cr_hdr_cpu {
+ struct pt_regs pt_regs;
It has been suggested (as done in x86/32 code) not to use 'struct pt_regs'
because it can (and has) changed on x86 and because it only container
the registers that the kernel trashes, not all usermode registers.
https://lists.linux-foundation.org/pipermail/containers/2008-August/012355.html
Yeah, I considered that discussion, but the situation is different for
powerpc (someone on linuxppc-dev smack me if I'm wrong here :)
pt_regs is part of the ABI, and it encompasses all user mode registers
except for floating point, which are handled separately.
+ /* relevant fields from thread_struct */
+ double fpr[32][TS_FPRWIDTH];
Can TS_FPRWIDTH change between sub-archs or kernel versions ? If so, it
needs to be stated explicitly.
+ unsigned int fpscr;
+ int fpexc_mode;
+ /* unsigned int align_ctl; this is never updated? */
+ unsigned long dabr;
Are these fields always guarantee to compile to the same number of bytes
regardless of 32/64 bit choice of compiler (or sub-arch?) ?
In the x86(32/64) architecture we use types with explicit size such as
__u32 and the like to ensure that it always compiled to the same
size.
Yeah, I'll have to fix these up.
+static void cr_hdr_init(struct cr_hdr *hdr, __s16 type, __s16 len, __u32
parent)
+{
+ hdr-type = type;
+ hdr-len = len;
+ hdr-parent = parent;
+}
+
This function is rather generic and useful to non-arch-dependent and other
architectures code. Perhaps put in a separate patch ?
Alright. By the way, why are cr_hdr-type and cr_hdr-len signed
types?
+int cr_write_cpu(struct cr_ctx *ctx, struct task_struct *t)
+{
+ struct cr_hdr_cpu *cpu_hdr;
+ struct pt_regs *pt_regs;
+ struct cr_hdr cr_hdr;
+ u32 parent;
+ int ret;
+
+ cpu_hdr = cr_hbuf_get(ctx, sizeof(*cpu_hdr));
+ if (!cpu_hdr)
+ return -ENOMEM;
+
+ parent = task_pid_vnr(t);
+
+ cr_hdr_init(cr_hdr, CR_HDR_CPU, sizeof(*cpu_hdr), parent);
+
+ /* pt_regs: GPRs, MSR, etc */
+ pt_regs = task_pt_regs(t);
+ cpu_hdr-pt_regs = *pt_regs;
+
+ /* FP state */
+ memcpy(cpu_hdr-fpr, t-thread.fpr, sizeof(cpu_hdr-fpr));
As note above, is sizeof(cpu_hdr-fpr) the same on all chips ?
It can differ depending on kernel configuration.
+/* restart APIs */
+
The restart APIs belong in a separate file: arch/powerpc/mm/restart.c
Explain why, please? This isn't a lot of code, and it seems likely
that checkpoint and restart paths will share data structures and tend
to be modified together over time.
+ pr_debug(%s: unexpected thread_hdr contents: 0x%lx\n,
+__func__, (unsigned long)thread_hdr-unimplemented);
Given the macro for 'pr_fmt' in include/linux/checkpoint.h, the use of
__func__ is redunant.
It seems to me that defining your own pr_fmt in a public header like
that is inappropriate, or at least unconventional. Any file that
happens to include linux/checkpoint.h will have any prior definitions
of pr_fmt overridden, no?
+ regs = task_pt_regs(current);
+ *regs = cpu_hdr-pt_regs;
+
+ regs-msr = sanitize_msr(regs-msr);
+
+ /* FP state */
+ memcpy(current-thread.fpr, cpu_hdr-fpr, sizeof(current-thread.fpr));
+ current-thread.fpscr.val = cpu_hdr-fpscr;
+ current-thread.fpexc_mode = cpu_hdr-fpexc_mode;
+
+ /* debug registers */
+ current-thread.dabr = cpu_hdr-dabr;
I'm unfamiliar with powerpc; is it necessary to sanitize any of the registers
here ? For instance, can the user cause harm with specially crafted values
of some registers ?
I had this in mind with the treatment of MSR, but I'll check on the
others, thanks.
+int cr_read_mm_context(struct cr_ctx *ctx, struct mm_struct *mm, int
rparent)
+{
+ struct cr_hdr_mm_context *mm_hdr;
+ int ret;
+
+ mm_hdr = cr_hbuf_get(ctx, sizeof(*mm_hdr));
+ if (!mm_hdr)
+ return -ENOMEM;
+
+ ret = cr_read_obj_type(ctx, mm_hdr, sizeof(*mm_hdr),
+ CR_HDR_MM_CONTEXT);
+ if (ret != rparent)
+ goto out;
Seems like 'ret' isn't set to an error value if the 'goto' executes.
It returns whatever error value cr_read_obj_type() returns. Hrm. I
guess if the image is garbage, cr_read_obj_type can potentially return
a non-error value that still isn't the desired value, is that right?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/5200: Bugfix for PCI mapping of memory and IMMR
On Mon, Jan 26, 2009 at 09:34:36PM -0700, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
This patch ensures that memory gets properly mapped into the PCI
address space. Without this patch, the memory window BAR is left
at whatever value happened to be loaded into the BAR when Linux
was booted. Without this patch, memory could end up getting mapped
at any of the 1G address boundaries instead of at '0' where Linux
expects it.
Similarly, this patch also ensures that the internally memory mapped
registers (IMMR) are mapped to the correct PCI address range.
Without this patch, PCI appears to work correctly until a PCI
device is inserted which DMAs into memory.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
No regression with a phyCORE-MPC5200B-tiny. U-Boot did probably the
right thing here...
Tested-by: Wolfram Sang w.s...@pengutronix.de
---
This is a bugfix that I intend to merge into 2.6.29 and once it is
mainlined get it added to the stable queue. If you have a 5200 system,
please test and make sure it works for you.
Thanks
g.
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 24 ++--
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index c3f2c21..87ff522 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -20,14 +20,6 @@
/*
*/
-/* PCI windows config
*/
-/*
*/
-
-#define MPC52xx_PCI_TARGET_IO0xf000
-#define MPC52xx_PCI_TARGET_MEM 0x
-
-
-/*
*/
/* Structures mapping Defines for PCI Unit
*/
/*
*/
@@ -244,7 +236,7 @@ static struct pci_ops mpc52xx_pci_ops = {
static void __init
mpc52xx_pci_setup(struct pci_controller *hose,
- struct mpc52xx_pci __iomem *pci_regs)
+ struct mpc52xx_pci __iomem *pci_regs, phys_addr_t pci_phys)
{
struct resource *res;
u32 tmp;
@@ -314,10 +306,14 @@ mpc52xx_pci_setup(struct pci_controller *hose,
/* Set all the IWCR fields at once; they're in the same reg */
out_be32(pci_regs-iwcr, MPC52xx_PCI_IWCR_PACK(iwcr0, iwcr1, iwcr2));
- out_be32(pci_regs-tbatr0,
- MPC52xx_PCI_TBATR_ENABLE | MPC52xx_PCI_TARGET_IO );
- out_be32(pci_regs-tbatr1,
- MPC52xx_PCI_TBATR_ENABLE | MPC52xx_PCI_TARGET_MEM );
+ /* Map IMMR onto PCI bus */
+ pci_phys = 0xfffc; /* bar0 has only 14 significant bits */
+ out_be32(pci_regs-tbatr0, MPC52xx_PCI_TBATR_ENABLE | pci_phys);
+ out_be32(pci_regs-bar0, PCI_BASE_ADDRESS_MEM_PREFETCH | pci_phys);
+
+ /* Map memory onto PCI bus */
+ out_be32(pci_regs-tbatr1, MPC52xx_PCI_TBATR_ENABLE);
+ out_be32(pci_regs-bar1, PCI_BASE_ADDRESS_MEM_PREFETCH);
out_be32(pci_regs-tcr, MPC52xx_PCI_TCR_LD | MPC52xx_PCI_TCR_WCT8);
@@ -414,7 +410,7 @@ mpc52xx_add_bridge(struct device_node *node)
/* Finish setting up PCI using values obtained by
* pci_proces_bridge_OF_ranges */
- mpc52xx_pci_setup(hose, pci_regs);
+ mpc52xx_pci_setup(hose, pci_regs, rsrc.start);
return 0;
}
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Broken PCI on Sequoia
On Thu, 2009-01-29 at 18:37 +0100, Geert Uytterhoeven wrote: Hi Ben, Josh, .../... Git-reverting this commit on top of 2.6.29-rc3 makes the crash go away. Perhaps sequoia.dts (and other 44x DTS files) had to be changed, too? Weird, maybe I have a bug when there is no ISA hole in the DT, I'll have a look later today. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mpc8270 and fs_enet
I've got an mpc8270 running the fs_enet v1.0 driver and we are having problems with randomly corrupted tx buffer descriptor ready bits. The CPM never clears the bit. This is a 2.6.19.2 kernel. We have the same kernel with the 8260_io driver (kernel is from the denx ELDK4.2) running on the mpc8250 that works perfect. I've been through the clock tree in u-boot and the kernel with both processors and they are configured corrected. I've checked all the pins and they are configured correctly. I back ported some spin_lock tx issues from 2.6.27.xx and still it is not working on the mpc8270. These are the tests I am failing. nmap -sS -v target ip mpc8270 Target Output ~ # fs_enet: eth0 FS_ENET ERROR(s) 0xe fs_enet: eth0 FS_ENET ERROR(s) 0xe fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0x4 fs_enet: eth0 FS_ENET ERROR(s) 0x4 fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0xc fs_enet: eth0 FS_ENET ERROR(s) 0x4 fs_enet: eth0 FS_ENET ERROR(s) 0x4 Host output- [r...@localhost linux]# nmap -sS -v 172.22.250.113 Starting Nmap 4.52 ( http://insecure.org ) at 2009-01-29 14:59 MST Initiating Ping Scan at 14:59 Scanning 172.22.250.113 [2 ports] Completed Ping Scan at 14:59, 0.00s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 14:59 Completed Parallel DNS resolution of 1 host. at 14:59, 0.27s elapsed Initiating SYN Stealth Scan at 14:59 Scanning 172.22.250.113 [1714 ports] Discovered open port 23/tcp on 172.22.250.113 Discovered open port 80/tcp on 172.22.250.113 Discovered open port 21/tcp on 172.22.250.113 eventually times out telnet target ip ftpput -u user name -p password host ip big file big file The telnet session hangs. Below is a BDI dump of the buffer descriptors for the tx side. Notice the BDs with a leading 0xd such as the ones at address 0x0e6e2100 and 0x0efe21d0. I can go in and clear the ready bit by hand with the BDI and everything starts working again without a reboot. The BDs on the rx side look text book perfect. 0e6e2100 : dc0005ea 0df8709e 1c0005ea 0df5f89e ..p. 0e6e2110 : 5c0005ea 0e29e89e 5c0005ea 0e29609e \)..\)`. 0e6e2120 : 1c000358 0e29389e 5c2a 0fa293c2 ...X.)8.\..* 0e6e2130 : 5c5a 0c42c202 5c5a 0c42c802 \..Z.B..\..Z.B.. 0e6e2140 : 1c5a 0c42c602 5c2a 0fa292c2 ...Z.B..\..* 0e6e2150 : 5c0005ea 0df8909e 1c0005ea 0df8c09e \... 0e6e2160 : 5c0005ea 0e29a09e 1c0005ea 0e29a89e \)...).. 0e6e2170 : 5c0005ea 0e29989e 5c0005ea 0e29189e \)..\).. 0e6e2180 : 1c0005ea 0df8989e 5c0005ea 0e29789e \)x. 0e6e2190 : 1c0005ea 0df8189e 5c0005ea 0df8109e \... 0e6e21a0 : 1c0005ea 0d86c09e 1c0005ea 0d86c89e 0e6e21b0 : 5c0005ea 0e29d89e 1c0005ea 0e29d09e \)...).. 0e6e21c0 : 5c0005ea 0e2bd89e 5c0005ea 0e2bd09e \+..\+.. 0e6e21d0 : dc0005ea 0e29289e 5c0005ea 0df8689e .)(.\.h. 0e6e21e0 : 1c0005ea 0e29f09e 5c0005ea 0e29909e .)..\).. 0e6e21f0 : dc0005ea 0df8609e 3c0005ea 0df6109e ..` Anyone have any experience about what could make such a difference between the two processors? -- Jim Black Senior Software Engineer Aztek Networks, Inc. 2477 55th Street, Suite 202 Boulder, CO 80301 www.azteknetworks.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rt on PowerPC
On Fri, 2009-01-30 at 00:34 +0300, Anton Vorontsov wrote:
Hi Steven,
I know 2.6.28-rt isn't yet ready, but I could not resist to try
it anyway. ;-)
Here are few issues and ways to solve them:
Currently the -rt tree doesn't link for arch/powerpc:
LD .tmp_vmlinux1
arch/powerpc/kernel/built-in.o: In function `show_interrupts':
(.text+0x27bc): undefined reference to `__call_bad_lock_func'
arch/powerpc/kernel/built-in.o: In function `show_interrupts':
(.text+0x28b0): undefined reference to `__call_bad_lock_func'
make: *** [.tmp_vmlinux1] Error 1
Thanks! I have not yet had the chance to apply any arch patches yet. I
do plan on doing so after getting the code mostly working on x86.
This can be trivially fixed:
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 838857f..cc7dd12 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -183,7 +183,7 @@ int show_interrupts(struct seq_file *p, void *v)
if (i NR_IRQS) {
desc = get_irq_desc(i);
- acquire_lock_irqsave(desc-lock, flags);
+ spin_lock_irqsave(desc-lock, flags);
action = desc-action;
if (!action || !action-handler)
goto skip;
@@ -204,7 +204,7 @@ int show_interrupts(struct seq_file *p, void *v)
seq_printf(p, , %s, action-name);
seq_putc(p, '\n');
skip:
- release_lock_irqrestore(desc-lock, flags);
+ spin_unlock_irqrestore(desc-lock, flags);
} else if (i == NR_IRQS) {
#if defined(CONFIG_PPC32) defined(CONFIG_TAU_INT)
if (tau_initialized){
--
While booting, this bug appears:
BUG: sleeping function called from invalid context at kernel/rtmutex.c:683
in_atomic(): 1 [00010001], irqs_disabled(): 1, pid: 1, name: swapper
Call Trace:
[cf82f9a0] [c0008be8] show_stack+0x4c/0x16c (unreliable)
[cf82f9e0] [c001c184] __might_sleep+0xd8/0xf8
[cf82f9f0] [c02b7758] rt_spin_lock+0x30/0x78
[cf82fa00] [c001853c] ipic_mask_irq+0x3c/0xb0
[cf82fa20] [c0054064] handle_level_irq+0x40/0x178
[cf82fa40] [c00068ec] do_IRQ+0x68/0xe0
[cf82fa50] [c0012924] ret_from_except+0x0/0x14
--- Exception: 501 at internal_add_timer+0x4/0xe0
This is trivially solved by converting arch/powerpc/sysdev/ipic.c
back to spinlocks (ipic_lock).
Assuming that converting-back is automatic, there are few other
chained interrupt controllers you might want to convert-back:
arch/powerpc/sysdev/i8259.c (i8259_lock)
arch/powerpc/sysdev/mpic.c (mpic_lock)
arch/powerpc/sysdev/qe_lib/qe_ic.c (qe_ic_lock)
Thanks! I'll add them to the file:
scripts/convert-locks-list
After this, kernel boots up to the userspace, but then bugs in the
middle (note: this is NFS boot, network activity etc.)...
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Activating swap...done.
Remounting root filesystem...done.
Checking all file systems: fsck
fsck 1.40 (29-Jun-2007)
Checking SELinux contexts: selinux-basics.
Starting network interfaces: done.
Starting portmap daemon
Cleaning: /tmp /var/lock /var/run done.
Setting pseudo-terminal access permissions...done.
Updating /etc/motd...done.
INIT: Entering runlevel: 3
Starting irqbalance.
Starting system log daemon: syslogd
BUG: sleeping function called from invalid context at kernel/rtmutex.c:683
in_atomic(): 1 [0100], irqs_disabled(): 0, pid: 7, name: sirq-net-rx/0
Call Trace:
[cf84bc20] [c0008be8] show_stack+0x4c/0x16c (unreliable)
[cf84bc60] [c001c194] __might_sleep+0xd8/0xf8
[cf84bc70] [c02b7768] rt_spin_lock+0x30/0x78
[cf84bc80] [c00800e0] kmem_cache_alloc+0x50/0x17c
[cf84bcb0] [c02568a4] ip_append_data+0x974/0x978
[cf84bd30] [c027aa0c] icmp_push_reply+0x54/0x128
[cf84bd50] [c027b59c] icmp_send+0x284/0x380
[cf84be40] [c0277328] __udp4_lib_rcv+0x3d4/0x5a0
[cf84bea0] [c0253208] ip_local_deliver_finish+0x74/0x128
[cf84bec0] [c0252fd0] ip_rcv_finish+0x148/0x30c
[cf84bf00] [c0236774] netif_receive_skb+0x21c/0x2e8
[cf84bf30] [c0238ecc] process_backlog+0x98/0x138
[cf84bf60] [c0238b24] net_rx_action+0xd4/0x198
[cf84bf90] [c002989c] ksoftirqd+0x108/0x23c
[cf84bfd0] [c003c918] kthread+0x48/0x84
[cf84bff0] [c00120b0] kernel_thread+0x4c/0x68
BUG: scheduling while atomic: sirq-net-rx/0/7/0x1101, CPU#0
Modules linked in:
Call Trace:
[cf84bee0] [c0008be8] show_stack+0x4c/0x16c (unreliable)
[cf84bf20] [c001e418] __schedule_bug+0x6c/0x80
[cf84bf30] [c02b5fdc] schedule+0x2e8/0x31c
[cf84bf70] [c001e460] __cond_resched+0x34/0x60
[cf84bf80] [c02b6348] _cond_resched+0x50/0x58
[cf84bf90] [c00298b8] ksoftirqd+0x124/0x23c
[cf84bfd0] [c003c918] kthread+0x48/0x84
[cf84bff0] [c00120b0] kernel_thread+0x4c/0x68
Turn on CONFIG_PREEMPT_TRACE (not TRACER) and it should show the
location that left preemption
Re: mpc8270 and fs_enet
James Black wrote: I've got an mpc8270 running the fs_enet v1.0 driver and we are having problems with randomly corrupted tx buffer descriptor ready bits. The CPM never clears the bit. This is a 2.6.19.2 kernel. We have the same kernel with the 8260_io driver (kernel is from the denx ELDK4.2) running on the mpc8250 that works perfect. Is it possible that some other CPM block is configured to use the same DPRAM area that the descriptors are in? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/1] powerpc: Fix partition migration hang under load
While testing partition migration with heavy CPU load using
shared processors, it was observed that sometimes the migration
would never complete and would appear to hang. Currently, the
migration code assumes that if H_SUCCESS is returned from the H_JOIN
then the migration is complete and the processor is waking up on
the target system. If there was an outstanding PROD to the processor
when the H_JOIN is called, however, it will return H_SUCCESS on the source
system, causing the migration to hang, or in some scenarios cause
the kernel to crash on the complete call waking the caller
of rtas_percpu_suspend_me. Fix this by calling H_JOIN multiple times
if necessary during the migration.
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
---
arch/powerpc/kernel/rtas.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff -puN arch/powerpc/kernel/rtas.c~powerpc_migration_hang_fix
arch/powerpc/kernel/rtas.c
--- linux-2.6/arch/powerpc/kernel/rtas.c~powerpc_migration_hang_fix
2009-01-29 17:19:58.0 -0600
+++ linux-2.6-bjking1/arch/powerpc/kernel/rtas.c2009-01-29
17:19:58.0 -0600
@@ -46,6 +46,7 @@ EXPORT_SYMBOL(rtas);
struct rtas_suspend_me_data {
atomic_t working; /* number of cpus accessing this struct */
+ atomic_t done;
int token; /* ibm,suspend-me */
int error;
struct completion *complete; /* wait on this until working == 0 */
@@ -689,7 +690,7 @@ static int ibm_suspend_me_token = RTAS_U
#ifdef CONFIG_PPC_PSERIES
static void rtas_percpu_suspend_me(void *info)
{
- long rc;
+ long rc = H_SUCCESS;
unsigned long msr_save;
int cpu;
struct rtas_suspend_me_data *data =
@@ -701,7 +702,8 @@ static void rtas_percpu_suspend_me(void
msr_save = mfmsr();
mtmsr(msr_save ~(MSR_EE));
- rc = plpar_hcall_norets(H_JOIN);
+ while (rc == H_SUCCESS !atomic_read(data-done))
+ rc = plpar_hcall_norets(H_JOIN);
mtmsr(msr_save);
@@ -724,6 +726,9 @@ static void rtas_percpu_suspend_me(void
smp_processor_id(), rc);
data-error = rc;
}
+
+ atomic_set(data-done, 1);
+
/* This cpu did the suspend or got an error; in either case,
* we need to prod all other other cpus out of join state.
* Extra prods are harmless.
@@ -766,6 +771,7 @@ static int rtas_ibm_suspend_me(struct rt
}
atomic_set(data.working, 0);
+ atomic_set(data.done, 0);
data.token = rtas_token(ibm,suspend-me);
data.error = 0;
data.complete = done;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8270 and fs_enet
I thought the same thing. So I verified the memory map. We did have a conflict with the SPI stomping the FCC temp so we moved that. An interesting note is that we drop packets from time to time on the MCC as well due to a similar ready bit problem. The CPM never clears the bit. -- IMMR memory map -- FCC1 Parameters0x8400256 FCC1 Temp buffer 0x9000128 SCC1 Parameters0x8000256 SCC2 Parameters0x8100256 SCC4 Parameters0x8300256 SMC1 Parameters0x 64 SMC2 Parameters0x0040 64 SCC1 Buff Desc 0x0080 64 SCC2 Buff Desc 0x00C0 64 SCC4 Buff Desc 0x0100 64 SPI Param Pointer 0x89FC 2 SPI Parameters0x9000 76 MCC2 Global Param 0x8800128 MCC2 HDLC Param0x2000 8192 MCC2 Extra Param 0xB000 1024 On Thu, Jan 29, 2009 at 4:05 PM, Scott Wood scottw...@freescale.com wrote: James Black wrote: I've got an mpc8270 running the fs_enet v1.0 driver and we are having problems with randomly corrupted tx buffer descriptor ready bits. The CPM never clears the bit. This is a 2.6.19.2 kernel. We have the same kernel with the 8260_io driver (kernel is from the denx ELDK4.2) running on the mpc8250 that works perfect. Is it possible that some other CPM block is configured to use the same DPRAM area that the descriptors are in? -Scott -- Jim Black Senior Software Engineer Aztek Networks, Inc. 2477 55th Street, Suite 202 Boulder, CO 80301 www.azteknetworks.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/5200: update device tree binding documentation
From: Grant Likely grant.lik...@secretlab.ca This patch updates the mpc5200 binding documentation to match actual usage conventions, to remove incorrect information, and to remove topics which are more thoroughly described elsewhere. Signed-off-by: Grant Likely grant.lik...@secretlab.ca CC: devicetree-disc...@ozlabs.org CC: Wolfram Sang w.s...@pengutronix.de --- Documentation/powerpc/dts-bindings/fsl/mpc5200.txt | 180 + .../powerpc/mpc52xx-device-tree-bindings.txt | 277 2 files changed, 180 insertions(+), 277 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt delete mode 100644 Documentation/powerpc/mpc52xx-device-tree-bindings.txt diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt new file mode 100644 index 000..b8b09d3 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt @@ -0,0 +1,180 @@ +MPC5200 Device Tree Bindings + + +(c) 2006-2009 Secret Lab Technologies Ltd +Grant Likely grant.lik...@secretlab.ca + +Naming conventions +-- +For mpc5200 on-chip devices, the format for each compatible value is +chip-device[-mode]. The OS should be able to match a device driver +to the device based solely on the compatible value. If two drivers +match on the compatible list; the 'most compatible' driver should be +selected. + +The split between the MPC5200 and the MPC5200B leaves a bit of a +conundrum. How should the compatible property be set up to provide +maximum compatibility information; but still accurately describe the +chip? For the MPC5200; the answer is easy. Most of the SoC devices +originally appeared on the MPC5200. Since they didn't exist anywhere +else; the 5200 compatible properties will contain only one item; +fsl,mpc5200-device. + +The 5200B is almost the same as the 5200, but not quite. It fixes +silicon bugs and it adds a small number of enhancements. Most of the +devices either provide exactly the same interface as on the 5200. A few +devices have extra functions but still have a backwards compatible mode. +To express this information as completely as possible, 5200B device trees +should have two items in the compatible list: + compatible = fsl,mpc5200b-device,fsl,mpc5200-device; + +It is *strongly* recommended that 5200B device trees follow this convention +(instead of only listing the base mpc5200 item). + +ie. ethernet on mpc5200: compatible = fsl,mpc5200-fec; +ethernet on mpc5200b: compatible = fsl,mpc5200b-fec, fsl,mpc5200-fec; + +Modal devices, like PSCs, also append the configured function to the +end of the compatible field. ie. A PSC in i2s mode would specify +fsl,mpc5200-psc-i2s, not fsl,mpc5200-i2s. This convention is chosen to +avoid naming conflicts with non-psc devices providing the same +function. For example, fsl,mpc5200-spi and fsl,mpc5200-psc-spi describe +the mpc5200 simple spi device and a PSC spi mode respectively. + +At the time of writing, exact chip may be either 'fsl,mpc5200' or +'fsl,mpc5200b'. + +The soc node + +This node describes the on chip SOC peripherals. Every mpc5200 based +board will have this node, and as such there is a common naming +convention for SOC devices. + +Required properties: +name description + --- +ranges Memory range of the internal memory mapped registers. + Should be 0 [baseaddr] 0xc000 +regShould be [baseaddr] 0x100 +compatible mpc5200: fsl,mpc5200-immr + mpc5200b: fsl,mpc5200b-immr +system-frequency 'fsystem' frequency in Hz; XLB, IPB, USB and PCI + clocks are derived from the fsystem clock. +bus-frequency IPB bus frequency in HZ. Clock rate + used by most of the soc devices. + +soc child nodes +--- +Any on chip SOC devices available to Linux must appear as soc5200 child nodes. + +Note: The tables below show the value for the mpc5200. A mpc5200b device +tree should use the fsl,mpc5200b-device,fsl,mpc5200-device form. + +Required soc5200 child nodes: +name compatible Description + -- --- +cdm@addr fsl,mpc5200-cdm Clock Distribution +interrupt-controller@addrfsl,mpc5200-pic need an interrupt + controller to boot +bestcomm@addrfsl,mpc5200-bestcommBestcomm DMA controller + +Recommended soc5200 child nodes; populate as needed for your board +name compatible Description + -- --- +timer@addr fsl,mpc5200-gpt General purpose timers +gpio@addrfsl,mpc5200-gpio MPC5200 simple gpio controller
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
Nathan Lynch wrote:
Hey Oren, thanks for taking a look.
Oren Laadan wrote:
Nathan Lynch wrote:
What doesn't work:
* restarting a 32-bit task from a 64-bit task and vice versa
Is there a test to bail if we attempt to checkpoint such tasks ?
No, but I'll add one if it looks too hard to fix for the next round.
+struct cr_hdr_cpu {
+ struct pt_regs pt_regs;
It has been suggested (as done in x86/32 code) not to use 'struct pt_regs'
because it can (and has) changed on x86 and because it only container
the registers that the kernel trashes, not all usermode registers.
https://lists.linux-foundation.org/pipermail/containers/2008-August/012355.html
Yeah, I considered that discussion, but the situation is different for
powerpc (someone on linuxppc-dev smack me if I'm wrong here :)
pt_regs is part of the ABI, and it encompasses all user mode registers
except for floating point, which are handled separately.
+ /* relevant fields from thread_struct */
+ double fpr[32][TS_FPRWIDTH];
Can TS_FPRWIDTH change between sub-archs or kernel versions ? If so, it
needs to be stated explicitly.
+ unsigned int fpscr;
+ int fpexc_mode;
+ /* unsigned int align_ctl; this is never updated? */
+ unsigned long dabr;
Are these fields always guarantee to compile to the same number of bytes
regardless of 32/64 bit choice of compiler (or sub-arch?) ?
In the x86(32/64) architecture we use types with explicit size such as
__u32 and the like to ensure that it always compiled to the same
size.
Yeah, I'll have to fix these up.
+static void cr_hdr_init(struct cr_hdr *hdr, __s16 type, __s16 len, __u32
parent)
+{
+ hdr-type = type;
+ hdr-len = len;
+ hdr-parent = parent;
+}
+
This function is rather generic and useful to non-arch-dependent and other
architectures code. Perhaps put in a separate patch ?
Alright. By the way, why are cr_hdr-type and cr_hdr-len signed
types?
No particular reason. I can change that in v14.
+int cr_write_cpu(struct cr_ctx *ctx, struct task_struct *t)
+{
+ struct cr_hdr_cpu *cpu_hdr;
+ struct pt_regs *pt_regs;
+ struct cr_hdr cr_hdr;
+ u32 parent;
+ int ret;
+
+ cpu_hdr = cr_hbuf_get(ctx, sizeof(*cpu_hdr));
+ if (!cpu_hdr)
+ return -ENOMEM;
+
+ parent = task_pid_vnr(t);
+
+ cr_hdr_init(cr_hdr, CR_HDR_CPU, sizeof(*cpu_hdr), parent);
+
+ /* pt_regs: GPRs, MSR, etc */
+ pt_regs = task_pt_regs(t);
+ cpu_hdr-pt_regs = *pt_regs;
+
+ /* FP state */
+ memcpy(cpu_hdr-fpr, t-thread.fpr, sizeof(cpu_hdr-fpr));
As note above, is sizeof(cpu_hdr-fpr) the same on all chips ?
It can differ depending on kernel configuration.
So the actual size needs to be explicitly indicated (and compared with).
+/* restart APIs */
+
The restart APIs belong in a separate file: arch/powerpc/mm/restart.c
Explain why, please? This isn't a lot of code, and it seems likely
that checkpoint and restart paths will share data structures and tend
to be modified together over time.
This one has little code, but usually that isn't the case, and many of
the data structures shared are anyway exported. Since the split makes
sense in other cases, it makes sense to follow convention.
Personally I don't have a strong opinion on this. However one of the
initial feedbacks for the existing patchset requested that I split the
functionality between files (and to separate commits).
In other words, if nobody else cries, I won't spoil it ;)
+ pr_debug(%s: unexpected thread_hdr contents: 0x%lx\n,
+__func__, (unsigned long)thread_hdr-unimplemented);
Given the macro for 'pr_fmt' in include/linux/checkpoint.h, the use of
__func__ is redunant.
It seems to me that defining your own pr_fmt in a public header like
that is inappropriate, or at least unconventional. Any file that
happens to include linux/checkpoint.h will have any prior definitions
of pr_fmt overridden, no?
Hmmm.. didn't think of it this way. Using the pr_debug() there was yet
another feedback from LKML, and it seemed reasonable to me. Can you
think of a case where linux/checkpoint.h will happen to be included
in checkpoint-related code ?
+ regs = task_pt_regs(current);
+ *regs = cpu_hdr-pt_regs;
+
+ regs-msr = sanitize_msr(regs-msr);
+
+ /* FP state */
+ memcpy(current-thread.fpr, cpu_hdr-fpr, sizeof(current-thread.fpr));
+ current-thread.fpscr.val = cpu_hdr-fpscr;
+ current-thread.fpexc_mode = cpu_hdr-fpexc_mode;
+
+ /* debug registers */
+ current-thread.dabr = cpu_hdr-dabr;
I'm unfamiliar with powerpc; is it necessary to sanitize any of the registers
here ? For instance, can the user cause harm with specially crafted values
of some registers ?
I had this in mind with the treatment of MSR, but I'll check on the
others, thanks.
+int cr_read_mm_context(struct cr_ctx *ctx, struct mm_struct *mm, int
rparent)
+{
+ struct cr_hdr_mm_context *mm_hdr;
Re: Broken PCI on Sequoia
On Fri, Jan 30, 2009 at 09:11:01AM +1100, Benjamin Herrenschmidt wrote: On Thu, 2009-01-29 at 18:37 +0100, Geert Uytterhoeven wrote: Hi Ben, Josh, .../... Git-reverting this commit on top of 2.6.29-rc3 makes the crash go away. Perhaps sequoia.dts (and other 44x DTS files) had to be changed, too? Weird, maybe I have a bug when there is no ISA hole in the DT, I'll have a look later today. Yeah. In fact, I think you have that bug in almost every board. You only updated Bamboo and Canyonlands with the initial patch and the changelog says other boards can be updated separately. Nobody did that. So not so weird after all. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'next' branch of linux-2.6-mpc52xx.git
Oops, forgot to CC the mailing list. g. On Thu, Jan 29, 2009 at 5:28 PM, Grant Likely grant.lik...@secretlab.ca wrote: Hi Ben, Here is the traditional defconfig update plus a bugfix for mpc5200 PCI. Please pull into 2.6.29. Thanks, g. The following changes since commit 18e352e4a73465349711a9324767e1b2453383e2: Linus Torvalds (1): Linux 2.6.29-rc3 are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx merge Grant Likely (2): powerpc/5200: update defconfigs powerpc/5200: Bugfix for PCI mapping of memory and IMMR arch/powerpc/configs/52xx/cm5200_defconfig| 83 ++-- arch/powerpc/configs/52xx/lite5200b_defconfig | 86 +++- arch/powerpc/configs/52xx/motionpro_defconfig | 85 +++- arch/powerpc/configs/52xx/pcm030_defconfig| 82 +-- arch/powerpc/configs/52xx/tqm5200_defconfig | 89 +++-- arch/powerpc/configs/mpc5200_defconfig| 104 ++--- arch/powerpc/platforms/52xx/mpc52xx_pci.c | 24 +++ 7 files changed, 396 insertions(+), 157 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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 1/1] powerpc: Fix partition migration hang under load
Brian King wrote: While testing partition migration with heavy CPU load using shared processors, it was observed that sometimes the migration would never complete and would appear to hang. Currently, the migration code assumes that if H_SUCCESS is returned from the H_JOIN then the migration is complete and the processor is waking up on the target system. If there was an outstanding PROD to the processor when the H_JOIN is called, however, it will return H_SUCCESS on the source system Hmm, did you determine where that outstanding H_PROD is coming from? AFAICT this is the only code which uses that hcall, and all processors should have consumed their prods from one migration before another migration can commence. Regardless, ACK -- if we were to add another H_PROD call site (or if there's one I missed) this would be necessary anyway. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] gianfar: Fix Wake-on-LAN support
From: Anton Vorontsov avoront...@ru.mvista.com Date: Wed, 28 Jan 2009 23:35:45 +0300 commit 0f0ca340e57bd7446855fefd07a64249acf81223 (phy: power management support) caused a regression in the gianfar driver. Now phylib turns off PHY power during suspend, and thus WOL doesn't work anymore. This patch workarounds the issue by enabling wakeup in the MDIO device, i.e. just restores the old behaviour for the gianfar driver. Note that this way all PHYs on a given MDIO bus won't be turned off during suspend, which isn't good from the power saving point of view. A proper, per netdevice wakeup management support will need a bit reworked phylib suspend/resume logic. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Applied, thanks Anton. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rt on PowerPC
On Thu, 2009-01-29 at 15:21 -0800, Frank Rowand wrote: Steven Rostedt wrote: Your email can at an opportune time for me... I was starting to try 2.6.28-rt on ARM and quickly came to the conclusion that the arch patches weren't the focus yet. But I'm currently side-tracked with getting my board to even boot a vanilla 2.6.28 kernel first. Do you expect to get to the arches in the next week or two? If not, I may head down that path for ARM myself. I'm going to try to apply the arch patches, but I do not have an arm board myself. I do have a PPC64 box that works, but that's about it. I have a powerbook too, but that box has never been able to boot an -rt kernel. Who knows, maybe this one will boot. I will create an rt/arm and an rt/ppc branch for the specific changes on each. I'll try to get them next week (maybe tomorrow if things go better than planned). -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Broken PCI on Sequoia
Yeah. In fact, I think you have that bug in almost every board. You only updated Bamboo and Canyonlands with the initial patch and the changelog says other boards can be updated separately. Nobody did that. So not so weird after all. I still don't see off hand what's wrong in the code.. Geert, any chance you can sprinkle printk's in ppc4xx_configure_pci_PMMs() ? I'd like to see the arguments to the various calls to ppc4xx_setup_one_pci_PMM(), and the value of hose-pci_mem_offset and hose-isa_mem_phys size. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rt on PowerPC
This is trivially solved by converting arch/powerpc/sysdev/ipic.c back to spinlocks (ipic_lock). Assuming that converting-back is automatic, there are few other chained interrupt controllers you might want to convert-back: arch/powerpc/sysdev/i8259.c (i8259_lock) arch/powerpc/sysdev/mpic.c (mpic_lock) arch/powerpc/sysdev/qe_lib/qe_ic.c (qe_ic_lock) Except that a bunch of those can be both primary and chained... It's simply not a solution to have to convert interrupt controller code to use a different locking scheme depending on whether they are chained or primary... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH] powerpc: Rework I$/D$ coherency
This patch reworks the way we do I and D cache coherency on PowerPC.
The old way was split in 3 different parts depending on the processor type:
- Hash with per-page exec support (64-bit and = POWER4 only) does it
at hashing time, by preventing exec on unclean pages and cleaning pages
on exec faults.
- Everything without per-page exec support (32-bit hash, 8xx, and
64-bit POWER4) does it for all page going to user space in update_mmu_cache().
- Embedded with per-page exec support does it from do_page_fault() on
exec faults, in a way similar to what the hash code does.
That leads to confusion, and bugs. For example, the method using
update_mmu_cache()
is racy on SMP where another processor can see the new PTE and hash it in before
we have cleaned the cache, and then blow trying to execute. This is hard to hit
but
I think it has bitten us in the past.
Also, it's inefficient for embedded where we always end up having to do at least
one more page fault.
This reworks the whole thing by moving the cache sync into two main call sites,
though we keep different behaviours depending on the HW capability. The call
sites are set_pte_at() which is now made out of line, and
ptep_set_access_flags()
which joins the former in pgtable.c
The base idea for Embedded with per-page exec support, is that we now do the
flush at set_pte_at() time when coming from an exec fault, which allows us
to avoid the double fault problem completely (we can even improve the situation
more by implementing TLB preload in update_mmu_cache() but that's for later).
If for some reason we didn't do it there and we try to execute, we'll hit
the page fault, which will do a minor fault, which will hit
ptep_set_access_flags()
to do things like update _PAGE_ACCESSED or _PAGE_DIRTY if needed, we just make
this guys also perform the I/D cache sync for exec faults now. This second path
is the catch all for things that weren't cleaned at set_pte_at() time.
For cpus without per-pag exec support, we always do the sync at set_pte_at(),
thus guaranteeing that when the PTE is visible to other processors, the cache
is clean.
For the 64-bit hash with per-page exec support case, we keep the old mechanism
for now. I'll look into changing it later, once I've reworked a bit how we
use _PAGE_EXEC.
This is also a first step for adding _PAGE_EXEC support for embedded platforms
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/highmem.h |2
arch/powerpc/include/asm/pgtable-ppc32.h | 53
arch/powerpc/include/asm/pgtable-ppc64.h | 28 +-
arch/powerpc/include/asm/pgtable.h | 84 +++
arch/powerpc/mm/fault.c | 46 +++---
arch/powerpc/mm/mem.c| 33 ---
arch/powerpc/mm/pgtable.c| 133 +++
7 files changed, 245 insertions(+), 134 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc32.h2009-01-28
15:55:58.0 +1100
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc32.h 2009-01-29
10:14:53.0 +1100
@@ -429,6 +429,8 @@ extern int icache_44x_need_flush;
#define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE()
#endif
+#define _PAGE_HPTEFLAGS _PAGE_HASHPTE
+
#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY)
@@ -667,44 +669,6 @@ static inline unsigned long long pte_upd
#endif /* CONFIG_PTE_64BIT */
/*
- * set_pte stores a linux PTE into the linux page table.
- * On machines which use an MMU hash table we avoid changing the
- * _PAGE_HASHPTE bit.
- */
-
-static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
- pte_t *ptep, pte_t pte)
-{
-#if (_PAGE_HASHPTE != 0) defined(CONFIG_SMP) !defined(CONFIG_PTE_64BIT)
- pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) ~_PAGE_HASHPTE);
-#elif defined(CONFIG_PTE_64BIT) defined(CONFIG_SMP)
-#if _PAGE_HASHPTE != 0
- if (pte_val(*ptep) _PAGE_HASHPTE)
- flush_hash_entry(mm, ptep, addr);
-#endif
- __asm__ __volatile__(\
- stw%U0%X0 %2,%0\n\
- eieio\n\
- stw%U0%X0 %L2,%1
- : =m (*ptep), =m (*((unsigned char *)ptep+4))
- : r (pte) : memory);
-#else
- *ptep = __pte((pte_val(*ptep) _PAGE_HASHPTE)
- | (pte_val(pte) ~_PAGE_HASHPTE));
-#endif
-}
-
-
-static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
- pte_t *ptep, pte_t pte)
-{
-#if defined(CONFIG_PTE_64BIT) defined(CONFIG_SMP)
defined(CONFIG_DEBUG_VM)
- WARN_ON(pte_present(*ptep));
-#endif
- __set_pte_at(mm, addr, ptep, pte);
-}
-
-/*
* 2.6 calls this without flushing the TLB entry; this is wrong
* for our hash-based implementation, we fix that up here.
*/
@@ -744,24 +708,13 @@ static inline void huge_ptep_set_wrprote
}
-#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
-static inline void
Re: 2.6.28-rt on PowerPC
On Fri, Jan 30, 2009 at 01:11:50PM +1100, Benjamin Herrenschmidt wrote: This is trivially solved by converting arch/powerpc/sysdev/ipic.c back to spinlocks (ipic_lock). Assuming that converting-back is automatic, there are few other chained interrupt controllers you might want to convert-back: arch/powerpc/sysdev/i8259.c (i8259_lock) arch/powerpc/sysdev/mpic.c (mpic_lock) arch/powerpc/sysdev/qe_lib/qe_ic.c (qe_ic_lock) Except that a bunch of those can be both primary and chained... Yeah, thanks for correcting. It's simply not a solution to have to convert interrupt controller code to use a different locking scheme depending on whether they are chained or primary... Actually, it doesn't matter whether a controller is a root IC or cascaded. Just as primary handlers, chained handlers don't run in threads, thus spinlocks should be used, not sleeping locks. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Dynamic-ftrace not working in PlayStation3
Hi,
Remis Lima Baima wrote:
Hi to all. I was tracing a bug in the snd_usb_audio driver
(PlayStation 3, Kernel 2.6.29-rc2,
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git) and
for that I tried to use the dynamic ftrace to get less debug output.
But it did not work at all. Ftrace (without the dynamic ftrace
support) works normally. So I traced the dynamic ftrace bug and I
think that I found the bug location but I got stucked. Could anyone
help, please? Below is the link with the debug output:
PS1: The problem seems to happen in the file
./git/linux-2.6/arch/powerpc/kernel/ftrace.c around the line 217:
if (ptr != GET_ADDR(addr)) {. It returns true.
PS2: I enabled the DEBUGP macro to get the debug output below and
changed the line 218 to printk(KERN_ERR addr does not match \nptr:
%lx \naddr: %lx \nGET_ADDR(addr): %lx \n, ptr, addr,
GET_ADDR(addr));.
//*
ip:d0045aec jumps to d0046340 r2: d0050c00
3d82 398c5740 5740 toc: d0046360 c000 7cac
ip:d00458d0 jumps to d0046340 r2: d0050c00
3d82 398c5740 5740 toc: d0046360 c000 7cac
ip:d0045838 jumps to d0046340 r2: d0050c00
3d82 398c5740 5740 toc: d0046360 c000 7cac
ip:d00456dc jumps to d0046340 r2: d0050c00
3d82 398c5740 5740 toc: d0046360 c000 7cac
...
ps3_system_bus_match:362: dev=11.0(lpm_01), drv=11.0(ps3-lpm): match
ps3_system_bus_match:362: dev=11.0(lpm_01), drv=11.0(ps3-lpm): match
ps3-lpm lpm_01: - ps3_lpm_probe:1245:
ip:d03fe280 jumps to d03ffad8 r2: d0422c70
3d82fffe 398cce68 fffece68 toc: d040faf8 6c656400 5f5f6b73
addr does not match
ptr: 6c6564005f5f6b73
addr: c04ff128
GET_ADDR(addr): c0007cac
I don't know so much about ftrace, but to get a better idea of the
problem, could you try with the patch below?
Is ps3-lpm built as a loadable module, and if so, is it the first one
that got loaded?
Also, try to either build with CONFIG_PS3_LPM=n, or delete ps3-lpm.ko
so it does not get loaded to see what happens.
-Geoff
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -23,7 +23,7 @@
#if 0
#define DEBUGP printk
#else
-#define DEBUGP(fmt , ...) do { } while (0)
+#define DEBUGP printk
#endif
static unsigned int ftrace_nop = PPC_NOP_INSTR;
@@ -213,6 +213,8 @@ __ftrace_make_nop(struct module *mod,
ptr = ((unsigned long)jmp[0] 32) + jmp[1];
+ printk(ptr %lx, addr %lx, GET_ADDR %lx\n, ptr, addr, GET_ADDR(addr));
+
/* This should match what was called */
if (ptr != GET_ADDR(addr)) {
printk(KERN_ERR addr does not match %lx\n, ptr);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Dynamic-ftrace not working in PlayStation3
On Thu, 29 Jan 2009, Geoff Levand wrote:
//*
ip:d0045aec jumps to d0046340 r2: d0050c00
3d82 398c5740 5740 toc: d0046360 c000 7cac
ip:d00458d0 jumps to d0046340 r2: d0050c00
3d82 398c5740 5740 toc: d0046360 c000 7cac
ip:d0045838 jumps to d0046340 r2: d0050c00
3d82 398c5740 5740 toc: d0046360 c000 7cac
ip:d00456dc jumps to d0046340 r2: d0050c00
3d82 398c5740 5740 toc: d0046360 c000 7cac
...
So I take it that the above showed that the code worked for some?
ps3_system_bus_match:362: dev=11.0(lpm_01), drv=11.0(ps3-lpm): match
ps3_system_bus_match:362: dev=11.0(lpm_01), drv=11.0(ps3-lpm): match
ps3-lpm lpm_01: - ps3_lpm_probe:1245:
ip:d03fe280 jumps to d03ffad8 r2: d0422c70
Could you find out what that function is? Perhaps do a:
printk(ip:%pF\n, ip);
As long as you have kallsyms on, that should point to the function that's
the problem.
3d82fffe 398cce68 fffece68 toc: d040faf8 6c656400 5f5f6b73
addr does not match
ptr: 6c6564005f5f6b73
ptr is the same info as the last line above.
addr: c04ff128
GET_ADDR(addr): c0007cac
I don't know so much about ftrace, but to get a better idea of the
problem, could you try with the patch below?
Is ps3-lpm built as a loadable module, and if so, is it the first one
that got loaded?
Also, try to either build with CONFIG_PS3_LPM=n, or delete ps3-lpm.ko
so it does not get loaded to see what happens.
-Geoff
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -23,7 +23,7 @@
#if 0
Heh, I would have just done:
- #if 0
+ #if 1
;-)
-- Steve
#define DEBUGP printk
#else
-#define DEBUGP(fmt , ...)do { } while (0)
+#define DEBUGP printk
#endif
static unsigned int ftrace_nop = PPC_NOP_INSTR;
@@ -213,6 +213,8 @@ __ftrace_make_nop(struct module *mod,
ptr = ((unsigned long)jmp[0] 32) + jmp[1];
+ printk(ptr %lx, addr %lx, GET_ADDR %lx\n, ptr, addr, GET_ADDR(addr));
+
/* This should match what was called */
if (ptr != GET_ADDR(addr)) {
printk(KERN_ERR addr does not match %lx\n, ptr);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
Quoting Oren Laadan (or...@cs.columbia.edu):
+static void cr_hdr_init(struct cr_hdr *hdr, __s16 type, __s16 len, __u32
parent)
+{
+ hdr-type = type;
+ hdr-len = len;
+ hdr-parent = parent;
+}
+
This function is rather generic and useful to non-arch-dependent and other
architectures code. Perhaps put in a separate patch ?
BTW I disagree here - looking through the patch I found
the use of this fn to be very distracting. To replace 3
simple in-line assignments, I have to verify the order of
4 weird-looking arguments, and actually first try to
remember what 'cr_hdr_init' is supposed to be and do?
That's not meant to be a complaint, just explanation :)
I prefer dropping its use altogether. Since I believe
most of the functions calling it in this patch shouldn't
exist anyway (just writing 0xdeadbeef into the file), it
all the more should just go away.
-serge
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28-rt on PowerPC
Actually, it doesn't matter whether a controller is a root IC or cascaded. Just as primary handlers, chained handlers don't run in threads, thus spinlocks should be used, not sleeping locks. Sounds good then. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Dynamic-ftrace not working in PlayStation3
On Thu, 2009-01-29 at 22:38 -0500, Steven Rostedt wrote: On Thu, 29 Jan 2009, Geoff Levand wrote: //* ip:d0045aec jumps to d0046340 r2: d0050c00 3d82 398c5740 5740 toc: d0046360 c000 7cac ip:d00458d0 jumps to d0046340 r2: d0050c00 3d82 398c5740 5740 toc: d0046360 c000 7cac ip:d0045838 jumps to d0046340 r2: d0050c00 3d82 398c5740 5740 toc: d0046360 c000 7cac ip:d00456dc jumps to d0046340 r2: d0050c00 3d82 398c5740 5740 toc: d0046360 c000 7cac ... So I take it that the above showed that the code worked for some? ps3_system_bus_match:362: dev=11.0(lpm_01), drv=11.0(ps3-lpm): match ps3_system_bus_match:362: dev=11.0(lpm_01), drv=11.0(ps3-lpm): match ps3-lpm lpm_01: - ps3_lpm_probe:1245: ip:d03fe280 jumps to d03ffad8 r2: d0422c70 Could you find out what that function is? Perhaps do a: printk(ip:%pF\n, ip); As long as you have kallsyms on, that should point to the function that's the problem. 3d82fffe 398cce68 fffece68 toc: d040faf8 6c656400 5f5f6b73 addr does not match ptr: 6c6564005f5f6b73 ptr is the same info as the last line above. 6c656400 5f5f6b73 = led\0__ks :) --- a/arch/powerpc/kernel/ftrace.c +++ b/arch/powerpc/kernel/ftrace.c @@ -23,7 +23,7 @@ #if 0 Heh, I would have just done: - #if 0 + #if 1 ;-) Should do s/DEBUGP/pr_debug/g cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/5200: update device tree binding documentation
On Thu, Jan 29, 2009 at 04:59:21PM -0700, Grant Likely wrote: From: Grant Likely grant.lik...@secretlab.ca This patch updates the mpc5200 binding documentation to match actual usage conventions, to remove incorrect information, and to remove topics which are more thoroughly described elsewhere. Signed-off-by: Grant Likely grant.lik...@secretlab.ca One minor nit, then you can add Reviewed-by: Wolfram Sang w.s...@pengutronix.de CC: devicetree-disc...@ozlabs.org CC: Wolfram Sang w.s...@pengutronix.de --- Documentation/powerpc/dts-bindings/fsl/mpc5200.txt | 180 + .../powerpc/mpc52xx-device-tree-bindings.txt | 277 2 files changed, 180 insertions(+), 277 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt delete mode 100644 Documentation/powerpc/mpc52xx-device-tree-bindings.txt diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt new file mode 100644 index 000..b8b09d3 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt @@ -0,0 +1,180 @@ +MPC5200 Device Tree Bindings + + +(c) 2006-2009 Secret Lab Technologies Ltd +Grant Likely grant.lik...@secretlab.ca + +Naming conventions +-- +For mpc5200 on-chip devices, the format for each compatible value is +chip-device[-mode]. The OS should be able to match a device driver +to the device based solely on the compatible value. If two drivers +match on the compatible list; the 'most compatible' driver should be +selected. + +The split between the MPC5200 and the MPC5200B leaves a bit of a +conundrum. How should the compatible property be set up to provide +maximum compatibility information; but still accurately describe the +chip? For the MPC5200; the answer is easy. Most of the SoC devices +originally appeared on the MPC5200. Since they didn't exist anywhere +else; the 5200 compatible properties will contain only one item; +fsl,mpc5200-device. + +The 5200B is almost the same as the 5200, but not quite. It fixes +silicon bugs and it adds a small number of enhancements. Most of the +devices either provide exactly the same interface as on the 5200. A few +devices have extra functions but still have a backwards compatible mode. +To express this information as completely as possible, 5200B device trees +should have two items in the compatible list: + compatible = fsl,mpc5200b-device,fsl,mpc5200-device; + +It is *strongly* recommended that 5200B device trees follow this convention +(instead of only listing the base mpc5200 item). + +ie. ethernet on mpc5200: compatible = fsl,mpc5200-fec; +ethernet on mpc5200b: compatible = fsl,mpc5200b-fec, fsl,mpc5200-fec; + +Modal devices, like PSCs, also append the configured function to the +end of the compatible field. ie. A PSC in i2s mode would specify +fsl,mpc5200-psc-i2s, not fsl,mpc5200-i2s. This convention is chosen to +avoid naming conflicts with non-psc devices providing the same +function. For example, fsl,mpc5200-spi and fsl,mpc5200-psc-spi describe +the mpc5200 simple spi device and a PSC spi mode respectively. + +At the time of writing, exact chip may be either 'fsl,mpc5200' or +'fsl,mpc5200b'. + +The soc node + +This node describes the on chip SOC peripherals. Every mpc5200 based +board will have this node, and as such there is a common naming +convention for SOC devices. + +Required properties: +name description + --- +ranges Memory range of the internal memory mapped registers. + Should be 0 [baseaddr] 0xc000 +reg Should be [baseaddr] 0x100 +compatible mpc5200: fsl,mpc5200-immr + mpc5200b: fsl,mpc5200b-immr +system-frequency 'fsystem' frequency in Hz; XLB, IPB, USB and PCI + clocks are derived from the fsystem clock. +bus-frequencyIPB bus frequency in HZ. Clock rate Should be Hz here, too, for consistency. + used by most of the soc devices. + +soc child nodes +--- +Any on chip SOC devices available to Linux must appear as soc5200 child nodes. + +Note: The tables below show the value for the mpc5200. A mpc5200b device +tree should use the fsl,mpc5200b-device,fsl,mpc5200-device form. + +Required soc5200 child nodes: +name compatible Description + -- --- +cdm@addr fsl,mpc5200-cdm Clock Distribution +interrupt-controller@addr fsl,mpc5200-pic need an interrupt + controller to boot +bestcomm@addr fsl,mpc5200-bestcommBestcomm DMA controller + +Recommended soc5200 child
Re: [RFC/PATCH] powerpc: Rework I$/D$ coherency
On Jan 29, 2009, at 8:26 PM, Benjamin Herrenschmidt wrote:
Index: linux-work/arch/powerpc/include/asm/pgtable-ppc64.h
===
--- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc64.h
2009-01-28 16:00:26.0 +1100
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc64.h 2009-01-29
10:50:58.0 +1100
@@ -125,6 +125,8 @@
#define _PTEIDX_SECONDARY 0x8
#define _PTEIDX_GROUP_IX0x7
+/* To make some generic powerpc code happy */
+#define _PAGE_HWEXEC 0
/*
* POWER4 and newer have per page execute protection, older chips
can only
@@ -285,6 +287,10 @@ static inline unsigned long pte_update(s
: r (ptep), r (clr), m (*ptep), i (_PAGE_BUSY)
: cc );
+ /* huge pages use the old page table lock */
+ if (!huge)
+ assert_pte_locked(mm, addr);
+
if (old _PAGE_HASHPTE)
hpte_need_flush(mm, addr, ptep, old, huge);
return old;
@@ -359,23 +365,12 @@ static inline void pte_clear(struct mm_s
pte_update(mm, addr, ptep, ~0UL, 0);
}
-/*
- * set_pte stores a linux PTE into the linux page table.
- */
-static inline void set_pte_at(struct mm_struct *mm, unsigned long
addr,
- pte_t *ptep, pte_t pte)
-{
- if (pte_present(*ptep))
- pte_clear(mm, addr, ptep);
- pte = __pte(pte_val(pte) ~_PAGE_HPTEFLAGS);
- *ptep = pte;
-}
/* Set the dirty and/or accessed bits atomically in a linux PTE, this
* function doesn't need to flush the hash entry
*/
#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
should the #define go since its in pgtable.h now?
-static inline void __ptep_set_access_flags(pte_t *ptep, pte_t
entry, int dirty)
+static inline void __ptep_set_access_flags(pte_t *ptep, pte_t entry)
{
unsigned long bits = pte_val(entry)
(_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW | _PAGE_EXEC);
@@ -392,15 +387,6 @@ static inline void __ptep_set_access_fla
:r (bits), r (ptep), m (*ptep), i (_PAGE_BUSY)
:cc);
}
-#define ptep_set_access_flags(__vma, __address, __ptep, __entry,
__dirty) \
-({\
- int __changed = !pte_same(*(__ptep), __entry); \
- if (__changed) { \
- __ptep_set_access_flags(__ptep, __entry, __dirty); \
- flush_tlb_page_nohash(__vma, __address); \
- } \
- __changed; \
-})
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
