* Re: PowerBook5,4 -- no sound?
From: Andreas Schwab @ 2006-04-17 13:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1145233812.9833.21.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Interesting... I would have expected that setup to work... Oh well... at
> this point, the best to do is to add support for your G5 to Johannes new
> snd-aoa
I agree. Unfortunately, the i2sbus probing already fails, due to
requesting a memory region that is already (partially) claimed by other
resources:
request_mem_region(80000000 - 80000fff, i2sbus control)
80000000-8007ffff : 0.80000000:mac-io
8000002c-8000002f : 0.0000004c:fans
80000030-80000033 : 0.0000004c:fans
80000034-80000037 : 0.0000004c:fans
8000004c-8000004f : 0.0000004c:fans
80000050-8000008a : 0.00000050:gpio
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Christoph Lameter @ 2006-04-17 16:55 UTC (permalink / raw)
To: kiran
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, Nick Piggin, grundler,
Steven Rostedt, starvik, Linus Torvalds, Thomas Gleixner, rth,
Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <4440855A.7040203@yahoo.com.au>
On Sat, 15 Apr 2006, Nick Piggin wrote:
> If I'm following you correctly, this adds another dependent load
> to a per-CPU data access, and from memory that isn't node-affine.
I am also concerned about that. Kiran has a patch to avoid allocpercpu
having to go through one level of indirection that I guess would no
longer work with this scheme.
> If so, I think people with SMP and NUMA kernels would care more
> about performance and scalability than the few k of memory this
> saves.
Right.
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Andi Kleen @ 2006-04-17 17:10 UTC (permalink / raw)
To: Nick Piggin
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, grundler, Steven Rostedt,
starvik, Linus Torvalds, Thomas Gleixner, rth, Chris Zankel,
tony.luck, LKML, ralf, Marc Gauthier, lethal, schwidefsky,
linux390, davem, parisc-linux
In-Reply-To: <4441ECE6.5010709@yahoo.com.au>
On Sunday 16 April 2006 09:06, Nick Piggin wrote:
> I still don't understand what the justification is for slowing down
> this critical bit of infrastructure for something that is only a
> problem in the -rt patchset, and even then only a problem when tracing
> is enabled.
There are actually problems outside -rt. e.g. the Xen kernel was running
into a near overflow and as more and more code is using per cpu variables
others might too.
I'm confident the problem can be solved without adding more variables
though - e.g. in the way rusty proposed.
-Andi
^ permalink raw reply
* [PATCH] ppc64-soft-reset-fixes
From: David Wilder @ 2006-04-17 17:58 UTC (permalink / raw)
To: fastboot, linuxppc-dev, akpm, Haren Myneni
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
This is a reposting of a patch formally named
kdump-ppc64-soft-reset-fixes.patch posted:
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/021958.html
With cleanup suggested by Andrew's posting:
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/021959.html
Description:
- For the crash scenario, when a CPU hangs with interrupts disabled and
the other CPUs panic or user invoked kdump boot using sysrq-c. In this
case, the hung CPU can not be stopped and causes the kdump boot not
successful. This case can be treated as complete system hang and asks
the user to activate soft-reset if all secondary CPUs are not stopped.
Regards
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: ppc64-soft-reset-fixes.patch --]
[-- Type: text/x-patch, Size: 10027 bytes --]
- For the crash scenario, when a CPU hangs with interrupts disabled and the other CPUs panic or user invoked kdump boot using sysrq-c. In this case, the hung CPU can not be stopped and causes the kdump boot not successful. This case can be treated as complete system hang and asks the user to activate soft-reset if all secondary CPUs are not stopped.
Signed-off-by: Haren Myneni <haren@us.ibm.com>
Signed-off-by: David Wilder <dwilder@us.ibm.com>
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 778f22f..20ef5d2 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -23,9 +23,11 @@
#include <linux/elfcore.h>
#include <linux/init.h>
#include <linux/types.h>
+#include <linux/irq.h>
#include <asm/processor.h>
#include <asm/machdep.h>
+#include <asm/kexec.h>
#include <asm/kdump.h>
#include <asm/lmb.h>
#include <asm/firmware.h>
@@ -40,6 +42,7 @@
/* This keeps a track of which one is crashing cpu. */
int crashing_cpu = -1;
+static cpumask_t cpus_in_crash = CPU_MASK_NONE;
static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
size_t data_len)
@@ -97,34 +100,66 @@ static void crash_save_this_cpu(struct p
}
#ifdef CONFIG_SMP
-static atomic_t waiting_for_crash_ipi;
+static atomic_t enter_on_soft_reset = ATOMIC_INIT(0);
void crash_ipi_callback(struct pt_regs *regs)
{
int cpu = smp_processor_id();
- if (cpu == crashing_cpu)
- return;
-
if (!cpu_online(cpu))
return;
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 1);
-
local_irq_disable();
+ if (!cpu_isset(cpu, cpus_in_crash))
+ crash_save_this_cpu(regs, cpu);
+ cpu_set(cpu, cpus_in_crash);
- crash_save_this_cpu(regs, cpu);
- atomic_dec(&waiting_for_crash_ipi);
+ /*
+ * Entered via soft-reset - could be the kdump
+ * process is invoked using soft-reset or user activated
+ * it if some CPU did not respond to an IPI.
+ * For soft-reset, the secondary CPU can enter this func
+ * twice. 1 - using IPI, and 2. soft-reset.
+ * Tell the kexec CPU that entered via soft-reset and ready
+ * to go down.
+ */
+ if (cpu_isset(cpu, cpus_in_sr)) {
+ cpu_clear(cpu, cpus_in_sr);
+ atomic_inc(&enter_on_soft_reset);
+ }
+
+ /*
+ * Starting the kdump boot.
+ * This barrier is needed to make sure that all CPUs are stopped.
+ * If not, soft-reset will be invoked to bring other CPUs.
+ */
+ while (!cpu_isset(crashing_cpu, cpus_in_crash))
+ cpu_relax();
+
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 1);
kexec_smp_wait();
/* NOTREACHED */
}
-static void crash_kexec_prepare_cpus(void)
+/*
+ * Wait until all CPUs are entered via soft-reset.
+ */
+static void crash_soft_reset_check(int cpu)
+{
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
+
+ cpu_clear(cpu, cpus_in_sr);
+ while (atomic_read(&enter_on_soft_reset) != ncpus)
+ cpu_relax();
+}
+
+
+static void crash_kexec_prepare_cpus(int cpu)
{
unsigned int msecs;
- atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
crash_send_ipi(crash_ipi_callback);
smp_wmb();
@@ -132,14 +167,13 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: Until we will have the way to stop other CPUSs reliabally,
* the crash CPU will send an IPI and wait for other CPUs to
- * respond. If not, proceed the kexec boot even though we failed to
- * capture other CPU states.
+ * respond.
* Delay of at least 10 seconds.
*/
- printk(KERN_ALERT "Sending IPI to other cpus...\n");
+ printk(KERN_EMERG "Sending IPI to other cpus...\n");
msecs = 10000;
- while ((atomic_read(&waiting_for_crash_ipi) > 0) && (--msecs > 0)) {
- barrier();
+ while ((cpus_weight(cpus_in_crash) < ncpus) && (--msecs > 0)) {
+ cpu_relax();
mdelay(1);
}
@@ -148,18 +182,71 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: In case if we do not get all CPUs, one possibility: ask the
* user to do soft reset such that we get all.
- * IPI handler is already set by the panic cpu initially. Therefore,
- * all cpus could invoke this handler from die() and the panic CPU
- * will call machine_kexec() directly from this handler to do
- * kexec boot.
- */
- if (atomic_read(&waiting_for_crash_ipi))
- printk(KERN_ALERT "done waiting: %d cpus not responding\n",
- atomic_read(&waiting_for_crash_ipi));
+ * Soft-reset will be used until better mechanism is implemented.
+ */
+ if (cpus_weight(cpus_in_crash) < ncpus) {
+ printk(KERN_EMERG "done waiting: %d cpu(s) not responding\n",
+ ncpus - cpus_weight(cpus_in_crash));
+ printk(KERN_EMERG "Activate soft-reset to stop other cpu(s)\n");
+ cpus_in_sr = CPU_MASK_NONE;
+ atomic_set(&enter_on_soft_reset, 0);
+ while (cpus_weight(cpus_in_crash) < ncpus)
+ cpu_relax();
+ }
+ /*
+ * Make sure all CPUs are entered via soft-reset if the kdump is
+ * invoked using soft-reset.
+ */
+ if (cpu_isset(cpu, cpus_in_sr))
+ crash_soft_reset_check(cpu);
/* Leave the IPI callback set */
}
+
+/*
+ * This function will be called by secondary cpus or by kexec cpu
+ * if soft-reset is activated to stop some CPUs.
+ */
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ int cpu = smp_processor_id();
+ unsigned long flags;
+ int msecs = 5;
+
+ local_irq_save(flags);
+ /* Wait 5ms if the kexec CPU is not entered yet. */
+ while (crashing_cpu < 0) {
+ if (--msecs < 0) {
+ /*
+ * Either kdump image is not loaded or
+ * kdump process is not started - Probably xmon
+ * exited using 'x'(exit and recover) or
+ * kexec_should_crash() failed for all running tasks.
+ */
+ cpu_clear(cpu, cpus_in_sr);
+ local_irq_restore(flags);
+ return;
+ }
+ mdelay(1);
+ cpu_relax();
+ }
+ if (cpu == crashing_cpu) {
+ /*
+ * Panic CPU will enter this func only via soft-reset.
+ * Wait until all secondary CPUs entered and
+ * then start kexec boot.
+ */
+ crash_soft_reset_check(cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
+ machine_kexec(kexec_crash_image);
+ /* NOTREACHED */
+ }
+ crash_ipi_callback(regs);
+}
+
#else
-static void crash_kexec_prepare_cpus(void)
+static void crash_kexec_prepare_cpus(int cpu)
{
/*
* move the secondarys to us so that we can copy
@@ -170,6 +257,10 @@ static void crash_kexec_prepare_cpus(voi
smp_release_cpus();
}
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ cpus_in_sr = CPU_MASK_NONE;
+}
#endif
void default_machine_crash_shutdown(struct pt_regs *regs)
@@ -185,15 +276,14 @@ void default_machine_crash_shutdown(stru
* The kernel is broken so disable interrupts.
*/
local_irq_disable();
-
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 0);
-
/*
* Make a note of crashing cpu. Will be used in machine_kexec
* such that another IPI will not be sent.
*/
crashing_cpu = smp_processor_id();
- crash_kexec_prepare_cpus();
crash_save_this_cpu(regs, crashing_cpu);
+ crash_kexec_prepare_cpus(crashing_cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
}
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 064a525..ad6500e 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -51,9 +51,13 @@
#include <asm/firmware.h>
#include <asm/processor.h>
#endif
+#include <asm/kexec.h>
#ifdef CONFIG_PPC64 /* XXX */
#define _IO_BASE pci_io_base
+#ifdef CONFIG_KEXEC
+cpumask_t cpus_in_sr = CPU_MASK_NONE;
+#endif
#endif
#ifdef CONFIG_DEBUGGER
@@ -96,7 +100,7 @@ static DEFINE_SPINLOCK(die_lock);
int die(const char *str, struct pt_regs *regs, long err)
{
- static int die_counter, crash_dump_start = 0;
+ static int die_counter;
if (debugger(regs))
return 1;
@@ -128,22 +132,12 @@ int die(const char *str, struct pt_regs
print_modules();
show_regs(regs);
bust_spinlocks(0);
-
- if (!crash_dump_start && kexec_should_crash(current)) {
- crash_dump_start = 1;
- spin_unlock_irq(&die_lock);
- crash_kexec(regs);
- /* NOTREACHED */
- }
spin_unlock_irq(&die_lock);
- if (crash_dump_start)
- /*
- * Only for soft-reset: Other CPUs will be responded to an IPI
- * sent by first kexec CPU.
- */
- for(;;)
- ;
+ if (kexec_should_crash(current))
+ crash_kexec(regs);
+ crash_kexec_secondary(regs);
+
if (in_interrupt())
panic("Fatal exception in interrupt");
@@ -205,6 +199,10 @@ void system_reset_exception(struct pt_re
if (ppc_md.system_reset_exception(regs))
return;
}
+
+#ifdef CONFIG_KEXEC
+ cpu_set(smp_processor_id(), cpus_in_sr);
+#endif
die("System Reset", regs, SIGABRT);
diff --git a/include/asm-powerpc/kexec.h b/include/asm-powerpc/kexec.h
index 6a2af2f..82097b3 100644
--- a/include/asm-powerpc/kexec.h
+++ b/include/asm-powerpc/kexec.h
@@ -114,6 +114,7 @@ extern void kexec_smp_wait(void); /* get
extern void __init kexec_setup(void);
extern int crashing_cpu;
extern void crash_send_ipi(void (*crash_ipi_callback)(struct pt_regs *));
+extern cpumask_t cpus_in_sr;
#endif /* __powerpc64 __ */
struct kimage;
@@ -123,8 +124,10 @@ extern int default_machine_kexec_prepare
extern void default_machine_crash_shutdown(struct pt_regs *regs);
extern void machine_kexec_simple(struct kimage *image);
-
+extern void crash_kexec_secondary(struct pt_regs *regs);
#endif /* ! __ASSEMBLY__ */
+#else
+static inline void crash_kexec_secondary(struct pt_regs *regs) { }
#endif /* CONFIG_KEXEC */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_KEXEC_H */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index cfb3410..6427949 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -106,6 +106,7 @@ extern struct page *kimage_alloc_control
extern void crash_kexec(struct pt_regs *);
int kexec_should_crash(struct task_struct *);
extern struct kimage *kexec_image;
+extern struct kimage *kexec_crash_image;
#define KEXEC_ON_CRASH 0x00000001
#define KEXEC_ARCH_MASK 0xffff0000
^ permalink raw reply related
* Re: about ppc <asm/string.h>
From: Becky Bruce @ 2006-04-17 18:52 UTC (permalink / raw)
To: HappyPhot; +Cc: linuxppc-embedded
In-Reply-To: <026801c661ed$bcb352d0$0760120a@photon>
Hi!
There's no string.h in include/asm-ppc because this is one of the
header files that has been merged between 32 and 64-bit powerpc. It
now lives in include/asm-powerpc with all the other merged headers.
Only headers specific to 32-bit ppc have been left in include/asm-
ppc. For a kernel build with ARCH=ppc, the build uses headers from
both include/asm-ppc and include/asm-powerpc. This is accomplished
through the use of a temporary include directory that is created in
the arch dir. Check out arch/ppc/Makefile for details.
Cheers,
-Becky
On Apr 17, 2006, at 2:08 AM, HappyPhot wrote:
> Hi,
>
> Under linux kernel, the file /include/linux/string.h will include
> <asm/string.h>.
> But I didn't found "string.h" under "asm-ppc", my asm is link to
> asm-ppc
> (CPU is ppc). This makes me compile some code failed.
> (kernel version 2.6.x)
>
> Anybody knows about this ? Why there is no string.h under "asm-ppc"
> directory.
>
> thanks a lot,
> /Phot
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Trouble with 2.6.16 on ppc8xx ?
From: Marcelo Tosatti @ 2006-04-17 21:52 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604141050.56757.david.jander@protonic.nl>
Hi David,
On Fri, Apr 14, 2006 at 10:50:56AM +0200, David Jander wrote:
>
> Hi all,
>
> I just cg-update'd to the HEAD of the denx 2.6.x kernel tree (2.6.16 as
> released).
Is it a vanilla 2.6.16?
> Our board-support stuff was succesfully moved along from 2.6.14 (when
> everything but the SCC3 and SCC4 uarts worked just fine).
> I compiled a kernel without any special drivers, just console on ttyCPM0, but
> after "Uncompressing Kernel Image ... OK" there is no more output and no
> further activity on ethernet (it should boot from nfs-root) or any other
> device.
>
> After "cg-seek DENX-v2.6.15; make clean uImage", it works again (everything
> seems fine, system boots).
>
> Our board is based on a MPC852T and until now we used "MPC86X" as the
> BOARD_CHIP_NAME and it worked just fine with 2.6.14 and 2.6.15, but not with
> 2.6.16 as described above.
>
> When doing "cg-diff" and carfully examining it's output, I can only see our
> board-support stuff (not very much, not very special) and some custom drivers
> that are disabled anyway.
>
> Any clue about where to start looking?
>
> I didn't find any suspicious changes in arch/ppc/mm, arch/ppc/syslib and
> arch/ppc/kernel. Neither in drivers/serial/cpm_uart.
>
> Which change from 2.6.15 to 2.6.16 could have broken 8xx support for us?
>
> Is there perhaps a known issue with 2.6.16 and ppc8xx I am unaware of?
2.6.16 working fine over here... What's your .config?
[root@CAS root]# cat /proc/cpuinfo
processor : 0
cpu : 8xx
clock : 48MHz
bus clock : 48MHz
revision : 0.0 (pvr 0050 0000)
bogomips : 47.71
[root@CAS root]# uname -a
Linux CAS 2.6.16 #1 Thu Apr 13 11:08:03 PDT 2006 ppc unknown
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Benjamin Herrenschmidt @ 2006-04-17 20:51 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <je1wvwfh7s.fsf@sykes.suse.de>
On Mon, 2006-04-17 at 15:45 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > Interesting... I would have expected that setup to work... Oh well... at
> > this point, the best to do is to add support for your G5 to Johannes new
> > snd-aoa
>
> I agree. Unfortunately, the i2sbus probing already fails, due to
> requesting a memory region that is already (partially) claimed by other
> resources:
>
> request_mem_region(80000000 - 80000fff, i2sbus control)
>
> 80000000-8007ffff : 0.80000000:mac-io
> 8000002c-8000002f : 0.0000004c:fans
> 80000030-80000033 : 0.0000004c:fans
> 80000034-80000037 : 0.0000004c:fans
> 8000004c-8000004f : 0.0000004c:fans
> 80000050-8000008a : 0.00000050:gpio
Johannes,
Look like the bugs in the device-tree I told you about ...
Ben.
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Johannes Berg @ 2006-04-17 20:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1145307118.3912.11.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
On Tue, 2006-04-18 at 06:51 +1000, Benjamin Herrenschmidt wrote:
> >
> > request_mem_region(80000000 - 80000fff, i2sbus control)
> >
> > 80000000-8007ffff : 0.80000000:mac-io
> > 8000002c-8000002f : 0.0000004c:fans
> > 80000030-80000033 : 0.0000004c:fans
> > 80000034-80000037 : 0.0000004c:fans
> > 8000004c-8000004f : 0.0000004c:fans
> > 80000050-8000008a : 0.00000050:gpio
>
> Johannes,
>
> Look like the bugs in the device-tree I told you about ...
I suppose so. I guess I'll have to go hardcode it then. Ick.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: Xilinx Virtex-2 PRO FPGA ppc 405 on ML310 board
From: Vincent Winstead @ 2006-04-17 21:00 UTC (permalink / raw)
To: Aidan Williams; +Cc: linuxppc-embedded list
In-Reply-To: <443D7AF5.6030401@nicta.com.au>
[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]
OK - I think i'm on a roll now. I downloaded the necessary files for the uClinux distribution. Two questions:
1. I'm having a problem with two steps
Step 5. In your uClinux-dist directory, create a symbolic link called linux-2.4.x which points to the linuxppc-2.4 directory (linux-2.4.x -> ../linuxppc-2.4).
Step 6. Ensure that you have the latest uClinux EDK Board Support Package installed (version 1.00d or later is required).
Now, as far as step 5, am I supposed to have a symbolic link that is named linux-2.4.x placed into the uClinux-dist directory? Because there's already a folder named linux-2.4.x which was in there already when I untarred everything. At the command prompt in the uClinux-dist directory I entered the following line:
ln -s ../linuxppc-2.4 linux-2.4.x
and the result of this operation was to put a symbolic link into my linuxppc-2.4 directory with the name of linux-2.4.x - is this correct?
Now on to Step 6 problem.
How am I supposed to make use uClinux EDK Board Support Package 1.0 files? I'm not sure how to go about using them in the Xilinx Platform Studio in order to generate the necessary auto-config.in file.
-Vincent
Aidan Williams <aidan@nicta.com.au> wrote:
Grant Likely wrote:
> If you use 2.4: You need to use rsync to get the linuxppc-2.4 tree
> because I don't think anyone is maintaining .tar.gz of the rsync
> snapshot. Email Tom Rini and ask him. The linuxppc-2.4 tree is
> special because it's one of the trees that actually has the ML300
> patches integrated. Mainline does not.
>
For 2.4, I've had good success on two different boards
using the v2pro and virtex4 parts with:
http://www.itee.uq.edu.au/~pml/uclinux_powerpc/
The kernel tarball there has support for various xilinx
supplied peripheral cores..
The neat thing about this approach is that there is a
uclinux BSP for the EDK that is used to generate an
auto-config.in file which you then drop directly
into the linux kernel tree.
Even though it is about the microblaze rather than
the PPC, a helpful "getting started" document is:
http://www.itee.uq.edu.au/~wu/downloads/uClinux_ready_Microblaze_design.pdf
- aidan
[-- Attachment #2: Type: text/html, Size: 2985 bytes --]
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Ravikiran G Thirumalai @ 2006-04-17 20:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Christoph Lameter, Joe Taylor, Andi Kleen,
linuxppc-dev, Paul Mackerras, benedict.gaster, bjornw,
Ingo Molnar, Nick Piggin, grundler, rusty, Steven Rostedt,
starvik, Linus Torvalds, Thomas Gleixner, rth, Chris Zankel,
tony.luck, LKML, ralf, Marc Gauthier, lethal, schwidefsky,
linux390, davem, parisc-linux
In-Reply-To: <200604161734.20256.arnd@arndb.de>
On Sun, Apr 16, 2006 at 05:34:18PM +0200, Arnd Bergmann wrote:
> On Sunday 16 April 2006 15:40, Steven Rostedt wrote:
> > I'll think more about this, but maybe someone else has some crazy ideas
> > that can find a solution to this that is both fast and robust.
>
> Ok, you asked for a crazy idea, you're going to get it ;-)
>
> You could take a fixed range from the vmalloc area (e.g. 1MB per cpu)
> and use that to remap pages on demand when you need per cpu data.
>
> #define PER_CPU_BASE 0xe000000000000000UL /* arch dependant */
> #define PER_CPU_SHIFT 0x100000UL
> #define __per_cpu_offset(__cpu) (PER_CPU_BASE + PER_CPU_STRIDE * (__cpu))
> #define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset(cpu)))
> #define __get_cpu_var(var) per_cpu(var, smp_processor_id())
>
> This is a lot like the current sparc64 implementation already is.
>
> The tricky part here is the remapping of pages. You'd need to
> alloc_pages_node() new pages whenever the already reserved space is
> not enough for the module you want to load and then map_vm_area()
> them into the space reserved for them.
>
> Advantages of this solution are:
> - no dependant load access for per_cpu()
> - might be flexible enough to implement a faster per_cpu_ptr()
> - can be combined with ia64-style per-cpu remapping
An implemenation similar to one you are mentioning was already proposed
sometime back.
http://lwn.net/Articles/119532/
The design was also meant to not restrict/limit per-cpu memory being
allocated from modules. Maybe it was too early then, and maybe now is the
right time, going by the interest in this thread :). IMHO, a new solution
should fix both static and dynamic per-cpu allocators,
- Avoid possibility of false sharing for dynamically allocated per-CPU data
(with current alloc percpu)
- work early enough -- if alloc_percpu can work early enough, (we can use
that for counters like slab cachep stats which is currently racy; using
atomic_t for them would be bad for performance)
An extra dereference in Steven's original proposal is bad, (I had done some
measurements earlier). My implementation had one less reference compared to
static per-cpu allocators, but the performance of both were the same as
the __per_cpu_offset table is always cache hot.
>
> Disadvantages are:
> - you can't use huge tlbs for mapping per cpu data like the
> regular linear mapping -> may be slower on some archs
Yep, we waste a few tlb entries then, which is a bit of concern, but then we
might be able to use hugetlbs for blocks of per-cpu data and minimize the
impact.
Thanks,
Kiran
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Andreas Schwab @ 2006-04-17 21:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <1145307118.3912.11.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Mon, 2006-04-17 at 15:45 +0200, Andreas Schwab wrote:
>> request_mem_region(80000000 - 80000fff, i2sbus control)
>>
>> 80000000-8007ffff : 0.80000000:mac-io
>> 8000002c-8000002f : 0.0000004c:fans
>> 80000030-80000033 : 0.0000004c:fans
>> 80000034-80000037 : 0.0000004c:fans
>> 8000004c-8000004f : 0.0000004c:fans
>> 80000050-8000008a : 0.00000050:gpio
>
> Johannes,
>
> Look like the bugs in the device-tree I told you about ...
There is special support for K2-Keylargo in sound/ppc/pmac.c, is it that
what you mean?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Benjamin Herrenschmidt @ 2006-04-17 21:50 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <jey7y3dgzw.fsf@sykes.suse.de>
On Mon, 2006-04-17 at 23:33 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > On Mon, 2006-04-17 at 15:45 +0200, Andreas Schwab wrote:
> >> request_mem_region(80000000 - 80000fff, i2sbus control)
> >>
> >> 80000000-8007ffff : 0.80000000:mac-io
> >> 8000002c-8000002f : 0.0000004c:fans
> >> 80000030-80000033 : 0.0000004c:fans
> >> 80000034-80000037 : 0.0000004c:fans
> >> 8000004c-8000004f : 0.0000004c:fans
> >> 80000050-8000008a : 0.00000050:gpio
> >
> > Johannes,
> >
> > Look like the bugs in the device-tree I told you about ...
>
> There is special support for K2-Keylargo in sound/ppc/pmac.c, is it that
> what you mean?
Yes, though it doesn't seem to affect all K2 based models, thus in this
regard, snd-powermac isn't bug free neither ... Apple keeps fucking up
their device-tree in all sort of funny ways.. at least kept, hopfeully
this is finished now :)
Ben.
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Ravikiran G Thirumalai @ 2006-04-17 22:02 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, Nick Piggin, grundler,
Steven Rostedt, starvik, Linus Torvalds, Thomas Gleixner, rth,
Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <Pine.LNX.4.64.0604170953390.29732@schroedinger.engr.sgi.com>
On Mon, Apr 17, 2006 at 09:55:02AM -0700, Christoph Lameter wrote:
> On Sat, 15 Apr 2006, Nick Piggin wrote:
>
> > If I'm following you correctly, this adds another dependent load
> > to a per-CPU data access, and from memory that isn't node-affine.
>
> I am also concerned about that. Kiran has a patch to avoid allocpercpu
> having to go through one level of indirection that I guess would no
> longer work with this scheme.
The alloc_percpu reimplementation would work regardless of changes to
static per-cpu areas. But, any extra indirection as was proposed initially
is bad IMHO.
>
> > If so, I think people with SMP and NUMA kernels would care more
> > about performance and scalability than the few k of memory this
> > saves.
>
> Right.
Me too :)
Kiran
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt @ 2006-04-17 23:44 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, Christoph Lameter,
Nick Piggin, grundler, starvik, Linus Torvalds, Thomas Gleixner,
rth, Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <20060417220238.GD3945@localhost.localdomain>
On Mon, 17 Apr 2006, Ravikiran G Thirumalai wrote:
> On Mon, Apr 17, 2006 at 09:55:02AM -0700, Christoph Lameter wrote:
> > On Sat, 15 Apr 2006, Nick Piggin wrote:
> >
> > > If I'm following you correctly, this adds another dependent load
> > > to a per-CPU data access, and from memory that isn't node-affine.
> >
> > I am also concerned about that. Kiran has a patch to avoid allocpercpu
> > having to go through one level of indirection that I guess would no
> > longer work with this scheme.
>
> The alloc_percpu reimplementation would work regardless of changes to
> static per-cpu areas. But, any extra indirection as was proposed initially
> is bad IMHO.
>
Don't worry, that idea has been shot down more than once ;-)
> >
> > > If so, I think people with SMP and NUMA kernels would care more
> > > about performance and scalability than the few k of memory this
> > > saves.
> >
> > Right.
>
> Me too :)
>
Understood, but I'm going to start looking in the way Rusty and Arnd
suggested with the vmalloc approach. This would allow for saving of
memory and dynamic allocation of module memory making it more robust. And
all this without that evil extra indirection!
So lets put my original patches where they belong, in the bit grave and
continue on. I lived, I learned and I've been shown the Way (thanks to
all BTW).
So now we can focus on a better solution.
Cheers,
-- Steve
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Christoph Lameter @ 2006-04-17 23:48 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, Ravikiran G Thirumalai,
Nick Piggin, grundler, starvik, Linus Torvalds, Thomas Gleixner,
rth, Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <Pine.LNX.4.58.0604171936040.24264@gandalf.stny.rr.com>
On Mon, 17 Apr 2006, Steven Rostedt wrote:
> So now we can focus on a better solution.
Could you have a look at Kiran's work?
Maybe one result of your work could be that the existing indirection
for alloc_percpu could be avoided?
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt @ 2006-04-18 1:51 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, Ravikiran G Thirumalai,
Nick Piggin, grundler, starvik, Linus Torvalds, Thomas Gleixner,
rth, Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <Pine.LNX.4.64.0604171647330.31773@schroedinger.engr.sgi.com>
On Mon, 2006-04-17 at 16:48 -0700, Christoph Lameter wrote:
> On Mon, 17 Apr 2006, Steven Rostedt wrote:
>
> > So now we can focus on a better solution.
>
> Could you have a look at Kiran's work?
>
> Maybe one result of your work could be that the existing indirection
> for alloc_percpu could be avoided?
Sure, I'll spend some time looking at what others have done and see
what I can put together. I'm also very busy on other stuff at the
moment, so this will be something I do more on the side. Don't think
there's a rush here, but I stated in a previous post, I probably wont
have something out for a month or two.
-- Steve
^ permalink raw reply
* Re: Xilinx Virtex-2 PRO FPGA ppc 405 on ML310 board
From: Aidan Williams @ 2006-04-18 2:45 UTC (permalink / raw)
To: Vincent Winstead; +Cc: linuxppc-embedded list
In-Reply-To: <20060417210038.18561.qmail@web52008.mail.yahoo.com>
Vincent Winstead wrote:
> Now, as far as step 5, am I supposed to have a symbolic link that is
> named linux-2.4.x placed into the uClinux-dist directory? Because
> there's already a folder named linux-2.4.x which was in there already
> when I untarred everything. At the command prompt in the uClinux-dist
> directory I entered the following line:
>
> ln -s ../linuxppc-2.4 linux-2.4.x
>
> and the result of this operation was to put a symbolic link into my
> linuxppc-2.4 directory with the name of linux-2.4.x - is this correct?
>
First, you'll need to move the existing directory aside using
a command like:
mv linux-2.4.x linux-2.4.x-dist
and then re-run the ln -s command above.
> Now on to Step 6 problem.
> How am I supposed to make use uClinux EDK Board Support Package 1.0
> files? I'm not sure how to go about using them in the Xilinx Platform
> Studio in order to generate the necessary auto-config.in file.
>
See the document below for the general approach:
> Even though it is about the microblaze rather than
> the PPC, a helpful "getting started" document is:
> http://www.itee.uq.edu.au/~wu/downloads/uClinux_ready_Microblaze_design.pdf
>
Look particularly at the section "Software Platform Settings"
on page 29, steps 67,68.
If you are not overly familiar with the EDK, it would
be best to find someone locally who can help walk you
through the process of generating a system.
- aidan
--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.
^ permalink raw reply
* [PATCH] powermac: Fix i2c on keywest based chips
From: Benjamin Herrenschmidt @ 2006-04-18 4:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The new i2c implementation for PowerMac has a regression that causes the
hardware to go out of state when probing non-existent devices. While
fixing that, I also found & fixed a couple of other corner cases. This
fixes booting with a pbbuttons version that scans the i2c bus for an LMU
controller among others. Tested on a dual G5 with thermal control (which
has heavy i2c activity) with no problem so far.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/platforms/powermac/low_i2c.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/low_i2c.c 2006-04-17 16:08:42.000000000 +1000
+++ linux-work/arch/powerpc/platforms/powermac/low_i2c.c 2006-04-17 16:41:32.000000000 +1000
@@ -231,6 +231,14 @@
return isr;
}
+static void kw_i2c_do_stop(struct pmac_i2c_host_kw *host, int result)
+{
+ kw_write_reg(reg_control, KW_I2C_CTL_STOP);
+ host->state = state_stop;
+ host->result = result;
+}
+
+
static void kw_i2c_handle_interrupt(struct pmac_i2c_host_kw *host, u8 isr)
{
u8 ack;
@@ -246,42 +254,36 @@
}
if (isr == 0) {
+ printk(KERN_WARNING "low_i2c: Timeout in i2c transfer"
+ " on keywest !\n");
if (host->state != state_stop) {
- DBG_LOW("KW: Timeout !\n");
- host->result = -EIO;
- goto stop;
- }
- if (host->state == state_stop) {
- ack = kw_read_reg(reg_status);
- if (ack & KW_I2C_STAT_BUSY)
- kw_write_reg(reg_status, 0);
- host->state = state_idle;
- kw_write_reg(reg_ier, 0x00);
- if (!host->polled)
- complete(&host->complete);
+ kw_i2c_do_stop(host, -EIO);
+ return;
}
+ ack = kw_read_reg(reg_status);
+ if (ack & KW_I2C_STAT_BUSY)
+ kw_write_reg(reg_status, 0);
+ host->state = state_idle;
+ kw_write_reg(reg_ier, 0x00);
+ if (!host->polled)
+ complete(&host->complete);
return;
}
if (isr & KW_I2C_IRQ_ADDR) {
ack = kw_read_reg(reg_status);
if (host->state != state_addr) {
- kw_write_reg(reg_isr, KW_I2C_IRQ_ADDR);
WRONG_STATE("KW_I2C_IRQ_ADDR");
- host->result = -EIO;
- goto stop;
+ kw_i2c_do_stop(host, -EIO);
}
if ((ack & KW_I2C_STAT_LAST_AAK) == 0) {
- host->result = -ENODEV;
- DBG_LOW("KW: NAK on address\n");
+ host->result = -ENXIO;
host->state = state_stop;
- return;
+ DBG_LOW("KW: NAK on address\n");
} else {
- if (host->len == 0) {
- kw_write_reg(reg_isr, KW_I2C_IRQ_ADDR);
- goto stop;
- }
- if (host->rw) {
+ if (host->len == 0)
+ kw_i2c_do_stop(host, 0);
+ else if (host->rw) {
host->state = state_read;
if (host->len > 1)
kw_write_reg(reg_control,
@@ -308,25 +310,19 @@
ack = kw_read_reg(reg_status);
if ((ack & KW_I2C_STAT_LAST_AAK) == 0) {
DBG_LOW("KW: nack on data write\n");
- host->result = -EIO;
- goto stop;
+ host->result = -EFBIG;
+ host->state = state_stop;
} else if (host->len) {
kw_write_reg(reg_data, *(host->data++));
host->len--;
- } else {
- kw_write_reg(reg_control, KW_I2C_CTL_STOP);
- host->state = state_stop;
- host->result = 0;
- }
- kw_write_reg(reg_isr, KW_I2C_IRQ_DATA);
+ } else
+ kw_i2c_do_stop(host, 0);
} else {
- kw_write_reg(reg_isr, KW_I2C_IRQ_DATA);
WRONG_STATE("KW_I2C_IRQ_DATA");
- if (host->state != state_stop) {
- host->result = -EIO;
- goto stop;
- }
+ if (host->state != state_stop)
+ kw_i2c_do_stop(host, -EIO);
}
+ kw_write_reg(reg_isr, KW_I2C_IRQ_DATA);
}
if (isr & KW_I2C_IRQ_STOP) {
@@ -340,14 +336,10 @@
complete(&host->complete);
}
+ /* Below should only happen in manual mode which we don't use ... */
if (isr & KW_I2C_IRQ_START)
kw_write_reg(reg_isr, KW_I2C_IRQ_START);
- return;
- stop:
- kw_write_reg(reg_control, KW_I2C_CTL_STOP);
- host->state = state_stop;
- return;
}
/* Interrupt handler */
@@ -544,11 +536,11 @@
return NULL;
}
- /* Make sure IRA is disabled */
+ /* Make sure IRQ is disabled */
kw_write_reg(reg_ier, 0);
/* Request chip interrupt */
- if (request_irq(host->irq, kw_i2c_irq, SA_SHIRQ, "keywest i2c", host))
+ if (request_irq(host->irq, kw_i2c_irq, 0, "keywest i2c", host))
host->irq = NO_IRQ;
printk(KERN_INFO "KeyWest i2c @0x%08x irq %d %s\n",
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Paul Mackerras @ 2006-04-18 5:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <1145048461.4223.38.camel@localhost.localdomain>
Benjamin Herrenschmidt writes:
> Looks good to me except that we need the same for ppc64 since the 970
> theorically has the same problem...
OK, does this look OK to everyone, before I send it off to Linus? I
now use a bit in the thread_info rather than using the HID0 bits
themselves to indicate that we're napping, since the m[ft]spr might be
slow. I added a `local_flags' field to the thread_info struct for
things that are only changed by the task itself and therefore don't
need to be accessed atomically.
This version does the same sort of change for the 970 as for 6xx.
Oh, and I also fixed a stupid bug in the 32-bit stack overflow code,
where we put &_end into r11, and then if there was a stack overflow,
saved registers into the stack frame pointed to by r11. :)
Paul.
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 54b48f3..8f85c5e 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -91,6 +91,7 @@ #endif /* CONFIG_SPE */
#endif /* CONFIG_PPC64 */
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
+ DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, local_flags));
DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count));
DEFINE(TI_TASK, offsetof(struct thread_info, task));
#ifdef CONFIG_PPC32
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index b3a9794..8866fd2 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -128,37 +128,36 @@ #if defined(CONFIG_40x) || defined(CONFI
stw r12,4(r11)
#endif
b 3f
+
2: /* if from kernel, check interrupted DOZE/NAP mode and
* check for stack overflow
*/
+ lwz r9,THREAD_INFO-THREAD(r12)
+ cmplw r1,r9 /* if r1 <= current->thread_info */
+ ble- stack_ovf /* then the kernel stack overflowed */
+5:
#ifdef CONFIG_6xx
- mfspr r11,SPRN_HID0
- mtcr r11
-BEGIN_FTR_SECTION
- bt- 8,4f /* Check DOZE */
-END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
-BEGIN_FTR_SECTION
- bt- 9,4f /* Check NAP */
-END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
+ tophys(r9,r9) /* check local flags */
+ lwz r12,TI_LOCAL_FLAGS(r9)
+ mtcrf 0x01,r12
+ bt- 31-TLF_NAPPING,4f
#endif /* CONFIG_6xx */
.globl transfer_to_handler_cont
transfer_to_handler_cont:
- lwz r11,THREAD_INFO-THREAD(r12)
- cmplw r1,r11 /* if r1 <= current->thread_info */
- ble- stack_ovf /* then the kernel stack overflowed */
3:
mflr r9
lwz r11,0(r9) /* virtual address of handler */
lwz r9,4(r9) /* where to go when done */
- FIX_SRR1(r10,r12)
mtspr SPRN_SRR0,r11
mtspr SPRN_SRR1,r10
mtlr r9
SYNC
RFI /* jump to handler, enable MMU */
-#ifdef CONFIG_6xx
-4: b power_save_6xx_restore
+#ifdef CONFIG_6xx
+4: rlwinm r12,r12,0,~_TLF_NAPPING
+ stw r12,TI_LOCAL_FLAGS(r9)
+ b power_save_6xx_restore
#endif
/*
@@ -167,10 +166,10 @@ #endif
*/
stack_ovf:
/* sometimes we use a statically-allocated stack, which is OK. */
- lis r11,_end@h
- ori r11,r11,_end@l
- cmplw r1,r11
- ble 3b /* r1 <= &_end is OK */
+ lis r12,_end@h
+ ori r12,r12,_end@l
+ cmplw r1,r12
+ ble 5b /* r1 <= &_end is OK */
SAVE_NVGPRS(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
lis r1,init_thread_union@ha
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index a5ae04a..3b500dc 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -381,6 +381,7 @@ #define STD_EXCEPTION_COMMON_LITE(trap,
.globl label##_common; \
label##_common: \
EXCEPTION_PROLOG_COMMON(trap, PACA_EXGEN); \
+ FINISH_NAP; \
DISABLE_INTS; \
bl .ppc64_runlatch_on; \
addi r3,r1,STACK_FRAME_OVERHEAD; \
@@ -388,6 +389,25 @@ label##_common: \
b .ret_from_except_lite
/*
+ * When the idle code in power4_idle puts the CPU into NAP mode,
+ * it has to do so in a loop, and relies on the external interrupt
+ * and decrementer interrupt entry code to get it out of the loop.
+ * It sets the _TLF_NAPPING bit in current_thread_info()->local_flags
+ * to signal that it is in the loop and needs help to get out.
+ */
+#if defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_MAPLE)
+#define FINISH_NAP \
+BEGIN_FTR_SECTION \
+ clrrdi r11,r1,THREAD_SHIFT; \
+ ld r9,TI_LOCAL_FLAGS(r11); \
+ andi. r10,r9,_TLF_NAPPING; \
+ bnel power4_fixup_nap; \
+END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
+#else
+#define FINISH_NAP
+#endif
+
+/*
* Start of pSeries system interrupt routines
*/
. = 0x100
@@ -1034,12 +1054,22 @@ unrecov_slb:
.globl hardware_interrupt_entry
hardware_interrupt_common:
EXCEPTION_PROLOG_COMMON(0x500, PACA_EXGEN)
+ FINISH_NAP
hardware_interrupt_entry:
DISABLE_INTS
bl .ppc64_runlatch_on
addi r3,r1,STACK_FRAME_OVERHEAD
bl .do_IRQ
b .ret_from_except_lite
+
+#if defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_MAPLE)
+power4_fixup_nap:
+ andc r9,r9,r10
+ std r9,TI_LOCAL_FLAGS(r11)
+ ld r10,_LINK(r1) /* make idle task do the */
+ std r10,_NIP(r1) /* equivalent of a blr */
+ blr
+#endif
.align 7
.globl alignment_common
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index 12a4efb..b45fa0e 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -22,8 +22,6 @@ #include <asm/thread_info.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
-#undef DEBUG
-
.text
/*
@@ -109,12 +107,6 @@ BEGIN_FTR_SECTION
dcbf 0,r4
dcbf 0,r4
END_FTR_SECTION_IFSET(CPU_FTR_NAP_DISABLE_L2_PR)
-#ifdef DEBUG
- lis r6,nap_enter_count@ha
- lwz r4,nap_enter_count@l(r6)
- addi r4,r4,1
- stw r4,nap_enter_count@l(r6)
-#endif
2:
BEGIN_FTR_SECTION
/* Go to low speed mode on some 750FX */
@@ -144,48 +136,42 @@ BEGIN_FTR_SECTION
DSSALL
sync
END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
+ rlwinm r9,r1,0,0,31-THREAD_SHIFT /* current thread_info */
+ lwz r8,TI_LOCAL_FLAGS(r9) /* set napping bit */
+ ori r8,r8,_TLF_NAPPING /* so when we take an exception */
+ stw r8,TI_LOCAL_FLAGS(r9) /* it will return to our caller */
mfmsr r7
ori r7,r7,MSR_EE
oris r7,r7,MSR_POW@h
- sync
- isync
+1: sync
mtmsr r7
isync
- sync
- blr
-
+ b 1b
+
/*
* Return from NAP/DOZE mode, restore some CPU specific registers,
* we are called with DR/IR still off and r2 containing physical
- * address of current.
+ * address of current. R11 points to the exception frame (physical
+ * address). We have to preserve r10.
*/
_GLOBAL(power_save_6xx_restore)
- mfspr r11,SPRN_HID0
- rlwinm. r11,r11,0,10,8 /* Clear NAP & copy NAP bit !state to cr1 EQ */
- cror 4*cr1+eq,4*cr0+eq,4*cr0+eq
-BEGIN_FTR_SECTION
- rlwinm r11,r11,0,9,7 /* Clear DOZE */
-END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
- mtspr SPRN_HID0, r11
-
-#ifdef DEBUG
- beq cr1,1f
- lis r11,(nap_return_count-KERNELBASE)@ha
- lwz r9,nap_return_count@l(r11)
- addi r9,r9,1
- stw r9,nap_return_count@l(r11)
-1:
-#endif
-
- rlwinm r9,r1,0,0,18
- tophys(r9,r9)
- lwz r11,TI_CPU(r9)
+ lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
+ stw r9,_NIP(r11) /* make it do a blr */
+
+#ifdef CONFIG_SMP
+ mfspr r12,SPRN_SPRG3
+ lwz r11,TI_CPU(r12) /* get cpu number * 4 */
slwi r11,r11,2
+#else
+ li r11,0
+#endif
/* Todo make sure all these are in the same page
- * and load r22 (@ha part + CPU offset) only once
+ * and load r11 (@ha part + CPU offset) only once
*/
BEGIN_FTR_SECTION
- beq cr1,1f
+ mfspr r9,SPRN_HID0
+ andis. r9,r9,HID0_NAP@h
+ beq 1f
addis r9,r11,(nap_save_msscr0-KERNELBASE)@ha
lwz r9,nap_save_msscr0@l(r9)
mtspr SPRN_MSSCR0, r9
@@ -210,10 +196,3 @@ _GLOBAL(nap_save_hid1)
_GLOBAL(powersave_lowspeed)
.long 0
-
-#ifdef DEBUG
-_GLOBAL(nap_enter_count)
- .space 4
-_GLOBAL(nap_return_count)
- .space 4
-#endif
diff --git a/arch/powerpc/kernel/idle_power4.S b/arch/powerpc/kernel/idle_power4.S
index 6dad1c0..d85c7c9 100644
--- a/arch/powerpc/kernel/idle_power4.S
+++ b/arch/powerpc/kernel/idle_power4.S
@@ -35,12 +35,16 @@ BEGIN_FTR_SECTION
DSSALL
sync
END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
+ clrrdi r9,r1,THREAD_SHIFT /* current thread_info */
+ ld r8,TI_LOCAL_FLAGS(r9) /* set napping bit */
+ ori r8,r8,_TLF_NAPPING /* so when we take an exception */
+ std r8,TI_LOCAL_FLAGS(r9) /* it will return to our caller */
mfmsr r7
ori r7,r7,MSR_EE
oris r7,r7,MSR_POW@h
- sync
+1: sync
isync
mtmsrd r7
isync
- sync
- blr
+ b 1b
+
diff --git a/include/asm-powerpc/thread_info.h b/include/asm-powerpc/thread_info.h
index ffc7462..88b553c 100644
--- a/include/asm-powerpc/thread_info.h
+++ b/include/asm-powerpc/thread_info.h
@@ -37,6 +37,8 @@ struct thread_info {
int preempt_count; /* 0 => preemptable,
<0 => BUG */
struct restart_block restart_block;
+ unsigned long local_flags; /* private flags for thread */
+
/* low level flags - has atomic operations done on it */
unsigned long flags ____cacheline_aligned_in_smp;
};
@@ -142,6 +144,12 @@ #define _TIF_SYSCALL_T_OR_A (_TIF_SYSCAL
#define _TIF_USER_WORK_MASK (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | \
_TIF_NEED_RESCHED | _TIF_RESTORE_SIGMASK)
#define _TIF_PERSYSCALL_MASK (_TIF_RESTOREALL|_TIF_NOERROR)
+
+/* Bits in local_flags */
+/* Don't move TLF_NAPPING without adjusting the code in entry_32.S */
+#define TLF_NAPPING 0 /* idle thread enabled NAP mode */
+
+#define _TLF_NAPPING (1 << TLF_NAPPING)
#endif /* __KERNEL__ */
^ permalink raw reply related
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Benjamin Herrenschmidt @ 2006-04-18 6:00 UTC (permalink / raw)
To: Paul Mackerras
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <17476.31998.168122.413195@cargo.ozlabs.ibm.com>
On Tue, 2006-04-18 at 15:45 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > Looks good to me except that we need the same for ppc64 since the 970
> > theorically has the same problem...
>
> OK, does this look OK to everyone, before I send it off to Linus? I
> now use a bit in the thread_info rather than using the HID0 bits
> themselves to indicate that we're napping, since the m[ft]spr might be
> slow. I added a `local_flags' field to the thread_info struct for
> things that are only changed by the task itself and therefore don't
> need to be accessed atomically.
>
> This version does the same sort of change for the 970 as for 6xx.
Hrm...
The 970 version bloats the exception prolog significantly... I
understand now why you were talking about putting the code in the exit
path on irc ... I don't like it that way.... Also, if you want to keep
it, maybe use a separate CONFIG_PPC_970STYLE_NAP or something that gets
selected by platforms that can do it ?
I suppose a PACA field would be less inefficient but still sucks... the
exception return to userland code path already accesses thread_info and
definitely looks like a better place to put it... as long as we never
have to add dodgy workarounds when getting out of NAP like we do on 6xx.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc64-soft-reset-fixes
From: Andrew Morton @ 2006-04-18 6:12 UTC (permalink / raw)
To: David Wilder; +Cc: linuxppc-dev, fastboot
In-Reply-To: <4443D738.3040704@us.ibm.com>
David Wilder <dwilder@us.ibm.com> wrote:
>
> - For the crash scenario, when a CPU hangs with interrupts disabled and
> the other CPUs panic or user invoked kdump boot using sysrq-c. In this
> case, the hung CPU can not be stopped and causes the kdump boot not
> successful. This case can be treated as complete system hang and asks
> the user to activate soft-reset if all secondary CPUs are not stopped.
It breaks `make allmodconfig':
arch/powerpc/kernel/built-in.o(.toc+0x2a00): In function `PPC64_CACHES':
: undefined reference to `kexec_crash_image'
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Paul Mackerras @ 2006-04-18 6:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <1145340034.4705.55.camel@localhost.localdomain>
Benjamin Herrenschmidt writes:
> The 970 version bloats the exception prolog significantly... I
Four instructions, in the external and decrementer interrupt entry
paths - I don't think that's really significant bloat.
> understand now why you were talking about putting the code in the exit
> path on irc ... I don't like it that way.... Also, if you want to keep
> it, maybe use a separate CONFIG_PPC_970STYLE_NAP or something that gets
> selected by platforms that can do it ?
The config option makes sense.
> I suppose a PACA field would be less inefficient but still sucks... the
> exception return to userland code path already accesses thread_info and
> definitely looks like a better place to put it... as long as we never
> have to add dodgy workarounds when getting out of NAP like we do on 6xx.
More likely we'll get more situations like Cell where we come in
through the soft reset vector after sleep.
Paul.
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Benjamin Herrenschmidt @ 2006-04-18 6:37 UTC (permalink / raw)
To: Paul Mackerras
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <17476.34830.897083.360572@cargo.ozlabs.ibm.com>
On Tue, 2006-04-18 at 16:32 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > The 970 version bloats the exception prolog significantly... I
>
> Four instructions, in the external and decrementer interrupt entry
> paths - I don't think that's really significant bloat.
Yeah well.. including a load.. ok, I admit that should be fairly hot...
btw, I suppose you took care of having those local flags in some hot
cache line ? :)
> More likely we'll get more situations like Cell where we come in
> through the soft reset vector after sleep.
Yeah.
Ben.
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Nick Piggin @ 2006-04-18 6:42 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, Ravikiran G Thirumalai,
Christoph Lameter, grundler, starvik, Linus Torvalds,
Thomas Gleixner, rth, Chris Zankel, tony.luck, LKML, ralf,
Marc Gauthier, lethal, schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <Pine.LNX.4.58.0604171936040.24264@gandalf.stny.rr.com>
Steven Rostedt wrote:
> Understood, but I'm going to start looking in the way Rusty and Arnd
> suggested with the vmalloc approach. This would allow for saving of
> memory and dynamic allocation of module memory making it more robust. And
> all this without that evil extra indirection!
Remember that this approach could effectively just move the indirection to
the TLB / page tables (well, I say "moves" because large kernel mappings
are effectively free compared with 4K mappings).
So be careful about coding up a large amount of work before unleashing it:
I doubt you'll be able to find a solution that doesn't involve tradeoffs
somewhere (but wohoo if you can).
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* isochronous mode of USB audio device on MPC5200
From: Sundar @ 2006-04-18 4:42 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 175 bytes --]
Hi Benny,
I am also facing the same problem. Can you send me the details about the changes you have done.
Thank you for any help.
with warm regards,
sundar
[-- Attachment #2: Type: text/html, Size: 806 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox