* [PATCH 8/8] powerpc/kdump: Disable ftrace during kexec
From: Anton Blanchard @ 2011-01-07 4:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
We should disable ftrace during kexec, some of the tracers are very invasive
and we do not want them going off while doing the low level work of swapping
one kernel out for another. This mirrors what we do on x86.
Even though we cannot return from a kexec on powerpc (since we do not implement
CONFIG_KEXEC_JUMP), add the restore code in case we do one day.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:56.222461754 +1100
+++ powerpc.git/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:52:02.012644243 +1100
@@ -15,6 +15,7 @@
#include <linux/memblock.h>
#include <linux/of.h>
#include <linux/irq.h>
+#include <linux/ftrace.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -82,8 +83,14 @@ void arch_crash_save_vmcoreinfo(void)
*/
void machine_kexec(struct kimage *image)
{
+ int save_ftrace_enabled;
+
+ save_ftrace_enabled = __ftrace_enabled_save();
+
default_machine_kexec(image);
+ __ftrace_enabled_restore(save_ftrace_enabled);
+
/* Fall back to normal restart if we're still alive. */
machine_restart(NULL);
for(;;);
^ permalink raw reply
* [PATCH 7/8] powerpc/kdump: Move crash_kexec_stop_spus to kdump crash handler
From: Anton Blanchard @ 2011-01-07 3:59 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
Use the crash handler hooks to run the SPU stop code, just like we do for
ehea and cell RAS code.
While I'm here I noticed "CPUSs reliabally"
so fix the spelling MISTAKESs reliabally.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/crash.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/crash.c 2010-12-13 22:52:03.475242242 +1100
+++ powerpc.git/arch/powerpc/kernel/crash.c 2011-01-07 12:52:00.812606428 +1100
@@ -48,7 +48,7 @@ int crashing_cpu = -1;
static cpumask_t cpus_in_crash = CPU_MASK_NONE;
cpumask_t cpus_in_sr = CPU_MASK_NONE;
-#define CRASH_HANDLER_MAX 2
+#define CRASH_HANDLER_MAX 3
/* NULL terminated list of shutdown handles */
static crash_shutdown_t crash_shutdown_handles[CRASH_HANDLER_MAX+1];
static DEFINE_SPINLOCK(crash_handlers_lock);
@@ -125,7 +125,7 @@ static void crash_kexec_prepare_cpus(int
smp_wmb();
/*
- * FIXME: Until we will have the way to stop other CPUSs reliabally,
+ * FIXME: Until we will have the way to stop other CPUs reliably,
* the crash CPU will send an IPI and wait for other CPUs to
* respond.
* Delay of at least 10 seconds.
@@ -254,72 +254,6 @@ void crash_kexec_secondary(struct pt_reg
cpus_in_sr = CPU_MASK_NONE;
}
#endif
-#ifdef CONFIG_SPU_BASE
-
-#include <asm/spu.h>
-#include <asm/spu_priv1.h>
-
-struct crash_spu_info {
- struct spu *spu;
- u32 saved_spu_runcntl_RW;
- u32 saved_spu_status_R;
- u32 saved_spu_npc_RW;
- u64 saved_mfc_sr1_RW;
- u64 saved_mfc_dar;
- u64 saved_mfc_dsisr;
-};
-
-#define CRASH_NUM_SPUS 16 /* Enough for current hardware */
-static struct crash_spu_info crash_spu_info[CRASH_NUM_SPUS];
-
-static void crash_kexec_stop_spus(void)
-{
- struct spu *spu;
- int i;
- u64 tmp;
-
- for (i = 0; i < CRASH_NUM_SPUS; i++) {
- if (!crash_spu_info[i].spu)
- continue;
-
- spu = crash_spu_info[i].spu;
-
- crash_spu_info[i].saved_spu_runcntl_RW =
- in_be32(&spu->problem->spu_runcntl_RW);
- crash_spu_info[i].saved_spu_status_R =
- in_be32(&spu->problem->spu_status_R);
- crash_spu_info[i].saved_spu_npc_RW =
- in_be32(&spu->problem->spu_npc_RW);
-
- crash_spu_info[i].saved_mfc_dar = spu_mfc_dar_get(spu);
- crash_spu_info[i].saved_mfc_dsisr = spu_mfc_dsisr_get(spu);
- tmp = spu_mfc_sr1_get(spu);
- crash_spu_info[i].saved_mfc_sr1_RW = tmp;
-
- tmp &= ~MFC_STATE1_MASTER_RUN_CONTROL_MASK;
- spu_mfc_sr1_set(spu, tmp);
-
- __delay(200);
- }
-}
-
-void crash_register_spus(struct list_head *list)
-{
- struct spu *spu;
-
- list_for_each_entry(spu, list, full_list) {
- if (WARN_ON(spu->number >= CRASH_NUM_SPUS))
- continue;
-
- crash_spu_info[spu->number].spu = spu;
- }
-}
-
-#else
-static inline void crash_kexec_stop_spus(void)
-{
-}
-#endif /* CONFIG_SPU_BASE */
/*
* Register a function to be called on shutdown. Only use this if you
@@ -439,8 +373,6 @@ void default_machine_crash_shutdown(stru
crash_shutdown_cpu = -1;
__debugger_fault_handler = old_handler;
- crash_kexec_stop_spus();
-
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(1, 0);
}
Index: powerpc.git/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/cell/spu_base.c 2010-12-13 22:52:03.495242622 +1100
+++ powerpc.git/arch/powerpc/platforms/cell/spu_base.c 2011-01-07 12:52:00.812606428 +1100
@@ -727,6 +727,67 @@ static ssize_t spu_stat_show(struct sys_
static SYSDEV_ATTR(stat, 0644, spu_stat_show, NULL);
+struct crash_spu_info {
+ struct spu *spu;
+ u32 saved_spu_runcntl_RW;
+ u32 saved_spu_status_R;
+ u32 saved_spu_npc_RW;
+ u64 saved_mfc_sr1_RW;
+ u64 saved_mfc_dar;
+ u64 saved_mfc_dsisr;
+};
+
+#define CRASH_NUM_SPUS 16 /* Enough for current hardware */
+static struct crash_spu_info crash_spu_info[CRASH_NUM_SPUS];
+
+static void crash_kexec_stop_spus(void)
+{
+ struct spu *spu;
+ int i;
+ u64 tmp;
+
+ for (i = 0; i < CRASH_NUM_SPUS; i++) {
+ if (!crash_spu_info[i].spu)
+ continue;
+
+ spu = crash_spu_info[i].spu;
+
+ crash_spu_info[i].saved_spu_runcntl_RW =
+ in_be32(&spu->problem->spu_runcntl_RW);
+ crash_spu_info[i].saved_spu_status_R =
+ in_be32(&spu->problem->spu_status_R);
+ crash_spu_info[i].saved_spu_npc_RW =
+ in_be32(&spu->problem->spu_npc_RW);
+
+ crash_spu_info[i].saved_mfc_dar = spu_mfc_dar_get(spu);
+ crash_spu_info[i].saved_mfc_dsisr = spu_mfc_dsisr_get(spu);
+ tmp = spu_mfc_sr1_get(spu);
+ crash_spu_info[i].saved_mfc_sr1_RW = tmp;
+
+ tmp &= ~MFC_STATE1_MASTER_RUN_CONTROL_MASK;
+ spu_mfc_sr1_set(spu, tmp);
+
+ __delay(200);
+ }
+}
+
+static void crash_register_spus(struct list_head *list)
+{
+ struct spu *spu;
+ int ret;
+
+ list_for_each_entry(spu, list, full_list) {
+ if (WARN_ON(spu->number >= CRASH_NUM_SPUS))
+ continue;
+
+ crash_spu_info[spu->number].spu = spu;
+ }
+
+ ret = crash_shutdown_register(&crash_kexec_stop_spus);
+ if (ret)
+ printk(KERN_ERR "Could not register SPU crash handler");
+}
+
static int __init init_spu_base(void)
{
int i, ret = 0;
^ permalink raw reply
* [PATCH 6/8] powerpc/kexec: Remove empty ppc_md.machine_kexec_prepare
From: Anton Blanchard @ 2011-01-07 3:58 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
We check for a valid handler before calling ppc_md.machine_kexec_prepare
so we can just remove these empty handlers.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/platforms/embedded6xx/wii.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/embedded6xx/wii.c 2010-12-13 22:52:03.535243386 +1100
+++ powerpc.git/arch/powerpc/platforms/embedded6xx/wii.c 2011-01-07 12:51:59.422562597 +1100
@@ -18,7 +18,6 @@
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/seq_file.h>
-#include <linux/kexec.h>
#include <linux/of_platform.h>
#include <linux/memblock.h>
#include <mm/mmu_decl.h>
@@ -226,13 +225,6 @@ static void wii_shutdown(void)
flipper_quiesce();
}
-#ifdef CONFIG_KEXEC
-static int wii_machine_kexec_prepare(struct kimage *image)
-{
- return 0;
-}
-#endif /* CONFIG_KEXEC */
-
define_machine(wii) {
.name = "wii",
.probe = wii_probe,
@@ -246,9 +238,6 @@ define_machine(wii) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
.machine_shutdown = wii_shutdown,
-#ifdef CONFIG_KEXEC
- .machine_kexec_prepare = wii_machine_kexec_prepare,
-#endif
};
static struct of_device_id wii_of_bus[] = {
Index: powerpc.git/arch/powerpc/platforms/embedded6xx/gamecube.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/embedded6xx/gamecube.c 2010-12-13 22:52:03.555243746 +1100
+++ powerpc.git/arch/powerpc/platforms/embedded6xx/gamecube.c 2011-01-07 12:51:59.422562597 +1100
@@ -75,14 +75,6 @@ static void gamecube_shutdown(void)
flipper_quiesce();
}
-#ifdef CONFIG_KEXEC
-static int gamecube_kexec_prepare(struct kimage *image)
-{
- return 0;
-}
-#endif /* CONFIG_KEXEC */
-
-
define_machine(gamecube) {
.name = "gamecube",
.probe = gamecube_probe,
@@ -95,9 +87,6 @@ define_machine(gamecube) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
.machine_shutdown = gamecube_shutdown,
-#ifdef CONFIG_KEXEC
- .machine_kexec_prepare = gamecube_kexec_prepare,
-#endif
};
^ permalink raw reply
* [PATCH 5/8] powerpc/kexec: Don't initialise kexec hooks to default handlers
From: Anton Blanchard @ 2011-01-07 3:57 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
There's no need to initialise ppc_md.machine_kexec and
ppc_md.machine_kexec_prepare to the default handlers.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/platforms/cell/qpace_setup.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/cell/qpace_setup.c 2011-01-07 12:51:56.222461754 +1100
+++ powerpc.git/arch/powerpc/platforms/cell/qpace_setup.c 2011-01-07 12:51:58.112521318 +1100
@@ -145,8 +145,4 @@ define_machine(qpace) {
.calibrate_decr = generic_calibrate_decr,
.progress = qpace_progress,
.init_IRQ = iic_init_IRQ,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
-#endif
};
Index: powerpc.git/arch/powerpc/platforms/pseries/kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/pseries/kexec.c 2011-01-07 12:51:56.222461754 +1100
+++ powerpc.git/arch/powerpc/platforms/pseries/kexec.c 2011-01-07 12:51:58.112521318 +1100
@@ -61,12 +61,3 @@ void __init setup_kexec_cpu_down_xics(vo
{
ppc_md.kexec_cpu_down = pseries_kexec_cpu_down_xics;
}
-
-static int __init pseries_kexec_setup(void)
-{
- ppc_md.machine_kexec = default_machine_kexec;
- ppc_md.machine_kexec_prepare = default_machine_kexec_prepare;
-
- return 0;
-}
-machine_device_initcall(pseries, pseries_kexec_setup);
^ permalink raw reply
* [PATCH 4/8] powerpc/kdump: Remove ppc_md.machine_crash_shutdown
From: Anton Blanchard @ 2011-01-07 3:56 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
No one uses ppc_md.machine_crash_shutdown, so remove it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/machdep.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:54.082394288 +1100
+++ powerpc.git/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:56.222461754 +1100
@@ -236,12 +236,6 @@ struct machdep_calls {
#ifdef CONFIG_KEXEC
void (*kexec_cpu_down)(int crash_shutdown, int secondary);
- /* Called to do the minimal shutdown needed to run a kexec'd kernel
- * to run successfully.
- * XXX Should we move this one out of kexec scope?
- */
- void (*machine_crash_shutdown)(struct pt_regs *regs);
-
/* Called to do what every setup is needed on image and the
* reboot code buffer. Returns 0 on success.
* Provide your own (maybe dummy) implementation if your platform
Index: powerpc.git/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:54.082394288 +1100
+++ powerpc.git/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:56.222461754 +1100
@@ -44,10 +44,7 @@ void machine_kexec_mask_interrupts(void)
void machine_crash_shutdown(struct pt_regs *regs)
{
- if (ppc_md.machine_crash_shutdown)
- ppc_md.machine_crash_shutdown(regs);
- else
- default_machine_crash_shutdown(regs);
+ default_machine_crash_shutdown(regs);
}
/*
Index: powerpc.git/arch/powerpc/platforms/cell/qpace_setup.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/cell/qpace_setup.c 2010-12-13 22:52:03.765247709 +1100
+++ powerpc.git/arch/powerpc/platforms/cell/qpace_setup.c 2011-01-07 12:51:56.222461754 +1100
@@ -148,6 +148,5 @@ define_machine(qpace) {
#ifdef CONFIG_KEXEC
.machine_kexec = default_machine_kexec,
.machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
#endif
};
Index: powerpc.git/arch/powerpc/platforms/pseries/kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/pseries/kexec.c 2010-12-13 22:52:03.745247341 +1100
+++ powerpc.git/arch/powerpc/platforms/pseries/kexec.c 2011-01-07 12:51:56.222461754 +1100
@@ -66,7 +66,6 @@ static int __init pseries_kexec_setup(vo
{
ppc_md.machine_kexec = default_machine_kexec;
ppc_md.machine_kexec_prepare = default_machine_kexec_prepare;
- ppc_md.machine_crash_shutdown = default_machine_crash_shutdown;
return 0;
}
^ permalink raw reply
* [PATCH 3/8] powerpc/kexec: Remove ppc_md.machine_kexec
From: Anton Blanchard @ 2011-01-07 3:55 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
No one uses ppc_md.machine_kexec, so remove it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/machdep.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:51.352308248 +1100
+++ powerpc.git/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:54.082394288 +1100
@@ -248,12 +248,6 @@ struct machdep_calls {
* claims to support kexec.
*/
int (*machine_kexec_prepare)(struct kimage *image);
-
- /* Called to perform the _real_ kexec.
- * Do NOT allocate memory or fail here. We are past the point of
- * no return.
- */
- void (*machine_kexec)(struct kimage *image);
#endif /* CONFIG_KEXEC */
#ifdef CONFIG_SUSPEND
Index: powerpc.git/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:51.352308248 +1100
+++ powerpc.git/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:54.082394288 +1100
@@ -85,10 +85,7 @@ void arch_crash_save_vmcoreinfo(void)
*/
void machine_kexec(struct kimage *image)
{
- if (ppc_md.machine_kexec)
- ppc_md.machine_kexec(image);
- else
- default_machine_kexec(image);
+ default_machine_kexec(image);
/* Fall back to normal restart if we're still alive. */
machine_restart(NULL);
^ permalink raw reply
* [PATCH 2/8] powerpc/kexec: Remove ppc_md.machine_kexec_cleanup
From: Anton Blanchard @ 2011-01-07 3:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
No one uses ppc_md.machine_kexec_cleanup, so remove it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/machdep.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:46.682161055 +1100
+++ powerpc.git/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:51.352308248 +1100
@@ -249,9 +249,6 @@ struct machdep_calls {
*/
int (*machine_kexec_prepare)(struct kimage *image);
- /* Called to handle any machine specific cleanup on image */
- void (*machine_kexec_cleanup)(struct kimage *image);
-
/* Called to perform the _real_ kexec.
* Do NOT allocate memory or fail here. We are past the point of
* no return.
Index: powerpc.git/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/machine_kexec.c 2010-12-13 22:52:03.975251680 +1100
+++ powerpc.git/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:51.352308248 +1100
@@ -65,8 +65,6 @@ int machine_kexec_prepare(struct kimage
void machine_kexec_cleanup(struct kimage *image)
{
- if (ppc_md.machine_kexec_cleanup)
- ppc_md.machine_kexec_cleanup(image);
}
void arch_crash_save_vmcoreinfo(void)
^ permalink raw reply
* [PATCH 1/8] powerpc: Move all ppc_md kexec function pointers together
From: Anton Blanchard @ 2011-01-07 3:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
Move all the kexec handlers together.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/machdep.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/machdep.h 2011-01-07 12:50:52.020438276 +1100
+++ powerpc.git/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:46.682161055 +1100
@@ -118,9 +118,6 @@ struct machdep_calls {
* If for some reason there is no irq, but the interrupt
* shouldn't be counted as spurious, return NO_IRQ_IGNORE. */
unsigned int (*get_irq)(void);
-#ifdef CONFIG_KEXEC
- void (*kexec_cpu_down)(int crash_shutdown, int secondary);
-#endif
/* PCI stuff */
/* Called after scanning the bus, before allocating resources */
@@ -237,6 +234,8 @@ struct machdep_calls {
void (*machine_shutdown)(void);
#ifdef CONFIG_KEXEC
+ void (*kexec_cpu_down)(int crash_shutdown, int secondary);
+
/* Called to do the minimal shutdown needed to run a kexec'd kernel
* to run successfully.
* XXX Should we move this one out of kexec scope?
^ permalink raw reply
* [PATCH 0/8]: Some kexec/kdump cleanups
From: Anton Blanchard @ 2011-01-07 3:52 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi,
These patches have been sitting around in my tree for a while. Back
when I was trying to understand the twisty maze of powerpc kexec/kdump
I did a number of cleanups. Here they are.
Anton
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Blanchard, Hollis @ 2011-01-06 21:52 UTC (permalink / raw)
To: Scott Wood; +Cc: Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <20110105170725.1a82c5a6@udp111988uds.am.freescale.net>
On 01/05/2011 03:07 PM, Scott Wood wrote:
> On Wed, 5 Jan 2011 14:49:40 -0800
> "Blanchard, Hollis"<Hollis_Blanchard@mentor.com> wrote:
>
>> On 01/05/2011 02:09 PM, Scott Wood wrote:
>>> On Wed, 5 Jan 2011 15:58:55 -0600
>>> Meador Inge<meador_inge@mentor.com> wrote:
>>>
>>>> We need some sort of mapping between a message register and a =
message
>>>> register number so that the message registers can be referenced =
through
>>>> some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that =
would
>>>> be by putting an order on the registers. Maybe there is a better =
way,
>>>> though ...
>>> A message register is uniquely identified by a reference to the =
device
>>> tree node, plus a 0-3 index into that node's message registers.
>> Really what we're talking about is software configuration, not =
hardware
>> description.
> Part of that software configuration involves identifying the hardware
> being referenced.
>
>> We've gone back and forth on representing this information
>> in the device tree, and most recently decided against it. Outside the
>> kernel, a device node reference isn't really practical.
> Global enumeration isn't much fun either. For something like this
> where it's very unlikely that additional MPIC message units will be
> added to the system dynamically, it's managable, but it's not a good
> habit to get into. Look at the pain that's been caused by such
> assumptions in the i2c subsystem, in kernel interrupt management, etc.
>
> A reference to a node is just a pointer to a software message driver
> object, which can be obtained from looking up an alias. It's a little
> less simple than just using a number, but it's not impractical. It =
also
> provides a natural place to put a layer of indirection in the code =
that
> isolates the upper-layer protocol from the details of what sort of
> message transport it is using.
>
> Now, if you don't care about this, and want to just use numbers in =
your
> application, go ahead. But I don't think that such an assumption
> should go into the device tree binding. Have the software number the
> message register banks in increasing physical address order, or based
> on numbered aliases similar to how U-Boot enumerates ethernet nodes, =
or
> something similar.
Using physical addresses doesn't solve the enumeration problem either,=20
but I think it's beside the point: userspace must refer to the device.=20
There is a rich history of userspace *not* walking /proc/device-tree in=20
order to refer to a physical device. Are you suggesting this case is=20
special?
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: DMA implementation on MPC8572
From: Ira W. Snyder @ 2011-01-06 20:52 UTC (permalink / raw)
To: deebul nair; +Cc: linuxppc-dev
In-Reply-To: <AANLkTik1br89HU+sUOfHYB74uWqOBJSCNpbvf21xsh_r@mail.gmail.com>
On Thu, Jan 06, 2011 at 07:54:16PM +0530, deebul nair wrote:
> Hi all
>
> I am using the MPC8572 processor.
> I wanted to use the DMA functionality in the powerpc board for talking to a
> FPGA device connected on the loacl bus.
>
> I have compiled the fsldma.c code and inserted it.
> On insertion the driver probes all the dma channels
> Can anyone tell me how to test the driver and also how to use the driver?
>
For memcpy tests, the dmatest module provides a good example. See
drivers/dma/dmatest.c for the source.
For more advanced usage, search the archives for:
[PATCH RFCv3 0/2] CARMA Board Support
Those drivers use some of the advanced features of the DMAEngine API to
transfer data from an FPGA into RAM.
Ira
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Scott Wood @ 2011-01-06 20:10 UTC (permalink / raw)
To: Meador Inge; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <4D252FDC.4090404@mentor.com>
On Wed, 5 Jan 2011 20:58:36 -0600
Meador Inge <meador_inge@mentor.com> wrote:
> On 01/03/2011 02:22 PM, Scott Wood wrote:
> > On Wed, 22 Dec 2010 23:58:09 -0600
> > Perhaps a something like this, with "doorbell" being a new standard
> > hw-independent service with its own binding:
> >
> > msg1: mpic-msg@1400 {
> > compatible = "fsl,mpic-v3.0-msg";
> > reg =<0x1400 0x200>;
> > interrupts<176 2 178 2>;
> >
> > // We have message registers 0 and 2 for sending,
> > // and 1 and 3 for receiving.
> > // If absent, we own all message registers in this block.
> > fsl,mpic-msg-send-mask =<0x5>;
> > fsl,mpic-msg-receive-mask =<0xa>;
Alternatively, we could describe available ranges similarly to the
existing MSI binding.
> After thinking about it a little more, I like the idea of having a
> 'receive-mask' to further partition the message register blocks. This
> would also allow us to remove IRQs from the 'interrupts' property that
> are not being used on a given node. As for the 'send-mask', why would
> we want to block sending messages? It seems to me that it would be
> reasonable to allow a node to send a message to any other node.
The send-mask, like the receive-mask, is optional. If for your
application it makes sense to give all partitions send access to all
doorbells, then you can do that.
You might want to provide a send-mask if you are not specifying to the
partition how to use the message registers, just splitting them up for
their own internal use (especially if you have a larger multicore system
where each partition has multiple CPUs).
Or, you may want to add a layer of robustness against one partition
interfering with a message register that is only supposed to be used by
another partition, even if there are instructions elsewhere about which
message register to use for what purpose.
Plus, it provides symmetry between send and receive -- otherwise, you'd
have a numberspace that is limited to your own resources on receive,
but a global numberspace on send.
> As an example, consider a four core system. Then we might have
> something like (only relevant DTS bits shown):
>
> Core 0:
> mpic-msgr-block@1400 {
> // Receives messages on registers 1 and 3.
> interrupts = <0xb1 2 0xb3 2>;
> receive-mask = <0xa>;
> };
> Core 1:
> mpic-msgr-block@1400 {
> // Receives messages on register 2.
> interrupts = <0xb2 2>;
> receive-mask = <0x4>;
> };
> Core 2:
> mpic-msgr-block@1400 {
> // Receives messages on register 0.
> interrupts = <0xb0 2>;
> receive-mask = <0x1>;
> };
> Core 3:
> mpic-msgr-block@1400 {
> // Receives no messages.
> interrupts = <>;
> };
For core 3 I'd just leave out the node entirely. Note that the absence
of a receive-mask indicates that all the registers are available (i.e.
normal unpartitioned case), not none.
-Scott
^ permalink raw reply
* RE: RapidIO: question about rionet probe call
From: Bounine, Alexandre @ 2011-01-06 19:43 UTC (permalink / raw)
To: Thomas Taranowski, linuxppc-dev
In-Reply-To: <AANLkTi=ns4-bz1JBdzjX0tvqNuEDRiM6UpmzMu_Fr8cw@mail.gmail.com>
Did you change anything in RIO initialization sequence?
For multiple mport support I had to adjust rio_init_mports/rio_init
sequence.
Alex.
> -----Original Message-----
> From: =
linuxppc-dev-bounces+alexandre.bounine=3Didt.com@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+alexandre.bounine=3Didt.com@lists.ozlabs.org] On Behalf Of
Thomas Taranowski
> Sent: Thursday, January 06, 2011 3:27 AM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: RapidIO: question about rionet probe call
>=20
> I'm doing some work to support multiple mport architectures, and have
> run into an issue where the rionet_probe() function isn't being
> called, so my rionet net device never get's created. I've also
> verified that the rio_device_probe() isn't being called either.
>=20
> The low level rio bus driver initializes and probes correctly, and
> creates the required entries in sysfs. Then, later, I see the
> rionet_init get called and return success, indicating it registered
> with the rapidio bus correctly, so everything looks good.
>=20
>=20
> I see the following output (extra debug prints added) , indicating the
> rionet driver is being added, but it never gets probed afterward.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~ rio_register_driver ~~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> bus: 'rapidio': add driver rionet
> initializing klist
> init and added kobj, err=3D0
> driver_create_file err=3D0
> driver added attrs, err=3D0
> returning 0
> RIO: rionet_init rio_register_driver: rc=3D0
>=20
>=20
> Any ideas on why rionet isn't being probed? Is rionet currently
working?
> I'm running a 2.6.36-rc8 baseline.
>=20
> Thanks,
> Thomas Taranowski
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Fix SPRG get/set for Book3S and BookE
From: Marcelo Tosatti @ 2011-01-06 16:39 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, kvm, kvm-ppc, agraf
In-Reply-To: <1293652285-13313-1-git-send-email-ptyser@xes-inc.com>
On Wed, Dec 29, 2010 at 01:51:25PM -0600, Peter Tyser wrote:
> Previously SPRGs 4-7 were improperly read and written in
> kvm_arch_vcpu_ioctl_get_regs() and kvm_arch_vcpu_ioctl_set_regs();
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> I noticed this while grepping for somthing unrelated and assume its
> a typo. Feel free to add to the patch description; I don't use KVM
> so don't know what the high-level consequences of this change are.
>
> arch/powerpc/kvm/book3s.c | 14 ++++++++------
> arch/powerpc/kvm/booke.c | 14 ++++++++------
> 2 files changed, 16 insertions(+), 12 deletions(-)
Applied, thanks.
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Joakim Tjernlund @ 2011-01-06 16:52 UTC (permalink / raw)
To: michael; +Cc: scottwood, linuxppc-dev, RFeany, rbeims
In-Reply-To: <4D25BB08.7000001@evidence.eu.com>
>>> + /* On 8xx, cache control instructions (particularly
>>> + * "dcbst" from flush=5Fdcache=5Ficache) fault as write
>>> + * operation if there is an unpopulated TLB entry
>>> + * for the address in question. To workaround that,
>>> + * we invalidate the TLB here, thus avoiding dcbst
>>> + * misbehaviour.
>>> + */
>>> + /* 8xx doesn't care about PID, size or ind args */
>>> + =5Ftlbil=5Fva(addr, 0, 0, 0);
>>> #endif /* CONFIG=5F8xx */
>>> +
>>> + if (!pg)
>>> + return pte;
>>> +
>>> + if (!PageReserved(pg)&& !test=5Fbit(PG=5Farch=5F1,&pg->flags)) {
>>> flush=5Fdcache=5Ficache=5Fpage(pg);
>>> set=5Fbit(PG=5Farch=5F1,&pg->flags);
>>> }
>> Rex, do you recall under what specific circumstances the =5Ftlbil=5Fva is
>> needed? Is it possible that it will be caused by a dcbst in other
>> contexts that are not dependent on the state of PG=5Farch=5F1?
The 8xx tlbil=5Fva should not be needed in recent 2.6 after I fixed the 8xx=
TLB code
to workaround the dcbst bug there instead. See=20
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dcomm=
itdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071fee994ff98c3=
7d03a4a7c5a3f8b1e3b8e5
Not sure what release it went into though.
Jocke=
=
^ permalink raw reply
* DMA implementation on MPC8572
From: deebul nair @ 2011-01-06 14:24 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
Hi all
I am using the MPC8572 processor.
I wanted to use the DMA functionality in the powerpc board for talking to a
FPGA device connected on the loacl bus.
I have compiled the fsldma.c code and inserted it.
On insertion the driver probes all the dma channels
Can anyone tell me how to test the driver and also how to use the driver?
--
Cheeers
Deebul !!!!!!
[-- Attachment #2: Type: text/html, Size: 481 bytes --]
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: michael @ 2011-01-06 12:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Rafael Beims, Rex Feany
In-Reply-To: <20110105174256.29fd378a@udp111988uds.am.freescale.net>
Hi
On 01/06/2011 12:42 AM, Scott Wood wrote:
> On Wed, 5 Jan 2011 19:23:33 +0100
> michael<michael@evidence.eu.com> wrote:
>
>> diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
>> index dd5ea95..cb67076 100644
>> --- a/arch/powerpc/include/asm/pte-8xx.h
>> +++ b/arch/powerpc/include/asm/pte-8xx.h
>> @@ -32,7 +32,7 @@
>> #define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
>> #define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
>> #define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
>> -#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
>> +#define _PAGE_SPECIAL 0x0000 /* SW entry, forced to 0 by the TLB miss */
> What do you think is going wrong with the special bit on 8xx?
>
> Or might the change to set_pte_filter() alone be what fixed the problem?
>
Only the set_pte_filter doesn't fix the problem. The slow-down depends on
the __HAVE_ARCH_PTE_SPECIAL related code, but 2 months ago I didn't find the reason
and now I don't have the architecture. I will do some tests when I will came back in Italy.
>> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
>> index 5304093..1da03a8 100644
>> --- a/arch/powerpc/mm/pgtable.c
>> +++ b/arch/powerpc/mm/pgtable.c
>> @@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
>> pte = __pte(pte_val(pte)& ~_PAGE_HPTEFLAGS);
>> if (pte_looks_normal(pte)&& !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
>> cpu_has_feature(CPU_FTR_NOEXECUTE))) {
>> - struct page *pg = maybe_pte_to_page(pte);
>> - if (!pg)
>> + unsigned long pfn = pte_pfn(pte);
>> + struct page *pg;
>> +
>> + if (unlikely(!pfn_valid(pfn)))
>> return pte;
>> - if (!test_bit(PG_arch_1,&pg->flags)) {
>> +
>> + pg = pfn_to_page(pfn);
>> #ifdef CONFIG_8xx
>> - /* On 8xx, cache control instructions (particularly
>> - * "dcbst" from flush_dcache_icache) fault as write
>> - * operation if there is an unpopulated TLB entry
>> - * for the address in question. To workaround that,
>> - * we invalidate the TLB here, thus avoiding dcbst
>> - * misbehaviour.
>> - */
>> - /* 8xx doesn't care about PID, size or ind args */
>> - _tlbil_va(addr, 0, 0, 0);
>> + /* On 8xx, cache control instructions (particularly
>> + * "dcbst" from flush_dcache_icache) fault as write
>> + * operation if there is an unpopulated TLB entry
>> + * for the address in question. To workaround that,
>> + * we invalidate the TLB here, thus avoiding dcbst
>> + * misbehaviour.
>> + */
>> + /* 8xx doesn't care about PID, size or ind args */
>> + _tlbil_va(addr, 0, 0, 0);
>> #endif /* CONFIG_8xx */
>> +
>> + if (!pg)
>> + return pte;
>> +
>> + if (!PageReserved(pg)&& !test_bit(PG_arch_1,&pg->flags)) {
>> flush_dcache_icache_page(pg);
>> set_bit(PG_arch_1,&pg->flags);
>> }
> Rex, do you recall under what specific circumstances the _tlbil_va is
> needed? Is it possible that it will be caused by a dcbst in other
> contexts that are not dependent on the state of PG_arch_1?
>
> -Scott
>
Michael
^ permalink raw reply
* RapidIO: question about rionet probe call
From: Thomas Taranowski @ 2011-01-06 8:26 UTC (permalink / raw)
To: linuxppc-dev
I'm doing some work to support multiple mport architectures, and have
run into an issue where the rionet_probe() function isn't being
called, so my rionet net device never get's created. I've also
verified that the rio_device_probe() isn't being called either.
The low level rio bus driver initializes and probes correctly, and
creates the required entries in sysfs. Then, later, I see the
rionet_init get called and return success, indicating it registered
with the rapidio bus correctly, so everything looks good.
I see the following output (extra debug prints added) , indicating the
rionet driver is being added, but it never gets probed afterward.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~ rio_register_driver ~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
bus: 'rapidio': add driver rionet
initializing klist
init and added kobj, err=0
driver_create_file err=0
driver added attrs, err=0
returning 0
RIO: rionet_init rio_register_driver: rc=0
Any ideas on why rionet isn't being probed? Is rionet currently working?
I'm running a 2.6.36-rc8 baseline.
Thanks,
Thomas Taranowski
^ permalink raw reply
* Re: [PATCH v2 1/2] video, sm501: add OF binding to support SM501
From: Paul Mundt @ 2011-01-06 4:47 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, linuxppc-dev
In-Reply-To: <1292049075-1809-1-git-send-email-hs@denx.de>
On Sat, Dec 11, 2010 at 07:31:15AM +0100, Heiko Schocher wrote:
> - add binding to OF, compatible name "smi,sm501"
>
> - add read/write functions for using this driver
> also on powerpc plattforms
>
> - add commandline options:
> sm501.fb_mode:
> Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"
> sm501.bpp:
> Specify bit-per-pixel if not specified mode
>
> - Add support for encoding display mode information
> in the device tree using verbatim EDID block.
>
> If the "edid" entry in the "smi,sm501" node is present,
> the driver will build mode database using EDID data
> and allow setting the display modes from this database.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> cc: linux-fbdev@vger.kernel.org
> cc: devicetree-discuss@ozlabs.org
> cc: Ben Dooks <ben@simtec.co.uk>
> cc: Vincent Sanders <vince@simtec.co.uk>
> cc: Samuel Ortiz <sameo@linux.intel.com>
> cc: linux-kernel@vger.kernel.org
>
> ---
> - changes since v1:
> add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
> Paul Mundt.
>
> Documentation/kernel-parameters.txt | 7 +
> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
> drivers/mfd/sm501.c | 141 ++++++++------
> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
> include/linux/sm501.h | 8 +
> 5 files changed, 299 insertions(+), 151 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>
So has this stalled out? If Samuel wants to ack the MFD bits I don't mind
taking it through the fbdev tree. I can dust off an SM501 board to make
sure it still works for the non-OF case, although most of the changes
look fairly mechanical, so I don't forsee too much difficulty.
A few minor notes however. For starters, it would be nice to see this
patch split out a bit more logically. All of the items in your changelog
are more or less independent logical changes, and should really be
independent patches. As such, I'd like to see the EDID support as one
patch, the OF binding support layered on top of that, the documentation
split out as a trivial patch, and the I/O routine thing dealt with
separately. This should also make it easier for Samuel to simply ack the
OF bindings part that touch the MFD driver without having to be bothered
with any of the other stuff should regressions pop up at a later point in
time via a bisection.
As far as the DTS bindings documentation goes, I'm not sure what the best
way to split that out is. Perhaps simply lumping it in with the OF
bindings makes the most logical sense, and it's obviously a dependency
for the architecture-specific portion as well.
> @@ -1698,6 +1727,9 @@ static int sm501fb_init_fb(struct fb_info *fb,
> fb->fbops = &par->ops;
> fb->flags = FBINFO_FLAG_DEFAULT | FBINFO_READS_FAST |
> FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
> +#if defined(CONFIG_PPC_MPC52xx)
> + FBINFO_FOREIGN_ENDIAN |
> +#endif
> FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN;
>
> /* fixed data */
This is now getting in to deep hack territory. It's also not entirely
obvious how you expect things like the imageblit op to work given that
you're not selecting any of FB_{BIG,LITTLE,BOTH,FOREIGN}_ENDIAN, which
leads me to suspect you are manually doing this in your .config in a
relatively fragile way.
In the OF case I suppose you probably want something like:
#ifdef __BIG_ENDIAN
if (of_get_property(dp, "little-endian", NULL))
foreign_endian = FBINFO_FOREIGN_ENDIAN;
#else
if (of_get_property(dp, "big-endian", NULL))
foreign_endian = FBINFO_FOREIGN_ENDIAN;
#endif
and then simply hide the details in the DTS file in order to get rid of
CPU-specific hacks.
> +#if defined(CONFIG_PPC_MPC52xx)
> +#define smc501_readl(addr) __do_readl_be((addr))
> +#define smc501_writel(val, addr) __do_writel_be((val), (addr))
> +#else
> +#define smc501_readl(addr) readl(addr)
> +#define smc501_writel(val, addr) writel(val, addr)
> +#endif
Based on the Kconfig option for endianness you could probably just wrap these
to ioread/write32{,be} and hide the semantics in your iomap implementation?
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2011-01-06 2:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <20110103142200.738c0b17@udp111988uds.am.freescale.net>
On 01/03/2011 02:22 PM, Scott Wood wrote:
> On Wed, 22 Dec 2010 23:58:09 -0600
> Perhaps a something like this, with "doorbell" being a new standard
> hw-independent service with its own binding:
>
> msg1: mpic-msg@1400 {
> compatible = "fsl,mpic-v3.0-msg";
> reg =<0x1400 0x200>;
> interrupts<176 2 178 2>;
>
> // We have message registers 0 and 2 for sending,
> // and 1 and 3 for receiving.
> // If absent, we own all message registers in this block.
> fsl,mpic-msg-send-mask =<0x5>;
> fsl,mpic-msg-receive-mask =<0xa>;
>
> doorbell-controller;
>
> // split into #doorbell-send-cells and #doorbell-receive-cells?
> #doorbell-cells =<1>;
> };
>
> some-amp-protocol-thingy {
> send-doorbells =<&msg1 0>; // generate messages on MSGR0
> receive-doorbells =<&msg1 0>; // receive messages on MSGR1
> };
>
> some-other-amp-protocol-thingy {
> send-doorbells =<&msg1 1>; // generate messages on MSGR2
> receive-doorbells =<&msg1 1>; // receive messages on MSGR3
> };
>
> Doorbell capabilities such as passing a 32-bit message can be negotiated
> between the drivers for the doorbell controller and the doorbell client.
After thinking about it a little more, I like the idea of having a
'receive-mask' to further partition the message register blocks. This
would also allow us to remove IRQs from the 'interrupts' property that
are not being used on a given node. As for the 'send-mask', why would
we want to block sending messages? It seems to me that it would be
reasonable to allow a node to send a message to any other node.
As an example, consider a four core system. Then we might have
something like (only relevant DTS bits shown):
Core 0:
mpic-msgr-block@1400 {
// Receives messages on registers 1 and 3.
interrupts = <0xb1 2 0xb3 2>;
receive-mask = <0xa>;
};
Core 1:
mpic-msgr-block@1400 {
// Receives messages on register 2.
interrupts = <0xb2 2>;
receive-mask = <0x4>;
};
Core 2:
mpic-msgr-block@1400 {
// Receives messages on register 0.
interrupts = <0xb0 2>;
receive-mask = <0x1>;
};
Core 3:
mpic-msgr-block@1400 {
// Receives no messages.
interrupts = <>;
};
Then the API usage, for say core 0, might look something like:
/* Core 0 */
mpic_msgr *reg0 = mpic_get(0);
mpic_msgr *reg1 = mpic_get(1);
assert(mpic_msgr_get(100) == NULL);
u32 value;
/* Send a message on register 0. */
assert(mpic_msgr_write(reg0, 12) == 0);
/* Send a message on register 1. */
assert(mpic_msgr_write(reg1, 12) == 0);
/* Attempt to read a message on register 0, but can't
since it is not owned. */
assert(mpic_msgr_read(reg0, &value) == -ENODEV);
/* Successfully read a message on register 1. */
assert(mpic_msgr_read(reg1, &value) == 0);
The API usage for other cores would look similar. As mentioned in
another thread, this will provide us with the low-level building blocks
and we can layer other protocols, such as the doorbell protocol, on top
later (if needed).
Hollis, how do you feel about this?
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: Per process DSCR
From: Alexey Kardashevskiy @ 2011-01-06 2:02 UTC (permalink / raw)
To: Linuxppc-dev
test
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Scott Wood @ 2011-01-05 23:42 UTC (permalink / raw)
To: michael, Rex Feany; +Cc: Rafael Beims, linuxppc-dev
In-Reply-To: <4D24B725.2020300@evidence.eu.com>
On Wed, 5 Jan 2011 19:23:33 +0100
michael <michael@evidence.eu.com> wrote:
> diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
> index dd5ea95..cb67076 100644
> --- a/arch/powerpc/include/asm/pte-8xx.h
> +++ b/arch/powerpc/include/asm/pte-8xx.h
> @@ -32,7 +32,7 @@
> #define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
> #define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
> #define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
> -#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
> +#define _PAGE_SPECIAL 0x0000 /* SW entry, forced to 0 by the TLB miss */
What do you think is going wrong with the special bit on 8xx?
Or might the change to set_pte_filter() alone be what fixed the problem?
> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
> index 5304093..1da03a8 100644
> --- a/arch/powerpc/mm/pgtable.c
> +++ b/arch/powerpc/mm/pgtable.c
> @@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
> pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
> if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
> cpu_has_feature(CPU_FTR_NOEXECUTE))) {
> - struct page *pg = maybe_pte_to_page(pte);
> - if (!pg)
> + unsigned long pfn = pte_pfn(pte);
> + struct page *pg;
> +
> + if (unlikely(!pfn_valid(pfn)))
> return pte;
> - if (!test_bit(PG_arch_1, &pg->flags)) {
> +
> + pg = pfn_to_page(pfn);
> #ifdef CONFIG_8xx
> - /* On 8xx, cache control instructions (particularly
> - * "dcbst" from flush_dcache_icache) fault as write
> - * operation if there is an unpopulated TLB entry
> - * for the address in question. To workaround that,
> - * we invalidate the TLB here, thus avoiding dcbst
> - * misbehaviour.
> - */
> - /* 8xx doesn't care about PID, size or ind args */
> - _tlbil_va(addr, 0, 0, 0);
> + /* On 8xx, cache control instructions (particularly
> + * "dcbst" from flush_dcache_icache) fault as write
> + * operation if there is an unpopulated TLB entry
> + * for the address in question. To workaround that,
> + * we invalidate the TLB here, thus avoiding dcbst
> + * misbehaviour.
> + */
> + /* 8xx doesn't care about PID, size or ind args */
> + _tlbil_va(addr, 0, 0, 0);
> #endif /* CONFIG_8xx */
> +
> + if (!pg)
> + return pte;
> +
> + if (!PageReserved(pg) && !test_bit(PG_arch_1, &pg->flags)) {
> flush_dcache_icache_page(pg);
> set_bit(PG_arch_1, &pg->flags);
> }
Rex, do you recall under what specific circumstances the _tlbil_va is
needed? Is it possible that it will be caused by a dcbst in other
contexts that are not dependent on the state of PG_arch_1?
-Scott
^ permalink raw reply
* Re: [PATCH] of/device: Don't register disabled devices
From: David Gibson @ 2011-01-05 23:35 UTC (permalink / raw)
To: Blanchard, Hollis
Cc: devicetree-discuss, linux-kernel, Saxena, Deepak, Scott Wood,
linuxppc-dev
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FA8E5@na3-mail.mgc.mentorg.com>
On Wed, Jan 05, 2011 at 02:53:27PM -0800, Blanchard, Hollis wrote:
> On 01/03/2011 03:01 PM, Grant Likely wrote:
> > Device nodes with the property status="disabled" are not usable and so
> > don't register them when parsing the device tree for devices.
> >
> This is great and all, but a fair amount of driver code explicitly
> searches the tree, rather than registering a probe function. That's why
> our earlier patches in this area were more comprehensive.
>
> What are your thoughts on handling those cases?
One by one. Trying to handle the explicit searches automagically is
just asking for trouble.
--
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
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Scott Wood @ 2011-01-05 23:07 UTC (permalink / raw)
To: Blanchard, Hollis; +Cc: Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FA8E4@na3-mail.mgc.mentorg.com>
On Wed, 5 Jan 2011 14:49:40 -0800
"Blanchard, Hollis" <Hollis_Blanchard@mentor.com> wrote:
> On 01/05/2011 02:09 PM, Scott Wood wrote:
> > On Wed, 5 Jan 2011 15:58:55 -0600
> > Meador Inge<meador_inge@mentor.com> wrote:
> >
> >> We need some sort of mapping between a message register and a message
> >> register number so that the message registers can be referenced through
> >> some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that would
> >> be by putting an order on the registers. Maybe there is a better way,
> >> though ...
> > A message register is uniquely identified by a reference to the device
> > tree node, plus a 0-3 index into that node's message registers.
> Really what we're talking about is software configuration, not hardware
> description.
Part of that software configuration involves identifying the hardware
being referenced.
> We've gone back and forth on representing this information
> in the device tree, and most recently decided against it. Outside the
> kernel, a device node reference isn't really practical.
Global enumeration isn't much fun either. For something like this
where it's very unlikely that additional MPIC message units will be
added to the system dynamically, it's managable, but it's not a good
habit to get into. Look at the pain that's been caused by such
assumptions in the i2c subsystem, in kernel interrupt management, etc.
A reference to a node is just a pointer to a software message driver
object, which can be obtained from looking up an alias. It's a little
less simple than just using a number, but it's not impractical. It also
provides a natural place to put a layer of indirection in the code that
isolates the upper-layer protocol from the details of what sort of
message transport it is using.
Now, if you don't care about this, and want to just use numbers in your
application, go ahead. But I don't think that such an assumption
should go into the device tree binding. Have the software number the
message register banks in increasing physical address order, or based
on numbered aliases similar to how U-Boot enumerates ethernet nodes, or
something similar.
-Scott
^ permalink raw reply
* [30/49] hvc_console: Fix race between hvc_close and hvc_remove
From: Greg KH @ 2011-01-05 23:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rusty Russell, linuxppc-dev, Amit Shah, akpm, torvalds,
stable-review, alan
In-Reply-To: <20110105230438.GA26241@kroah.com>
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Amit Shah <amit.shah@redhat.com>
commit e74d098c66543d0731de62eb747ccd5b636a6f4c upstream.
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
Alan describes it thus:
The hvc_console assumes that a close and remove call can't occur at the
same time.
In addition tty_hangup(tty) is problematic as tty_hangup is asynchronous
itself....
So this can happen
hvc_close hvc_remove
hung up ? - no
lock
tty = hp->tty
unlock
lock
hp->tty = NULL
unlock
notify del
kref_put the hvc struct
close completes
tty is destroyed
tty_hangup dead tty
tty->ops will be NULL
NULL->...
This patch adds some tty krefs and also converts to using tty_vhangup().
Reported-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: linuxppc-dev@ozlabs.org
CC: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/char/hvc_console.c | 31 +++++++++++++++++++++----------
1 file changed, 21 insertions(+), 10 deletions(-)
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -312,6 +312,7 @@ static int hvc_open(struct tty_struct *t
spin_lock_irqsave(&hp->lock, flags);
/* Check and then increment for fast path open. */
if (hp->count++ > 0) {
+ tty_kref_get(tty);
spin_unlock_irqrestore(&hp->lock, flags);
hvc_kick();
return 0;
@@ -319,7 +320,7 @@ static int hvc_open(struct tty_struct *t
tty->driver_data = hp;
- hp->tty = tty;
+ hp->tty = tty_kref_get(tty);
spin_unlock_irqrestore(&hp->lock, flags);
@@ -336,6 +337,7 @@ static int hvc_open(struct tty_struct *t
spin_lock_irqsave(&hp->lock, flags);
hp->tty = NULL;
spin_unlock_irqrestore(&hp->lock, flags);
+ tty_kref_put(tty);
tty->driver_data = NULL;
kref_put(&hp->kref, destroy_hvc_struct);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -363,13 +365,18 @@ static void hvc_close(struct tty_struct
return;
hp = tty->driver_data;
+
spin_lock_irqsave(&hp->lock, flags);
+ tty_kref_get(tty);
if (--hp->count == 0) {
/* We are done with the tty pointer now. */
hp->tty = NULL;
spin_unlock_irqrestore(&hp->lock, flags);
+ /* Put the ref obtained in hvc_open() */
+ tty_kref_put(tty);
+
if (hp->ops->notifier_del)
hp->ops->notifier_del(hp, hp->data);
@@ -389,6 +396,7 @@ static void hvc_close(struct tty_struct
spin_unlock_irqrestore(&hp->lock, flags);
}
+ tty_kref_put(tty);
kref_put(&hp->kref, destroy_hvc_struct);
}
@@ -424,10 +432,11 @@ static void hvc_hangup(struct tty_struct
spin_unlock_irqrestore(&hp->lock, flags);
if (hp->ops->notifier_hangup)
- hp->ops->notifier_hangup(hp, hp->data);
+ hp->ops->notifier_hangup(hp, hp->data);
while(temp_open_count) {
--temp_open_count;
+ tty_kref_put(tty);
kref_put(&hp->kref, destroy_hvc_struct);
}
}
@@ -592,7 +601,7 @@ int hvc_poll(struct hvc_struct *hp)
}
/* No tty attached, just skip */
- tty = hp->tty;
+ tty = tty_kref_get(hp->tty);
if (tty == NULL)
goto bail;
@@ -672,6 +681,8 @@ int hvc_poll(struct hvc_struct *hp)
tty_flip_buffer_push(tty);
}
+ if (tty)
+ tty_kref_put(tty);
return poll_mask;
}
@@ -806,7 +817,7 @@ int hvc_remove(struct hvc_struct *hp)
struct tty_struct *tty;
spin_lock_irqsave(&hp->lock, flags);
- tty = hp->tty;
+ tty = tty_kref_get(hp->tty);
if (hp->index < MAX_NR_HVC_CONSOLES)
vtermnos[hp->index] = -1;
@@ -818,18 +829,18 @@ int hvc_remove(struct hvc_struct *hp)
/*
* We 'put' the instance that was grabbed when the kref instance
* was initialized using kref_init(). Let the last holder of this
- * kref cause it to be removed, which will probably be the tty_hangup
+ * kref cause it to be removed, which will probably be the tty_vhangup
* below.
*/
kref_put(&hp->kref, destroy_hvc_struct);
/*
- * This function call will auto chain call hvc_hangup. The tty should
- * always be valid at this time unless a simultaneous tty close already
- * cleaned up the hvc_struct.
+ * This function call will auto chain call hvc_hangup.
*/
- if (tty)
- tty_hangup(tty);
+ if (tty) {
+ tty_vhangup(tty);
+ tty_kref_put(tty);
+ }
return 0;
}
^ 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