* Re: [v10 PATCH 8/9]: pSeries: implement pSeries processor idle module
From: Benjamin Herrenschmidt @ 2009-12-04 2:47 UTC (permalink / raw)
To: arun
Cc: linux-arch, Peter Zijlstra, linux-kernel, linux-acpi,
Venkatesh Pallipadi, Ingo Molnar, linuxppc-dev
In-Reply-To: <20091202100255.GI27251@linux.vnet.ibm.com>
On Wed, 2009-12-02 at 15:32 +0530, Arun R Bharadwaj wrote:
> * Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-12-02 15:24:27]:
>
> This patch creates arch/powerpc/platforms/pseries/processor_idle.c,
> which implements the cpuidle infrastructure for pseries.
> It implements a pseries_cpuidle_loop() which would be the main idle loop
> called from cpu_idle(). It makes decision of entering either
> dedicated_snooze_loop or dedicated_cede_loop for dedicated lpar and
> shared_cede_loop for shared lpar processor based on the
> decision taken by the cpuidle governor.
So unless I'm mistaken, you removed our powerpc "generic" idle loop that
calls into ppc_md.power_save(), and replaced it by some pseries specific
idle loops... Now what about all the other powerpc platforms ? native
970 (aka G5) ? 6xx ? Cell ? Or are you still calling ppc_md.power_save
somewhere that I missed ?
Cheers,
Ben.
> Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/system.h | 6
> arch/powerpc/kernel/sysfs.c | 2
> arch/powerpc/platforms/pseries/Makefile | 1
> arch/powerpc/platforms/pseries/processor_idle.c | 196 ++++++++++++++++++++++++
> arch/powerpc/platforms/pseries/pseries.h | 6
> 5 files changed, 211 insertions(+)
>
> Index: linux.trees.git/arch/powerpc/platforms/pseries/Makefile
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/pseries/Makefile
> +++ linux.trees.git/arch/powerpc/platforms/pseries/Makefile
> @@ -26,3 +26,4 @@ obj-$(CONFIG_HCALL_STATS) += hvCall_inst
> obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
> obj-$(CONFIG_CMM) += cmm.o
> obj-$(CONFIG_DTL) += dtl.o
> +obj-$(CONFIG_CPU_IDLE) += processor_idle.o
> Index: linux.trees.git/arch/powerpc/platforms/pseries/pseries.h
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/pseries/pseries.h
> +++ linux.trees.git/arch/powerpc/platforms/pseries/pseries.h
> @@ -10,6 +10,8 @@
> #ifndef _PSERIES_PSERIES_H
> #define _PSERIES_PSERIES_H
>
> +#include <linux/cpuidle.h>
> +
> extern void __init fw_feature_init(const char *hypertas, unsigned long len);
>
> struct pt_regs;
> @@ -40,4 +42,8 @@ extern unsigned long rtas_poweron_auto;
>
> extern void find_udbg_vterm(void);
>
> +DECLARE_PER_CPU(unsigned long, smt_snooze_delay);
> +
> +extern struct cpuidle_driver pseries_idle_driver;
> +
> #endif /* _PSERIES_PSERIES_H */
> Index: linux.trees.git/arch/powerpc/platforms/pseries/processor_idle.c
> ===================================================================
> --- /dev/null
> +++ linux.trees.git/arch/powerpc/platforms/pseries/processor_idle.c
> @@ -0,0 +1,196 @@
> +/*
> + * processor_idle - idle state cpuidle driver.
> + * Adapted from drivers/acpi/processor_idle.c
> + *
> + * Arun R Bharadwaj <arun@linux.vnet.ibm.com>
> + *
> + * Copyright (C) 2009 IBM Corporation.
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or (at
> + * your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/moduleparam.h>
> +#include <linux/cpuidle.h>
> +
> +#include <asm/paca.h>
> +#include <asm/reg.h>
> +#include <asm/system.h>
> +#include <asm/machdep.h>
> +#include <asm/firmware.h>
> +
> +#include "plpar_wrappers.h"
> +#include "pseries.h"
> +
> +MODULE_AUTHOR("Arun R Bharadwaj");
> +MODULE_DESCRIPTION("pSeries Idle State Driver");
> +MODULE_LICENSE("GPL");
> +
> +struct cpuidle_driver pseries_idle_driver = {
> + .name = "pseries_idle",
> + .owner = THIS_MODULE,
> +};
> +
> +DEFINE_PER_CPU(struct cpuidle_device, pseries_dev);
> +
> +#define IDLE_STATE_COUNT 2
> +
> +/* pSeries Idle state Flags */
> +#define PSERIES_DEDICATED_SNOOZE (0x01)
> +#define PSERIES_DEDICATED_CEDE (0x02)
> +#define PSERIES_SHARED_CEDE (0x03)
> +
> +static int pseries_idle_init(struct cpuidle_device *dev)
> +{
> + return cpuidle_register_device(dev);
> +}
> +
> +static void shared_cede_loop(void)
> +{
> + get_lppaca()->idle = 1;
> + cede_processor();
> + get_lppaca()->idle = 0;
> +}
> +
> +static void dedicated_snooze_loop(void)
> +{
> + local_irq_enable();
> + set_thread_flag(TIF_POLLING_NRFLAG);
> + while (!need_resched()) {
> + ppc64_runlatch_off();
> + HMT_low();
> + HMT_very_low();
> + }
> + HMT_medium();
> + clear_thread_flag(TIF_POLLING_NRFLAG);
> + smp_mb();
> + local_irq_disable();
> +}
> +
> +static void dedicated_cede_loop(void)
> +{
> + ppc64_runlatch_off();
> + HMT_medium();
> + cede_processor();
> +}
> +
> +static void pseries_cpuidle_loop(struct cpuidle_device *dev,
> + struct cpuidle_state *st)
> +{
> + unsigned long in_purr, out_purr;
> +
> + get_lppaca()->idle = 1;
> + get_lppaca()->donate_dedicated_cpu = 1;
> + in_purr = mfspr(SPRN_PURR);
> +
> + if (st->flags & PSERIES_SHARED_CEDE)
> + shared_cede_loop();
> + else if (st->flags & PSERIES_DEDICATED_SNOOZE)
> + dedicated_snooze_loop();
> + else
> + dedicated_cede_loop();
> +
> + out_purr = mfspr(SPRN_PURR);
> + get_lppaca()->wait_state_cycles += out_purr - in_purr;
> + get_lppaca()->donate_dedicated_cpu = 0;
> + get_lppaca()->idle = 0;
> +}
> +
> +static int pseries_setup_cpuidle(struct cpuidle_device *dev, int cpu)
> +{
> + int i;
> + struct cpuidle_state *state;
> +
> + dev->cpu = cpu;
> +
> + if (get_lppaca()->shared_proc) {
> + state = &dev->states[0];
> + snprintf(state->name, CPUIDLE_NAME_LEN, "IDLE");
> + state->enter = pseries_cpuidle_loop;
> + strncpy(state->desc, "shared_cede", CPUIDLE_DESC_LEN);
> + state->flags = PSERIES_SHARED_CEDE;
> + state->exit_latency = 0;
> + state->target_residency = 0;
> + return 0;
> + }
> +
> + for (i = 0; i < IDLE_STATE_COUNT; i++) {
> + state = &dev->states[i];
> +
> + snprintf(state->name, CPUIDLE_NAME_LEN, "CEDE%d", i);
> + state->enter = pseries_cpuidle_loop;
> +
> + switch (i) {
> + case 0:
> + strncpy(state->desc, "snooze", CPUIDLE_DESC_LEN);
> + state->flags = PSERIES_DEDICATED_SNOOZE;
> + state->exit_latency = 0;
> + state->target_residency = 0;
> + break;
> +
> + case 1:
> + strncpy(state->desc, "cede", CPUIDLE_DESC_LEN);
> + state->flags = PSERIES_DEDICATED_CEDE;
> + state->exit_latency = 1;
> + state->target_residency =
> + __get_cpu_var(smt_snooze_delay);
> + break;
> + }
> + }
> + dev->state_count = IDLE_STATE_COUNT;
> +
> + return 0;
> +}
> +
> +void update_smt_snooze_delay(int snooze)
> +{
> + int cpu;
> + for_each_online_cpu(cpu)
> + per_cpu(pseries_dev, cpu).states[0].target_residency = snooze;
> +}
> +
> +static int __init pseries_processor_idle_init(void)
> +{
> + int cpu;
> + int result;
> +
> + result = cpuidle_register_driver(&pseries_idle_driver);
> +
> + if (result < 0)
> + return result;
> +
> + printk(KERN_DEBUG "pSeries idle driver registered\n");
> +
> + if (!firmware_has_feature(FW_FEATURE_SPLPAR)) {
> + printk(KERN_DEBUG "Using default idle\n");
> + return 0;
> + }
> +
> + for_each_online_cpu(cpu) {
> + pseries_setup_cpuidle(&per_cpu(pseries_dev, cpu), cpu);
> + pseries_idle_init(&per_cpu(pseries_dev, cpu));
> + }
> +
> + printk(KERN_DEBUG "Using cpuidle idle loop\n");
> +
> + return 0;
> +}
> +
> +device_initcall(pseries_processor_idle_init);
> Index: linux.trees.git/arch/powerpc/include/asm/system.h
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/include/asm/system.h
> +++ linux.trees.git/arch/powerpc/include/asm/system.h
> @@ -549,5 +549,11 @@ extern struct dentry *powerpc_debugfs_ro
>
> void cpu_idle_wait(void);
>
> +#ifdef CONFIG_CPU_IDLE
> +extern void update_smt_snooze_delay(int snooze);
> +#else
> +static inline void update_smt_snooze_delay(int snooze) {}
> +#endif
> +
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_SYSTEM_H */
> Index: linux.trees.git/arch/powerpc/kernel/sysfs.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/kernel/sysfs.c
> +++ linux.trees.git/arch/powerpc/kernel/sysfs.c
> @@ -18,6 +18,7 @@
> #include <asm/machdep.h>
> #include <asm/smp.h>
> #include <asm/pmc.h>
> +#include <asm/system.h>
>
> #include "cacheinfo.h"
>
> @@ -51,6 +52,7 @@ static ssize_t store_smt_snooze_delay(st
> return -EINVAL;
>
> per_cpu(smt_snooze_delay, cpu->sysdev.id) = snooze;
> + update_smt_snooze_delay(snooze);
>
> return count;
> }
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: Fix thinko in _stp_arg()
From: Ananth N Mavinakayanahalli @ 2009-12-04 4:21 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Jim Keniston, systemtap
In-Reply-To: <20091203233151.GA3416@oksana.dev.rtsoft.ru>
On Fri, Dec 04, 2009 at 02:31:51AM +0300, Anton Vorontsov wrote:
> _stp_arg() has an almost unnoticeable thinko in the argnum handling,
> which causes it to always return u_register("r10"):
>
> 'else (argnum == 8)' should actually be 'else if (argnum == 8)'.
>
> Though, since we check for 'if (argnum < 1 || argnum > 8)' at the
> beginning of _stp_arg(), let's make it just 'else'.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Ugh! What was I thinking?
Thanks for fixing this Anton.
Ananth
^ permalink raw reply
* Re: PCI interrupt question
From: Stefan Roese @ 2009-12-04 4:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeff Hane
In-Reply-To: <1259869140.18190.52.camel@qu102.quarc.com>
On Thursday 03 December 2009 20:39:00 Jeff Hane wrote:
> > Can you clarify:
> >
> > 1. 460EX is your PCI host CPU?
>
> yes. We are using a canyonlands board with 460ex.
PCI works on Canyonlands without any problems. I just tested latest Linux
release (2.6.32) with an PCI USB card:
-bash-3.2# uname -a
Linux canyonlands 2.6.32 #1 Fri Dec 4 05:42:35 CET 2009 ppc ppc ppc GNU/Linux
-bash-3.2# cat /proc/cpuinfo
processor : 0
cpu : 460EX
clock : 800.000010MHz
revision : 24.162 (pvr 1302 18a2)
bogomips : 1600.00
timebase : 800000010
platform : PowerPC 44x Platform
model : amcc,canyonlands
Memory : 512 MB
-bash-3.2# cat /proc/interrupts
CPU0
18: 0 UIC Edge L2C
19: 22 UIC Level ohci_hcd:usb2, ohci_hcd:usb3
20: 15220 UIC Level serial
23: 8038 UIC Level MAL TX EOB
24: 15510 UIC Level MAL RX EOB
25: 0 UIC Level MAL SERR
26: 0 UIC Level MAL TX DE
27: 0 UIC Level MAL RX DE
28: 0 UIC Level EMAC
34: 1 UIC Level ohci_hcd:usb1
35: 2926 UIC Level IBM IIC
38: 0 UIC Level IBM IIC
BAD: 0
-bash-3.2#
I can't see any problems with PCI interrupts here.
Cheers,
Stefan
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Michael Lawnick @ 2009-12-04 6:58 UTC (permalink / raw)
To: Ben Dooks; +Cc: linuxppc-dev, Esben Haabendal, Esben Haabendal, linux-i2c
In-Reply-To: <20091203152916.GC23152@trinity.fluff.org>
Ben Dooks said the following:
> On Thu, Dec 03, 2009 at 04:09:57PM +0100, Michael Lawnick wrote:
>> Ben Dooks said the following:
>> > On Tue, May 26, 2009 at 01:30:21PM +0200, Esben Haabendal wrote:
>> >> On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal <eha@doredevelopment.dk> wrote:
>> >> > This fixes MAL (arbitration lost) bug caused by illegal use of
>> >> > RSTA (repeated START) after STOP condition generated after last byte
>> >> > of reads. With this patch, it is possible to do an i2c_transfer() with
>> >> > additional i2c_msg's following the I2C_M_RD messages.
>> >> >
>> >> > It still needs to be resolved if it is possible to fix this issue
>> >> > by removing the STOP condition after reads in a robust way.
>> >> >
>> >> > Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
>> >> > ---
>> >> > ?drivers/i2c/busses/i2c-mpc.c | ? ?9 +++++++--
>> >> > ?1 files changed, 7 insertions(+), 2 deletions(-)
>> >>
>> >> Any blockers to get this accepted?
>> >
>> > It would be nice to get an ack from someone who can actually test
>> > the driver before getting this merged.
>> >
>> What is the state of this patch?
>> Shouldn't we attack the problem on a more general way by inventing a
>> Flag I2C_M_RESTART (or better I2C_M_NO_RESTART for backward compatibility)?
>> This way the client driver is able to decide what it needs. If we do the
>> choice within adapter, chance is about 50% to be wrong.
>
> The documentation for 'struct i2c_msg' already says the STOP should only
> be generated for the last message of the transfer. If STOP is being
> generated for a message that isn't the last in the transfer than this
> is incorrect behaviour.
Ah, now I see, this is a mpc-only problem of implementation
(automatically generating stop in read function).
I couldn't find the above mentioned specification of STOP/RESTART (seems
I need new glasses) and was worried about whether my own implementation
for OCTEON is correct.
Thank you.
--
Michael
^ permalink raw reply
* using different format for hugetlbfs
From: Kumar Gala @ 2009-12-04 7:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, David Gibson; +Cc: linux-ppc list
Ben, David,
If we want to support true 4G/4G split on ppc32 using the MSB of the
address to determine of the pgd_t is for hugetlbfs isn't going to
work. Since every pointer in the pgd_t -> pud_t -> pmd_t is point to
at least a 4K page I would think the low order 12-bits should always
be 0.
Could we use something like:
addr[0:51] || shift [52:59] || flags [60:63]
with the LSB flag being 'normal pointer' vs 'hugetlbfs mangled
pointer'. Seems like shift will at most be 64 so 8-bits should cover
it.
- k
^ permalink raw reply
* Re: [v10 PATCH 8/9]: pSeries: implement pSeries processor idle module
From: Arun R Bharadwaj @ 2009-12-04 8:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-arch, Peter Zijlstra, linux-kernel, linux-acpi,
Venkatesh Pallipadi, Arun Bharadwaj, Ingo Molnar, linuxppc-dev
In-Reply-To: <1259894858.2076.1251.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> [2009-12-04 13:47:38]:
> On Wed, 2009-12-02 at 15:32 +0530, Arun R Bharadwaj wrote:
> > * Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-12-02 15:24:27]:
> >
> > This patch creates arch/powerpc/platforms/pseries/processor_idle.c,
> > which implements the cpuidle infrastructure for pseries.
> > It implements a pseries_cpuidle_loop() which would be the main idle loop
> > called from cpu_idle(). It makes decision of entering either
> > dedicated_snooze_loop or dedicated_cede_loop for dedicated lpar and
> > shared_cede_loop for shared lpar processor based on the
> > decision taken by the cpuidle governor.
>
> So unless I'm mistaken, you removed our powerpc "generic" idle loop that
> calls into ppc_md.power_save(), and replaced it by some pseries specific
> idle loops... Now what about all the other powerpc platforms ? native
> 970 (aka G5) ? 6xx ? Cell ? Or are you still calling ppc_md.power_save
> somewhere that I missed ?
>
> Cheers,
> Ben.
Hi Ben,
I forgot to attach the patch which enables cpuidle for the rest of the
POWER platforms. Attaching it below.
So for these platforms, ppc_md.power_save will be called from from the
cpuidle_idle_call idle loop itself. Also, this cpuidle_idle_call is
not a pseries specific idle loop. It is a common loop for Intel and
PPC which use cpuidle infrastructure.
arun
This patch enables cpuidle for the rest of the POWER platforms like
44x, Cell, Pasemi etc.
Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/system.h | 2 ++
arch/powerpc/kernel/idle.c | 28 ++++++++++++++++++++++++++++
arch/powerpc/kernel/setup_32.c | 8 ++++++--
arch/powerpc/platforms/44x/idle.c | 2 ++
arch/powerpc/platforms/cell/pervasive.c | 2 ++
arch/powerpc/platforms/pasemi/idle.c | 2 ++
arch/powerpc/platforms/ps3/setup.c | 2 ++
7 files changed, 44 insertions(+), 2 deletions(-)
Index: linux.trees.git/arch/powerpc/include/asm/system.h
===================================================================
--- linux.trees.git.orig/arch/powerpc/include/asm/system.h
+++ linux.trees.git/arch/powerpc/include/asm/system.h
@@ -551,8 +551,10 @@ void cpu_idle_wait(void);
#ifdef CONFIG_CPU_IDLE
extern void update_smt_snooze_delay(int snooze);
+extern void setup_cpuidle_ppc(void);
#else
static inline void update_smt_snooze_delay(int snooze) {}
+static inline void setup_cpuidle_ppc(void) {}
#endif
#endif /* __KERNEL__ */
Index: linux.trees.git/arch/powerpc/kernel/idle.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/idle.c
+++ linux.trees.git/arch/powerpc/kernel/idle.c
@@ -129,6 +129,34 @@ void default_idle(void)
HMT_very_low();
}
+#ifdef CONFIG_CPU_IDLE
+DEFINE_PER_CPU(struct cpuidle_device, ppc_idle_devices);
+struct cpuidle_driver cpuidle_ppc_driver = {
+ .name = "cpuidle_ppc",
+};
+
+static void ppc_idle_loop(struct cpuidle_device *dev, struct cpuidle_state *st)
+{
+ ppc_md.power_save();
+}
+
+void setup_cpuidle_ppc(void)
+{
+ struct cpuidle_device *dev;
+ int cpu;
+
+ cpuidle_register_driver(&cpuidle_ppc_driver);
+
+ for_each_online_cpu(cpu) {
+ dev = &per_cpu(ppc_idle_devices, cpu);
+ dev->cpu = cpu;
+ dev->states[0].enter = ppc_idle_loop;
+ dev->state_count = 1;
+ cpuidle_register_device(dev);
+ }
+}
+#endif
+
int powersave_nap;
#ifdef CONFIG_SYSCTL
Index: linux.trees.git/arch/powerpc/kernel/setup_32.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/kernel/setup_32.c
+++ linux.trees.git/arch/powerpc/kernel/setup_32.c
@@ -133,14 +133,18 @@ notrace void __init machine_init(unsigne
#ifdef CONFIG_6xx
if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
- cpu_has_feature(CPU_FTR_CAN_NAP))
+ cpu_has_feature(CPU_FTR_CAN_NAP)) {
ppc_md.power_save = ppc6xx_idle;
+ setup_cpuidle_ppc();
+ }
#endif
#ifdef CONFIG_E500
if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
- cpu_has_feature(CPU_FTR_CAN_NAP))
+ cpu_has_feature(CPU_FTR_CAN_NAP)) {
ppc_md.power_save = e500_idle;
+ setup_cpuidle_ppc();
+ }
#endif
if (ppc_md.progress)
ppc_md.progress("id mach(): done", 0x200);
Index: linux.trees.git/arch/powerpc/platforms/44x/idle.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/platforms/44x/idle.c
+++ linux.trees.git/arch/powerpc/platforms/44x/idle.c
@@ -24,6 +24,7 @@
#include <linux/of.h>
#include <linux/kernel.h>
#include <asm/machdep.h>
+#include <asm/system.h>
static int mode_spin;
@@ -46,6 +47,7 @@ int __init ppc44x_idle_init(void)
/* If we are not setting spin mode
then we set to wait mode */
ppc_md.power_save = &ppc44x_idle;
+ setup_cpuidle_ppc();
}
return 0;
Index: linux.trees.git/arch/powerpc/platforms/cell/pervasive.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/platforms/cell/pervasive.c
+++ linux.trees.git/arch/powerpc/platforms/cell/pervasive.c
@@ -35,6 +35,7 @@
#include <asm/pgtable.h>
#include <asm/reg.h>
#include <asm/cell-regs.h>
+#include <asm/system.h>
#include "pervasive.h"
@@ -128,5 +129,6 @@ void __init cbe_pervasive_init(void)
}
ppc_md.power_save = cbe_power_save;
+ setup_cpuidle_ppc();
ppc_md.system_reset_exception = cbe_system_reset_exception;
}
Index: linux.trees.git/arch/powerpc/platforms/pasemi/idle.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/platforms/pasemi/idle.c
+++ linux.trees.git/arch/powerpc/platforms/pasemi/idle.c
@@ -27,6 +27,7 @@
#include <asm/machdep.h>
#include <asm/reg.h>
#include <asm/smp.h>
+#include <asm/system.h>
#include "pasemi.h"
@@ -81,6 +82,7 @@ static int __init pasemi_idle_init(void)
ppc_md.system_reset_exception = pasemi_system_reset_exception;
ppc_md.power_save = modes[current_mode].entry;
+ setup_cpuidle_ppc();
printk(KERN_INFO "Using PA6T idle loop (%s)\n", modes[current_mode].name);
return 0;
Index: linux.trees.git/arch/powerpc/platforms/ps3/setup.c
===================================================================
--- linux.trees.git.orig/arch/powerpc/platforms/ps3/setup.c
+++ linux.trees.git/arch/powerpc/platforms/ps3/setup.c
@@ -33,6 +33,7 @@
#include <asm/prom.h>
#include <asm/lv1call.h>
#include <asm/ps3gpu.h>
+#include <asm/system.h>
#include "platform.h"
@@ -214,6 +215,7 @@ static void __init ps3_setup_arch(void)
prealloc_ps3flash_bounce_buffer();
ppc_md.power_save = ps3_power_save;
+ setup_cpuidle_ppc();
ps3_os_area_init();
DBG(" <- %s:%d\n", __func__, __LINE__);
^ permalink raw reply
* Re: using different format for hugetlbfs
From: Benjamin Herrenschmidt @ 2009-12-04 8:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ppc list, David Gibson
In-Reply-To: <230774E3-2D94-44DA-85AC-151485996789@kernel.crashing.org>
On Fri, 2009-12-04 at 01:18 -0600, Kumar Gala wrote:
> Ben, David,
>
> If we want to support true 4G/4G split on ppc32 using the MSB of the
> address to determine of the pgd_t is for hugetlbfs isn't going to
> work. Since every pointer in the pgd_t -> pud_t -> pmd_t is point to
> at least a 4K page I would think the low order 12-bits should always
> be 0.
On 32 bit maybe. On 64, the pg/u/md's can be smaller. I don't really
want to have a different encoding for both types though.
> Could we use something like:
>
> addr[0:51] || shift [52:59] || flags [60:63]
>
> with the LSB flag being 'normal pointer' vs 'hugetlbfs mangled
> pointer'. Seems like shift will at most be 64 so 8-bits should cover
> it.
Cheers,
Ben.
^ permalink raw reply
* Re: PCI interrupt question
From: Benjamin Herrenschmidt @ 2009-12-04 9:02 UTC (permalink / raw)
To: Jeff Hane; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1259869140.18190.52.camel@qu102.quarc.com>
> So are you saying linux should be writing the irq number to the
> INTERRUPT_LINE config reg? This is what I expected but I do not see
> it.
No it won't necessarily touch it, this is not terribly useful anyways.
Linux will assign an interrupt based on the informations from the
device-tree and you should be able to retrieve it in pci_dev->irq.
> I believe the DTS is being parsed properly and the connection is made
> to the correct interrupt line on the device. But somebody still needs
> to assign and IRQ number, right?
What do you mean ? If the connection is made properly, the code will
obtain an HW IRQ input number on the UIC and will map it to a linux
virtual IRQ number which you can find in pci_dev->irq.
> This is the part that is not clear,
> there is an irq field in pci_dev structure which is filled in after
> looking at the DTS and I just want to be sure this is the irq number to
> be used when calling request_irq.
Yes, it is.
If things don't work, it's possible that you assigned the wrong number
in the device-tree ?
Cheers,
Ben.
> thanks,
> jeff
>
>
>
> > These comments might not be 100% correct, but the list of things
> > to check should be close enough for you to track down your
> > problem.
> >
> > Cheers,
> > Dave
> >
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PCI interrupt question
From: Benjamin Herrenschmidt @ 2009-12-04 9:05 UTC (permalink / raw)
To: David Hawkins; +Cc: Jeff Hane, linuxppc-dev@ozlabs.org
In-Reply-To: <4B1816F9.1020601@ovro.caltech.edu>
On Thu, 2009-12-03 at 11:52 -0800, David Hawkins wrote:
>
> Really? I thought the pci_dev structures represent the
> devices found on the PCI bus, and the IRQ line in
> that structure was merely copied from the configuration
> space registers.
No, it's not. In fact it's mostly irrelevant. It has room for only 8
bits and we commonly manipulate a lot more interrupts on some modern
systems.
Linux will obtain from the device-tree the routing for the interrupt
line(s) of the device. If you don't have a node for the device (which is
allowed for PCI), linux will use the INTERRUPT_PIN register to query
which interrupt line is the device output, and will use the host bridge
device-tree node "interrupt-map" property to find where it's connected
to on the PIC.
It will then map that to a linux virtual IRQ number which is what you
find in pci_dev. At least that's how it works on powerpc :-)
> When you request that interrupt, the
> code would have to remap it to a host IRQ line, which
> it would use the DTS for. (But I'm just speculating).
No, it's already remapped in pci_dev. The mapping happen when the PCI
devices are discovered by the kernel.
> Bottom line is; if the IRQ field of lspci is 0, then you
> need to figure out that problem first :)
I wouldn't trust lspci too much, I'm not sure we bother writing back the
number to the PCI_INTERRUPT_LINE register anymore anyways.
If your pci_dev->irq is non-0 then Linux found -something- but it might
not be right, it depends on your device-tree.
Cheers,
Ben.
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Benjamin Herrenschmidt @ 2009-12-04 9:08 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20091203141853.3eafba47@lappy.seanm.ca>
On Thu, 2009-12-03 at 14:18 -0500, Sean MacLennan wrote:
> With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
> shown below. I believe these started in 2.6.32-rc8 or possibly
> 2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
> on that release, and not really testing the 2.6.32 stream.
>
> I wish I could give more info, but I don't really even have the time to
> write this email :( I am hoping somebody will have a eureka moment.
That's a concern. Remind me what CPU / MMU type is Pika using ?
Cheers,
Ben.
> Cheers,
> Sean
>
>
> [ 147.410448] BUG: Bad page map in process udevd pte:ffffffffffffffff pmd:cd883000
> [ 147.417989] addr:48003000 vm_flags:08000875 anon_vma:(null) mapping:cf4150ac index:3
> [ 147.425837] vma->vm_ops->fault: filemap_fault+0x0/0x410
> [ 147.431101] vma->vm_file->f_op->mmap: nfs_file_mmap+0x0/0x94
> [ 147.436795] Call Trace:
> [ 147.439268] [cf2dbd80] [c00065a4] show_stack+0x48/0x168 (unreliable)
> [ 147.445708] [cf2dbdb0] [c0064ac8] print_bad_pte+0x14c/0x204
> [ 147.451337] [cf2dbde0] [c0064cd4] vm_normal_page+0x90/0x98
> [ 147.456875] [cf2dbdf0] [c0064ee8] unmap_vmas+0x20c/0x638
> [ 147.462239] [cf2dbe80] [c0069194] exit_mmap+0xc8/0x170
> [ 147.467441] [cf2dbea0] [c001caa4] mmput+0x50/0xf4
> [ 147.472195] [cf2dbeb0] [c0020808] exit_mm+0x100/0x138
> [ 147.477299] [cf2dbee0] [c00211b0] do_exit+0xb0/0x580
> [ 147.482315] [cf2dbf20] [c00216c4] do_group_exit+0x44/0x9c
> [ 147.487766] [cf2dbf30] [c0021730] sys_exit_group+0x14/0x28
> [ 147.493308] [cf2dbf40] [c000dde4] ret_from_syscall+0x0/0x3c
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [v10 PATCH 8/9]: pSeries: implement pSeries processor idle module
From: Benjamin Herrenschmidt @ 2009-12-04 10:00 UTC (permalink / raw)
To: arun
Cc: linux-arch, Peter Zijlstra, linux-kernel, linux-acpi,
Venkatesh Pallipadi, Ingo Molnar, linuxppc-dev
In-Reply-To: <20091204081539.GA5883@linux.vnet.ibm.com>
On Fri, 2009-12-04 at 13:45 +0530, Arun R Bharadwaj wrote:
>
> Hi Ben,
>
> I forgot to attach the patch which enables cpuidle for the rest of the
> POWER platforms. Attaching it below.
>
> So for these platforms, ppc_md.power_save will be called from from the
> cpuidle_idle_call idle loop itself. Also, this cpuidle_idle_call is
> not a pseries specific idle loop. It is a common loop for Intel and
> PPC which use cpuidle infrastructure.
Ok, so there was a missing piece in the puzzle ;-)
I'll review asap.
Cheers,
Ben.
> arun
>
>
>
> This patch enables cpuidle for the rest of the POWER platforms like
> 44x, Cell, Pasemi etc.
>
> Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/system.h | 2 ++
> arch/powerpc/kernel/idle.c | 28 ++++++++++++++++++++++++++++
> arch/powerpc/kernel/setup_32.c | 8 ++++++--
> arch/powerpc/platforms/44x/idle.c | 2 ++
> arch/powerpc/platforms/cell/pervasive.c | 2 ++
> arch/powerpc/platforms/pasemi/idle.c | 2 ++
> arch/powerpc/platforms/ps3/setup.c | 2 ++
> 7 files changed, 44 insertions(+), 2 deletions(-)
>
> Index: linux.trees.git/arch/powerpc/include/asm/system.h
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/include/asm/system.h
> +++ linux.trees.git/arch/powerpc/include/asm/system.h
> @@ -551,8 +551,10 @@ void cpu_idle_wait(void);
>
> #ifdef CONFIG_CPU_IDLE
> extern void update_smt_snooze_delay(int snooze);
> +extern void setup_cpuidle_ppc(void);
> #else
> static inline void update_smt_snooze_delay(int snooze) {}
> +static inline void setup_cpuidle_ppc(void) {}
> #endif
>
> #endif /* __KERNEL__ */
> Index: linux.trees.git/arch/powerpc/kernel/idle.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/kernel/idle.c
> +++ linux.trees.git/arch/powerpc/kernel/idle.c
> @@ -129,6 +129,34 @@ void default_idle(void)
> HMT_very_low();
> }
>
> +#ifdef CONFIG_CPU_IDLE
> +DEFINE_PER_CPU(struct cpuidle_device, ppc_idle_devices);
> +struct cpuidle_driver cpuidle_ppc_driver = {
> + .name = "cpuidle_ppc",
> +};
> +
> +static void ppc_idle_loop(struct cpuidle_device *dev, struct cpuidle_state *st)
> +{
> + ppc_md.power_save();
> +}
> +
> +void setup_cpuidle_ppc(void)
> +{
> + struct cpuidle_device *dev;
> + int cpu;
> +
> + cpuidle_register_driver(&cpuidle_ppc_driver);
> +
> + for_each_online_cpu(cpu) {
> + dev = &per_cpu(ppc_idle_devices, cpu);
> + dev->cpu = cpu;
> + dev->states[0].enter = ppc_idle_loop;
> + dev->state_count = 1;
> + cpuidle_register_device(dev);
> + }
> +}
> +#endif
> +
> int powersave_nap;
>
> #ifdef CONFIG_SYSCTL
> Index: linux.trees.git/arch/powerpc/kernel/setup_32.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/kernel/setup_32.c
> +++ linux.trees.git/arch/powerpc/kernel/setup_32.c
> @@ -133,14 +133,18 @@ notrace void __init machine_init(unsigne
>
> #ifdef CONFIG_6xx
> if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
> - cpu_has_feature(CPU_FTR_CAN_NAP))
> + cpu_has_feature(CPU_FTR_CAN_NAP)) {
> ppc_md.power_save = ppc6xx_idle;
> + setup_cpuidle_ppc();
> + }
> #endif
>
> #ifdef CONFIG_E500
> if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
> - cpu_has_feature(CPU_FTR_CAN_NAP))
> + cpu_has_feature(CPU_FTR_CAN_NAP)) {
> ppc_md.power_save = e500_idle;
> + setup_cpuidle_ppc();
> + }
> #endif
> if (ppc_md.progress)
> ppc_md.progress("id mach(): done", 0x200);
> Index: linux.trees.git/arch/powerpc/platforms/44x/idle.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/44x/idle.c
> +++ linux.trees.git/arch/powerpc/platforms/44x/idle.c
> @@ -24,6 +24,7 @@
> #include <linux/of.h>
> #include <linux/kernel.h>
> #include <asm/machdep.h>
> +#include <asm/system.h>
>
> static int mode_spin;
>
> @@ -46,6 +47,7 @@ int __init ppc44x_idle_init(void)
> /* If we are not setting spin mode
> then we set to wait mode */
> ppc_md.power_save = &ppc44x_idle;
> + setup_cpuidle_ppc();
> }
>
> return 0;
> Index: linux.trees.git/arch/powerpc/platforms/cell/pervasive.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/cell/pervasive.c
> +++ linux.trees.git/arch/powerpc/platforms/cell/pervasive.c
> @@ -35,6 +35,7 @@
> #include <asm/pgtable.h>
> #include <asm/reg.h>
> #include <asm/cell-regs.h>
> +#include <asm/system.h>
>
> #include "pervasive.h"
>
> @@ -128,5 +129,6 @@ void __init cbe_pervasive_init(void)
> }
>
> ppc_md.power_save = cbe_power_save;
> + setup_cpuidle_ppc();
> ppc_md.system_reset_exception = cbe_system_reset_exception;
> }
> Index: linux.trees.git/arch/powerpc/platforms/pasemi/idle.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/pasemi/idle.c
> +++ linux.trees.git/arch/powerpc/platforms/pasemi/idle.c
> @@ -27,6 +27,7 @@
> #include <asm/machdep.h>
> #include <asm/reg.h>
> #include <asm/smp.h>
> +#include <asm/system.h>
>
> #include "pasemi.h"
>
> @@ -81,6 +82,7 @@ static int __init pasemi_idle_init(void)
>
> ppc_md.system_reset_exception = pasemi_system_reset_exception;
> ppc_md.power_save = modes[current_mode].entry;
> + setup_cpuidle_ppc();
> printk(KERN_INFO "Using PA6T idle loop (%s)\n", modes[current_mode].name);
>
> return 0;
> Index: linux.trees.git/arch/powerpc/platforms/ps3/setup.c
> ===================================================================
> --- linux.trees.git.orig/arch/powerpc/platforms/ps3/setup.c
> +++ linux.trees.git/arch/powerpc/platforms/ps3/setup.c
> @@ -33,6 +33,7 @@
> #include <asm/prom.h>
> #include <asm/lv1call.h>
> #include <asm/ps3gpu.h>
> +#include <asm/system.h>
>
> #include "platform.h"
>
> @@ -214,6 +215,7 @@ static void __init ps3_setup_arch(void)
> prealloc_ps3flash_bounce_buffer();
>
> ppc_md.power_save = ps3_power_save;
> + setup_cpuidle_ppc();
> ps3_os_area_init();
>
> DBG(" <- %s:%d\n", __func__, __LINE__);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Josh Boyer @ 2009-12-04 11:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <1259917707.2076.1271.camel@pasglop>
On Fri, Dec 04, 2009 at 08:08:27PM +1100, Benjamin Herrenschmidt wrote:
>On Thu, 2009-12-03 at 14:18 -0500, Sean MacLennan wrote:
>> With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
>> shown below. I believe these started in 2.6.32-rc8 or possibly
>> 2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
>> on that release, and not really testing the 2.6.32 stream.
>>
>> I wish I could give more info, but I don't really even have the time to
>> write this email :( I am hoping somebody will have a eureka moment.
>
>That's a concern. Remind me what CPU / MMU type is Pika using ?
440EP
josh
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Benjamin Herrenschmidt @ 2009-12-04 11:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <20091204110055.GP14279@hansolo.jdub.homelinux.org>
On Fri, 2009-12-04 at 06:00 -0500, Josh Boyer wrote:
> On Fri, Dec 04, 2009 at 08:08:27PM +1100, Benjamin Herrenschmidt wrote:
> >On Thu, 2009-12-03 at 14:18 -0500, Sean MacLennan wrote:
> >> With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
> >> shown below. I believe these started in 2.6.32-rc8 or possibly
> >> 2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
> >> on that release, and not really testing the 2.6.32 stream.
> >>
> >> I wish I could give more info, but I don't really even have the time to
> >> write this email :( I am hoping somebody will have a eureka moment.
> >
> >That's a concern. Remind me what CPU / MMU type is Pika using ?
>
> 440EP
Ok, I'll have a look next week. In the meantime, Sean, can you give me a
hint of what you do to trigger it ? Boot time ? specific workload ?
Cheers,
Ben.
^ permalink raw reply
* Git tags
From: Martyn Welch @ 2009-12-04 11:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
Hi Ben,
Could you please pull the git tags from Linus' tree when you pull?
It aids a little in quickly seeing how far a tree on kernel has moved
forward, at the moment the last tag on your tree is "v2.6.26-rc9" [1].
Martyn
[1]
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/benh/powerpc.git;a=summary
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: [RFC PATCH v4 2/2] powerpc: gamecube/wii: early debugging using usbgecko
From: Segher Boessenkool @ 2009-12-04 12:04 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4f4baca1cd65f7949610ca901c9a8bcb1bb74cfd.1259871725.git.albert_herranz@yahoo.es>
> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
> +setup_usbgecko_bat:
> + /* prepare a BAT for early io */
> +#if defined(CONFIG_GAMECUBE)
> + lis r8, 0x0c00
> +#elif defined(CONFIG_WII)
> + lis r8, 0x0d00
> +#else
> +#error Invalid platform for USB Gecko based early debugging.
> +#endif
A kernel with both CONFIG_WII and CONFIG_GAMECUBE works fine
on either, right? If so, could you please switch the two #ifs?
A dual-platform kernel will be used on a Wii much more likely
than on a GC.
> + /*
> + * The virtual address used must match the virtual address
> + * associated to the fixmap entry FIX_EARLY_DEBUG_BASE.
> + */
> + lis r11, 0xfffe /* top 128K */
> + ori r8, r8, 0x002a /* uncached, guarded ,rw */
> + ori r11, r11, 0x3 /* 128K */
I think you should clear Vp since the BAT mapping can survive until
after user space is started; it won't hurt to remove it either way.
So 2 instead of 3. And put the meaning in the comment :-)
Looks fine otherwise.
Segher
^ permalink raw reply
* Re: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT (v2)
From: Sachin Sant @ 2009-12-04 12:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Stephen Rothwell, David Gibson
In-Reply-To: <20091127045604.GE3184@yookeroo>
David Gibson wrote:
> Oops, stupid compile bug in the !CONFIG_PPC_SUBPAGE_PROT case with the
> last version. Fixed below.
>
> Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
>
> Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
> of kmem_caches for allocating various levels of pagetables.
> Unfortunately, it conflicts badly with CONFIG_PPC_SUBPAGE_PROT, due to
> the latter's cleverly hidden technique of adding some extra allocation
> space to the top level page directory to store the extra information
> it needs.
>
> Since that extra allocation really doesn't fit into the cleaned up
> page directory allocating scheme, this patch alters
> CONFIG_PPC_SUBPAGE_PROT to instead allocate its struct
> subpage_prot_table as part of the mm_context_t.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Ben,
Ping on this patch. It is still missing from linux-next.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
From: Josh Boyer @ 2009-12-04 12:07 UTC (permalink / raw)
To: Curtis Wald; +Cc: linuxppc-dev
In-Reply-To: <13F6A75BE29CE44F801B912901C3EF270233B6A4@wgv4.watchguardvideo.local>
On Mon, Nov 30, 2009 at 09:25:51AM -0600, Curtis Wald wrote:
>Josh,
>Here is a resend of the Yosemite.dts patch, deleting tabs and spaces in
>the IDSEL section that should look better when viewing as 80 column.
Something is still eating your patches when you send them out. They get
corrupted to the point of being unusable as you can see here:
http://patchwork.ozlabs.org/patch/39810/
However, your intentions are pretty clear. Could you look at the patch below
and see if it was what you intended? If so, I'll include it in my 'next'
branch today.
josh
---
diff --git a/arch/powerpc/boot/dts/yosemite.dts b/arch/powerpc/boot/dts/yosemite.dts
index 1fa3cb4..6492324 100644
--- a/arch/powerpc/boot/dts/yosemite.dts
+++ b/arch/powerpc/boot/dts/yosemite.dts
@@ -282,20 +282,10 @@
/* Inbound 2GB range starting at 0 */
dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x80000000>;
- /* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = <0xf800 0x0 0x0 0x0>;
interrupt-map = <
- /* IDSEL 1 */
- 0x800 0x0 0x0 0x0 &UIC0 0x1c 0x8
-
- /* IDSEL 2 */
- 0x1000 0x0 0x0 0x0 &UIC0 0x1b 0x8
-
- /* IDSEL 3 */
- 0x1800 0x0 0x0 0x0 &UIC0 0x1a 0x8
-
- /* IDSEL 4 */
- 0x2000 0x0 0x0 0x0 &UIC0 0x19 0x8
+ /* IDSEL 12 */
+ 0x6000 0x0 0x0 0x0 &UIC0 0x19 0x8
>;
};
};
^ permalink raw reply related
* Re: using different format for hugetlbfs
From: Kumar Gala @ 2009-12-04 14:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ppc list, David Gibson
In-Reply-To: <1259917136.2076.1264.camel@pasglop>
On Dec 4, 2009, at 2:58 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2009-12-04 at 01:18 -0600, Kumar Gala wrote:
>> Ben, David,
>>
>> If we want to support true 4G/4G split on ppc32 using the MSB of the
>> address to determine of the pgd_t is for hugetlbfs isn't going to
>> work. Since every pointer in the pgd_t -> pud_t -> pmd_t is point to
>> at least a 4K page I would think the low order 12-bits should always
>> be 0.
>
> On 32 bit maybe. On 64, the pg/u/md's can be smaller. I don't really
> want to have a different encoding for both types though.
What do you mean they can be smaller? We have some scenario when we
dont allocate a full page? I agree having the encodings be different
would be bad. I'm trying to avoid having it be different between 32
bit and 64 (but maybe that will be impossible).
>> Could we use something like:
>>
>> addr[0:51] || shift [52:59] || flags [60:63]
>>
>> with the LSB flag being 'normal pointer' vs 'hugetlbfs mangled
>> pointer'. Seems like shift will at most be 64 so 8-bits should cover
>> it.
>
> Cheers,
> Ben.
>
- k
^ permalink raw reply
* RE: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
From: Curtis Wald @ 2009-12-04 14:19 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20091204120744.GI2937@zod.rchland.ibm.com>
Josh,
Yes, the patch you provided below is exactly what is needed for PCI
functionality.
I've verified using a 2 port Silicon Image 3512 PCI to SATA controller
card on Yosemite.
-Curtis
> -----Original Message-----
> From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com]
> Sent: Friday, December 04, 2009 6:08 AM
> To: Curtis Wald
> Cc: mporter@kernel.crashing.org; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] POWERPC 4xx: Fix PCI in AMCC 440EP Yosemite DTS
>=20
> On Mon, Nov 30, 2009 at 09:25:51AM -0600, Curtis Wald wrote:
> >Josh,
> >Here is a resend of the Yosemite.dts patch, deleting tabs and spaces
> in
> >the IDSEL section that should look better when viewing as 80 column.
>=20
> Something is still eating your patches when you send them out. They
> get
> corrupted to the point of being unusable as you can see here:
>=20
> http://patchwork.ozlabs.org/patch/39810/
>=20
> However, your intentions are pretty clear. Could you look at the
patch
> below
> and see if it was what you intended? If so, I'll include it in my
> 'next'
> branch today.
>=20
> josh
>=20
> ---
>=20
> diff --git a/arch/powerpc/boot/dts/yosemite.dts
> b/arch/powerpc/boot/dts/yosemite.dts
> index 1fa3cb4..6492324 100644
> --- a/arch/powerpc/boot/dts/yosemite.dts
> +++ b/arch/powerpc/boot/dts/yosemite.dts
> @@ -282,20 +282,10 @@
> /* Inbound 2GB range starting at 0 */
> dma-ranges =3D <0x42000000 0x0 0x0 0x0 0x0 0x0
> 0x80000000>;
>=20
> - /* Bamboo has all 4 IRQ pins tied together per
slot
> */
> interrupt-map-mask =3D <0xf800 0x0 0x0 0x0>;
> interrupt-map =3D <
> - /* IDSEL 1 */
> - 0x800 0x0 0x0 0x0 &UIC0 0x1c 0x8
> -
> - /* IDSEL 2 */
> - 0x1000 0x0 0x0 0x0 &UIC0 0x1b 0x8
> -
> - /* IDSEL 3 */
> - 0x1800 0x0 0x0 0x0 &UIC0 0x1a 0x8
> -
> - /* IDSEL 4 */
> - 0x2000 0x0 0x0 0x0 &UIC0 0x19 0x8
> + /* IDSEL 12 */
> + 0x6000 0x0 0x0 0x0 &UIC0 0x19 0x8
> >;
> };
> };
^ permalink raw reply
* TQM5200 + SM501 FB
From: Rolf Offermanns @ 2009-12-04 14:23 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
does anyone has a working SM501 framebuffer on the STK5200 board? The
board itself works fine on the 2.6.32 kernel.
I got a patch from TQ which used to work around 2.6.24 but it seems with
the unification of the "simple mpc5200" boards the sm501 support got lost.
I toyed around with the patch a bit and I got the driver to probe and
initialize the chip, but I don't get an output on the crt port and an
open() on /dev/fb0 or /dev/fb1 fails with "no device".
Any hints are welcome.
Thanks,
Rolf.
^ permalink raw reply
* Please pull 'next' branch of 4xx tree
From: Josh Boyer @ 2009-12-04 14:38 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi Ben,
A couple of DTS fixups for you. Thanks.
josh
The following changes since commit 5a7b4193e564d1611ecf1cd859aed60d5612d78f:
Benjamin Herrenschmidt (1):
Revert "powerpc/mm: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT"
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next
Curtis Wald (1):
powerpc/44x: Fix PCI node in Yosemite DTS
pbathija@amcc.com (1):
powerpc/44x: Fix DMA ranges in DTS file for Katmai board.
arch/powerpc/boot/dts/katmai.dts | 22 +++++++++++-----------
arch/powerpc/boot/dts/yosemite.dts | 14 ++------------
2 files changed, 13 insertions(+), 23 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH v2 1/6] powerpc: wii: device tree
From: Segher Boessenkool @ 2009-12-04 15:25 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1259880447-5008-2-git-send-email-albert_herranz@yahoo.es>
> Add a device tree source file for the Nintendo Wii video game console.
>
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Great work Albert!
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Sean MacLennan @ 2009-12-04 16:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259925535.2076.1275.camel@pasglop>
On Fri, 04 Dec 2009 22:18:55 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Ok, I'll have a look next week. In the meantime, Sean, can you give
> me a hint of what you do to trigger it ? Boot time ? specific
> workload ?
It hasn't happened that often, but I have been focusing on 2.6.31.
So far, it has always happened well after the boot, but not hours. I
haven't worked out a specific workload.
Cheers,
Sean
^ permalink raw reply
* Re: [RFC PATCH v4 2/2] powerpc: gamecube/wii: early debugging using usbgecko
From: Albert Herranz @ 2009-12-04 16:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <364F1867-9601-44FD-B140-EAA0FCC2C237@kernel.crashing.org>
Segher Boessenkool wrote:
>> +#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
>> +setup_usbgecko_bat:
>> + /* prepare a BAT for early io */
>> +#if defined(CONFIG_GAMECUBE)
>> + lis r8, 0x0c00
>> +#elif defined(CONFIG_WII)
>> + lis r8, 0x0d00
>> +#else
>> +#error Invalid platform for USB Gecko based early debugging.
>> +#endif
>
> A kernel with both CONFIG_WII and CONFIG_GAMECUBE works fine
> on either, right? If so, could you please switch the two #ifs?
> A dual-platform kernel will be used on a Wii much more likely
> than on a GC.
>
Nope, a GameCube kernel currently doesn't work on a Wii and the same the other way around.
But I can make that particular check a runtime check.
The idea would be to enclose that snippet in GAMECUBE_COMMON and check the PVR. If it is a Gekko (a fixed value) then we have a GameCube, otherwise we assume a Wii.
>> + /*
>> + * The virtual address used must match the virtual address
>> + * associated to the fixmap entry FIX_EARLY_DEBUG_BASE.
>> + */
>> + lis r11, 0xfffe /* top 128K */
>> + ori r8, r8, 0x002a /* uncached, guarded ,rw */
>> + ori r11, r11, 0x3 /* 128K */
>
> I think you should clear Vp since the BAT mapping can survive until
> after user space is started; it won't hurt to remove it either way.
> So 2 instead of 3. And put the meaning in the comment :-)
This BAT is re-setup again on MMU_init, way before starting userspace.
But I'll make it Vs=1, Vp=0 here too :)
>
> Looks fine otherwise.
>
Thanks.
>
> Segher
>
>
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH v2 1/6] powerpc: wii: device tree
From: Albert Herranz @ 2009-12-04 16:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <E340F52C-7795-4A0B-8286-C2B6028054CC@kernel.crashing.org>
Segher Boessenkool wrote:
>> Add a device tree source file for the Nintendo Wii video game console.
>>
>> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
>
> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
>
> Great work Albert!
>
Thanks!
Cheers,
Albert
^ 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