* [PATCH v2] edac/mpc85xx: Limit setting/clearing of HID1[RFXE] to e500v1/v2 cores
From: Kumar Gala @ 2011-04-01 14:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: bluesmoke-devel, dougthompson
Only the e500v1/v2 cores have HID1[RXFE] so we should attempt to set or
clear this register bit on them. Otherwise we get crashes like:
NIP: c0579f84 LR: c006d550 CTR: c0579f84
REGS: ef857ec0 TRAP: 0700 Not tainted (2.6.38.2-00072-gf15ba3c)
MSR: 00021002 <ME,CE> CR: 22044022 XER: 00000000
TASK = ef8559c0[1] 'swapper' THREAD: ef856000 CPU: 0
GPR00: c006d538 ef857f70 ef8559c0 00000000 00000004 00000000 00000000 00000000
GPR08: c0590000 c30170a8 00000000 c30170a8 00000001 0fffe000 00000000 00000000
GPR16: 00000000 7ffa0e60 00000000 00000000 7ffb0bd8 7ff3b844 c05be000 00000000
GPR24: 00000000 00000000 c05c28b0 c0579fac 00000000 00029002 00000000 c0579f84
NIP [c0579f84] mpc85xx_mc_clear_rfxe+0x0/0x28
LR [c006d550] on_each_cpu+0x34/0x50
Call Trace:
[ef857f70] [c006d538] on_each_cpu+0x1c/0x50 (unreliable)
[ef857f90] [c057a070] mpc85xx_mc_init+0xc4/0xdc
[ef857fa0] [c0001cd4] do_one_initcall+0x34/0x1a8
[ef857fd0] [c055d9d8] kernel_init+0x17c/0x218
[ef857ff0] [c000cda4] kernel_thread+0x4c/0x68
Instruction dump:
40be0018 3c60c052 3863c70c 4be9baad 3be0ffed 4bd7c99d 80010014 7fe3fb78
83e1000c 38210010 7c0803a6 4e800020 <7c11faa6> 54290024 81290008
3d60c06e
Oops: Exception in kernel mode, sig: 4 [#2]
---[ end trace 49ff3b8f93efde1a ]---
Also use the HID1_RFXE define rather than a magic number.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
v2 - fix accidently typo change
drivers/edac/mpc85xx_edac.c | 27 +++++++++++++++++++--------
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index b123bb3..1981a71 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -1150,13 +1150,14 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
static void __init mpc85xx_mc_clear_rfxe(void *data)
{
orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
- mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x20000));
+ mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~HID1_RFXE));
}
#endif
static int __init mpc85xx_mc_init(void)
{
int res = 0;
+ u32 pvr = 0;
printk(KERN_INFO "Freescale(R) MPC85xx EDAC driver, "
"(C) 2006 Montavista Software\n");
@@ -1186,12 +1187,17 @@ static int __init mpc85xx_mc_init(void)
#endif
#ifdef CONFIG_FSL_SOC_BOOKE
- /*
- * need to clear HID1[RFXE] to disable machine check int
- * so we can catch it
- */
- if (edac_op_state == EDAC_OPSTATE_INT)
- on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+ pvr = mfspr(SPRN_PVR);
+
+ if ((PVR_VER(pvr) == PVR_VER_E500V1) ||
+ (PVR_VER(pvr) == PVR_VER_E500V2)) {
+ /*
+ * need to clear HID1[RFXE] to disable machine check int
+ * so we can catch it
+ */
+ if (edac_op_state == EDAC_OPSTATE_INT)
+ on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+ }
#endif
return 0;
@@ -1209,7 +1215,12 @@ static void __exit mpc85xx_mc_restore_hid1(void *data)
static void __exit mpc85xx_mc_exit(void)
{
#ifdef CONFIG_FSL_SOC_BOOKE
- on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+ u32 pvr = mfspr(SPRN_PVR);
+
+ if ((PVR_VER(pvr) == PVR_VER_E500V1) ||
+ (PVR_VER(pvr) == PVR_VER_E500V2)) {
+ on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+ }
#endif
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] edac/mpc85xx: Limit setting/clearing of HID1[RFXE] to e500v1/v2 cores
From: Kumar Gala @ 2011-04-01 13:03 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, bluesmoke-devel, dougthompson
In-Reply-To: <20110331224208.GA30426@us.ibm.com>
On Mar 31, 2011, at 5:42 PM, Nishanth Aravamudan wrote:
> On 31.03.2011 [17:23:14 -0500], Kumar Gala wrote:
>> Only the e500v1/v2 cores have HID1[RXFE] so we should attempt to set =
or
>> clear this register bit on them. Otherwise we get crashes like:
>=20
> <snip>
>=20
>> diff --git a/drivers/edac/mpc85xx_edac.c =
b/drivers/edac/mpc85xx_edac.c
>> index b123bb3..5aef2ed 100644
>> --- a/drivers/edac/mpc85xx_edac.c
>> +++ b/drivers/edac/mpc85xx_edac.c
>=20
> <snip>
>=20
>> @@ -1209,10 +1215,15 @@ static void __exit =
mpc85xx_mc_restore_hid1(void *data)
>> static void __exit mpc85xx_mc_exit(void)
>> {
>> #ifdef CONFIG_FSL_SOC_BOOKE
>> - on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
>> + u32 pvr =3D mfspr(SPRN_PVR);
>> +
>> + if ((PVR_VER(pvr) =3D=3D PVR_VER_E500V1) ||
>> + (PVR_VER(pvr) =3D=3D PVR_VER_E500V2)) {
>> + on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
>> + }
>> #endif
>> #ifdef CONFIG_PCI
>> - of_unregister_platform_driver(&mpc85xx_pci_err_driver);
>> + of_unregistr_platform_driver(&mpc85xx_pci_err_driver);
>=20
> Unintended change?
Yep, thanks for catching.
- k=
^ permalink raw reply
* configuration from flash PROM
From: SACHIN SOLANKI @ 2011-04-01 7:07 UTC (permalink / raw)
To: brandon, prasanna, mcmillan
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Respected sir,
i am a M.tech. student form national institute of
technology bhopal, india.I try to configure FPGA from flash prom memory
virtex II pro.i think to put diffrent .bit file to flash PROM and by some
how method configure FPGA by selecting specific .bit file.i don't have any
idea how is it possible to configure FPGA by selecting diffrent diffrent
.bit file from Flash PTROM.i do have xilinx 9.1i, EDK 9.1i & VIRTEX II PRO
XUP2PV BOARD.
sir please guide me in this matter...
thanks
sachin kumar solanki
N.I.T. BHOPAL
INDIA
[-- Attachment #2: Type: text/html, Size: 603 bytes --]
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-04-01 5:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Some more powerpc bits for you.
One is actually a change from Anton to the generic kexec to make a
function weak so powerpc can override it.
It has been around for ever, there were initial objections I think
mostly due to a misunderstanding of the problem.
Since then, it's been a deafening silence to our responses/expanations
and no answers from Eric so I think it should go in as the powerpc
counterpart that implements our version of that weak function is already
(and has been for a while as d72e063bb32c06c6c1cec14f6857b7c37ba62d7a)
and it fixes a real nasty bug.
The rest is a series of fixes to our CPU hotplug code that I've been
sitting on for a little while (by myself) and was originally thinking
about putting in for the next release.
I eventually changed my mind, there is no point in sitting on them any
longer since they fix some real issues on some machines (such as G5's
crashing on re-plug) and brings us in line with what other archs do for
setting up and re-initializing the idle threads.
Cheers,
Ben.
The following changes since commit ecb78ab6f30106ab72a575a25b1cdfd1633b7ca2:
Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 (2011-03-30 12:22:15 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Blanchard (1):
kdump: Allow shrinking of kdump region to be overridden
Benjamin Herrenschmidt (18):
powerpc: Make decrementer interrupt robust against offlined CPUs
powerpc/smp: soft-replugged CPUs must go back to start_secondary
powerpc/smp: Fix generic_mach_cpu_die()
powerpc/smp: Remove unused generic_cpu_enable()
powerpc/smp: Remove unused smp_ops->cpu_enable()
powerpc/pmac/smp: Fix 32-bit PowerMac cpu_die
powerpc/pmac/smp: Rename fixup_irqs() to migrate_irqs() and use it on ppc32
powerpc/pmac/smp: Fixup smp_core99_cpu_disable() and use it on 64-bit
powerpc/pmac/smp: Consolidate 32-bit and 64-bit PowerMac cpu_die in one file
powerpc/pmac/smp: Remove HMT changes for PowerMac offline code
powerpc/pmac/smp: Properly NAP offlined CPU on G5
powerpc/pmac: Rename cpu_state in therm_pm72 to avoid collision
powerpc/smp: Add a smp_ops->bringup_up() done callback
powerpc/pmac/smp: Fix CPU hotplug crashes on some machines
powerpc/smp: Don't expose per-cpu "cpu_state" array
powerpc/smp: Create idle threads on demand and properly reset them
powerpc/smp: Increase vdso_data->processorCount, not just decrease it
powerpc/pmac/smp: Remove no-longer needed preempt workaround
arch/powerpc/include/asm/machdep.h | 3 +-
arch/powerpc/include/asm/smp.h | 5 +-
arch/powerpc/kernel/head_32.S | 9 ++
arch/powerpc/kernel/head_64.S | 7 +
arch/powerpc/kernel/idle_power4.S | 21 ---
arch/powerpc/kernel/irq.c | 3 +-
arch/powerpc/kernel/smp.c | 153 ++++++++++++++--------
arch/powerpc/kernel/time.c | 15 ++-
arch/powerpc/platforms/powermac/pmac.h | 1 -
arch/powerpc/platforms/powermac/setup.c | 56 --------
arch/powerpc/platforms/powermac/smp.c | 154 ++++++++++++++++-------
arch/powerpc/platforms/pseries/offline_states.h | 2 -
drivers/macintosh/therm_pm72.c | 60 +++++-----
include/linux/kexec.h | 1 +
kernel/kexec.c | 5 +-
15 files changed, 272 insertions(+), 223 deletions(-)
^ permalink raw reply
* [PATCH] powerpc/pseries: Fix build without CONFIG_HOTPLUG_CPU
From: Benjamin Herrenschmidt @ 2011-04-01 5:33 UTC (permalink / raw)
To: linuxppc-dev
From: Matt Evans <matt@ozlabs.au.ibm.com>
Signed-off-by: Matt Evans <matt@ozlabs.au.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/pseries/smp.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
index 0317cce..5fe1ad6 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -112,10 +112,10 @@ static inline int __devinit smp_startup_cpu(unsigned int lcpu)
/* Fixup atomic count: it exited inside IRQ handler. */
task_thread_info(paca[lcpu].__current)->preempt_count = 0;
-
+#ifdef CONFIG_HOTPLUG_CPU
if (get_cpu_current_state(lcpu) == CPU_STATE_INACTIVE)
goto out;
-
+#endif
/*
* If the RTAS start-cpu token does not exist then presume the
* cpu is already spinning.
@@ -130,7 +130,9 @@ static inline int __devinit smp_startup_cpu(unsigned int lcpu)
return 0;
}
+#ifdef CONFIG_HOTPLUG_CPU
out:
+#endif
return 1;
}
@@ -144,16 +146,15 @@ static void __devinit smp_xics_setup_cpu(int cpu)
vpa_init(cpu);
cpumask_clear_cpu(cpu, of_spin_mask);
+#ifdef CONFIG_HOTPLUG_CPU
set_cpu_current_state(cpu, CPU_STATE_ONLINE);
set_default_offline_state(cpu);
-
+#endif
}
#endif /* CONFIG_XICS */
static void __devinit smp_pSeries_kick_cpu(int nr)
{
- long rc;
- unsigned long hcpuid;
BUG_ON(nr < 0 || nr >= NR_CPUS);
if (!smp_startup_cpu(nr))
@@ -165,16 +166,20 @@ static void __devinit smp_pSeries_kick_cpu(int nr)
* the processor will continue on to secondary_start
*/
paca[nr].cpu_start = 1;
-
+#ifdef CONFIG_HOTPLUG_CPU
set_preferred_offline_state(nr, CPU_STATE_ONLINE);
if (get_cpu_current_state(nr) == CPU_STATE_INACTIVE) {
+ long rc;
+ unsigned long hcpuid;
+
hcpuid = get_hard_smp_processor_id(nr);
rc = plpar_hcall_norets(H_PROD, hcpuid);
if (rc != H_SUCCESS)
printk(KERN_ERR "Error: Prod to wake up processor %d "
"Ret= %ld\n", nr, rc);
}
+#endif
}
static int smp_pSeries_cpu_bootable(unsigned int nr)
^ permalink raw reply related
* [PATCH] powerpc: Set nr_cpu_ids early and use it to free PACAs
From: Benjamin Herrenschmidt @ 2011-04-01 5:33 UTC (permalink / raw)
To: linuxppc-dev
From: Ryan Grimm <grimm@us.ibm.com>
Without this, "holes" in the CPU numbering can cause us to
free too many PACAs
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/paca.c | 2 +-
arch/powerpc/kernel/setup-common.c | 3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index f4adf89..10f0aad 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -203,7 +203,7 @@ void __init free_unused_pacas(void)
{
int new_size;
- new_size = PAGE_ALIGN(sizeof(struct paca_struct) * num_possible_cpus());
+ new_size = PAGE_ALIGN(sizeof(struct paca_struct) * nr_cpu_ids);
if (new_size >= paca_size)
return;
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 9d4882a..21f30cb 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -509,6 +509,9 @@ void __init smp_setup_cpu_maps(void)
*/
cpu_init_thread_core_maps(nthreads);
+ /* Now that possible cpus are set, set nr_cpu_ids for later use */
+ nr_cpu_ids = find_last_bit(cpumask_bits(cpu_possible_mask),NR_CPUS) + 1;
+
free_unused_pacas();
}
#endif /* CONFIG_SMP */
^ permalink raw reply related
* [PATCH] powerpc/pseries: Don't register global initcall
From: Benjamin Herrenschmidt @ 2011-04-01 4:49 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/pseries/setup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 82f632e..0e5e91a 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -377,7 +377,7 @@ static int __init pSeries_init_panel(void)
return 0;
}
-arch_initcall(pSeries_init_panel);
+machine_arch_initcall(pseries, pSeries_init_panel);
static int pseries_set_dabr(unsigned long dabr)
{
^ permalink raw reply related
* [PATCH] powerpc/pseries: Fix build without CONFIG_HOTPLUG_CPU
From: Benjamin Herrenschmidt @ 2011-04-01 4:48 UTC (permalink / raw)
To: linuxppc-dev
From: Matt Evans <matt@ozlabs.au.ibm.com>
Signed-off-by: Matt Evans <matt@ozlabs.au.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/pseries/smp.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
index 0317cce..5fe1ad6 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -112,10 +112,10 @@ static inline int __devinit smp_startup_cpu(unsigned int lcpu)
/* Fixup atomic count: it exited inside IRQ handler. */
task_thread_info(paca[lcpu].__current)->preempt_count = 0;
-
+#ifdef CONFIG_HOTPLUG_CPU
if (get_cpu_current_state(lcpu) == CPU_STATE_INACTIVE)
goto out;
-
+#endif
/*
* If the RTAS start-cpu token does not exist then presume the
* cpu is already spinning.
@@ -130,7 +130,9 @@ static inline int __devinit smp_startup_cpu(unsigned int lcpu)
return 0;
}
+#ifdef CONFIG_HOTPLUG_CPU
out:
+#endif
return 1;
}
@@ -144,16 +146,15 @@ static void __devinit smp_xics_setup_cpu(int cpu)
vpa_init(cpu);
cpumask_clear_cpu(cpu, of_spin_mask);
+#ifdef CONFIG_HOTPLUG_CPU
set_cpu_current_state(cpu, CPU_STATE_ONLINE);
set_default_offline_state(cpu);
-
+#endif
}
#endif /* CONFIG_XICS */
static void __devinit smp_pSeries_kick_cpu(int nr)
{
- long rc;
- unsigned long hcpuid;
BUG_ON(nr < 0 || nr >= NR_CPUS);
if (!smp_startup_cpu(nr))
@@ -165,16 +166,20 @@ static void __devinit smp_pSeries_kick_cpu(int nr)
* the processor will continue on to secondary_start
*/
paca[nr].cpu_start = 1;
-
+#ifdef CONFIG_HOTPLUG_CPU
set_preferred_offline_state(nr, CPU_STATE_ONLINE);
if (get_cpu_current_state(nr) == CPU_STATE_INACTIVE) {
+ long rc;
+ unsigned long hcpuid;
+
hcpuid = get_hard_smp_processor_id(nr);
rc = plpar_hcall_norets(H_PROD, hcpuid);
if (rc != H_SUCCESS)
printk(KERN_ERR "Error: Prod to wake up processor %d "
"Ret= %ld\n", nr, rc);
}
+#endif
}
static int smp_pSeries_cpu_bootable(unsigned int nr)
^ permalink raw reply related
* [PATCH] powerpc: Set nr_cpu_ids early and use it to free PACAs
From: Benjamin Herrenschmidt @ 2011-04-01 4:47 UTC (permalink / raw)
To: linuxppc-dev
From: Ryan Grimm <grimm@us.ibm.com>
Without this, "holes" in the CPU numbering can cause us to
free too many PACAs
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/paca.c | 2 +-
arch/powerpc/kernel/setup-common.c | 3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index f4adf89..10f0aad 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -203,7 +203,7 @@ void __init free_unused_pacas(void)
{
int new_size;
- new_size = PAGE_ALIGN(sizeof(struct paca_struct) * num_possible_cpus());
+ new_size = PAGE_ALIGN(sizeof(struct paca_struct) * nr_cpu_ids);
if (new_size >= paca_size)
return;
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 9d4882a..21f30cb 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -509,6 +509,9 @@ void __init smp_setup_cpu_maps(void)
*/
cpu_init_thread_core_maps(nthreads);
+ /* Now that possible cpus are set, set nr_cpu_ids for later use */
+ nr_cpu_ids = find_last_bit(cpumask_bits(cpu_possible_mask),NR_CPUS) + 1;
+
free_unused_pacas();
}
#endif /* CONFIG_SMP */
^ permalink raw reply related
* Re: [PATCH] edac/mpc85xx: Limit setting/clearing of HID1[RFXE] to e500v1/v2 cores
From: Nishanth Aravamudan @ 2011-03-31 22:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, dougthompson
In-Reply-To: <1301610194-29971-1-git-send-email-galak@kernel.crashing.org>
On 31.03.2011 [17:23:14 -0500], Kumar Gala wrote:
> Only the e500v1/v2 cores have HID1[RXFE] so we should attempt to set or
> clear this register bit on them. Otherwise we get crashes like:
<snip>
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index b123bb3..5aef2ed 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
<snip>
> @@ -1209,10 +1215,15 @@ static void __exit mpc85xx_mc_restore_hid1(void *data)
> static void __exit mpc85xx_mc_exit(void)
> {
> #ifdef CONFIG_FSL_SOC_BOOKE
> - on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
> + u32 pvr = mfspr(SPRN_PVR);
> +
> + if ((PVR_VER(pvr) == PVR_VER_E500V1) ||
> + (PVR_VER(pvr) == PVR_VER_E500V2)) {
> + on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
> + }
> #endif
> #ifdef CONFIG_PCI
> - of_unregister_platform_driver(&mpc85xx_pci_err_driver);
> + of_unregistr_platform_driver(&mpc85xx_pci_err_driver);
Unintended change?
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] edac/mpc85xx: Limit setting/clearing of HID1[RFXE] to e500v1/v2 cores
From: Kumar Gala @ 2011-03-31 22:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: bluesmoke-devel, dougthompson
Only the e500v1/v2 cores have HID1[RXFE] so we should attempt to set or
clear this register bit on them. Otherwise we get crashes like:
NIP: c0579f84 LR: c006d550 CTR: c0579f84
REGS: ef857ec0 TRAP: 0700 Not tainted (2.6.38.2-00072-gf15ba3c)
MSR: 00021002 <ME,CE> CR: 22044022 XER: 00000000
TASK = ef8559c0[1] 'swapper' THREAD: ef856000 CPU: 0
GPR00: c006d538 ef857f70 ef8559c0 00000000 00000004 00000000 00000000 00000000
GPR08: c0590000 c30170a8 00000000 c30170a8 00000001 0fffe000 00000000 00000000
GPR16: 00000000 7ffa0e60 00000000 00000000 7ffb0bd8 7ff3b844 c05be000 00000000
GPR24: 00000000 00000000 c05c28b0 c0579fac 00000000 00029002 00000000 c0579f84
NIP [c0579f84] mpc85xx_mc_clear_rfxe+0x0/0x28
LR [c006d550] on_each_cpu+0x34/0x50
Call Trace:
[ef857f70] [c006d538] on_each_cpu+0x1c/0x50 (unreliable)
[ef857f90] [c057a070] mpc85xx_mc_init+0xc4/0xdc
[ef857fa0] [c0001cd4] do_one_initcall+0x34/0x1a8
[ef857fd0] [c055d9d8] kernel_init+0x17c/0x218
[ef857ff0] [c000cda4] kernel_thread+0x4c/0x68
Instruction dump:
40be0018 3c60c052 3863c70c 4be9baad 3be0ffed 4bd7c99d 80010014 7fe3fb78
83e1000c 38210010 7c0803a6 4e800020 <7c11faa6> 54290024 81290008
3d60c06e
Oops: Exception in kernel mode, sig: 4 [#2]
---[ end trace 49ff3b8f93efde1a ]---
Also use the HID1_RFXE define rather than a magic number.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Doug, unless otherwise told I plan on pushing this via the powerpc.git tree
- k
drivers/edac/mpc85xx_edac.c | 29 ++++++++++++++++++++---------
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index b123bb3..5aef2ed 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -1150,13 +1150,14 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
static void __init mpc85xx_mc_clear_rfxe(void *data)
{
orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
- mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x20000));
+ mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~HID1_RFXE));
}
#endif
static int __init mpc85xx_mc_init(void)
{
int res = 0;
+ u32 pvr = 0;
printk(KERN_INFO "Freescale(R) MPC85xx EDAC driver, "
"(C) 2006 Montavista Software\n");
@@ -1186,12 +1187,17 @@ static int __init mpc85xx_mc_init(void)
#endif
#ifdef CONFIG_FSL_SOC_BOOKE
- /*
- * need to clear HID1[RFXE] to disable machine check int
- * so we can catch it
- */
- if (edac_op_state == EDAC_OPSTATE_INT)
- on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+ pvr = mfspr(SPRN_PVR);
+
+ if ((PVR_VER(pvr) == PVR_VER_E500V1) ||
+ (PVR_VER(pvr) == PVR_VER_E500V2)) {
+ /*
+ * need to clear HID1[RFXE] to disable machine check int
+ * so we can catch it
+ */
+ if (edac_op_state == EDAC_OPSTATE_INT)
+ on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+ }
#endif
return 0;
@@ -1209,10 +1215,15 @@ static void __exit mpc85xx_mc_restore_hid1(void *data)
static void __exit mpc85xx_mc_exit(void)
{
#ifdef CONFIG_FSL_SOC_BOOKE
- on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+ u32 pvr = mfspr(SPRN_PVR);
+
+ if ((PVR_VER(pvr) == PVR_VER_E500V1) ||
+ (PVR_VER(pvr) == PVR_VER_E500V2)) {
+ on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+ }
#endif
#ifdef CONFIG_PCI
- of_unregister_platform_driver(&mpc85xx_pci_err_driver);
+ of_unregistr_platform_driver(&mpc85xx_pci_err_driver);
#endif
of_unregister_platform_driver(&mpc85xx_l2_err_driver);
of_unregister_platform_driver(&mpc85xx_mc_err_driver);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/dts:Update PCIe memory maps to match u-boot of Px020RDB
From: Kumar Gala @ 2011-03-31 21:26 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: meet2prabhu, linuxppc-dev, Prabhakar Kushwaha
In-Reply-To: <AANLkTi=HSU42BJCVY+GoRE1WzU8auUK9vRyz8YrNZ8B_@mail.gmail.com>
On Mar 31, 2011, at 6:44 AM, Leon Woestenberg wrote:
> Hello Prabhakar, Kumar,
>=20
> (I missed the original post, due to temporarely being unsubscribed, I
> am responding to Kumar's reply).
>=20
> On Thu, Mar 31, 2011 at 10:22 AM, Kumar Gala =
<galak@kernel.crashing.org> wrote:
>> On Mar 24, 2011, at 11:47 PM, Prabhakar Kushwaha wrote:
>>=20
>>> PCIe memory address space is 1:1 mapped with u-boot.
>>>=20
>>> Update dts of Px020RDB i.e. P1020RDB and P2020RDB to match the =
address map
>>> changes in u-boot.
>>>=20
> Does this mean u-boot and Linux versions should be selectively =
matched, or not?
=46rom time to time they have to be. PCIe was broken between u-boot & =
linux on these boards.
> What commit in u-boot does this apply to?
=
http://git.denx.de/?p=3Du-boot.git;a=3Dcommit;h=3Db0c5ceb305054aadf2f810b0=
b7bfcc94926b78ad
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: Implement dma_mmap_coherent()
From: Benjamin Herrenschmidt @ 2011-03-31 21:05 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: tiwai, linuxppc-dev
In-Reply-To: <20110331203921.56030@gmx.net>
On Thu, 2011-03-31 at 22:39 +0200, Gerhard Pircher wrote:
> Anyway, it compiles with explicit type casts and I could test it on my
> semi-noncoherent AmigaOne. So far it works just fine with the VIA
> onboard
> sound and a Soundblaster Live PCI card.
>
> Thanks a lot for the fix!
Yes, the version I sent to Linus has that fixed, I forgot to send it to
the list also :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Implement dma_mmap_coherent()
From: Gerhard Pircher @ 2011-03-31 20:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev; +Cc: tiwai
-------- Original-Nachricht --------
> Datum: Fri, 25 Mar 2011 17:50:06 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
> CC: Takashi Iwai <tiwai@suse.de>
> Betreff: [PATCH] powerpc: Implement dma_mmap_coherent()
> This is used by Alsa to mmap buffers allocated with dma_alloc_coherent()
> into userspace. We need a special variant to handle machines with
> non-coherent DMAs as those buffers have "special" virt addresses and
> require non-cachable mappings
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Dunno if anybody with CONFIG_NOT_COHERENT_CACHE has some audio device
> that uses dma buffers (ie not usb-audio) and wants to try that out...
> should fix a long standing problem.
Compilation fails here with these error messages:
> CC arch/powerpc/mm/dma-noncoherent.o
> arch/powerpc/mm/dma-noncoherent.c: In function ‘__dma_get_coherent_pfn’:
> arch/powerpc/mm/dma-noncoherent.c:413: error: invalid operands to binary >> (have ‘void *’ and ‘int’)
> cc1: warnings being treated as errors
> arch/powerpc/mm/dma-noncoherent.c:414: error: passing argument 2 of ‘pud_offset’ makes integer from pointer without a cast
> arch/powerpc/mm/dma-noncoherent.c:415: error: passing argument 2 of ‘pmd_offset’ makes integer from pointer without a cast
> arch/powerpc/mm/dma-noncoherent.c:416: error: invalid operands to binary >> (have ‘void *’ and ‘int’)
> make[1]: *** [arch/powerpc/mm/dma-noncoherent.o] Fehler 1
> make: *** [arch/powerpc/mm] Fehler 2
Anyway, it compiles with explicit type casts and I could test it on my
semi-noncoherent AmigaOne. So far it works just fine with the VIA onboard
sound and a Soundblaster Live PCI card.
Thanks a lot for the fix!
regards,
Gerhard
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-31 20:38 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: linuxppc-dev, Andrew Morton, Hugh Dickins, Peter Zijlstra
In-Reply-To: <4D94B810.4000107@goop.org>
On Thu, 2011-03-31 at 10:21 -0700, Jeremy Fitzhardinge wrote:
>
> No, its the same accessors for both, since the need to distinguish them
> hasn't really come up. Could you put a "if (preemptable()) return;"
> guard in your implementations?
That would be a band-aid but would probably do the trick for now
for !-rt, tho it wouldn't do the right thing for -rt...
> Otherwise I have no objections to passing the mm in (we'll probably just
> continue to ignore the arg in x86-land).
Ben.
^ permalink raw reply
* [PATCH] powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP.
From: Paul Gortmaker @ 2011-03-31 17:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
Commit b3df895aebe091b1657 "powerpc/kexec: Add support for FSL-BookE"
introduced the original PPC_STD_MMU_64 checks around the function
crash_kexec_wait_realmode(). Then commit c2be05481f61252
"powerpc: Fix default_machine_crash_shutdown #ifdef botch" changed
the ifdef around the calling site to add a check on SMP, but the
ifdef around the function itself was left unchanged, leaving an
unused function for PPC_STD_MMU_64=y and SMP=n
Rather than have two ifdefs that can get out of sync like this,
simply put the corrected conditional around the function and use
a stub to get rid of one set of ifdefs completely.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/kernel/crash.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 3d569e2..3d3d416 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -163,7 +163,7 @@ static void crash_kexec_prepare_cpus(int cpu)
}
/* wait for all the CPUs to hit real mode but timeout if they don't come in */
-#ifdef CONFIG_PPC_STD_MMU_64
+#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
static void crash_kexec_wait_realmode(int cpu)
{
unsigned int msecs;
@@ -188,6 +188,8 @@ static void crash_kexec_wait_realmode(int cpu)
}
mb();
}
+#else
+static inline void crash_kexec_wait_realmode(int cpu) {}
#endif
/*
@@ -344,9 +346,7 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
crash_save_cpu(regs, crashing_cpu);
crash_kexec_prepare_cpus(crashing_cpu);
cpu_set(crashing_cpu, cpus_in_crash);
-#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
crash_kexec_wait_realmode(crashing_cpu);
-#endif
machine_kexec_mask_interrupts();
--
1.7.3.3
^ permalink raw reply related
* Re: mmotm threatens ppc preemption again
From: Jeremy Fitzhardinge @ 2011-03-31 17:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, Hugh Dickins, Peter Zijlstra
In-Reply-To: <1301532729.2407.16.camel@pasglop>
On 03/30/2011 05:52 PM, Benjamin Herrenschmidt wrote:
> We deal with preemption already since the PTL turns into a mutex on -rt,
> so we could bring that patch into mainline. The easiest approach however
> for now would be to not do the kernel batched updates on kernel
> (solution 4), and I can sort it out later if I want to enable it.
>
> The problem is that it's hard for me to "fix" that with the current
> accessors as arch_enter_lazy_mmu_mode() don't get any argument that
> could point me to which mm is being operated on.
>
> Jeremy, I haven't had a chance to look at your patches in detail, do
> you just use those accessors or do you create new ones for batching
> kernel updates in which case powerpc could just make them do nothing ?
>
> Else, we could have one patch that adds an mm argument accross the tree,
> it shouldn't be too hard.
No, its the same accessors for both, since the need to distinguish them
hasn't really come up. Could you put a "if (preemptable()) return;"
guard in your implementations?
Otherwise I have no objections to passing the mm in (we'll probably just
continue to ignore the arg in x86-land).
Thanks,
J
^ permalink raw reply
* Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
From: Eric B Munson @ 2011-03-31 16:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: a.p.zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev
In-Reply-To: <1301551476.2407.61.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]
On Thu, 31 Mar 2011, Benjamin Herrenschmidt wrote:
> On Wed, 2011-03-30 at 14:36 -0400, Eric B Munson wrote:
> > On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote:
> >
> > > On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote:
> > > > Here I made the assumption that the hardware would never remove more events in
> > > > a speculative roll back than it had added. This is not a situation I
> > > > encoutered in my limited testing, so I didn't think underflow was possible. I
> > > > will send out a V2 using the signed 32 bit delta and remeber to CC stable
> > > > this time.
> > >
> > > I'm not thinking about underflow but rollover... or that isn't possible
> > > with those counters ? IE. They don't wrap back to 0 after hitting
> > > ffffffff ?
> > >
> >
> > They do roll over to 0 after ffffffff, but I thought that case was already
> > covered by the perf_event_interrupt. Are you concerned that we will reset a
> > counter and speculative roll back will underflow that counter?
>
> No, but take this part of the patch:
>
> > --- a/arch/powerpc/kernel/perf_event.c
> > +++ b/arch/powerpc/kernel/perf_event.c
> > @@ -416,6 +416,15 @@ static void power_pmu_read(struct perf_event *event)
> > prev = local64_read(&event->hw.prev_count);
> > barrier();
> > val = read_pmc(event->hw.idx);
> > + /*
> > + * POWER7 can roll back counter values, if the new value is
> > + * smaller than the previous value it will cause the delta
> > + * and the counter to have bogus values. If this is the
> > + * case skip updating anything until the counter grows again.
> > + * This can lead to a small lack of precision in the counters.
> > + */
> > + if (val < prev)
> > + return;
> > } while (local64_cmpxchg(&event->hw.prev_count, prev, val) != prev);
>
> Doesn't that mean that power_pmu_read() can only ever increase the value of
> the perf_event and so will essentially -stop- once the counter rolls over ?
>
> Similar comments every where you do this type of comparison.
>
Sorry for being so dense on this, but I think that when a counter overflows
both the register value and the previous value are reset so we should continue
seeing new event counts after the overflow interrupt handler puts the counter
back into a sane state. What am I not seeing?
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: dtc: remove obsolete .gitignore entries
From: Grant Likely @ 2011-03-31 15:58 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <1299948250-32084-1-git-send-email-w.sang@pengutronix.de>
On Sat, Mar 12, 2011 at 05:44:10PM +0100, Wolfram Sang wrote:
> dtc was moved and .gitignores have been added to the new location. So, we can
> delete the old, forgotten ones.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
It's Ben's jurisdiction, but I've picked it up into my
devicetree/merge branch anyway. If I don't hear from Ben either way
then I'll push it out to Linus next week.
g.
> ---
> arch/powerpc/boot/.gitignore | 1 -
> arch/powerpc/boot/dtc-src/.gitignore | 3 ---
> 2 files changed, 0 insertions(+), 4 deletions(-)
> delete mode 100644 arch/powerpc/boot/dtc-src/.gitignore
>
> diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
> index 3d80c3e..12da77e 100644
> --- a/arch/powerpc/boot/.gitignore
> +++ b/arch/powerpc/boot/.gitignore
> @@ -1,5 +1,4 @@
> addnote
> -dtc
> empty.c
> hack-coff
> infblock.c
> diff --git a/arch/powerpc/boot/dtc-src/.gitignore b/arch/powerpc/boot/dtc-src/.gitignore
> deleted file mode 100644
> index a7c3f94..0000000
> --- a/arch/powerpc/boot/dtc-src/.gitignore
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -dtc-lexer.lex.c
> -dtc-parser.tab.c
> -dtc-parser.tab.h
> --
> 1.7.2.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc/dts:Update PCIe memory maps to match u-boot of Px020RDB
From: Leon Woestenberg @ 2011-03-31 11:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: meet2prabhu, linuxppc-dev, Prabhakar Kushwaha
In-Reply-To: <38B7F1DC-21FC-4723-AF41-E66E04DF0B1F@kernel.crashing.org>
Hello Prabhakar, Kumar,
(I missed the original post, due to temporarely being unsubscribed, I
am responding to Kumar's reply).
On Thu, Mar 31, 2011 at 10:22 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> On Mar 24, 2011, at 11:47 PM, Prabhakar Kushwaha wrote:
>
>> PCIe memory address space is 1:1 mapped with u-boot.
>>
>> Update dts of Px020RDB i.e. P1020RDB and P2020RDB to match the address map
>> changes in u-boot.
>>
Does this mean u-boot and Linux versions should be selectively matched, or not?
What commit in u-boot does this apply to?
Regards,
--
Leon
^ permalink raw reply
* configure FPGA
From: SACHIN SOLANKI @ 2011-03-31 9:42 UTC (permalink / raw)
To: linuxppc-dev
hi sir,
i want to store some bit stream to compect flesh in diffrenrt memory
location.is it possible through powerPC control programing that we
can select sinrgle bit stream from complect flesh card and configure
fpga.
looking forward for reply....
^ permalink raw reply
* Re: [PATCH] powerpc/dts:Update PCIe memory maps to match u-boot of Px020RDB
From: Kumar Gala @ 2011-03-31 8:22 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: meet2prabhu, linuxppc-dev
In-Reply-To: <1301028465-3897-1-git-send-email-prabhakar@freescale.com>
On Mar 24, 2011, at 11:47 PM, Prabhakar Kushwaha wrote:
> PCIe memory address space is 1:1 mapped with u-boot.
>=20
> Update dts of Px020RDB i.e. P1020RDB and P2020RDB to match the address =
map
> changes in u-boot.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> Acked-by: Kumar Gala <kumar.gala@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =
(Branch master)
>=20
> arch/powerpc/boot/dts/p1020rdb.dts | 12 ++++++------
> arch/powerpc/boot/dts/p2020rdb.dts | 12 ++++++------
> arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 4 ++--
> arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 10 +++++-----
> 4 files changed, 19 insertions(+), 19 deletions(-)
applied to 'merge'
- k=
^ permalink raw reply
* [PATCH] powerpc/85xx: Don't add disabled PCIe devices
From: Prabhakar Kushwaha @ 2011-03-31 7:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meet2prabhu, Prabhakar Kushwaha
PCIe nodes with the property status="disabled" are not usable and so
avoid adding "disabled" PCIe bridge with the system.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Acked-by: Kumar Gala <kumar.gala@freescale.com>
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch master)
arch/powerpc/sysdev/fsl_pci.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index f8f7f28..68ca929 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -324,6 +324,11 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
struct resource rsrc;
const int *bus_range;
+ if (!of_device_is_available(dev)) {
+ pr_warning("%s: disabled\n", dev->full_name);
+ return -ENODEV;
+ }
+
pr_debug("Adding PCI host bridge %s\n", dev->full_name);
/* Fetch host bridge registers address */
--
1.7.3
^ permalink raw reply related
* Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
From: Benjamin Herrenschmidt @ 2011-03-31 6:04 UTC (permalink / raw)
To: Eric B Munson
Cc: a.p.zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev
In-Reply-To: <20110330183656.GA2564@mgebm.net>
On Wed, 2011-03-30 at 14:36 -0400, Eric B Munson wrote:
> On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote:
>
> > On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote:
> > > Here I made the assumption that the hardware would never remove more events in
> > > a speculative roll back than it had added. This is not a situation I
> > > encoutered in my limited testing, so I didn't think underflow was possible. I
> > > will send out a V2 using the signed 32 bit delta and remeber to CC stable
> > > this time.
> >
> > I'm not thinking about underflow but rollover... or that isn't possible
> > with those counters ? IE. They don't wrap back to 0 after hitting
> > ffffffff ?
> >
>
> They do roll over to 0 after ffffffff, but I thought that case was already
> covered by the perf_event_interrupt. Are you concerned that we will reset a
> counter and speculative roll back will underflow that counter?
No, but take this part of the patch:
> --- a/arch/powerpc/kernel/perf_event.c
> +++ b/arch/powerpc/kernel/perf_event.c
> @@ -416,6 +416,15 @@ static void power_pmu_read(struct perf_event *event)
> prev = local64_read(&event->hw.prev_count);
> barrier();
> val = read_pmc(event->hw.idx);
> + /*
> + * POWER7 can roll back counter values, if the new value is
> + * smaller than the previous value it will cause the delta
> + * and the counter to have bogus values. If this is the
> + * case skip updating anything until the counter grows again.
> + * This can lead to a small lack of precision in the counters.
> + */
> + if (val < prev)
> + return;
> } while (local64_cmpxchg(&event->hw.prev_count, prev, val) != prev);
Doesn't that mean that power_pmu_read() can only ever increase the value of
the perf_event and so will essentially -stop- once the counter rolls over ?
Similar comments every where you do this type of comparison.
Cheers,
Ben.
^ permalink raw reply
* Re: How to define an I2C-to-SPI bridge device ?
From: Grant Likely @ 2011-03-31 3:43 UTC (permalink / raw)
To: Andre Schwarz; +Cc: LinuxPPC List
In-Reply-To: <4D92071E.3060906@matrix-vision.de>
On Tue, Mar 29, 2011 at 06:21:50PM +0200, Andre Schwarz wrote:
> On 03/25/2011 10:28 AM, Andre Schwarz wrote:
> >Grant, Anton,
>
> got it.
> providing modalis = "spidev" within spi_board_info works like a charme ...
Good. Glad you got it sorted out.
g.
^ 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