Re: device tree variations
Thanks. The fdt_del_node approach works pretty nicely. I added a dt_ops hook since fdt is static in libfdt-wrapper.c. .../... David says your patch is ok, However it's not in the right form. Could you repost it please with a proper changeset comment and signed-off-by: line ? Thanks ! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Support for relocatable kdump kernel
On Mon, 2008-10-20 at 15:04 +0530, Mohan Kumar M wrote:
Michael Ellerman wrote:
#ifdef CONFIG_CRASH_DUMP
+#ifdef CONFIG_RELOCATABLE
+
+static inline void reserve_kdump_trampoline(void) { ; }
+static inline void setup_kdump_trampoline(void) { ; }
+
+#else
extern void reserve_kdump_trampoline(void);
extern void setup_kdump_trampoline(void);
+#endif /* CONFIG_RELOCATABLE */
You've disabled the else case with your Kconfig changes, so you should
just rip all that code out.
I made Kconfig changes only to the 64 bit powerpc path and still the 32
bit powerpc code uses the legacy kdump code. So we need to retain some
of legacy kdump code.
Does it? I see CONFIG_CRASH_DUMP depending on PPC64, so there is no
32-bit kdump possible. Or is someone working on it out-of-tree?
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index e409338..5b12b10 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -97,6 +97,14 @@ __secondary_hold_spinloop:
__secondary_hold_acknowledge:
.llong 0x0
+ /* This flag is set only for kdump kernels so that */
+ /* it will be relocatable. Purgatory code user space kexec-tools */
+ /* sets this flag. Do not move this variable as purgatory code */
+ /* relies on the position of this variables */
+ .globl __kdump_flag
+__kdump_flag:
+ .llong 0x0
I guess the __ matches the other flags here, it's not the prettiest
though. For client code (like in iommu.c) it'd be nice to have static
inline, perhaps is_kdump_kernel() that hides this.
Do you expect a function to do the checking in iommu.c?
You'd use the function in iommu.c, but it should be defined in some
header.
#ifdef CONFIG_PPC_ISERIES
/*
* At offset 0x20, there is a pointer to iSeries LPAR data.
@@ -1384,8 +1392,13 @@ _STATIC(__after_prom_start)
/* process relocations for the final address of the kernel */
lis r25,[EMAIL PROTECTED] /* compute virtual base of kernel */
sldir25,r25,32
+#ifdef CONFIG_CRASH_DUMP
+ ld r7,__kdump_flag-_stext(r26)
+ cmpldi cr0,r7,1/* relocatable kernel ? */
You don't use the signature here?
kexec-tools check the signature and based on the signature it sets
__kdump_flag to 1 (or 0). So kernel code just checks whether its set or not.
OK. Does old purgatory ensure that the register is 0? Otherwise I think
it's possible that a new kernel could get confused by cruft left in that
register by an old purgatory - causing the 2nd kernel to think it's a
kdump kernel when it shouldn't be.
@@ -1401,9 +1414,21 @@ _STATIC(__after_prom_start)
beq 9f /* have already put us at zero */
li r6,0x100/* Start offset, the first 0x100 */
/* bytes were copied earlier.*/
-#ifdef CONFIG_RELOCATABLE
+
+#ifdef CONFIG_CRASH_DUMP
+/*
+ * Check if the kernel has to be running as relocatable kernel based on
the
+ * variable __kdump_flag, if it is set the kernel is treated as
relocatble
+ * kernel, otherwise it will be moved to PHYSICAL_START
+ */
+ ld r7,__kdump_flag-_stext(r26)
+ cmpldi cr0,r7,1
+ bne regular
+
li r5,__end_interrupts - _stext/* just copy interrupts */
-#else
+ b 5f
+regular:
+#endif
lis r5,(copy_to_here - _stext)@ha
addir5,r5,(copy_to_here - _stext)@l /* # bytes of memory to copy */
I'm jet lagged to hell, so I'm not sure I can trust my parsing of this.
But I think this definitely breaks CONFIG_RELOCATABLE without
CRASH_DUMP, and I'm not sure it's right otherwise.
Hmmm, I compiled and tried the kernel with 3 config option combinations:
1. CONFIG_RELOCATABLE and CONFIG_CRASH_DUMP 2. CONFIG_RELOCATABLE 3.
Without CONFIG_RELOCATABLE (without CONFIG_CRASH_DUMP)
All of the above 3 combinations worked. This patch relies on Pauls'
patch5 in the relocatable kernel patcheset.
OK if you've tested.
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] igb: add IGB_DCA instead of selecting INTEL_IOATDMA
Jeff Kirsher wrote: Add a bool IGB_DCA defined to y if IGB and DCA are enabled, but IGB isn't y while DCA=m. And thus remove the need to select INTEL_IOATDMA when IGB is enabled, so that non-x86 architectures can build the igb driver. Based on work/patch from Brice Goglin [EMAIL PROTECTED] Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: delete prom_strtoul and prom_memparse
On Mon, 2008-10-20 at 23:03 -0500, Milton Miller wrote: These functions should have been static, and inspection shows they are no longer used. (We used to parse mem= but we now defer that to early_param). Actually the last user was the crashkernel= handling, but that was removed a while ago too, my bad. Acked-by: Michael Ellerman [EMAIL PROTECTED] 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
Bug in genirq: record trigger type
On Mon, 2008-10-20 at 22:05 +, Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0c5d1eb77a8be917b638344a22afe1398236482b
Commit: 0c5d1eb77a8be917b638344a22afe1398236482b
Parent: d6d5aeb661fc14655c417f3582ae7ec52985d2a8
Author: David Brownell [EMAIL PROTECTED]
AuthorDate: Wed Oct 1 14:46:18 2008 -0700
Committer: Ingo Molnar [EMAIL PROTECTED]
CommitDate: Thu Oct 2 10:24:09 2008 +0200
This one is obviously broken and breaks booting on a whole bunch of
machines (including powermac's and thus my G5, it's never good when my
own machine breaks !).
Nice to see 3 SOB's and one Ack and nobody caught the obvious bug :-)
desc = irq_desc + irq;
- if (desc-chip-set_type) {
- spin_lock_irqsave(desc-lock, flags);
- ret = desc-chip-set_type(irq, type);
- spin_unlock_irqrestore(desc-lock, flags);
- }
+ if (type == IRQ_TYPE_NONE)
+ return 0;
+
+ spin_lock_irqsave(desc-lock, flags);
+ ret = __irq_set_trigger(desc, irq, flags);
type maybe ?
+ spin_unlock_irqrestore(desc-lock, flags);
return ret;
}
I have to run so no patch until tomorrow unless somebody beats me to it.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[REGRESSION 2.6.27] i2c-mpc not probing on linkstation (was Re: [PATCH] powerpc: enable heap randomization for linkstations)
On Mon, 20 Oct 2008, Jon Smirl wrote: On Mon, Oct 20, 2008 at 1:55 AM, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: On Sun, 19 Oct 2008, Jon Smirl wrote: Is i2c-mpc built into your kernel? It's not going to module auto-load because the names don't match - fsl-i2c and i2c-mpc. It is built into the kernel. Put a printk in it's init function to make sure it is initializing. I don't need that, I see it here: /sys/bus/of_platform/drivers/mpc-i2c Next thing I do is put printks over in arch/powerpc/.. to tell me which strings from the device tree are being looked for. You can also look in /proc/device_tree and make sure fsl-i2c is in there. When you find the problem is will probably be something simple like a mismatch between _ and -. I have been down this path before and spent a day figuring out why a module wouldn't load and it was a simple typo. Thanks, I know, that I can find the reason and, probably, a fix after a day of printk debugging. The thing is - I don't have this day, and I am sure there are people on this list, who can spot and fix the problem within minutes, that's why I posted it here after I realised, that 2 hours of me searching for the problem didn't bring any result. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] genirq: fix set_irq_type() when recording trigger type
* Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Mon, 2008-10-20 at 22:05 +, Linux Kernel Mailing List wrote: Gitweb: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0c5d1eb77a8be917b638344a22afe1398236482b Commit: 0c5d1eb77a8be917b638344a22afe1398236482b Parent: d6d5aeb661fc14655c417f3582ae7ec52985d2a8 Author: David Brownell [EMAIL PROTECTED] AuthorDate: Wed Oct 1 14:46:18 2008 -0700 Committer: Ingo Molnar [EMAIL PROTECTED] CommitDate: Thu Oct 2 10:24:09 2008 +0200 [...] Signed-off-by: David Brownell [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Acked-by: Thomas Gleixner [EMAIL PROTECTED] Signed-off-by: Ingo Molnar [EMAIL PROTECTED] This one is obviously broken and breaks booting on a whole bunch of machines (including powermac's and thus my G5, it's never good when my own machine breaks !). Nice to see 3 SOB's and one Ack and nobody caught the obvious bug :-) that patch came from -mm towards us shortly before the merge window. Once we had it integrated Chris Friesen reported a boot hang on a G5, and there's a fix pending for the bug, see it below. Will send it to Linus expressly. Fortunately only a minority of Linux users will ever run a box that uses set_irq_type() - but yes it needs to be fixed. Ingo -- From aac4ddd11a8d0e402ddc3fbc75204cb64efa0aac Mon Sep 17 00:00:00 2001 From: Chris Friesen [EMAIL PROTECTED] Date: Mon, 20 Oct 2008 12:41:58 -0600 Subject: [PATCH] genirq: fix set_irq_type() when recording trigger type In set_irq_type() we want to pass the type rather than the current interrupt state. Signed-off-by: Chris Friesen [EMAIL PROTECTED] Signed-off-by: Ingo Molnar [EMAIL PROTECTED] --- kernel/irq/chip.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index 4895fde..3de6ea3 100644 --- a/kernel/irq/chip.c +++ b/kernel/irq/chip.c @@ -127,7 +127,7 @@ int set_irq_type(unsigned int irq, unsigned int type) return 0; spin_lock_irqsave(desc-lock, flags); - ret = __irq_set_trigger(desc, irq, flags); + ret = __irq_set_trigger(desc, irq, type); spin_unlock_irqrestore(desc-lock, flags); return ret; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bug in genirq: record trigger type
* Yinghai Lu [EMAIL PROTECTED] wrote:
On Mon, Oct 20, 2008 at 11:32 PM, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Mon, 2008-10-20 at 22:05 +, Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0c5d1eb77a8be917b638344a22afe1398236482b
Commit: 0c5d1eb77a8be917b638344a22afe1398236482b
Parent: d6d5aeb661fc14655c417f3582ae7ec52985d2a8
Author: David Brownell [EMAIL PROTECTED]
AuthorDate: Wed Oct 1 14:46:18 2008 -0700
Committer: Ingo Molnar [EMAIL PROTECTED]
CommitDate: Thu Oct 2 10:24:09 2008 +0200
This one is obviously broken and breaks booting on a whole bunch of
machines (including powermac's and thus my G5, it's never good when my
own machine breaks !).
Nice to see 3 SOB's and one Ack and nobody caught the obvious bug :-)
desc = irq_desc + irq;
- if (desc-chip-set_type) {
- spin_lock_irqsave(desc-lock, flags);
- ret = desc-chip-set_type(irq, type);
- spin_unlock_irqrestore(desc-lock, flags);
- }
+ if (type == IRQ_TYPE_NONE)
+ return 0;
+
+ spin_lock_irqsave(desc-lock, flags);
+ ret = __irq_set_trigger(desc, irq, flags);
type maybe ?
+ spin_unlock_irqrestore(desc-lock, flags);
return ret;
}
I have to run so no patch until tomorrow unless somebody beats me to it.
there is patch about it, but somehow get lost.
should be all sorted now, the fix is below.
Ingo
--
From aac4ddd11a8d0e402ddc3fbc75204cb64efa0aac Mon Sep 17 00:00:00 2001
From: Chris Friesen [EMAIL PROTECTED]
Date: Mon, 20 Oct 2008 12:41:58 -0600
Subject: [PATCH] genirq: fix set_irq_type() when recording trigger type
In set_irq_type() we want to pass the type rather than the current
interrupt state.
Signed-off-by: Chris Friesen [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
kernel/irq/chip.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 4895fde..3de6ea3 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -127,7 +127,7 @@ int set_irq_type(unsigned int irq, unsigned int type)
return 0;
spin_lock_irqsave(desc-lock, flags);
- ret = __irq_set_trigger(desc, irq, flags);
+ ret = __irq_set_trigger(desc, irq, type);
spin_unlock_irqrestore(desc-lock, flags);
return ret;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bug in genirq: record trigger type
On Tue, 2008-10-21 at 09:28 +0200, Ingo Molnar wrote: From: Chris Friesen [EMAIL PROTECTED] Date: Mon, 20 Oct 2008 12:41:58 -0600 Subject: [PATCH] genirq: fix set_irq_type() when recording trigger type In set_irq_type() we want to pass the type rather than the current interrupt state. Signed-off-by: Chris Friesen [EMAIL PROTECTED] Signed-off-by: Ingo Molnar [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- kernel/irq/chip.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index 4895fde..3de6ea3 100644 --- a/kernel/irq/chip.c +++ b/kernel/irq/chip.c @@ -127,7 +127,7 @@ int set_irq_type(unsigned int irq, unsigned int type) return 0; spin_lock_irqsave(desc-lock, flags); - ret = __irq_set_trigger(desc, irq, flags); + ret = __irq_set_trigger(desc, irq, type); spin_unlock_irqrestore(desc-lock, flags); return ret; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bug in genirq: record trigger type
* Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2008-10-21 at 09:28 +0200, Ingo Molnar wrote: From: Chris Friesen [EMAIL PROTECTED] Date: Mon, 20 Oct 2008 12:41:58 -0600 Subject: [PATCH] genirq: fix set_irq_type() when recording trigger type In set_irq_type() we want to pass the type rather than the current interrupt state. Signed-off-by: Chris Friesen [EMAIL PROTECTED] Signed-off-by: Ingo Molnar [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] thx, added your ack to the commit as well. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH 0/5] patches for a network-based hvc backend (s390)
On Tue, Oct 21, 2008 at 10:23:37AM +1100, Benjamin Herrenschmidt wrote: What's the status with that patch serie ? Is this 2.6.28 material ? It is 2.6.28 material. Alan, are you ok with those ? Hendrik, have there been any respin other than v2 of patch 4/5 ? The other patches have not been changed. fyi: patch 1/5 (hangup notifier) applies successfully with an offset of 2 lines due to commit eef2622a9fcfa96407ea72c7c9cd20ad45e6 (hvc_console: Fix free_irq in spinlocked section). I can merge it via powerpc but it's getting late in the merge window... Thanks... that would be really great! Regards Hendrik -- Hendrik Brueckner D/3303 Linux on System z Development Tel: +49 7031 16-1073 Fax: +49 7031 16-3456 eMail: [EMAIL PROTECTED] IBM Deutschland Research Development GmbH, Schoenaicher Str. 220, 71032 Boeblingen IBM Deutschland Research Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Erich Baier Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull from powerpc.git next branch
Hi Linus ! This is the remaining powerpc bits for this merge window (minus -maybe- some kdump related stuff that Paul we'll see tomorrow, in any case, it's not in this batch). Nothing terribly fancy, mostly bug fixes, a few new embedded boards, some serious fixes to Cell SPU oprofile. A few things outside of arch/powerpc / drivers/of that should either have appropriate ack's or be powerpc specific drivers unless I screwed up. Cheers, Ben. The following changes since commit 2515ddc6db8eb49a79f0fe5e67ff09ac7c81eab4: Paul Mundt (1): binfmt_elf_fdpic: Update for cputime changes. are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git master Andre Detsch (2): powerpc/spufs: Improve search of node for contexts with SPU affinity powerpc/spufs: Explain conditional decrement of aff_sched_count Anton Vorontsov (3): powerpc: Remove device_type = board_control properties in .dts files powerpc/83xx: Add support for MCU microcontroller in .dts files powerpc/83xx: Add DS1339 RTC support for MPC8349E-mITX boards .dts Benjamin Herrenschmidt (4): Merge commit 'jwb/jwb-next' Merge commit 'gcl/gcl-next' Merge commit 'kumar/kumar-for-2.6.28' Merge commit 'origin' into master Carl Love (1): powerpc/oprofile: Fix mutex locking for cell spu-oprofile Ed Swarthout (1): powerpc/85xx: Fix mpc8536ds dma interrupt numbers Grant Likely (2): powerpc/52xx: Make cuImage more robust in locating immr node. powerpc: Add missing cuImage.initrd.% target Jason Jin (1): powerpc/85xx: Enable enhanced functions for 8536 TSEC Jeremy Kerr (6): powerpc/spufs: sputrace: Only enable logging on open(), prevent multiple openers powerpc/spufs: sputrace: Don't block until the read buffer is full powerpc/spufs: Use state_mutex for switch_log locking, and prevent multiple openers powerpc/spufs: Don't require full buffer in switch_log read powerpc/spufs: Don't spu_acquire_saved unnecessarily in regs read powerpc/spufs: Use kmalloc rather than kzalloc for switch log buffer Jon Smirl (1): of: Format string bug in drivers/of/of_i2c.c Jon Tollefson (1): powerpc/numa: Make memory reserve code more robust Josh Boyer (6): powerpc/40x: AMCC PowerPC 405EZ Acadia DTS powerpc/40x: Add AMCC PowerPC 405EZ to cputable powerpc/40x: Add PowerPC 40x simple platform support powerpc/40x: Add cuboot wrapper for Acadia board powerpc/40x: Add PowerPC 405EZ Acadia defconfig ibm_newemac: Fix new MAL feature handling Kumar Gala (3): powerpc: Fix build issue with CONFIG_RELOCATABLE=y powerpc: Remove Kconfig support for PPC_MERGE powerpc/85xx: Move mpc8572ds.dts to address-cells/size-cells = 2 Mike Ditto (1): powerpc: Fix boot wrapper memcmp() called with zero length argument Milton Miller (4): powerpc: Find and destroy possible stale kernel added properties powerpc: Use cpu_thread_in_core in smp_init for of_spin_map powerpc: Always trim numa memory to lmb_end_of_DRAM() powerpc: Delete unused prom_strtoul and prom_memparse Nathan Fontenot (1): powerpc/pseries: Validate PFN in pseries_remove_lmb() Niklaus Giger (1): powerpc/40x: Add support for Netstal HCU4 board Paul Mackerras (1): powerpc: Revert CHRP boot wrapper to real-base = 12MB on 32-bit Sebastian Siewior (1): powerpc/boot: Compare _start against ei.loadsize instead ei.memsize Steven A. Falco (1): powerpc/4xx: Add PowerPC 4xx GPIO driver Wolfgang Ocker (1): of/spi: Support specifying chip select as active high via device tree Wolfram Sang (3): powerpc/mpc5200: Don't touch pipelining for MPC5200B powerpc/mpc5200: Refactor FEC mdio read/write routines i2c-cpm: Suppress autoprobing for devices roel kluin (1): powerpc: Unsigned speed cannot be negative in udbg_16559.c Documentation/powerpc/booting-without-of.txt |2 + Documentation/powerpc/dts-bindings/fsl/board.txt |4 +- arch/powerpc/Kconfig |3 - arch/powerpc/boot/Makefile |7 +- arch/powerpc/boot/addnote.c | 41 +- arch/powerpc/boot/cuboot-52xx.c |4 + arch/powerpc/boot/cuboot-acadia.c| 174 arch/powerpc/boot/dts/acadia.dts | 224 ++ arch/powerpc/boot/dts/hcu4.dts | 168 arch/powerpc/boot/dts/mpc8315erdb.dts|8 + arch/powerpc/boot/dts/mpc832x_mds.dts|2 +- arch/powerpc/boot/dts/mpc8349emitx.dts | 16 + arch/powerpc/boot/dts/mpc8349emitxgp.dts |8 + arch/powerpc/boot/dts/mpc834x_mds.dts|2 +- arch/powerpc/boot/dts/mpc836x_mds.dts|2 +- arch/powerpc/boot/dts/mpc8377_rdb.dts|8 + arch/powerpc/boot/dts/mpc8378_rdb.dts|8 +
Re: Bug in genirq: record trigger type
On Monday 20 October 2008, Benjamin Herrenschmidt wrote: This one is obviously broken and breaks booting on a whole bunch of machines (including powermac's and thus my G5, it's never good when my own machine breaks !). Nice to see 3 SOB's and one Ack and nobody caught the obvious bug :-) As you saw, that one's fixed. Chris' patch unfortunately didn't get integrated right away. I'm a bit more curious about another potential issue though ... as described in the patch comment: - Make set_irq_type() usage match request_irq() usage: * IRQ_TYPE_NONE should be a NOP; succeed, so irq_chip methods won't have to handle that case any more (many do it wrong). It might be a bit more accurate to say irq_chip.set_type() methods are *inconsistent* in handling IRQ_TYPE_NONE. Previously the set_irq_type() method would pass that down to irq_chip code. I had observed two behaviors, but I thought I observed a third one in some of the PowerPC code: (1) ignore it ... matching request_irq() usage (2) return an error ... nasty (3) assign some irq_chip-specific trigger mode That third behavior might cause a bit of trouble, but I think it was only used during platform init. Someone more attuned to PowerPC might want to check ... - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: build failure on powerpc with current -git
Hi Paulus, On Tue, 21 Oct 2008 16:33:10 +1100 Paul Mackerras [EMAIL PROTECTED] wrote: It's a bug in older versions of ld (including 2.16.1) that's fixed in the current version (2.18). However, this patch appears to work around the problem - at least, it let me build a 32-bit kernel with a cross-toolchain including a 2.16.1 ld. Let me know if this gets it working for you. With that patch applied I got these errors for a powerpc ppc64_defconfig build (linux-next). /usr/bin/objcopy: Warning: '/dev/null' is not an ordinary file make[2]: *** [arch/powerpc/boot/zImage.pmac] Error 1 make[2]: *** Waiting for unfinished jobs /usr/bin/objcopy: Warning: '/dev/null' is not an ordinary file make[2]: *** [arch/powerpc/boot/zImage.pseries] Error 1 -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpfcEtTU2z6E.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bug in genirq: record trigger type
On Tue, 2008-10-21 at 01:01 -0700, David Brownell wrote: I'm a bit more curious about another potential issue though ... as described in the patch comment: - Make set_irq_type() usage match request_irq() usage: * IRQ_TYPE_NONE should be a NOP; succeed, so irq_chip methods won't have to handle that case any more (many do it wrong). It might be a bit more accurate to say irq_chip.set_type() methods are *inconsistent* in handling IRQ_TYPE_NONE. Previously the set_irq_type() method would pass that down to irq_chip code. I had observed two behaviors, but I thought I observed a third one in some of the PowerPC code: (1) ignore it ... matching request_irq() usage (2) return an error ... nasty (3) assign some irq_chip-specific trigger mode That third behavior might cause a bit of trouble, but I think it was only used during platform init. Someone more attuned to PowerPC might want to check ... Ok, I wrote a lot of the port of powerpc stuff to genirq so I supposed I'm the person to do that sweep :-) I'll have a look tomorrow. Thanks for the heads up, Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Bug in genirq: record trigger type
On Mon, Oct 20, 2008 at 11:32 PM, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Mon, 2008-10-20 at 22:05 +, Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0c5d1eb77a8be917b638344a22afe1398236482b
Commit: 0c5d1eb77a8be917b638344a22afe1398236482b
Parent: d6d5aeb661fc14655c417f3582ae7ec52985d2a8
Author: David Brownell [EMAIL PROTECTED]
AuthorDate: Wed Oct 1 14:46:18 2008 -0700
Committer: Ingo Molnar [EMAIL PROTECTED]
CommitDate: Thu Oct 2 10:24:09 2008 +0200
This one is obviously broken and breaks booting on a whole bunch of
machines (including powermac's and thus my G5, it's never good when my
own machine breaks !).
Nice to see 3 SOB's and one Ack and nobody caught the obvious bug :-)
desc = irq_desc + irq;
- if (desc-chip-set_type) {
- spin_lock_irqsave(desc-lock, flags);
- ret = desc-chip-set_type(irq, type);
- spin_unlock_irqrestore(desc-lock, flags);
- }
+ if (type == IRQ_TYPE_NONE)
+ return 0;
+
+ spin_lock_irqsave(desc-lock, flags);
+ ret = __irq_set_trigger(desc, irq, flags);
type maybe ?
+ spin_unlock_irqrestore(desc-lock, flags);
return ret;
}
I have to run so no patch until tomorrow unless somebody beats me to it.
there is patch about it, but somehow get lost.
YH
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mmc spi bindings
On Mon, Oct 20, 2008 at 08:44:30PM -0400, Jon Smirl wrote: Anton, is your mmc_spi driver (of_mmc_spi.c) going in any time soon? Let's hope in 2.6.29. The 2.6.28 merge window is about to close. :-/ I've been running it in my local tree for several months. Ditto. ;-) -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/35] x86: clean up speedctep-centrino and reduce cpumask_t usage
Stephen Rothwell wrote: Hi Mike, Just a first small thing: On Mon, 20 Oct 2008 10:03:20 -0700 Mike Travis [EMAIL PROTECTED] wrote: 1) The #ifdef CONFIG_HOTPLUG_CPU seems unnecessary these days. 2) The loop can simply skip over offline cpus, rather than creating a tmp mask. 3) set_mask is set to either a single cpu or all online cpus in a policy. Since it's just used for set_cpus_allowed(), any offline cpus in a policy don't matter, so we can just use cpumask_of_cpu() or the policy-cpus. From: Rusty Russell [EMAIL PROTECTED] Signed-off-by: Rusty Russell [EMAIL PROTECTED] Signed-off-by: Mike Travis [EMAIL PROTECTED] The From: line should be the first nonempty line in the mail to get the attribution correct. Ahh, ok, thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 18/35] cpumask: add nr_cpumask_bits
On Tuesday 21 October 2008 04:03:37 Mike Travis wrote: When nr_cpu_ids is set to CONFIG_NR_CPUS then references to nr_cpu_ids will return the maximum index of the configured NR_CPUS (+1) instead of the maximum index of the possible number of cpus (+1). This results in extra unused memory being allocated by functions that are setting up arrays of structs to keep track of per cpu items. 1) I like the name in this context: it's a beacon of sanity after NR_CPUS and nr_cpu_ids. But it's not so clearly a win when general code uses it: if (cpumask_first(mymask) == nr_cpumask_bits) ... vs: if (cpumask_first(mymask) == nr_cpu_ids) ... 2) This breaks anyone who tests that the iterators etc. return == nr_cpu_ids. One of the other patches tried to change them from NR_CPUS to nr_cpu_ids, that should now be revisited reaudited. 3) Noone should be naively allocating * nr_cpu_ids arrays, they should be using per-cpu pointers. Not doing so wastes memory on non-contiguous processor systems. 4) It should be a constant not be dependent on CONFIG_CPUMASK_OFFSTACK, but rather as it was on NR_CPUS BITS_PER_LONG. I think that's the sweet spot, and should also make your 2MB gain vanish. That's why I suggested a max_possible_cpu() function, and using that for those who really want to do allocations, who should be audited anyway, see (3). I don't want it as prominent as nr_cpu_ids, which is usually the Right Thing, and always safe. Cheers, Rusty. PS. I have part of a patch for this... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 18/35] cpumask: add nr_cpumask_bits
Rusty Russell wrote: On Tuesday 21 October 2008 04:03:37 Mike Travis wrote: When nr_cpu_ids is set to CONFIG_NR_CPUS then references to nr_cpu_ids will return the maximum index of the configured NR_CPUS (+1) instead of the maximum index of the possible number of cpus (+1). This results in extra unused memory being allocated by functions that are setting up arrays of structs to keep track of per cpu items. 1) I like the name in this context: it's a beacon of sanity after NR_CPUS and nr_cpu_ids. But it's not so clearly a win when general code uses it: if (cpumask_first(mymask) == nr_cpumask_bits) ... vs: if (cpumask_first(mymask) == nr_cpu_ids) ... I think the correct use for iterators would be: if (cpumask_first(mymask) = nr_cpu_ids) ... since nr_cpu_ids is guaranteed to be = nr_cpumask_bits. And nr_cpumask_bits is not really meant to be used anywhere except in the bit operations supporting the cpumask_* operators. 2) This breaks anyone who tests that the iterators etc. return == nr_cpu_ids. I think that's broken anyways... ;-) One of the other patches tried to change them from NR_CPUS to nr_cpu_ids, that should now be revisited reaudited. The change from NR_CPUS to nr_cpu_ids is ok, but it should also be changed from: (x == NR_CPUS) to: (x = nr_cpu_ids) 3) Noone should be naively allocating * nr_cpu_ids arrays, they should be using per-cpu pointers. Not doing so wastes memory on non-contiguous processor systems. The problem often arises where an array is allocated that will use the cpu as an index into the array. They can be changed eventually to use a percpu pointer, but in the interim keeping nr_cpu_ids intact maintains compatibility without allocating unused memory. 4) It should be a constant not be dependent on CONFIG_CPUMASK_OFFSTACK, but rather as it was on NR_CPUS BITS_PER_LONG. I think that's the sweet spot, and should also make your 2MB gain vanish. I'll run the test again but most likely the result will be an extra 1Mb of unused memory instead. ;-) One other note, that test compile used the default config [and NR_CPUS=128] which turns off a lot of functions. A typical distro config will have many more options turned on. And the beauty of using a separate flag to enable variable length cpumasks, is there may be cases where an arch or specific system config wants a multiple word cpumask on the stack for performance reasons (like cache or node locality, avoidance of the kmalloc's, etc.) That's why I suggested a max_possible_cpu() function, and using that for those who really want to do allocations, who should be audited anyway, see (3). I don't want it as prominent as nr_cpu_ids, which is usually the Right Thing, and always safe. We could change all refs from nr_cpu_ids to max_possible_cpu but wouldn't we still be leaving a window open where it could be incorrectly used? So far all the cpumask conversions allow for mixed-use cpumask (i.e., cpumask_t and struct cpumask *) by maintaining backwards compatility, until everything is eventually sorted out. Keeping nr_cpu_ids representing the same value maintains this compatibility bridge. The most correct way would be to use the (not yet implemented) zero based PERCPU allocator. Slightly less efficient would be to allocate node local memory for each struct, in a loop using a per cpu pointer and for_each_possible_cpu(). Cheers, Rusty. PS. I have part of a patch for this... But as I've said, it's not critical to the new functionality... Thanks! Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: find and destroy possible stale kernel added properties
Milton Miller wrote: + /* remove any stale propertys so ours can be found */ s/propertys/properties ? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC/PATCH] pci: Workaround invalid P2P bridge bus numbers
Benjamin Herrenschmidt wrote: Ayman, can you double check that this variant of the patch still fixes your problem ? Thanks ! I've tried it out and it is working correctly with my devices. The subordinate bus numbers on all the ports are correct. Best Regards, Ayman ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for-2.6.28' branch
On Tue, Oct 21, 2008 at 12:47:37AM +0400, Anton Vorontsov wrote: On Mon, Oct 20, 2008 at 02:32:21PM -0500, Kumar Gala wrote: On Oct 20, 2008, at 2:17 PM, Anton Vorontsov wrote: Hi Kumar, On Mon, Oct 20, 2008 at 01:04:36PM -0500, Kumar Gala wrote: Please pull from 'for-2.6.28' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.28 Could you tell the status of this patch? [1/4] powerpc/QE: implement QE Pin Multiplexing API http://patchwork.ozlabs.org/patch/4897/ I reposted it several times (w/o changes), received no comments. If it's ok, could you merge it for 2.6.28? Sorry, I was thinking this patch required an OF interface change getting accepted... is that true? Benjamin merged the OF patch, it's in the Linus' tree already. Maybe I was unclear... The OF interface change was accepted, so the QE pinmux patch doesn't depend on anything.. Thus, can we please merge the patch? It is needed for the FHCI USB driver, which I still hope could get in into the 2.6.28-rc2, since it is self-sufficient new feature that can't break anything. Thanks and sorry for the annoyance, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for-2.6.28' branch
On Oct 21, 2008, at 9:41 AM, Anton Vorontsov wrote: Maybe I was unclear... The OF interface change was accepted, so the QE pinmux patch doesn't depend on anything.. Thus, can we please merge the patch? It is needed for the FHCI USB driver, which I still hope could get in into the 2.6.28-rc2, since it is self-sufficient new feature that can't break anything. Thanks and sorry for the annoyance, I understood, just haven't had time to look at these patches. I don't know if this is likely to make it into 2.6.28. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enable heap randomization for linkstations
On Mon, Oct 20, 2008 at 12:28:09AM +0200, Guennadi Liakhovetski wrote:
On Sun, 19 Oct 2008, Jon Smirl wrote:
That should match:
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
compatible = fsl-i2c;
reg = 0x80003000 0x1000;
interrupts = 5 2;
interrupt-parent = mpic;
[EMAIL PROTECTED] {
device_type = rtc;
compatible = ricoh,rs5c372a;
reg = 0x32;
};
};
It should, but it doesn't.
Is the parent of the i2c node covered by the list passed to
of_platform_bus_probe() on this board?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enable heap randomization for linkstations
On Tue, 21 Oct 2008, Scott Wood wrote:
On Mon, Oct 20, 2008 at 12:28:09AM +0200, Guennadi Liakhovetski wrote:
On Sun, 19 Oct 2008, Jon Smirl wrote:
That should match:
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
compatible = fsl-i2c;
reg = 0x80003000 0x1000;
interrupts = 5 2;
interrupt-parent = mpic;
[EMAIL PROTECTED] {
device_type = rtc;
compatible = ricoh,rs5c372a;
reg = 0x32;
};
};
It should, but it doesn't.
Is the parent of the i2c node covered by the list passed to
of_platform_bus_probe() on this board?
You mean something like this:
static __initdata struct of_device_id storcenter_of_bus[] = {
{ .name = soc, },
{},
};
static int __init storcenter_device_probe(void)
{
of_platform_bus_probe(NULL, storcenter_of_bus, NULL);
return 0;
}
machine_device_initcall(storcenter, storcenter_device_probe);
? No, linkstation doesn't do that. Somehow, as this API has been
introduced, linkstation has been left aside:-(
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enable heap randomization for linkstations
Guennadi Liakhovetski wrote:
static __initdata struct of_device_id storcenter_of_bus[] = {
{ .name = soc, },
{},
};
Add .compatible = simple-bus to the list.
static int __init storcenter_device_probe(void)
{
of_platform_bus_probe(NULL, storcenter_of_bus, NULL);
return 0;
}
machine_device_initcall(storcenter, storcenter_device_probe);
? No, linkstation doesn't do that. Somehow, as this API has been
introduced, linkstation has been left aside:-(
This is almost as much of a FAQ as interrupt mapping... I'm wondering
if we should have stuck with a default list, and added a call to
of_platform_bus_probe by common code that could be overridden by some
board flag if really necessary, rather than have a bunch of
duplication-with-mutation in the platform files.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for-2.6.28' branch
On Tue, Oct 21, 2008 at 9:49 AM, Kumar Gala [EMAIL PROTECTED] wrote: I understood, just haven't had time to look at these patches. I don't know if this is likely to make it into 2.6.28. I ack'd the QE library portions of these patches back in April. Sure, a lot has changed since then, but what's the point of having a merge window if you don't actually merge the code? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel Oops when run ifconfig on MPC8360MDS board
Enable the debug flag on ucc_geth.c: there is the dmesg: ucc_geth_open: IN ucc_geth_startup: IN Machine check in kernel mode. Caused by (from SRR1=49030): Transfer error ack signal Oops: machine check, sig: 7 NIP: C0126910 XER: 2000 LR: C01268D0 SP: CFD0DD80 REGS: cfd0dcd0 TRAP: 0200Not tainted MSR: 00049030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = cfd0c000[398] 'ifconfig' Last syscall: 54 last math cfd0c000 last altivec GPR00: CFD0DD80 CFD0C000 1032 CC10E000 C0247264 C04D1F74 GPR08: BA2E8BA3 D110 C01EE55C 4808 100235F8 GPR16: 1002 1002 9032 CFD0DE78 GPR24: 8914 C000 C01D CFD0DDB8 D100 C0586D20 C0269C20 Call backtrace: C0126890 C00D59D0 C00D761C C012F400 C0130DD4 C01746B4 C017712C C0127770 C004D8B0 C0005ABC 10001214 100023C4 0FEC4E00 On Tue, Oct 21, 2008 at 12:26 AM, mike zheng [EMAIL PROTECTED] wrote: Oh, I forgot to metion just now. The linux is based on a custom built kernel 2.4.22, not from Freescale. On 10/20/08, mike zheng [EMAIL PROTECTED] wrote: On 10/20/08, Kim Phillips [EMAIL PROTECTED] wrote: On Mon, 20 Oct 2008 15:00:33 -0700 mike zheng [EMAIL PROTECTED] wrote: I have following kernel Oops when I run ifconfig to setup the UEC0 of MPC8360MDS board. There is no hardware problem, the UEC0 runs well under Uboot. does this occur on vanilla u-boot and kernel versions? if so, which ones, and on what board revision? The kernel Oops happened under Linux when I try to use ifconfig to setup the eth0. Under Uboot, the UEC0 works fine. I am able to do ping, tftp via the ethernet port. Call backtrace: C0126890 C00D59D0 C00D761C C012F400 C0130DD4 C01746B4 C017712C C0127770 C004D8B0 C0005ABC 10001214 100023C4 0FEC4E00 might want to turn on verbose debugging while you're at it. Which flag shall I turned on? I am not formaliar to the network driver. Thanks! Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for-2.6.28' branch
On Oct 21, 2008, at 10:35 AM, Timur Tabi wrote: On Tue, Oct 21, 2008 at 9:49 AM, Kumar Gala [EMAIL PROTECTED] wrote: I understood, just haven't had time to look at these patches. I don't know if this is likely to make it into 2.6.28. I ack'd the QE library portions of these patches back in April. Sure, a lot has changed since then, but what's the point of having a merge window if you don't actually merge the code? The point is to attempt to get code merged. There is only so much a maintainer can do during or before the window. The fact that Ben had issues with the OF patch caused me to ignore this change until that got resolved. Since that was resolved close to the merge window this particular set of patches suffered. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Support for relocatable kdump kernel
Michael Ellerman wrote: Does it? I see CONFIG_CRASH_DUMP depending on PPC64, so there is no 32-bit kdump possible. Or is someone working on it out-of-tree? IIUC Anton Vorontsov is working on the 32-bit kdump kernel support. Do you expect a function to do the checking in iommu.c? You'd use the function in iommu.c, but it should be defined in some header. Yeah, I will do that. OK. Does old purgatory ensure that the register is 0? Otherwise I think it's possible that a new kernel could get confused by cruft left in that register by an old purgatory - causing the 2nd kernel to think it's a kdump kernel when it shouldn't be. __kdump_flag is by default is 0 and old purgatory code even won't know that it need to modify __kdump_flag. So unless __kdump_flag is 1, the kernel will behave as a normal one. Regards, Mohan. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/83xx: add DS1339 RTC support for MPC8349E-mITX boards
On Fri, Oct 17, 2008 at 10:56:59PM +0400, Anton Vorontsov wrote:
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5cedf37..7fc5414 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -83,6 +83,14 @@
interrupts = 15 0x8;
interrupt-parent = ipic;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ device_type = rtc;
+ compatible = dallas,ds1339;
+ reg = 0x68;
+ interrupts = 18 0x8;
+ interrupt-parent = ipic;
+ };
Why are we adding more device_types?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/83xx: add DS1339 RTC support for MPC8349E-mITX boards
On Oct 21, 2008, at 1:23 PM, Scott Wood wrote:
On Fri, Oct 17, 2008 at 10:56:59PM +0400, Anton Vorontsov wrote:
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/
boot/dts/mpc8349emitx.dts
index 5cedf37..7fc5414 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -83,6 +83,14 @@
interrupts = 15 0x8;
interrupt-parent = ipic;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ device_type = rtc;
+ compatible = dallas,ds1339;
+ reg = 0x68;
+ interrupts = 18 0x8;
+ interrupt-parent = ipic;
+ };
Why are we adding more device_types?
I think the 'rtc' device_type is legacy from OF.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/83xx: add DS1339 RTC support for MPC8349E-mITX boards
Kumar Gala wrote: On Oct 21, 2008, at 1:23 PM, Scott Wood wrote: Why are we adding more device_types? I think the 'rtc' device_type is legacy from OF. Yes, and it advertises a run-time service that we do not and cannot support. We should not have it in flat trees. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/83xx: add DS1339 RTC support for MPC8349E-mITX boards
On Tue, Oct 21, 2008 at 01:23:44PM -0500, Scott Wood wrote:
On Fri, Oct 17, 2008 at 10:56:59PM +0400, Anton Vorontsov wrote:
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5cedf37..7fc5414 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -83,6 +83,14 @@
interrupts = 15 0x8;
interrupt-parent = ipic;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ device_type = rtc;
+ compatible = dallas,ds1339;
+ reg = 0x68;
+ interrupts = 18 0x8;
+ interrupt-parent = ipic;
+ };
Why are we adding more device_types?
It seems that CHRP is using the device_type for rtc devices, which
means that real OF also provide it. But I guess we don't need it,
right? Then we should cleanup all the boards.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Remove device_type = rtc properties in .dts files
We don't want to encourage the device_type usage. It isn't used in the
code, so we can simply remove it from the dts files.
Suggested-by: Scott Wood [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/kuroboxHD.dts |1 -
arch/powerpc/boot/dts/kuroboxHG.dts |1 -
arch/powerpc/boot/dts/lite5200.dts |1 -
arch/powerpc/boot/dts/lite5200b.dts |1 -
arch/powerpc/boot/dts/motionpro.dts |1 -
arch/powerpc/boot/dts/mpc8315erdb.dts|1 -
arch/powerpc/boot/dts/mpc8349emitx.dts |1 -
arch/powerpc/boot/dts/mpc8349emitxgp.dts |1 -
arch/powerpc/boot/dts/mpc8377_rdb.dts|1 -
arch/powerpc/boot/dts/mpc8378_rdb.dts|1 -
arch/powerpc/boot/dts/mpc8379_rdb.dts|1 -
arch/powerpc/boot/dts/pcm030.dts |2 --
arch/powerpc/boot/dts/tqm5200.dts|1 -
13 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/boot/dts/kuroboxHD.dts
b/arch/powerpc/boot/dts/kuroboxHD.dts
index 2e5a1a1..8d725d1 100644
--- a/arch/powerpc/boot/dts/kuroboxHD.dts
+++ b/arch/powerpc/boot/dts/kuroboxHD.dts
@@ -76,7 +76,6 @@ add flash parts, rtc, ??
interrupt-parent = mpic;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = ricoh,rs5c372a;
reg = 0x32;
};
diff --git a/arch/powerpc/boot/dts/kuroboxHG.dts
b/arch/powerpc/boot/dts/kuroboxHG.dts
index e4916e6..b13a11e 100644
--- a/arch/powerpc/boot/dts/kuroboxHG.dts
+++ b/arch/powerpc/boot/dts/kuroboxHG.dts
@@ -76,7 +76,6 @@ add flash parts, rtc, ??
interrupt-parent = mpic;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = ricoh,rs5c372a;
reg = 0x32;
};
diff --git a/arch/powerpc/boot/dts/lite5200.dts
b/arch/powerpc/boot/dts/lite5200.dts
index 2cf9a87..3f7a5dc 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -130,7 +130,6 @@
[EMAIL PROTECTED] { // Real time clock
compatible = fsl,mpc5200-rtc;
- device_type = rtc;
reg = 0x800 0x100;
interrupts = 1 5 0 1 6 0;
interrupt-parent = mpc5200_pic;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts
b/arch/powerpc/boot/dts/lite5200b.dts
index 7bd5b9c..63e3bb4 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -130,7 +130,6 @@
[EMAIL PROTECTED] { // Real time clock
compatible = fsl,mpc5200b-rtc,fsl,mpc5200-rtc;
- device_type = rtc;
reg = 0x800 0x100;
interrupts = 1 5 0 1 6 0;
interrupt-parent = mpc5200_pic;
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 9e3c921..52ba6f9 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -248,7 +248,6 @@
fsl5200-clocking;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = dallas,ds1339;
reg = 0x68;
};
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index 6b85067..d3d3097 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -117,7 +117,6 @@
interrupt-parent = ipic;
dfsrr;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = dallas,ds1339;
reg = 0x68;
};
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 2c9d54a..d86c6a3 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -85,7 +85,6 @@
dfsrr;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = dallas,ds1339;
reg = 0x68;
interrupts = 18 0x8;
diff --git a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
index fa40647..fd4bbc4 100644
--- a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
@@ -83,7 +83,6 @@
dfsrr;
[EMAIL PROTECTED] {
- device_type = rtc;
Re: [PATCH] powerpc: Remove device_type = rtc properties in .dts files
2008/10/21 Anton Vorontsov [EMAIL PROTECTED]:
We don't want to encourage the device_type usage. It isn't used in the
code, so we can simply remove it from the dts files.
Suggested-by: Scott Wood [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/kuroboxHD.dts |1 -
arch/powerpc/boot/dts/kuroboxHG.dts |1 -
arch/powerpc/boot/dts/lite5200.dts |1 -
arch/powerpc/boot/dts/lite5200b.dts |1 -
arch/powerpc/boot/dts/motionpro.dts |1 -
arch/powerpc/boot/dts/mpc8315erdb.dts|1 -
arch/powerpc/boot/dts/mpc8349emitx.dts |1 -
arch/powerpc/boot/dts/mpc8349emitxgp.dts |1 -
arch/powerpc/boot/dts/mpc8377_rdb.dts|1 -
arch/powerpc/boot/dts/mpc8378_rdb.dts|1 -
arch/powerpc/boot/dts/mpc8379_rdb.dts|1 -
arch/powerpc/boot/dts/pcm030.dts |2 --
arch/powerpc/boot/dts/tqm5200.dts|1 -
13 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/boot/dts/kuroboxHD.dts
b/arch/powerpc/boot/dts/kuroboxHD.dts
index 2e5a1a1..8d725d1 100644
--- a/arch/powerpc/boot/dts/kuroboxHD.dts
+++ b/arch/powerpc/boot/dts/kuroboxHD.dts
@@ -76,7 +76,6 @@ add flash parts, rtc, ??
interrupt-parent = mpic;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = ricoh,rs5c372a;
reg = 0x32;
};
diff --git a/arch/powerpc/boot/dts/kuroboxHG.dts
b/arch/powerpc/boot/dts/kuroboxHG.dts
index e4916e6..b13a11e 100644
--- a/arch/powerpc/boot/dts/kuroboxHG.dts
+++ b/arch/powerpc/boot/dts/kuroboxHG.dts
@@ -76,7 +76,6 @@ add flash parts, rtc, ??
interrupt-parent = mpic;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = ricoh,rs5c372a;
reg = 0x32;
};
diff --git a/arch/powerpc/boot/dts/lite5200.dts
b/arch/powerpc/boot/dts/lite5200.dts
index 2cf9a87..3f7a5dc 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -130,7 +130,6 @@
[EMAIL PROTECTED] { // Real time clock
compatible = fsl,mpc5200-rtc;
- device_type = rtc;
reg = 0x800 0x100;
interrupts = 1 5 0 1 6 0;
interrupt-parent = mpc5200_pic;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts
b/arch/powerpc/boot/dts/lite5200b.dts
index 7bd5b9c..63e3bb4 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -130,7 +130,6 @@
[EMAIL PROTECTED] { // Real time clock
compatible = fsl,mpc5200b-rtc,fsl,mpc5200-rtc;
- device_type = rtc;
reg = 0x800 0x100;
interrupts = 1 5 0 1 6 0;
interrupt-parent = mpc5200_pic;
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 9e3c921..52ba6f9 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -248,7 +248,6 @@
fsl5200-clocking;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = dallas,ds1339;
reg = 0x68;
};
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index 6b85067..d3d3097 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -117,7 +117,6 @@
interrupt-parent = ipic;
dfsrr;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = dallas,ds1339;
reg = 0x68;
};
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 2c9d54a..d86c6a3 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -85,7 +85,6 @@
dfsrr;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = dallas,ds1339;
reg = 0x68;
interrupts = 18 0x8;
diff --git a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
index fa40647..fd4bbc4 100644
--- a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
@@
Re: [1/1] powerpc: Update page in counter for CMM
Milton Miller wrote:
X-Patchwork-Id: 5144
diff -puN arch/powerpc/mm/fault.c~powerpc_vrm_mm_pressure
arch/powerpc/mm/fault.c
--- linux-2.6/arch/powerpc/mm/fault.c~powerpc_vrm_mm_pressure
2008-10-20 17:13:25.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/mm/fault.c2008-10-20
17:13:25.0 -0500
..
@@ -318,9 +320,11 @@ good_area:
goto do_sigbus;
BUG();
}
-if (ret VM_FAULT_MAJOR)
+if (ret VM_FAULT_MAJOR) {
current-maj_flt++;
-else
+if (firmware_has_feature(FW_FEATURE_CMO))
+atomic_inc((atomic_t *)((get_lppaca()-page_ins)));
+} else
current-min_flt++;
up_read(mm-mmap_sem);
return 0;
(1) why do we need atomic_inc and the hundreds or thousands of cycles to
do the atomic inc in a per-cpu area?
We don't. I've now removed it.
(2) assuming we make this a normal increment, should we keep the
feature test or just do it unconditionally (ie is the additional load
and branch worse that just doing the load and store of the counter --
the address was previously reserved, right? (no question if
it has to be atomic).
Simplified patch on the way...
Ramble things one might consider
Ben asked if we need to worry about the hypervisor clearing the
count. If they treat it as a only-incrementing then we don't need
to worry. And since its only an indicator, then we may not care
about a big count by them interrupting between the load and store
This is a read only field from the hypervisor's perspective. They
shouldn't be clearing it.
If we are worried about linux preemption, then we need to disable
it to avoid crossing cpu variables or getting to this point multiple
times. (I have not looked at the context to see if we are already
disabled).
Looks to me like linux preemption is a possibility in this code, so
I've added the code to disable preemption around the increment.
-Brian
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2 1/1] powerpc: Update page in counter for CMM
A new field has been added to the VPA as a method for
the client OS to communicate to firmware the number of
page ins it is performing when running collaborative
memory overcommit. The hypervisor will use this information
to better determine if a partition is experiencing memory
pressure and needs more memory allocated to it.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
arch/powerpc/include/asm/lppaca.h |3 ++-
arch/powerpc/kernel/paca.c|1 +
arch/powerpc/mm/fault.c |7 +--
3 files changed, 8 insertions(+), 3 deletions(-)
diff -puN arch/powerpc/mm/fault.c~powerpc_vrm_mm_pressure
arch/powerpc/mm/fault.c
--- linux-2.6/arch/powerpc/mm/fault.c~powerpc_vrm_mm_pressure 2008-10-20
17:13:25.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/mm/fault.c 2008-10-21 14:52:24.0
-0500
@@ -318,9 +318,12 @@ good_area:
goto do_sigbus;
BUG();
}
- if (ret VM_FAULT_MAJOR)
+ if (ret VM_FAULT_MAJOR) {
current-maj_flt++;
- else
+ preempt_disable();
+ get_lppaca()-page_ins++;
+ preempt_enable();
+ } else
current-min_flt++;
up_read(mm-mmap_sem);
return 0;
diff -puN arch/powerpc/include/asm/lppaca.h~powerpc_vrm_mm_pressure
arch/powerpc/include/asm/lppaca.h
--- linux-2.6/arch/powerpc/include/asm/lppaca.h~powerpc_vrm_mm_pressure
2008-10-20 17:13:25.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/include/asm/lppaca.h 2008-10-21
13:46:45.0 -0500
@@ -133,7 +133,8 @@ struct lppaca {
//=
// CACHE_LINE_4-5 0x0180 - 0x027F Contains PMC interrupt data
//=
- u8 pmc_save_area[256]; // PMC interrupt Area x00-xFF
+ u32 page_ins; // CMO Hint - # page ins by OS
x00-x04
+ u8 pmc_save_area[252]; // PMC interrupt Area x04-xFF
} __attribute__((__aligned__(0x400)));
extern struct lppaca lppaca[];
diff -puN arch/powerpc/kernel/paca.c~powerpc_vrm_mm_pressure
arch/powerpc/kernel/paca.c
--- linux-2.6/arch/powerpc/kernel/paca.c~powerpc_vrm_mm_pressure
2008-10-20 17:13:25.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/kernel/paca.c2008-10-20
17:13:25.0 -0500
@@ -37,6 +37,7 @@ struct lppaca lppaca[] = {
.end_of_quantum = 0xul,
.slb_count = 64,
.vmxregs_in_use = 0,
+ .page_ins = 0,
},
};
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hugetlbfs for ppc440 - kernel BUG
On Tue, 2007-07-10 at 13:38 -0500, Satya wrote: hello, I am trying to implement hugetlbfs on the IBM Bluegene/L IO node (ppc440) and I have a big problem as well as a few questions to ask the group. I patched a 2.6.21.6 linux kernel (manually) with Edi Shmueli's hugetlbfs implementation (found here: http://patchwork.ozlabs.org/linuxppc/patch?id=8427) for this. I did have to make slight changes (described at the end) to make it work. My test program is a shortened version of a sys v shared memory example described in Documentation/vm/hugetlbpage.txt Hi ! The patchwork link unfortunately didn't survive the transition to patchwork 2. Do you know what's the status of Hugetlb support for 44x ? Is there any plan to release that for upstream inclusion ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add del_node function to allow early boot code to prune inapplicable devices.
Reposting in proper format...
Some platforms have variants that can share most of a flat device tree but need
a few devices selectively pruned at boot time. This adds del_node() to ops.h
to allow access to the existing fdt_del_node().
Signed-off-by: Mike Ditto [EMAIL PROTECTED]
---
Index: arch/powerpc/boot/ops.h
===
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ops.h
--- arch/powerpc/boot/ops.h 11 Oct 2008 02:51:35 - 1.1.1.1
+++ arch/powerpc/boot/ops.h 18 Oct 2008 02:06:45 -
@@ -40,6 +40,7 @@
const int buflen);
int (*setprop)(const void *phandle, const char *name,
const void *buf, const int buflen);
+ int (*del_node)(const void *phandle);
void *(*get_parent)(const void *phandle);
/* The node must not already exist. */
void *(*create_node)(const void *parent, const char *name);
@@ -124,6 +125,11 @@
return dt_ops.setprop(devp, name, buf, strlen(buf) + 1);
return -1;
+}
+
+static inline int del_node(const void *devp)
+{
+ return dt_ops.del_node ? dt_ops.del_node(devp) : -1;
}
static inline void *get_parent(const char *devp)
Index: arch/powerpc/boot/libfdt-wrapper.c
===
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 libfdt-wrapper.c
--- arch/powerpc/boot/libfdt-wrapper.c 11 Oct 2008 02:51:35 - 1.1.1.1
+++ arch/powerpc/boot/libfdt-wrapper.c 17 Oct 2008 22:08:44 -
@@ -105,6 +105,11 @@
return check_err(rc);
}
+static int fdt_wrapper_del_node(const void *devp)
+{
+ return fdt_del_node(fdt, devp_offset(devp));
+}
+
static void *fdt_wrapper_get_parent(const void *devp)
{
return offset_devp(fdt_parent_offset(fdt, devp_offset(devp)));
@@ -173,6 +178,7 @@
dt_ops.create_node = fdt_wrapper_create_node;
dt_ops.find_node_by_prop_value = fdt_wrapper_find_node_by_prop_value;
dt_ops.find_node_by_compatible = fdt_wrapper_find_node_by_compatible;
+ dt_ops.del_node = fdt_wrapper_del_node;
dt_ops.get_path = fdt_wrapper_get_path;
dt_ops.finalize = fdt_wrapper_finalize;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC/PATCH] pci: Workaround invalid P2P bridge bus numbers
On Tue, 2008-10-21 at 09:36 -0500, Ayman El-Khashab wrote: Ayman, can you double check that this variant of the patch still fixes your problem ? Thanks ! I've tried it out and it is working correctly with my devices. The subordinate bus numbers on all the ports are correct. Thanks ! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hugetlbfs for ppc440 - kernel BUG
On Tue, 2008-10-21 at 15:46 -0700, Satya wrote: Ben, Look here: http://www-unix.mcs.anl.gov/zeptoos/hugepages/ Thanks. What is the status ? Do they work fine ? Are they going to be re-submitted for inclusion ? Cheers, Ben. thanks, ./satya On Tue, Oct 21, 2008 at 1:47 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2007-07-10 at 13:38 -0500, Satya wrote: hello, I am trying to implement hugetlbfs on the IBM Bluegene/L IO node (ppc440) and I have a big problem as well as a few questions to ask the group. I patched a 2.6.21.6 linux kernel (manually) with Edi Shmueli's hugetlbfs implementation (found here: http://patchwork.ozlabs.org/linuxppc/patch?id=8427) for this. I did have to make slight changes (described at the end) to make it work. My test program is a shortened version of a sys v shared memory example described in Documentation/vm/hugetlbpage.txt Hi ! The patchwork link unfortunately didn't survive the transition to patchwork 2. Do you know what's the status of Hugetlb support for 44x ? Is there any plan to release that for upstream inclusion ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] pci: Workaround invalid P2P bridge bus numbers
On Tuesday, October 21, 2008 3:33 pm Benjamin Herrenschmidt wrote: On Tue, 2008-10-21 at 09:36 -0500, Ayman El-Khashab wrote: Ayman, can you double check that this variant of the patch still fixes your problem ? Thanks ! I've tried it out and it is working correctly with my devices. The subordinate bus numbers on all the ports are correct. Thanks ! Great, pushed to linux-next. Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add del_node function to allow early boot code to prune inapplicable devices.
On Tue, Oct 21, 2008 at 02:32:29PM -0700, Mike Ditto wrote:
Reposting in proper format...
Some platforms have variants that can share most of a flat device tree but
need
a few devices selectively pruned at boot time. This adds del_node() to ops.h
to allow access to the existing fdt_del_node().
Signed-off-by: Mike Ditto [EMAIL PROTECTED]
Looks good to me.
Acked-by: Grant Likely [EMAIL PROTECTED]
---
Index: arch/powerpc/boot/ops.h
===
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ops.h
--- arch/powerpc/boot/ops.h 11 Oct 2008 02:51:35 - 1.1.1.1
+++ arch/powerpc/boot/ops.h 18 Oct 2008 02:06:45 -
@@ -40,6 +40,7 @@
const int buflen);
int (*setprop)(const void *phandle, const char *name,
const void *buf, const int buflen);
+ int (*del_node)(const void *phandle);
void *(*get_parent)(const void *phandle);
/* The node must not already exist. */
void *(*create_node)(const void *parent, const char *name);
@@ -124,6 +125,11 @@
return dt_ops.setprop(devp, name, buf, strlen(buf) + 1);
return -1;
+}
+
+static inline int del_node(const void *devp)
+{
+ return dt_ops.del_node ? dt_ops.del_node(devp) : -1;
}
static inline void *get_parent(const char *devp)
Index: arch/powerpc/boot/libfdt-wrapper.c
===
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 libfdt-wrapper.c
--- arch/powerpc/boot/libfdt-wrapper.c11 Oct 2008 02:51:35 -
1.1.1.1
+++ arch/powerpc/boot/libfdt-wrapper.c17 Oct 2008 22:08:44 -
@@ -105,6 +105,11 @@
return check_err(rc);
}
+static int fdt_wrapper_del_node(const void *devp)
+{
+ return fdt_del_node(fdt, devp_offset(devp));
+}
+
static void *fdt_wrapper_get_parent(const void *devp)
{
return offset_devp(fdt_parent_offset(fdt, devp_offset(devp)));
@@ -173,6 +178,7 @@
dt_ops.create_node = fdt_wrapper_create_node;
dt_ops.find_node_by_prop_value = fdt_wrapper_find_node_by_prop_value;
dt_ops.find_node_by_compatible = fdt_wrapper_find_node_by_compatible;
+ dt_ops.del_node = fdt_wrapper_del_node;
dt_ops.get_path = fdt_wrapper_get_path;
dt_ops.finalize = fdt_wrapper_finalize;
___
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: [PATCH] Implement polling for 5200FEC to make netconsole work.
Is anyone going to pick this up?
On Sat, Oct 18, 2008 at 5:40 PM, Jon Smirl [EMAIL PROTECTED] wrote:
Implement polling for 5200FEC to make netconsole work. Tested on Phytec
pcm030 and Efika.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
drivers/net/fec_mpc52xx.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 4e4f683..aec3b97 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -401,6 +401,21 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buff
*skb, struct net_device *d
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void mpc52xx_fec_poll_controller(struct net_device *dev)
+{
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ disable_irq(priv-t_irq);
+ mpc52xx_fec_tx_interrupt(priv-t_irq, dev);
+ enable_irq(priv-t_irq);
+ disable_irq(priv-r_irq);
+ mpc52xx_fec_rx_interrupt(priv-r_irq, dev);
+ enable_irq(priv-r_irq);
+}
+#endif
+
+
/* This handles BestComm transmit task interrupts
*/
static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
@@ -926,6 +941,9 @@ mpc52xx_fec_probe(struct of_device *op, const struct
of_device_id *match)
ndev-tx_timeout= mpc52xx_fec_tx_timeout;
ndev-watchdog_timeo= FEC_WATCHDOG_TIMEOUT;
ndev-base_addr = mem.start;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ ndev-poll_controller = mpc52xx_fec_poll_controller;
+#endif
priv-t_irq = priv-r_irq = ndev-irq = NO_IRQ; /* IRQ are free for
now */
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Implement polling for 5200FEC to make netconsole work.
On Tue, Oct 21, 2008 at 5:41 PM, Jon Smirl [EMAIL PROTECTED] wrote:
Is anyone going to pick this up?
I'm looking at it, but I'm not picking it up for .28. It's
non-trivial enough that I would have needed to have it before the
merge window opened to get it into .28.
g.
On Sat, Oct 18, 2008 at 5:40 PM, Jon Smirl [EMAIL PROTECTED] wrote:
Implement polling for 5200FEC to make netconsole work. Tested on Phytec
pcm030 and Efika.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
drivers/net/fec_mpc52xx.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 4e4f683..aec3b97 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -401,6 +401,21 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buff
*skb, struct net_device *d
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void mpc52xx_fec_poll_controller(struct net_device *dev)
+{
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
+ disable_irq(priv-t_irq);
+ mpc52xx_fec_tx_interrupt(priv-t_irq, dev);
+ enable_irq(priv-t_irq);
+ disable_irq(priv-r_irq);
+ mpc52xx_fec_rx_interrupt(priv-r_irq, dev);
+ enable_irq(priv-r_irq);
+}
+#endif
+
+
/* This handles BestComm transmit task interrupts
*/
static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
@@ -926,6 +941,9 @@ mpc52xx_fec_probe(struct of_device *op, const struct
of_device_id *match)
ndev-tx_timeout= mpc52xx_fec_tx_timeout;
ndev-watchdog_timeo= FEC_WATCHDOG_TIMEOUT;
ndev-base_addr = mem.start;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ ndev-poll_controller = mpc52xx_fec_poll_controller;
+#endif
priv-t_irq = priv-r_irq = ndev-irq = NO_IRQ; /* IRQ are free for
now */
--
Jon Smirl
[EMAIL PROTECTED]
--
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: [PATCHv2 1/1] powerpc: Update page in counter for CMM
- if (ret VM_FAULT_MAJOR)
+ if (ret VM_FAULT_MAJOR) {
current-maj_flt++;
- else
+ preempt_disable();
+ get_lppaca()-page_ins++;
+ preempt_enable();
+ } else
That isn't going to work very well on 32-bit or non-pseries
platforms :-)
We need either something like a ppc_md. callback or at least a test for
firmware feature... (which probably still needs an ifdef to build on
32 bit).
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add del_node function to allow early boot code to prune inapplicable devices.
On Tue, 2008-10-21 at 17:33 -0600, Grant Likely wrote: On Tue, Oct 21, 2008 at 02:32:29PM -0700, Mike Ditto wrote: Reposting in proper format... Some platforms have variants that can share most of a flat device tree but need a few devices selectively pruned at boot time. This adds del_node() to ops.h to allow access to the existing fdt_del_node(). Signed-off-by: Mike Ditto [EMAIL PROTECTED] Looks good to me. Acked-by: Grant Likely [EMAIL PROTECTED] little nit: The patch doesn't quite have the right form. Patches to the kernel are expected to apply with -p1, so for example, the patch line contains: arch/powerpc/boot/ops.h It should be something/arch/powerpc/boot/ops.h I've fixed it up manually so no need to re-submit, but you'll know next time :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add del_node function to allow early boot code to prune inapplicable devices.
Benjamin Herrenschmidt wrote: I've fixed it up manually so no need to re-submit, but you'll know next time :-) Thanks! -=] Mike [=- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/7] i2c: add info-archdata field
On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote: Hi Anton, On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote: If present the info-archdata is copied into the dev-archdata. Some (OpenFirmware) platforms need it. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- So who's pushing this one ? Jean ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
But it doesn't work as a module (i.e. OF-specific bits should be always in-kernel). Why not ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, Oct 22, 2008 at 11:29:20AM +1100, Benjamin Herrenschmidt wrote: But it doesn't work as a module (i.e. OF-specific bits should be always in-kernel). Why not ? If say X driver loads prior to bus-notifier module (where we fill the platform data), then X.0 device will try to probe w/o platform data and will fail. The only way to re-probe things is to rmmod X insmod of_pdata_filler_X insmod X. So things depend on the module load order. The obvious solution is to link the OF stuff into the module, but this also won't work, since modules have only one entry (and exit) point. So there is no way* to hook our OF helpers into the module. * Well, there is one solution to this problem. We can implement arch-specific init_module and cleanup_module entry/exit points, where we can load/unload the OF hooks. This is quite easy, but may look ugly. I could show the drafts. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hugetlbfs for ppc440 - kernel BUG
Ben, Look here: http://www-unix.mcs.anl.gov/zeptoos/hugepages/ thanks, ./satya On Tue, Oct 21, 2008 at 1:47 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2007-07-10 at 13:38 -0500, Satya wrote: hello, I am trying to implement hugetlbfs on the IBM Bluegene/L IO node (ppc440) and I have a big problem as well as a few questions to ask the group. I patched a 2.6.21.6 linux kernel (manually) with Edi Shmueli's hugetlbfs implementation (found here: http://patchwork.ozlabs.org/linuxppc/patch?id=8427) for this. I did have to make slight changes (described at the end) to make it work. My test program is a shortened version of a sys v shared memory example described in Documentation/vm/hugetlbpage.txt Hi ! The patchwork link unfortunately didn't survive the transition to patchwork 2. Do you know what's the status of Hugetlb support for 44x ? Is there any plan to release that for upstream inclusion ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hugetlbfs for ppc440 - kernel BUG
On Tue, Oct 21, 2008 at 3:46 PM, Satya [EMAIL PROTECTED] wrote: Ben, Look here: http://www-unix.mcs.anl.gov/zeptoos/hugepages/ thanks, ./satya On Tue, Oct 21, 2008 at 1:47 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2007-07-10 at 13:38 -0500, Satya wrote: hello, I am trying to implement hugetlbfs on the IBM Bluegene/L IO node (ppc440) and I have a big problem as well as a few questions to ask the group. I patched a 2.6.21.6 linux kernel (manually) with Edi Shmueli's hugetlbfs implementation (found here: http://patchwork.ozlabs.org/linuxppc/patch?id=8427) for this. I did have to make slight changes (described at the end) to make it work. My test program is a shortened version of a sys v shared memory example described in Documentation/vm/hugetlbpage.txt Hi ! The patchwork link unfortunately didn't survive the transition to patchwork 2. Do you know what's the status of Hugetlb support for 44x ? Is there any plan to release that for upstream inclusion ? Cheers, Ben. whoops, sorry for top-posting. Here is a patch that worked at that time: http://www-unix.mcs.anl.gov/zeptoos/hugepages/hugetlbpage_44x.patch I didn't follow up after this to get it merged upstream. Also I don't know if hugetlb core has changed to deal with PTEs in high memory. ./satya ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Don't use a 16G page if beyond mem= limits
If mem= is used on the boot command line to limit memory then the memory block
where a 16G page resides may not be available.
Thanks to Michael Ellerman for finding the problem.
Signed-off-by: Jon Tollefson [EMAIL PROTECTED]
---
arch/powerpc/mm/hash_utils_64.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 5c64af1..8d5b475 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -382,8 +382,10 @@ static int __init htab_dt_scan_hugepage_blocks(unsigned
long node,
printk(KERN_INFO Huge page(16GB) memory:
addr = 0x%lX size = 0x%lX pages = %d\n,
phys_addr, block_size, expected_pages);
- lmb_reserve(phys_addr, block_size * expected_pages);
- add_gpage(phys_addr, block_size, expected_pages);
+ if (phys_addr + (16 * GB) = lmb_end_of_DRAM()) {
+ lmb_reserve(phys_addr, block_size * expected_pages);
+ add_gpage(phys_addr, block_size, expected_pages);
+ }
return 0;
}
#endif /* CONFIG_HUGETLB_PAGE */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove device_type = rtc properties in .dts files
On Tue, Oct 21, 2008 at 10:58:44PM +0400, Anton Vorontsov wrote: We don't want to encourage the device_type usage. It isn't used in the code, so we can simply remove it from the dts files. Suggested-by: Scott Wood [EMAIL PROTECTED] Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] Acked-by: David Gibson [EMAIL PROTECTED] -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add del_node function to allow early boot code to prune inapplicable devices.
On Tue, Oct 21, 2008 at 02:32:29PM -0700, Mike Ditto wrote: Reposting in proper format... Some platforms have variants that can share most of a flat device tree but need a few devices selectively pruned at boot time. This adds del_node() to ops.h to allow access to the existing fdt_del_node(). Signed-off-by: Mike Ditto [EMAIL PROTECTED] Acked-by: David Gibson [EMAIL PROTECTED] -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hugetlbfs for ppc440 - kernel BUG
On Wed, Oct 22, 2008 at 09:53:13AM +1100, Benjamin Herrenschmidt wrote: On Tue, 2008-10-21 at 15:46 -0700, Satya wrote: Ben, Look here: http://www-unix.mcs.anl.gov/zeptoos/hugepages/ Thanks. What is the status ? Do they work fine ? Are they going to be re-submitted for inclusion ? Hrm. Last I looked at the 440 hugepage patches they appeared to have several serious bugs (I was surprised they worked at all). I had meant to fix them up and push, but I never quite got around to it. I'll have at this link later today. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, Oct 22, 2008 at 05:03:47AM +0400, Anton Vorontsov wrote: On Wed, Oct 22, 2008 at 11:29:20AM +1100, Benjamin Herrenschmidt wrote: But it doesn't work as a module (i.e. OF-specific bits should be always in-kernel). Why not ? If say X driver loads prior to bus-notifier module (where we fill the platform data), then X.0 device will try to probe w/o platform data and will fail. The only way to re-probe things is to rmmod X insmod of_pdata_filler_X insmod X. So things depend on the module load order. Thinking about it more, I started recalling other issues. The bus notifier chain doesn't replay previous events, so we also have to register the notifier before the _devices_ are registered. And this ruins the whole approach. :-/ Yeah, that's why I abandoned the bus notifier idea. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, 2008-10-22 at 05:03 +0400, Anton Vorontsov wrote: If say X driver loads prior to bus-notifier module (where we fill the platform data), then X.0 device will try to probe w/o platform data and will fail. The only way to re-probe things is to rmmod X insmod of_pdata_filler_X insmod X. So things depend on the module load order. The obvious solution is to link the OF stuff into the module, but this also won't work, since modules have only one entry (and exit) point. So there is no way* to hook our OF helpers into the module. Well, right, we need the bus notifier to be registered before any device gets added ... which mean from the same module_init that registers the bus itself. A bit annoying ... * Well, there is one solution to this problem. We can implement arch-specific init_module and cleanup_module entry/exit points, where we can load/unload the OF hooks. This is quite easy, but may look ugly. I could show the drafts. Yuck :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, 2008-10-22 at 05:42 +0400, Anton Vorontsov wrote: Thinking about it more, I started recalling other issues. The bus notifier chain doesn't replay previous events, so we also have to register the notifier before the _devices_ are registered. And this ruins the whole approach. :-/ Yeah, that's why I abandoned the bus notifier idea. The notifier can be registered before the devices, though it's a little bit fishy and fragile. Easier I suppose to just have OF specific hooks in the bus code. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Support for relocatable kdump kernel
From: Mohan Kumar M [EMAIL PROTECTED] This adds relocatable kernel support for kdump. With this one can use the same regular kernel to capture the kdump. A signature (0xfeed1234) is passed in r6 from panic code to the next kernel through kexec_sequence and purgatory code. The signature is used to differentiate between kdump kernel and non-kdump kernels. The purgatory code compares the signature and sets the __kdump_flag in head_64.S. During the boot up, kernel code checks __kdump_flag and if it is set, the kernel will behave as relocatable kdump kernel. This kernel will boot at the address where it was loaded by kexec-tools ie. at the address reserved through crashkernel boot parameter. CONFIG_CRASH_DUMP depends on CONFIG_RELOCATABLE option to build kdump kernel as relocatable. So the same kernel can be used as production and kdump kernel. This patch incorporates the changes suggested by Paul Mackerras to avoid GOT use and to avoid two copies of the code. Signed-off-by: Paul Mackerras [EMAIL PROTECTED] Signed-off-by: Mohan Kumar M [EMAIL PROTECTED] Signed-off-by: Michael Ellerman [EMAIL PROTECTED] --- Documentation/kdump/kdump.txt | 14 +- arch/powerpc/Kconfig | 10 +--- arch/powerpc/include/asm/kdump.h | 17 ++-- arch/powerpc/kernel/crash_dump.c |2 + arch/powerpc/kernel/head_64.S | 39 +++--- arch/powerpc/kernel/iommu.c| 69 +--- arch/powerpc/kernel/machine_kexec.c|2 + arch/powerpc/kernel/machine_kexec_64.c | 13 -- arch/powerpc/kernel/misc_64.S |9 +++- arch/powerpc/platforms/cell/ras.c |6 +- arch/powerpc/platforms/pseries/iommu.c |6 +- 11 files changed, 121 insertions(+), 66 deletions(-) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 0705040..3f4bc84 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -109,7 +109,8 @@ There are two possible methods of using Kdump. 2) Or use the system kernel binary itself as dump-capture kernel and there is no need to build a separate dump-capture kernel. This is possible only with the architecutres which support a relocatable kernel. As - of today, i386, x86_64 and ia64 architectures support relocatable kernel. + of today, i386, x86_64, ppc64 and ia64 architectures support relocatable + kernel. Building a relocatable kernel is advantageous from the point of view that one does not have to build a second kernel for capturing the dump. But @@ -207,8 +208,15 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64) Dump-capture kernel config options (Arch Dependent, ppc64) -- -* Make and install the kernel and its modules. DO NOT add this kernel - to the boot loader configuration files. +1) Enable Build a kdump crash kernel support under Kernel options: + + CONFIG_CRASH_DUMP=y + +2) Enable Build a relocatable kernel support + + CONFIG_RELOCATABLE=y + + Make and install the kernel and its modules. Dump-capture kernel config options (Arch Dependent, ia64) -- diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 369d93e..5b15278 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -323,13 +323,11 @@ config KEXEC config CRASH_DUMP bool Build a kdump crash kernel - depends on PPC_MULTIPLATFORM PPC64 + depends on PPC_MULTIPLATFORM PPC64 RELOCATABLE help Build a kernel suitable for use as a kdump capture kernel. - The kernel will be linked at a different address than normal, and - so can only be used for Kdump. - - Don't change this unless you know what you are doing. + The same kernel binary can be used as production kernel and dump + capture kernel. config PHYP_DUMP bool Hypervisor-assisted dump (EXPERIMENTAL) @@ -829,11 +827,9 @@ config PAGE_OFFSET default 0xc000 config KERNEL_START hex - default 0xc200 if CRASH_DUMP default 0xc000 config PHYSICAL_START hex - default 0x0200 if CRASH_DUMP default 0x endif diff --git a/arch/powerpc/include/asm/kdump.h b/arch/powerpc/include/asm/kdump.h index f6c93c7..a503da9 100644 --- a/arch/powerpc/include/asm/kdump.h +++ b/arch/powerpc/include/asm/kdump.h @@ -9,6 +9,12 @@ * Reserve to the end of the FWNMI area, see head_64.S */ #define KDUMP_RESERVE_LIMIT0x1 /* 64K */ +/* + * Used to differentiate between relocatable kdump kernel and other + * kernels + */ +#define KDUMP_SIGNATURE0xfeed1234 + #ifdef CONFIG_CRASH_DUMP #define KDUMP_TRAMPOLINE_START 0x0100 @@ -19,17 +25,18 @@ #endif /* CONFIG_CRASH_DUMP */ #ifndef __ASSEMBLY__ -#ifdef CONFIG_CRASH_DUMP +extern unsigned long __kdump_flag; + +#if
Re: build failure on powerpc with current -git
Stephen Rothwell writes:
On Tue, 21 Oct 2008 16:33:10 +1100 Paul Mackerras [EMAIL PROTECTED] wrote:
It's a bug in older versions of ld (including 2.16.1) that's fixed in
the current version (2.18). However, this patch appears to work
around the problem - at least, it let me build a 32-bit kernel with a
cross-toolchain including a 2.16.1 ld. Let me know if this gets it
working for you.
With that patch applied I got these errors for a powerpc ppc64_defconfig
build (linux-next).
/usr/bin/objcopy: Warning: '/dev/null' is not an ordinary file
Hmmm, so do I, and in fact the arch/powerpc/boot/wrapper change now
seems to be unnecessary with my cross-compile setup (which has ld
2.16.1), whereas yesterday I'm sure it got errors. Weird.
Chris, could you try just the following change (my previous patch
without the arch/powerpc/boot/wrapper change) and let me know if it
fixes things with the ld you use?
Paul.
---
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index b39c27e..384dca5 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -187,6 +187,7 @@ SECTIONS
*(.machine.desc)
__machine_desc_end = . ;
}
+#ifdef CONFIG_RELOCATABLE
. = ALIGN(8);
.dynsym : AT(ADDR(.dynsym) - LOAD_OFFSET) { *(.dynsym) }
.dynstr : AT(ADDR(.dynstr) - LOAD_OFFSET) { *(.dynstr) }
@@ -202,6 +203,7 @@ SECTIONS
__rela_dyn_start = .;
*(.rela*)
}
+#endif
/* Fake ELF header containing RPA note; for addnote */
.fakeelf : AT(ADDR(.fakeelf) - LOAD_OFFSET) { *(.fakeelf) }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/7] of: fill the archdata for I2C devices
On Thu, Oct 16, 2008 at 09:12:56PM +0400, Anton Vorontsov wrote:
For I2C devices we just setting the the node pointer in the archdata.
This is needed so that the other code would know device's node.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Looks okay to me.
Acked-by: Grant Likely [EMAIL PROTECTED]
---
drivers/of/of_i2c.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 6a98dc8..f9e18ed 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -24,6 +24,7 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
for_each_child_of_node(adap_node, node) {
struct i2c_board_info info = {};
+ struct dev_archdata dev_ad = {};
const u32 *addr;
int len;
@@ -41,6 +42,9 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
info.addr = *addr;
+ dev_archdata_set_node(dev_ad, node);
+ info.archdata = dev_ad;
+
request_module(info.type);
result = i2c_new_device(adap, info);
@@ -51,6 +55,13 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
irq_dispose_mapping(info.irq);
continue;
}
+
+ /*
+ * Get the node to not lose the dev_archdata-of_node.
+ * Currently there is no way to put it back, as well as no
+ * of_unregister_i2c_devices() call.
+ */
+ of_node_get(node);
}
}
EXPORT_SYMBOL(of_register_i2c_devices);
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, Oct 22, 2008 at 01:28:17PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2008-10-22 at 05:42 +0400, Anton Vorontsov wrote: Thinking about it more, I started recalling other issues. The bus notifier chain doesn't replay previous events, so we also have to register the notifier before the _devices_ are registered. And this ruins the whole approach. :-/ Yeah, that's why I abandoned the bus notifier idea. The notifier can be registered before the devices, though it's a little bit fishy and fragile. Easier I suppose to just have OF specific hooks in the bus code. Every time I think about the problem, this is the conclusion that I come to. Either have OF specific hooks in the probe/remove functions; or have separate probe/remove for OF created instances of a device. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote: The notifier can be registered before the devices, though it's a little bit fishy and fragile. Easier I suppose to just have OF specific hooks in the bus code. Like what I suggested: chip-aware OF glue drivers. The relevant bus code being the of_platform_bus_type infrastructure. Example: instead of Anton's patch #6 modifying the existing pca953x driver, an of_pca953x driver that knows how to poke around in the OF device attributes to (a) create the pca953x_platform_data, (b) call i2c_register_board_info() to make that available later, and then finally (c) vanish, since it's not needed any longer. Better that than either the $SUBJECT patch, or modifying gpiolib to grow OF-specific hooks ... hooks that can at best solve *one* of the problems: which GPIO numbers to use with this chip. The platform data does solve other problems(*) like: (i) how to initialize the polarity inversion register, (ii) arranging to set up other devices only after their GPIOs are ready, (iii) initializing things that device drivers won't always know about, or which may need to be set up before such drivers are available. - Dave (*) A trivial example of (ii) would be LEDs driven by those GPIOs. A less trivial example: see arch/arm/mach-davinci/board-evm.c in current GIT. There are three pcf8574 I2C expanders used for various things ... LEDs, audio PLL, device power supplies, reset lines for external devices, more. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Support for relocatable kdump kernel
On Wed Oct 22 at 14:38:10 EST in 2008, Michael Ellerman wrote:
This adds relocatable kernel support for kdump. With this one can
use the same regular kernel to capture the kdump. A signature
(0xfeed1234)
is passed in r6 from panic code to the next kernel through
kexec_sequence
and purgatory code. The signature is used to differentiate between
kdump kernel and non-kdump kernels.
I object to this signature being passed from the kernel. The
purgatory code should be modified to set this based on a memory
variable in its space, and that varable should be set by the
userspace code code that prepares purgatory. (The standard
kexec-tools has library code to do this and we already use it
to tell purgatory the location of the device tree and kernel).
The purgatory code compares the signature and sets the __kdump_flag in
head_64.S. During the boot up, kernel code checks __kdump_flag and if
it
is set, the kernel will behave as relocatable kdump kernel. This kernel
will boot at the address where it was loaded by kexec-tools ie. at the
address reserved through crashkernel boot parameter.
I was hoping for a more generic test, but I haven't had the time to
write code for this so I'll accept this part for now.
CONFIG_CRASH_DUMP depends on CONFIG_RELOCATABLE option to build kdump
kernel as relocatable. So the same kernel can be used as production and
kdump kernel.
diff --git a/arch/powerpc/include/asm/kdump.h
b/arch/powerpc/include/asm/kdump.h
index f6c93c7..a503da9 100644
--- a/arch/powerpc/include/asm/kdump.h
+++ b/arch/powerpc/include/asm/kdump.h
@@ -9,6 +9,12 @@
* Reserve to the end of the FWNMI area, see head_64.S */
#define KDUMP_RESERVE_LIMIT0x1 /* 64K */
+/*
+ * Used to differentiate between relocatable kdump kernel and other
+ * kernels
+ */
+#define KDUMP_SIGNATURE0xfeed1234
+
This can go
#ifdef CONFIG_CRASH_DUMP
#define KDUMP_TRAMPOLINE_START 0x0100
@@ -19,17 +25,18 @@
#endif /* CONFIG_CRASH_DUMP */
#ifndef __ASSEMBLY__
-#ifdef CONFIG_CRASH_DUMP
+extern unsigned long __kdump_flag;
+
This will not be needed. It will only be referenced by the
assembly code in head.S.
+#if defined(CONFIG_CRASH_DUMP) !defined(CONFIG_RELOCATABLE)
extern void reserve_kdump_trampoline(void);
extern void setup_kdump_trampoline(void);
-
-#else /* !CONFIG_CRASH_DUMP */
-
+#else
+/* !CRASH_DUMP || RELOCATABLE */
static inline void reserve_kdump_trampoline(void) { ; }
static inline void setup_kdump_trampoline(void) { ; }
+#endif
-#endif /* CONFIG_CRASH_DUMP */
#endif /* __ASSEMBLY__ */
#endif /* __PPC64_KDUMP_H */
diff --git a/arch/powerpc/kernel/crash_dump.c
b/arch/powerpc/kernel/crash_dump.c
index 97e0563..19671ac 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -30,6 +30,7 @@
/* Stores the physical address of elf header of crash image. */
unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+#ifndef CONFIG_RELOCATABLE
is this done somewhere else for the relocatable case?
a comment pointing to where would be helpful.
void __init reserve_kdump_trampoline(void)
{
lmb_reserve(0, KDUMP_RESERVE_LIMIT);
@@ -68,6 +69,7 @@ void __init setup_kdump_trampoline(void)
DBG( - setup_kdump_trampoline()\n);
}
+#endif /* CONFIG_RELOCATABLE */
/*
* Note: elfcorehdr_addr is not just limited to vmcore. It is also
used by
diff --git a/arch/powerpc/kernel/head_64.S
b/arch/powerpc/kernel/head_64.S
index 84856be..69489bd 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -97,6 +97,12 @@ __secondary_hold_spinloop:
__secondary_hold_acknowledge:
.llong 0x0
+ /* This flag is set by purgatory if we should be a kdump
kernel. */
+ /* Do not move this variable as purgatory knows about it. */
+ .globl __kdump_flag
+__kdump_flag:
+ .llong 0x0
+
#ifdef CONFIG_PPC_ISERIES
/*
* At offset 0x20, there is a pointer to iSeries LPAR data.
@@ -1384,7 +1390,13 @@ _STATIC(__after_prom_start)
/* process relocations for the final address of the kernel */
lis r25,PAGE_OFFSET at highest /* compute virtual
base of kernel */
sldir25,r25,32
- mr r3,r25
+#ifdef CONFIG_CRASH_DUMP
+ ld r7,__kdump_flag-_stext(r26)
+ cmpldi cr0,r7,1/* kdump kernel ? - stay where we are
*/
+ bne 1f
+ add r25,r25,r26
+#endif
+1: mr r3,r25
bl .relocate
#endif
@@ -1398,11 +1410,26 @@ _STATIC(__after_prom_start)
li r3,0/* target addr */
mr. r4,r26 /* In some cases the loader
may */
beq 9f /* have already put us at zero
*/
- lis r5,(copy_to_here - _stext)@ha
- addir5,r5,(copy_to_here - _stext)@l /* # bytes of memory
to copy */
li r6,0x100/* Start offset, the first
0x100 */
/*
[git pull] Please pull from powerpc.git next branch
Hi Linus ! Here's some additions to yesterday's pull request. Mostly things that slipped through the cracks, for example, for the hvc_console work there was some confusion as to who was going to merge it, and the kdump bits I mentioned yesterday that were getting some rebasing/massaging. The rest is either trivial enough or bug fixes, That should now bit it for the features for this merge window The following changes since commit a02efb906d12c9d4eb2ab7c59049ba9545e5412d: Benjamin Herrenschmidt (1): Merge commit 'origin' into master are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git master Becky Bruce (1): powerpc: Move memory size print into common show_cpuinfo for 32-bit David Gibson (1): powerpc: Further compile fixup for STRICT_MM_TYPECHECKS Hendrik Brueckner (5): hvc_console: Add a hangup notifier for backends hvc_console: Add tty driver flag TTY_DRIVER_RESET_TERMIOS hvc_console: Fix loop if put_char() returns 0 hvc_console: Add support for tty window resizing hvc_console: Remove __devexit annotation of hvc_remove() Jon Tollefson (1): powerpc: Don't use a 16G page if beyond mem= limits Michael Neuling (1): powerpc: Remove empty #else from signal_64.c Mike Ditto (1): powerpc: Add del_node() for early boot code to prune inapplicable devices. Mohan Kumar M (1): powerpc: Support for relocatable kdump kernel Documentation/kdump/kdump.txt | 14 +++- arch/powerpc/Kconfig | 10 +-- arch/powerpc/boot/libfdt-wrapper.c |6 ++ arch/powerpc/boot/ops.h|6 ++ arch/powerpc/include/asm/kdump.h | 17 +++-- arch/powerpc/kernel/crash_dump.c |2 + arch/powerpc/kernel/head_64.S | 39 +-- arch/powerpc/kernel/iommu.c| 69 ++- arch/powerpc/kernel/machine_kexec.c|2 + arch/powerpc/kernel/machine_kexec_64.c | 13 +++- arch/powerpc/kernel/misc_64.S |9 ++- arch/powerpc/kernel/pci-common.c |3 +- arch/powerpc/kernel/setup-common.c |7 ++ arch/powerpc/kernel/signal_64.c|2 - arch/powerpc/mm/hash_utils_64.c|6 +- arch/powerpc/platforms/85xx/ksi8560.c |4 - arch/powerpc/platforms/85xx/mpc85xx_ads.c |4 - arch/powerpc/platforms/85xx/mpc85xx_cds.c |4 - arch/powerpc/platforms/85xx/sbc8548.c |4 - arch/powerpc/platforms/85xx/sbc8560.c |4 - arch/powerpc/platforms/85xx/stx_gp3.c |4 - arch/powerpc/platforms/85xx/tqm85xx.c |4 - arch/powerpc/platforms/86xx/gef_sbc610.c |2 - arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |2 - arch/powerpc/platforms/86xx/sbc8641d.c |2 - arch/powerpc/platforms/cell/ras.c |6 +- arch/powerpc/platforms/embedded6xx/c2k.c |3 - arch/powerpc/platforms/embedded6xx/prpmc2800.c |3 - arch/powerpc/platforms/pseries/iommu.c |6 +- drivers/char/hvc_console.c | 86 drivers/char/hvc_console.h | 12 +++- drivers/char/hvc_irq.c |5 ++ drivers/char/hvc_iseries.c |1 + drivers/char/hvc_vio.c |1 + drivers/char/hvc_xen.c |1 + drivers/char/virtio_console.c |1 + 36 files changed, 238 insertions(+), 126 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
