* Re: [PATCH 3/5 v2] Add the platform device support with RapidIO to MPC8641HPCN platform.
From: Arnd Bergmann @ 2007-06-28 14:47 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <46B96294322F7D458F9648B60E15112C6F31B2@zch01exm26.fsl.freescale.net>
On Thursday 28 June 2007, Zhang Wei-r63237 wrote:
> > > +static __init int mpc86xx_of_device_init(void)
> > > +{
> > > +=A0=A0=A0=A0=A0=A0=A0return of_platform_bus_probe(NULL, mpc86xx_of_i=
ds, NULL);
> > > +}
> >=20
> > This will add any devices below the "fsl,rapidio-delta" device
> > as an of_device. Is that what you actually want? I would guess that
> > you want to add the bridge itself, not the devices below it.
> >=20
> > Is the rapidio device at the root of the device tree, and if so, why
> > not under the soc bus?
> >=20
>=20
> RapidIO is rather a bus that a device although these is no other nodes de=
fined in its sector now.
>=20
That's exactly my point. The meaning of of_platform_bus_probe() is 'add all
direct children of these nodes', not 'add these nodes', although it
happens to do that in the process.
Of course, looking at the device tree, rapidio is a device, not a bus,
because it does not have a device_type and it does not have any children
of its own.
Arnd <><
^ permalink raw reply
* patches pushed to powerpc.git for-2.6.23 branch
From: Paul Mackerras @ 2007-06-28 12:55 UTC (permalink / raw)
To: linuxppc-dev
I have just pushed some more patches to the for-2.6.23 branch of
powerpc.git. There are still more to go, of course. :)
If anyone has a patch that was posted more than a couple of weeks ago
that they want to go in and that isn't in, it would be a good idea to
remind me (or Kumar for 8xxx stuff, or Arnd for cell stuff) of it.
Paul.
David Gibson (3):
[POWERPC] Make more OF-related bootwrapper functions available to non-OF platforms
[POWERPC] Abolish unused ucBoardRev variables
[POWERPC] In booting-without-of.txt, clarify that properties must precede subnodes
David Woodhouse (2):
[POWERPC] PS3: System-bus uevent
[POWERPC] PS3: System-bus modinfo attribute
Geert Uytterhoeven (7):
[POWERPC] PS3: Fix sparse warnings
[POWERPC] PS3: Simplify definition of DBG
[POWERPC] PS3: Frame buffer system-bus rework
[POWERPC] PS3: Fix more sparse warnings
[POWERPC] PS3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
[POWERPC] PS3: Storage Driver Core
[POWERPC] PS3: Storage device registration routines
Geoff Levand (23):
[POWERPC] cell: Add spu shutdown method
[POWERPC] PS3: Rename IPI symbols
[POWERPC] PS3: Use __maybe_unused
[POWERPC] PS3: Map SPU regions as non-guarded
[POWERPC] PS3: Move chip mask defs up
[POWERPC] PS3: Kexec support
[POWERPC] PS3: System-bus rework
[POWERPC] PS3: Repository probe cleanups
[POWERPC] PS3: Vuart rework
[POWERPC] PS3: System manager re-work
[POWERPC] PS3: Rework AV settings driver
[POWERPC] PS3: Device registration routines.
[POWERPC] PS3: Rename processor id symbols
[POWERPC] PS3: Use clear_bit
[POWERPC] Output params value in early_init_devtree
[POWERPC] Correct __secondary_hold comment
[POWERPC] Add signed types to bootwrapper
[POWERPC] Add u64 printf to bootwrapper
[POWERPC] Fix constantness of bootwrapper arg
[POWERPC] Make kernel_entry_t have global scope in bootwrapper
[POWERPC] PS3: Device tree source
[POWERPC] PS3: Select MEMORY_HOTPLUG
[POWERPC] PS3: Update ps3_defconfig
Guennadi Liakhovetski (1):
[POWERPC] Don't link timer.o for powerpc systems using generic rtc
Johannes Berg (1):
[POWERPC] Use mktime in timer sysdev
Mark A. Greer (5):
[POWERPC] Remove 'make zImage.dts' feature
[POWERPC] When appropriate, wrap device tree with zImage
[POWERPC] Update holly to use new dts wrapping feature
[POWERPC] Call add_preferred_console when MPSC is console
[POWERPC] Remove 'console=' from cmdline on prpmc2800
Masakazu Mokuno (1):
[POWERPC] PS3: Compare firmware version
Masashi Kimoto (1):
[POWERPC] PS3: Add support for HDMI RGB Full Range mode
Michael Ellerman (4):
[POWERPC] Split virq setup logic out into irq_setup_virq()
[POWERPC] Add irq_create_direct_mapping()
[POWERPC] Add for_each_compatible_node()
[POWERPC] Turn off debugging in arch/powerpc/kernel/pci_64.c
Michael Neuling (2):
[POWERPC] Fix stolen time for SMT without LPAR
[POWERPC] Do firmware feature fixups after features are initialised
Milton Miller (1):
[POWERPC] kexec: Send slaves to new kernel earlier
Mohan Kumar M (1):
[POWERPC] Fix interrupt distribution in ppc970
Nathan Lynch (1):
[POWERPC] Remove spinlock from struct cpu_purr_data
Olof Johansson (2):
[POWERPC] pasemi: Electra IDE/pata_platform glue
[POWERPC] Uninline and export virq_to_hw()
Sachin P. Sant (1):
[POWERPC] Fix Kexec/Kdump for power6
Tony Breeds (1):
[POWERPC] Move iSeries_tb_recal into its own late_initcall.
Documentation/powerpc/booting-without-of.txt | 8
arch/powerpc/Kconfig | 5
arch/powerpc/Makefile | 2
arch/powerpc/boot/Makefile | 50 -
arch/powerpc/boot/dts/prpmc2800.dts | 2
arch/powerpc/boot/dts/ps3.dts | 68 ++
arch/powerpc/boot/main.c | 2
arch/powerpc/boot/of.c | 30 -
arch/powerpc/boot/of.h | 6
arch/powerpc/boot/ofconsole.c | 10
arch/powerpc/boot/oflib.c | 40 +
arch/powerpc/boot/ops.h | 4
arch/powerpc/boot/serial.c | 2
arch/powerpc/boot/stdio.c | 10
arch/powerpc/boot/types.h | 4
arch/powerpc/configs/holly_defconfig | 104 +--
arch/powerpc/configs/ps3_defconfig | 131 ++--
arch/powerpc/kernel/head_64.S | 4
arch/powerpc/kernel/irq.c | 62 +-
arch/powerpc/kernel/misc_64.S | 26 -
arch/powerpc/kernel/pci_64.c | 2
arch/powerpc/kernel/prom.c | 2
arch/powerpc/kernel/setup_64.c | 12
arch/powerpc/kernel/time.c | 56 +-
arch/powerpc/platforms/cell/spu_base.c | 12
arch/powerpc/platforms/embedded6xx/Kconfig | 1
arch/powerpc/platforms/iseries/setup.c | 6
arch/powerpc/platforms/pasemi/Kconfig | 10
arch/powerpc/platforms/pasemi/Makefile | 1
arch/powerpc/platforms/pasemi/electra_ide.c | 96 +++
arch/powerpc/platforms/ps3/Kconfig | 26 -
arch/powerpc/platforms/ps3/Makefile | 1
arch/powerpc/platforms/ps3/device-init.c | 785 ++++++++++++++++++++++
arch/powerpc/platforms/ps3/htab.c | 19 -
arch/powerpc/platforms/ps3/interrupt.c | 272 ++++----
arch/powerpc/platforms/ps3/mm.c | 630 +++++++++++++++---
arch/powerpc/platforms/ps3/os-area.c | 4
arch/powerpc/platforms/ps3/platform.h | 43 +
arch/powerpc/platforms/ps3/repository.c | 586 +++++++++-------
arch/powerpc/platforms/ps3/setup.c | 105 ++-
arch/powerpc/platforms/ps3/smp.c | 18 -
arch/powerpc/platforms/ps3/spu.c | 13
arch/powerpc/platforms/ps3/system-bus.c | 562 ++++++++++++++--
arch/powerpc/platforms/ps3/time.c | 2
arch/powerpc/platforms/pseries/lpar.c | 17
arch/powerpc/platforms/pseries/plpar_wrappers.h | 15
arch/powerpc/platforms/pseries/xics.c | 53 +
arch/powerpc/sysdev/Makefile | 2
arch/powerpc/sysdev/mv64x60_dev.c | 28 +
arch/powerpc/sysdev/timer.c | 14
arch/ppc/platforms/prep_setup.c | 3
drivers/ps3/Makefile | 5
drivers/ps3/ps3av.c | 372 ++++++----
drivers/ps3/ps3av_cmd.c | 51 +
drivers/ps3/ps3stor_lib.c | 302 +++++++++
drivers/ps3/sys-manager-core.c | 68 ++
drivers/ps3/sys-manager.c | 290 +++++---
drivers/ps3/vuart.c | 817 ++++++++++++++---------
drivers/ps3/vuart.h | 71 +-
drivers/video/Kconfig | 4
drivers/video/ps3fb.c | 290 ++++----
include/asm-powerpc/irq.h | 14
include/asm-powerpc/lv1call.h | 3
include/asm-powerpc/mmu-hash64.h | 3
include/asm-powerpc/processor.h | 8
include/asm-powerpc/prom.h | 3
include/asm-powerpc/ps3.h | 182 +++--
include/asm-powerpc/ps3av.h | 48 +
include/asm-powerpc/ps3fb.h | 12
include/asm-powerpc/ps3stor.h | 71 ++
include/asm-powerpc/time.h | 4
71 files changed, 4635 insertions(+), 1949 deletions(-)
create mode 100644 arch/powerpc/boot/dts/ps3.dts
create mode 100644 arch/powerpc/platforms/pasemi/electra_ide.c
create mode 100644 arch/powerpc/platforms/ps3/device-init.c
create mode 100644 drivers/ps3/ps3stor_lib.c
create mode 100644 drivers/ps3/sys-manager-core.c
create mode 100644 include/asm-powerpc/ps3stor.h
^ permalink raw reply
* [patch] cell: pmi remove support for mutiple devices.
From: Christian Krafft @ 2007-06-28 12:20 UTC (permalink / raw)
To: Christian Krafft; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <20070628131438.274a796e@localhost>
[-- Attachment #1: Type: text/plain, Size: 8438 bytes --]
From: Christian Krafft <krafft@de.ibm.com>
The pmi driver got simplified by removing support for multiple devices.
As there is no more than one pmi device per maschine, there is no need to
specify the device for listening and sending messages.
This way the caller (cbe_cpufreq) doesn't need to scan the device tree.
When registering the handler on a board without a pmi
interface, pmi.c will just return -ENODEV.
The patch that fixed the breakage of cell_defconfig has been
broken out of the earlier version of this patch. So this is
the version that applies cleanly on top of it.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux-2.6.22-rc5/arch/powerpc/platforms/cell/cbe_cpufreq.c
===================================================================
--- linux-2.6.22-rc5.orig/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ linux-2.6.22-rc5/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -68,11 +68,12 @@ static u64 MIC_Slow_Next_Timer_table[] =
};
static unsigned int pmi_frequency_limit = 0;
+
/*
* hardware specific functions
*/
-static struct of_device *pmi_dev;
+static bool cbe_cpufreq_has_pmi;
#ifdef CONFIG_PPC_PMI
static int set_pmode_pmi(int cpu, unsigned int pmode)
@@ -91,7 +92,7 @@ static int set_pmode_pmi(int cpu, unsign
time = (u64) get_cycles();
#endif
- pmi_send_message(pmi_dev, pmi_msg);
+ pmi_send_message(pmi_msg);
ret = pmi_msg.data2;
pr_debug("PMI returned slow mode %d\n", ret);
@@ -157,16 +158,16 @@ static int set_pmode_reg(int cpu, unsign
return 0;
}
-static int set_pmode(int cpu, unsigned int slow_mode) {
+static int set_pmode(int cpu, unsigned int slow_mode)
+{
#ifdef CONFIG_PPC_PMI
- if (pmi_dev)
+ if (cbe_cpufreq_has_pmi)
return set_pmode_pmi(cpu, slow_mode);
- else
#endif
- return set_pmode_reg(cpu, slow_mode);
+ return set_pmode_reg(cpu, slow_mode);
}
-static void cbe_cpufreq_handle_pmi(struct of_device *dev, pmi_message_t pmi_msg)
+static void cbe_cpufreq_handle_pmi(pmi_message_t pmi_msg)
{
u8 cpu;
u8 cbe_pmode_new;
@@ -253,7 +254,7 @@ static int cbe_cpufreq_cpu_init(struct c
cpufreq_frequency_table_get_attr(cbe_freqs, policy->cpu);
- if (pmi_dev) {
+ if (cbe_cpufreq_has_pmi) {
/* frequency might get limited later, initialize limit with max_freq */
pmi_frequency_limit = max_freq;
cpufreq_register_notifier(&pmi_notifier_block, CPUFREQ_POLICY_NOTIFIER);
@@ -265,7 +266,7 @@ static int cbe_cpufreq_cpu_init(struct c
static int cbe_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
- if (pmi_dev)
+ if (cbe_cpufreq_has_pmi)
cpufreq_unregister_notifier(&pmi_notifier_block, CPUFREQ_POLICY_NOTIFIER);
cpufreq_frequency_table_put_attr(policy->cpu);
@@ -326,29 +327,20 @@ static struct cpufreq_driver cbe_cpufreq
static int __init cbe_cpufreq_init(void)
{
-#ifdef CONFIG_PPC_PMI
- struct device_node *np;
-#endif
if (!machine_is(cell))
return -ENODEV;
-#ifdef CONFIG_PPC_PMI
- np = of_find_node_by_type(NULL, "ibm,pmi");
- pmi_dev = of_find_device_by_node(np);
+ cbe_cpufreq_has_pmi = pmi_register_handler(&cbe_pmi_handler) == 0;
- if (pmi_dev)
- pmi_register_handler(pmi_dev, &cbe_pmi_handler);
-#endif
return cpufreq_register_driver(&cbe_cpufreq_driver);
}
static void __exit cbe_cpufreq_exit(void)
{
-#ifdef CONFIG_PPC_PMI
- if (pmi_dev)
- pmi_unregister_handler(pmi_dev, &cbe_pmi_handler);
-#endif
cpufreq_unregister_driver(&cbe_cpufreq_driver);
+
+ if (cbe_cpufreq_has_pmi)
+ pmi_unregister_handler(&cbe_pmi_handler);
}
module_init(cbe_cpufreq_init);
Index: linux-2.6.22-rc5/arch/powerpc/sysdev/pmi.c
===================================================================
--- linux-2.6.22-rc5.orig/arch/powerpc/sysdev/pmi.c
+++ linux-2.6.22-rc5/arch/powerpc/sysdev/pmi.c
@@ -48,15 +48,13 @@ struct pmi_data {
struct work_struct work;
};
+static struct pmi_data *data;
static int pmi_irq_handler(int irq, void *dev_id)
{
- struct pmi_data *data;
u8 type;
int rc;
- data = dev_id;
-
spin_lock(&data->pmi_spinlock);
type = ioread8(data->pmi_reg + PMI_READ_TYPE);
@@ -111,16 +109,13 @@ MODULE_DEVICE_TABLE(of, pmi_match);
static void pmi_notify_handlers(struct work_struct *work)
{
- struct pmi_data *data;
struct pmi_handler *handler;
- data = container_of(work, struct pmi_data, work);
-
spin_lock(&data->handler_spinlock);
list_for_each_entry(handler, &data->handler, node) {
pr_debug(KERN_INFO "pmi: notifying handler %p\n", handler);
if (handler->type == data->msg.type)
- handler->handle_pmi_message(data->dev, data->msg);
+ handler->handle_pmi_message(data->msg);
}
spin_unlock(&data->handler_spinlock);
}
@@ -129,9 +124,14 @@ static int pmi_of_probe(struct of_device
const struct of_device_id *match)
{
struct device_node *np = dev->node;
- struct pmi_data *data;
int rc;
+ if (data) {
+ printk(KERN_ERR "pmi: driver has already been initialized.\n");
+ rc = -EBUSY;
+ goto out;
+ }
+
data = kzalloc(sizeof(struct pmi_data), GFP_KERNEL);
if (!data) {
printk(KERN_ERR "pmi: could not allocate memory.\n");
@@ -154,7 +154,6 @@ static int pmi_of_probe(struct of_device
INIT_WORK(&data->work, pmi_notify_handlers);
- dev->dev.driver_data = data;
data->dev = dev;
data->irq = irq_of_parse_and_map(np, 0);
@@ -164,7 +163,7 @@ static int pmi_of_probe(struct of_device
goto error_cleanup_iomap;
}
- rc = request_irq(data->irq, pmi_irq_handler, 0, "pmi", data);
+ rc = request_irq(data->irq, pmi_irq_handler, 0, "pmi", NULL);
if (rc) {
printk(KERN_ERR "pmi: can't request IRQ %d: returned %d\n",
data->irq, rc);
@@ -187,12 +186,9 @@ out:
static int pmi_of_remove(struct of_device *dev)
{
- struct pmi_data *data;
struct pmi_handler *handler, *tmp;
- data = dev->dev.driver_data;
-
- free_irq(data->irq, data);
+ free_irq(data->irq, NULL);
iounmap(data->pmi_reg);
spin_lock(&data->handler_spinlock);
@@ -202,7 +198,8 @@ static int pmi_of_remove(struct of_devic
spin_unlock(&data->handler_spinlock);
- kfree(dev->dev.driver_data);
+ kfree(data);
+ data = NULL;
return 0;
}
@@ -226,13 +223,13 @@ static void __exit pmi_module_exit(void)
}
module_exit(pmi_module_exit);
-void pmi_send_message(struct of_device *device, pmi_message_t msg)
+int pmi_send_message(pmi_message_t msg)
{
- struct pmi_data *data;
unsigned long flags;
DECLARE_COMPLETION_ONSTACK(completion);
- data = device->dev.driver_data;
+ if (!data)
+ return -ENODEV;
mutex_lock(&data->msg_mutex);
@@ -256,30 +253,26 @@ void pmi_send_message(struct of_device *
data->completion = NULL;
mutex_unlock(&data->msg_mutex);
+
+ return 0;
}
EXPORT_SYMBOL_GPL(pmi_send_message);
-void pmi_register_handler(struct of_device *device,
- struct pmi_handler *handler)
+int pmi_register_handler(struct pmi_handler *handler)
{
- struct pmi_data *data;
- data = device->dev.driver_data;
-
if (!data)
- return;
+ return -ENODEV;
spin_lock(&data->handler_spinlock);
list_add_tail(&handler->node, &data->handler);
spin_unlock(&data->handler_spinlock);
+
+ return 0;
}
EXPORT_SYMBOL_GPL(pmi_register_handler);
-void pmi_unregister_handler(struct of_device *device,
- struct pmi_handler *handler)
+void pmi_unregister_handler(struct pmi_handler *handler)
{
- struct pmi_data *data;
- data = device->dev.driver_data;
-
if (!data)
return;
Index: linux-2.6.22-rc5/include/asm-powerpc/pmi.h
===================================================================
--- linux-2.6.22-rc5.orig/include/asm-powerpc/pmi.h
+++ linux-2.6.22-rc5/include/asm-powerpc/pmi.h
@@ -55,13 +55,13 @@ typedef struct {
struct pmi_handler {
struct list_head node;
u8 type;
- void (*handle_pmi_message) (struct of_device *, pmi_message_t);
+ void (*handle_pmi_message) (pmi_message_t);
};
-void pmi_register_handler(struct of_device *, struct pmi_handler *);
-void pmi_unregister_handler(struct of_device *, struct pmi_handler *);
+int pmi_register_handler(struct pmi_handler *);
+void pmi_unregister_handler(struct pmi_handler *);
-void pmi_send_message(struct of_device *, pmi_message_t);
+int pmi_send_message(pmi_message_t);
#endif /* __KERNEL__ */
#endif /* _POWERPC_PMI_H */
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* uncompressing zImage
From: sarpa @ 2007-06-28 12:01 UTC (permalink / raw)
To: linuxppc-embedded
I am unable to complete gunzip called from arch/ppc/boot/simple/misc.c. The
gunzip code is in arch/ppc/boot/common/misc-common.c & it is trying to do
"zalloc()". Here i am getting avail_ram greater than end_avail. So its stops
executing further. I have my RAM from 0x00000000 to 0x02000000. In this I
had copied zImage at 0x00800000. Now i am unable to continue from misc.c
file's decompress algorithm. Please provide me some tips or suggestions.
Thanks & Regards,
Sarpa
--
View this message in context: http://www.nabble.com/uncompressing-zImage-tf3994018.html#a11341785
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: PMI breakage in cell_defconfig
From: Christian Krafft @ 2007-06-28 11:14 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org; +Cc: Christian Krafft, Paul Mackerras
In-Reply-To: <20070628115049.393e8a6d@localhost>
[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]
Subject: cbe_cpufreq: fix build error
From: Christian Krafft <krafft@de.ibm.com>
The cbe_cpufreq driver should build without PMI
interface. The code that deals with PMI has been
#ifdef'ed out. This is not the optimal solution for now.
A later version of the cpufreq driver has been cleaned out
from all PMI code. Until that patch makes it into the kernel
use this patch to fix build issues when building cpufreq driver without PMI.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux/arch/powerpc/platforms/cell/cbe_cpufreq.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ linux/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -74,6 +74,7 @@ static unsigned int pmi_frequency_limit
static struct of_device *pmi_dev;
+#ifdef CONFIG_PPC_PMI
static int set_pmode_pmi(int cpu, unsigned int pmode)
{
int ret;
@@ -102,7 +103,7 @@ static int set_pmode_pmi(int cpu, unsign
#endif
return ret;
}
-
+#endif
static int get_pmode(int cpu)
{
@@ -157,9 +158,11 @@ static int set_pmode_reg(int cpu, unsign
}
static int set_pmode(int cpu, unsigned int slow_mode) {
+#ifdef CONFIG_PPC_PMI
if (pmi_dev)
return set_pmode_pmi(cpu, slow_mode);
else
+#endif
return set_pmode_reg(cpu, slow_mode);
}
@@ -323,26 +326,28 @@ static struct cpufreq_driver cbe_cpufreq
static int __init cbe_cpufreq_init(void)
{
+#ifdef CONFIG_PPC_PMI
struct device_node *np;
-
+#endif
if (!machine_is(cell))
return -ENODEV;
-
+#ifdef CONFIG_PPC_PMI
np = of_find_node_by_type(NULL, "ibm,pmi");
pmi_dev = of_find_device_by_node(np);
if (pmi_dev)
pmi_register_handler(pmi_dev, &cbe_pmi_handler);
-
+#endif
return cpufreq_register_driver(&cbe_cpufreq_driver);
}
static void __exit cbe_cpufreq_exit(void)
{
+#ifdef CONFIG_PPC_PMI
if (pmi_dev)
pmi_unregister_handler(pmi_dev, &cbe_pmi_handler);
-
+#endif
cpufreq_unregister_driver(&cbe_cpufreq_driver);
}
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Benjamin Herrenschmidt @ 2007-06-28 11:09 UTC (permalink / raw)
To: Vladislav Buzov; +Cc: linuxppc-dev list
In-Reply-To: <468391B3.3080100@ru.mvista.com>
On Thu, 2007-06-28 at 14:47 +0400, Vladislav Buzov wrote:
>
> I've looked through cache.S and see it contains a dcbf loop over 4Mb
> along with L2, L3 HW cache flushing. The comments says 'Due to a bug
> with the HW flush on some CPU revs, we occasionally experience data
> corruption...'. Could you please clarify which CPU revisions have this
> bug and whether it is the same bug described in errata and requiring a
> complete cache locking before flushing? Do we still need to use the dcbf
> loop in _set_L2CR() for MPC7450 processors?
Can't remember ... that code is pretty old now.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Vladislav Buzov @ 2007-06-28 10:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1183022026.5521.269.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
>>>The erratum says nothing about any HW bugs with L3 cache flush. I just
>>>mentioned that the L3 cache flush operation described in MPC7450
>>>Reference manual is similar to the L2 using the L3 cache hardware
>>>flushing mechanism. For instance, it requires a complete L3 locking
>>>before flushing.
>>>
>>>
>>Then I think we should use that mechanism in the Linux kernel.
>>Anything else is waiting for bugs to bite.
>>
>>
>
>I just figured out ... we actually already have all of that cache flush
>code :-) I wrote most of it in fact. It's just that for some (bad)
>reasons, it's somewhat hidden in arch/powerpc/platforms/powermac/cache.S
>
>So I think best would be to take it from there and make it more
>generic ...
>
>
I'm just wondering who is supposed to do that. I can copy the code from
cache.S to l2cr_6xx.S and test it on 7448 since I have only this
processor on hand. So, I can't test the L3.
I've looked through cache.S and see it contains a dcbf loop over 4Mb
along with L2, L3 HW cache flushing. The comments says 'Due to a bug
with the HW flush on some CPU revs, we occasionally experience data
corruption...'. Could you please clarify which CPU revisions have this
bug and whether it is the same bug described in errata and requiring a
complete cache locking before flushing? Do we still need to use the dcbf
loop in _set_L2CR() for MPC7450 processors?
Thanks,
Vlad.
>Cheers,
>Ben.
>
>
>
>
^ permalink raw reply
* PCI IO range limitation
From: Marian Balakowicz @ 2007-06-28 10:20 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Trying to change PCI IO window base for 52xx target I found that
we are pretty much limited to a "0" offset only.
pci_process_bridge_OF_ranges() will not process any IO range that has
addresses set to anything else.
956: case 1: /* I/O space */
957: if (ranges[2] != 0)
958: break;
When this range[2] checking is removed from
pci_process_bridge_OF_ranges() kernel boots ok with the non-zero PCI IO
base, but the PCI device I am using (e100) will not work.
I guess that with the above dropping of non-zero based PCI IO ranges
this is not supposed to be working. But does anyone know why?
Thanks,
Marian
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Gabriel Paubert @ 2007-06-28 10:00 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <b1bc50e84cd3f8009eca2b470bea026f@kernel.crashing.org>
On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > Here is an implementation to allow PReP systems to boot under the
> > arch/powerpc codebase, one of the few remaining platforms supported in
> > arch/ppc but not so far in arch/powerpc.
>
> > Too big for the list, the patch is at:
> > http://ozlabs.org/~dgibson/home/prep-support
>
> Too lazy to split the patch into bite-size chunks, you mean ;-)
>
> Anyway, here goes the DTS bits:
>
> +/*
> + * PReP skeleton device tree
> + *
> + * Paul Mackerras <paulus@samba.org>
> + */
> +
> +/ {
> + device_type = "prep";
> + model = "IBM,PReP";
>
> Not specific enough, leave it out or fill it in in the bootwrapper.
Motorola also provided PreP boards (MTX and MVME at least).
>
> + compatible = "prep";
>
> Maybe fill this in, too.
>
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
>
> Do all (supported) PReP boards have one CPU only?
Not sure, but I don't have any. I believe that there were
dual processors MTX boards, and dual 604 MVME boards were
offered (but probably not very popular).
>
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <0>; // filled in by bootwrapper
> + bus-frequency = <0>; // filled in by bootwrapper
> + timebase-frequency = <0>; // filled in by bootwrapper
> + i-cache-line-size = <0>; // filled in by bootwrapper
> + d-cache-line-size = <0>; // filled in by bootwrapper
> + d-cache-size = <0>; // filled in by bootwrapper
> + i-cache-size = <0>; // filled in by bootwrapper
> + external-control;
>
> Really?
Well, is anybody actually using eciwx/ecowx?
>
> + graphics;
> + performance-monitor;
> +
> + l2-cache {
> + device_type = "cache";
> + i-cache-size = <00100000>;
> + d-cache-size = <00100000>;
> + i-cache-sets = <00008000>;
> + d-cache-sets = <00008000>;
> + i-cache-line-size = <00000020>;
> + d-cache-line-size = <00000020>;
>
> Drop the leading zeroes, they make my head spin :-)
It's also wrong, my boards have 256kB of L2 cache.
>
> + cache-unified;
> + };
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + // dummy range here, zImage wrapper will fill in the actual
> + // amount of memory from the residual data
> + reg = <00000000 00000000>;
> + };
> +
> + pci@80000000 {
> + device_type = "pci";
> + compatible = "prep";
>
> Is that specific enough?
On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
space is smaller and at a higher address. Actually for
MVME2400/2600/2700, I wrote a bootloader that reprograms the bridge
in a CHRP like mode since nobody needs almost 1GB of PCI I/O space
but having 1.5GB of PCI memory space is very useful.
>
> + clock-frequency = <01fca055>;
> + reg = <80000000 7effffff>;
> + 8259-interrupt-acknowledge = <bffffff0>;
Not always. It is at feff0030 on Raven/Falcon/Hawk boards (given
by a system address assigned to the 8259 PIC in the residual data).
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges=<01000000 00000000 00000000 80000000 00000000 00800000
> + 01000000 00000000 00800000 81000000 00000000 3e800000
> + 02000000 00000000 00000000 c0000000 00000000 01000000
> + 02000000 00000000 01000000 c1000000 00000000 3e000000>;
> + interrupt-map-mask = <f800 0 0 7>;
> + interrupt-map = <6000 0 0 1 &MPIC 6 0
> + 8000 0 0 1 &MPIC 7 0
> + 9000 0 0 1 &MPIC 2 0
> + b000 0 0 1 &MPIC 1 0>;
>
> I can't believe this "ranges" and interrupt mapping will
> work on all PReP systems...
Neither do I.
> + isa {
> + device_type = "isa";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + ranges = <00000001 00000000
> + 01005800 00000000 00000000 00010000
> + 00000000 00000000
> + 02005800 00000000 00000000 01000000>;
> +
> + parallel {
> + device_type = "parallel";
> + compatible = "ecp", "pnpPNP,400";
>
> "pnpPNP,401", "pnpPNP,400"
>
> + reg = <00000001 000003bc 00000008
> + 00000001 000007bc 00000006>;
> + interrupts = <00000007 00000003>;
> + interrupt-parent = <&PIC8259>;
> + };
> +
> + serial@3f8 {
> + device_type = "serial";
> + compatible = "pnpPNP,501";
>
> "pnpPNP,501", "pnpPNP,500" I'd say. Many/some device
> tree users will only care it is _some_ 8250 family thing.
>
> + clock-frequency = <001c2000>;
> + reg = <00000001 000003f8 00000008>;
> + interrupts = <00000004 00000003>;
> + interrupt-parent = <&PIC8259>;
> + };
> + serial@2f8 {
> + device_type = "serial";
> + compatible = "pnpPNP,501";
> + clock-frequency = <001c2000>;
> + reg = <00000001 000002f8 00000008>;
> + interrupts = <00000003 00000003>;
> + interrupt-parent = <&PIC8259>;
> + };
Some of my boards have only one serial port (and also only 1 in the residual data).
> + PIC8259: interrupt-controller {
> + device_type = "i8259";
>
> device_type = "interrupt-controller".
>
> + compatible = "prep,iic";
> + reg = < 00000001 00000020 00000002
> + 00000001 000000a0 00000002
> + 00000001 000004d0 00000002>;
> + interrupts = <00000000 00000003
> + 00000002 00000003>;
> + interrupt-parent = <&MPIC>;
> + };
> + };
> +
> + MPIC: interrupt-controller@d {
> + device_type = "open-pic";
>
> device_type = "interrupt-controller".
>
> + compatible = "mpic";
> + reg = < 00006800 00000000 00000000 00000000 00000000
> + 02006810 00000000 00000000 00000000 00040000>;
> + assigned-addresses = <
> + 82006810 00000000 3afc0000 00000000 00040000>;
> + };
> + };
> +
> + chosen {
> + linux,stdout-path = "/pci/isa/serial@3f8";
> + };
> +};
>
> What is the plan here -- have the bootwrapper build the
> device tree / fill in the details from the residual data?
I think so. I might have some time to try a more recent kernel
on MVME2400/2600 boards next week.
Regards,
Gabriel
^ permalink raw reply
* Re: powerpc stacktrace and lockdep support
From: Johannes Berg @ 2007-06-27 19:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <1182898073.4769.6.camel@johannes.berg>
Here's a somewhat cleaned-up version that also works with preempt, still
64-bit only, still breaks 32-bit compile (I think, untested).
Works fine on my quad G5 and I've actually made a patch to lockdep to
support flagging my workqueue deadlock, that works too. And the XFS
report I had previously was also "correct" in the sense that it occurs
on all machines and has been patched (although there never was a
possible deadlock.)
---
arch/powerpc/Kconfig | 8 +++++
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/entry_64.S | 24 +++++++++++++++++
arch/powerpc/kernel/head_64.S | 54 ++++++++++++++++++++++++++++++++--------
arch/powerpc/kernel/irq.c | 2 -
arch/powerpc/kernel/irqtrace.S | 47 ++++++++++++++++++++++++++++++++++
arch/powerpc/kernel/ppc_ksyms.c | 2 -
arch/powerpc/kernel/setup_64.c | 6 ++++
include/asm-powerpc/hw_irq.h | 34 +++++++++++++------------
include/asm-powerpc/irqflags.h | 13 ---------
include/asm-powerpc/rwsem.h | 34 +++++++++++++++++++------
include/asm-powerpc/spinlock.h | 1
12 files changed, 176 insertions(+), 50 deletions(-)
--- linux-2.6-git.orig/arch/powerpc/Kconfig 2007-06-27 17:37:39.884965668 +0200
+++ linux-2.6-git/arch/powerpc/Kconfig 2007-06-27 17:38:07.929965668 +0200
@@ -38,6 +38,14 @@ config STACKTRACE_SUPPORT
bool
default y
+config TRACE_IRQFLAGS_SUPPORT
+ bool
+ default y
+
+config LOCKDEP_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
--- linux-2.6-git.orig/arch/powerpc/kernel/irq.c 2007-06-27 17:37:39.907965668 +0200
+++ linux-2.6-git/arch/powerpc/kernel/irq.c 2007-06-27 17:38:07.953965668 +0200
@@ -114,7 +114,7 @@ static inline void set_soft_enabled(unsi
: : "r" (enable), "i" (offsetof(struct paca_struct, soft_enabled)));
}
-void local_irq_restore(unsigned long en)
+void raw_local_irq_restore(unsigned long en)
{
/*
* get_paca()->soft_enabled = en;
--- linux-2.6-git.orig/arch/powerpc/kernel/ppc_ksyms.c 2007-06-27 17:37:39.930965668 +0200
+++ linux-2.6-git/arch/powerpc/kernel/ppc_ksyms.c 2007-06-27 17:38:07.954965668 +0200
@@ -50,7 +50,7 @@
#endif
#ifdef CONFIG_PPC64
-EXPORT_SYMBOL(local_irq_restore);
+EXPORT_SYMBOL(raw_local_irq_restore);
#endif
#ifdef CONFIG_PPC32
--- linux-2.6-git.orig/include/asm-powerpc/hw_irq.h 2007-06-27 17:37:40.209965668 +0200
+++ linux-2.6-git/include/asm-powerpc/hw_irq.h 2007-06-27 17:38:08.025965668 +0200
@@ -27,7 +27,7 @@ static inline unsigned long local_get_fl
return flags;
}
-static inline unsigned long local_irq_disable(void)
+static inline unsigned long raw_local_irq_disable(void)
{
unsigned long flags, zero;
@@ -39,14 +39,15 @@ static inline unsigned long local_irq_di
return flags;
}
-extern void local_irq_restore(unsigned long);
+extern void raw_local_irq_restore(unsigned long);
extern void iseries_handle_interrupts(void);
-#define local_irq_enable() local_irq_restore(1)
-#define local_save_flags(flags) ((flags) = local_get_flags())
-#define local_irq_save(flags) ((flags) = local_irq_disable())
+#define raw_local_irq_enable() raw_local_irq_restore(1)
+#define raw_local_save_flags(flags) ((flags) = local_get_flags())
+#define raw_local_irq_save(flags) ((flags) = raw_local_irq_disable())
-#define irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled_flags(flags) ((flags) == 0)
#define __hard_irq_enable() __mtmsrd(mfmsr() | MSR_EE, 1)
#define __hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
@@ -62,13 +63,13 @@ extern void iseries_handle_interrupts(vo
#if defined(CONFIG_BOOKE)
#define SET_MSR_EE(x) mtmsr(x)
-#define local_irq_restore(flags) __asm__ __volatile__("wrtee %0" : : "r" (flags) : "memory")
+#define raw_local_irq_restore(flags) __asm__ __volatile__("wrtee %0" : : "r" (flags) : "memory")
#else
#define SET_MSR_EE(x) mtmsr(x)
-#define local_irq_restore(flags) mtmsr(flags)
+#define raw_local_irq_restore(flags) mtmsr(flags)
#endif
-static inline void local_irq_disable(void)
+static inline void raw_local_irq_disable(void)
{
#ifdef CONFIG_BOOKE
__asm__ __volatile__("wrteei 0": : :"memory");
@@ -80,7 +81,7 @@ static inline void local_irq_disable(voi
#endif
}
-static inline void local_irq_enable(void)
+static inline void raw_local_irq_enable(void)
{
#ifdef CONFIG_BOOKE
__asm__ __volatile__("wrteei 1": : :"memory");
@@ -92,7 +93,7 @@ static inline void local_irq_enable(void
#endif
}
-static inline void local_irq_save_ptr(unsigned long *flags)
+static inline void raw_local_irq_save_ptr(unsigned long *flags)
{
unsigned long msr;
msr = mfmsr();
@@ -105,12 +106,13 @@ static inline void local_irq_save_ptr(un
__asm__ __volatile__("": : :"memory");
}
-#define local_save_flags(flags) ((flags) = mfmsr())
-#define local_irq_save(flags) local_irq_save_ptr(&flags)
-#define irqs_disabled() ((mfmsr() & MSR_EE) == 0)
+#define raw_local_save_flags(flags) ((flags) = mfmsr())
+#define raw_local_irq_save(flags) raw_local_irq_save_ptr(&flags)
+#define raw_irqs_disabled() ((mfmsr() & MSR_EE) == 0)
+#define raw_irqs_disabled_flags(flags) (((flags) & MSR_EE) == 0)
-#define hard_irq_enable() local_irq_enable()
-#define hard_irq_disable() local_irq_disable()
+#define hard_irq_enable() raw_local_irq_enable()
+#define hard_irq_disable() raw_local_irq_disable()
#endif /* CONFIG_PPC64 */
--- linux-2.6-git.orig/include/asm-powerpc/irqflags.h 2007-06-27 17:37:40.234965668 +0200
+++ linux-2.6-git/include/asm-powerpc/irqflags.h 2007-06-27 17:39:18.499965668 +0200
@@ -15,17 +15,4 @@
*/
#include <asm-powerpc/hw_irq.h>
-/*
- * Do the CPU's IRQ-state tracing from assembly code. We call a
- * C function, so save all the C-clobbered registers:
- */
-#ifdef CONFIG_TRACE_IRQFLAGS
-
-#error No support on PowerPC yet for CONFIG_TRACE_IRQFLAGS
-
-#else
-# define TRACE_IRQS_ON
-# define TRACE_IRQS_OFF
-#endif
-
#endif
--- linux-2.6-git.orig/include/asm-powerpc/rwsem.h 2007-06-27 17:37:40.256965668 +0200
+++ linux-2.6-git/include/asm-powerpc/rwsem.h 2007-06-27 17:38:08.051965668 +0200
@@ -28,11 +28,21 @@ struct rw_semaphore {
#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
spinlock_t wait_lock;
struct list_head wait_list;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
};
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+# define __RWSEM_DEP_MAP_INIT(lockname) , .dep_map = { .name = #lockname }
+#else
+# define __RWSEM_DEP_MAP_INIT(lockname)
+#endif
+
#define __RWSEM_INITIALIZER(name) \
{ RWSEM_UNLOCKED_VALUE, SPIN_LOCK_UNLOCKED, \
- LIST_HEAD_INIT((name).wait_list) }
+ LIST_HEAD_INIT((name).wait_list) \
+ __RWSEM_DEP_MAP_INIT(name) }
#define DECLARE_RWSEM(name) \
struct rw_semaphore name = __RWSEM_INITIALIZER(name)
@@ -42,12 +52,15 @@ extern struct rw_semaphore *rwsem_down_w
extern struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem);
extern struct rw_semaphore *rwsem_downgrade_wake(struct rw_semaphore *sem);
-static inline void init_rwsem(struct rw_semaphore *sem)
-{
- sem->count = RWSEM_UNLOCKED_VALUE;
- spin_lock_init(&sem->wait_lock);
- INIT_LIST_HEAD(&sem->wait_list);
-}
+extern void __init_rwsem(struct rw_semaphore *sem, const char *name,
+ struct lock_class_key *key);
+
+#define init_rwsem(sem) \
+ do { \
+ static struct lock_class_key __key; \
+ \
+ __init_rwsem((sem), #sem, &__key); \
+ } while (0)
/*
* lock for reading
@@ -74,7 +87,7 @@ static inline int __down_read_trylock(st
/*
* lock for writing
*/
-static inline void __down_write(struct rw_semaphore *sem)
+static inline void __down_write_nested(struct rw_semaphore *sem, int subclass)
{
int tmp;
@@ -84,6 +97,11 @@ static inline void __down_write(struct r
rwsem_down_write_failed(sem);
}
+static inline void __down_write(struct rw_semaphore *sem)
+{
+ __down_write_nested(sem, 0);
+}
+
static inline int __down_write_trylock(struct rw_semaphore *sem)
{
int tmp;
--- linux-2.6-git.orig/include/asm-powerpc/spinlock.h 2007-06-27 17:37:40.293965668 +0200
+++ linux-2.6-git/include/asm-powerpc/spinlock.h 2007-06-27 17:38:08.056965668 +0200
@@ -19,6 +19,7 @@
*
* (the type definitions are in asm/spinlock_types.h)
*/
+#include <linux/irqflags.h>
#ifdef CONFIG_PPC64
#include <asm/paca.h>
#include <asm/hvcall.h>
--- linux-2.6-git.orig/arch/powerpc/kernel/head_64.S 2007-06-27 17:37:39.953965668 +0200
+++ linux-2.6-git/arch/powerpc/kernel/head_64.S 2007-06-27 17:52:08.742965668 +0200
@@ -394,6 +394,12 @@ label##_iSeries: \
EXCEPTION_PROLOG_ISERIES_2; \
b label##_common; \
+#ifdef CONFIG_TRACE_IRQFLAGS
+#define TRACE_DISABLE_INTS bl .powerpc_trace_hardirqs_off
+#else
+#define TRACE_DISABLE_INTS
+#endif
+
#ifdef CONFIG_PPC_ISERIES
#define DISABLE_INTS \
li r11,0; \
@@ -405,14 +411,15 @@ BEGIN_FW_FTR_SECTION; \
mfmsr r10; \
ori r10,r10,MSR_EE; \
mtmsrd r10,1; \
-END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
+END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES); \
+ TRACE_DISABLE_INTS
#else
#define DISABLE_INTS \
li r11,0; \
stb r11,PACASOFTIRQEN(r13); \
- stb r11,PACAHARDIRQEN(r13)
-
+ stb r11,PACAHARDIRQEN(r13); \
+ TRACE_DISABLE_INTS
#endif /* CONFIG_PPC_ISERIES */
#define ENABLE_INTS \
@@ -965,24 +972,38 @@ bad_stack:
*/
fast_exc_return_irq: /* restores irq state too */
ld r3,SOFTE(r1)
- ld r12,_MSR(r1)
+#ifdef CONFIG_TRACE_IRQFLAGS
+ cmpdi r3,0
+ beq 1f
+ bl .trace_hardirqs_on
+ ld r3,SOFTE(r1)
+1:
stb r3,PACASOFTIRQEN(r13) /* restore paca->soft_enabled */
+ cmpdi r3,0
+ bne 2f
+ bl .trace_hardirqs_off
+ ld r3,SOFTE(r1)
+2:
+#else
+ stb r3,PACASOFTIRQEN(r13) /* restore paca->soft_enabled */
+#endif
+ ld r12,_MSR(r1)
rldicl r4,r12,49,63 /* get MSR_EE to LSB */
stb r4,PACAHARDIRQEN(r13) /* restore paca->hard_enabled */
- b 1f
+ b 3f
.globl fast_exception_return
fast_exception_return:
ld r12,_MSR(r1)
-1: ld r11,_NIP(r1)
+3: ld r11,_NIP(r1)
andi. r3,r12,MSR_RI /* check if RI is set */
beq- unrecov_fer
#ifdef CONFIG_VIRT_CPU_ACCOUNTING
andi. r3,r12,MSR_PR
- beq 2f
+ beq 4f
ACCOUNT_CPU_USER_EXIT(r3, r4)
-2:
+4:
#endif
ld r3,_CCR(r1)
@@ -1387,11 +1408,24 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER
/*
* hash_page couldn't handle it, set soft interrupt enable back
- * to what it was before the trap. Note that .local_irq_restore
+ * to what it was before the trap. Note that .raw_local_irq_restore
* handles any interrupts pending at this point.
*/
ld r3,SOFTE(r1)
- bl .local_irq_restore
+#ifdef CONFIG_TRACE_IRQFLAGS
+ cmpdi r3,0
+ beq 14f
+ bl .trace_hardirqs_on
+ ld r3,SOFTE(r1)
+14:
+ bl .raw_local_irq_restore
+ cmpdi r3,0
+ bne 15f
+ bl .trace_hardirqs_off
+15:
+#else
+ bl .raw_local_irq_restore
+#endif
b 11f
/* Here we have a page fault that hash_page can't handle. */
--- linux-2.6-git.orig/arch/powerpc/kernel/setup_64.c 2007-06-27 17:37:39.976965668 +0200
+++ linux-2.6-git/arch/powerpc/kernel/setup_64.c 2007-06-27 17:38:08.062965668 +0200
@@ -33,6 +33,7 @@
#include <linux/serial_8250.h>
#include <linux/bootmem.h>
#include <linux/pci.h>
+#include <linux/lockdep.h>
#include <asm/io.h>
#include <asm/kdump.h>
#include <asm/prom.h>
@@ -359,6 +360,11 @@ void __init setup_system(void)
&__start___fw_ftr_fixup, &__stop___fw_ftr_fixup);
/*
+ * start lockdep
+ */
+ lockdep_init();
+
+ /*
* Unflatten the device-tree passed by prom_init or kexec
*/
unflatten_device_tree();
--- linux-2.6-git.orig/arch/powerpc/kernel/entry_64.S 2007-06-27 17:37:40.045965668 +0200
+++ linux-2.6-git/arch/powerpc/kernel/entry_64.S 2007-06-27 17:50:16.499965668 +0200
@@ -91,6 +91,13 @@ system_call_common:
li r10,1
stb r10,PACASOFTIRQEN(r13)
stb r10,PACAHARDIRQEN(r13)
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_on
+ REST_GPR(0,r1)
+ REST_4GPRS(3,r1)
+ REST_2GPRS(7,r1)
+ addi r9,r1,STACK_FRAME_OVERHEAD
+#endif
std r10,SOFTE(r1)
#ifdef CONFIG_PPC_ISERIES
BEGIN_FW_FTR_SECTION
@@ -491,8 +498,20 @@ BEGIN_FW_FTR_SECTION
4:
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
#endif
+#ifdef CONFIG_TRACE_IRQFLAGS
+ cmpdi r5,0
+ beq 5f
+ bl .trace_hardirqs_on
+ ld r5,SOFTE(r1)
stb r5,PACASOFTIRQEN(r13)
-
+ b 6f
+5:
+ stb r5,PACASOFTIRQEN(r13)
+ bl .trace_hardirqs_off
+6:
+#else
+ stb r5,PACASOFTIRQEN(r13)
+#endif
/* extract EE bit and use it to restore paca->hard_enabled */
ld r3,_MSR(r1)
rldicl r4,r3,49,63 /* r0 = (r3 >> 15) & 1 */
@@ -560,6 +579,9 @@ do_work:
bne restore
/* here we are preempting the current task */
1:
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .powerpc_trace_hardirqs_on
+#endif
li r0,1
stb r0,PACASOFTIRQEN(r13)
stb r0,PACAHARDIRQEN(r13)
--- linux-2.6-git.orig/arch/powerpc/kernel/Makefile 2007-06-27 17:37:40.100965668 +0200
+++ linux-2.6-git/arch/powerpc/kernel/Makefile 2007-06-27 17:38:08.064965668 +0200
@@ -62,6 +62,7 @@ obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
+obj-$(CONFIG_TRACE_IRQFLAGS) += irqtrace.o
module-$(CONFIG_PPC64) += module_64.o
obj-$(CONFIG_MODULES) += $(module-y)
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-git/arch/powerpc/kernel/irqtrace.S 2007-06-27 17:49:15.650965668 +0200
@@ -0,0 +1,47 @@
+/*
+ * crappy helper for irq-trace
+ */
+
+#include <asm/ppc_asm.h>
+#include <asm/asm-offsets.h>
+
+#define STACKSPACE GPR0 + 16*8
+
+#ifdef __powerpc64__
+#define ST std
+#define L ld
+#else
+#define ST stw
+#define L lw
+#endif
+
+#define PRE \
+ subi r1,r1,STACKSPACE ; \
+ SAVE_GPR(0, r1) ; \
+ SAVE_8GPRS(2, r1) ; \
+ SAVE_4GPRS(10, r1) ; \
+ mfcr r0 ; \
+ ST r0, (14*8)(r1) ; \
+ mflr r0 ; \
+ ST r0, (15*8)(r1)
+
+#define POST \
+ REST_8GPRS(2, r1) ; \
+ REST_4GPRS(10, r1) ; \
+ L r0, (14*8)(r1) ; \
+ mtcr r0 ; \
+ L r0, (15*8)(r1) ; \
+ mtlr r0 ; \
+ REST_GPR(0, r1) ; \
+ addi r1,r1,STACKSPACE
+
+_GLOBAL(powerpc_trace_hardirqs_off)
+ PRE
+ bl .trace_hardirqs_off
+ POST
+ blr
+_GLOBAL(powerpc_trace_hardirqs_on)
+ PRE
+ bl .trace_hardirqs_on
+ POST
+ blr
^ permalink raw reply
* Re: In booting-without-of.txt, clarify that properties must precede subnodes
From: Segher Boessenkool @ 2007-06-28 9:24 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070628055626.GB10769@localhost.localdomain>
> A strict reading of the flattened device tree format defined in
> booting-without-of.txt does in fact require that all the tags defining
> properties for a node go before any definitions of subnodes, however
> it's not particularly emphasised. Although allowing intermingled
> properties and subnodes would not be ambiguous in meaning, the kernel
> parser does currently require that properties precede subnodes.
> Furthermore, keeping this constraint makes life easier for various
> device tree scanning tools.
>
> Therefore, re-emphasise in booting-without-of.txt that this is a
> strict requirement of the flattened device tree format.
Do you want to require this for device tree source files,
too? I think that's how the tools work right now but that's
not made explicit anywhere afaik.
Segher
^ permalink raw reply
* Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Segher Boessenkool @ 2007-06-28 9:23 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20070628002438.GB15298@localhost.localdomain>
>> + k) RapidIO
>> +
>> + Required properties:
>
> Should probably recommend a name for the node here, as well. "srio" I
> guess, from the example below.
I would prefer "rapidio", being more generic and more
readable. What would parallel RapidIO be, "prio"? No
thanks :-)
Segher
^ permalink raw reply
* Re: [PATCH 1/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Segher Boessenkool @ 2007-06-28 9:22 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <11829333481977-git-send-email-wei.zhang@freescale.com>
> + - #address-cells : Address representation for "rapidio" devices.
> + This field represents the number of cells needed to represent
> + the RapidIO address of the registers. For supporting more than
> + 32-bits RapidIO address, this field should be <2>.
> + See 1) above for more details on defining #address-cells.
What does the RapidIO standard say about number of address
bits? You want to follow that, so all RapidIO devices can
use the same #address-cells, not just the FSL ones. Also,
are there different kinds of address spaces on the bus, or
is it just one big memory-like space?
Segher
^ permalink raw reply
* Re: [PATCH 09/15] [POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-28 9:18 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070628002342.GA15298@localhost.localdomain>
>>> This can't be right, and I suspect it will break any kernel access to
>>> the first 0x1000 bytes of the CCSR_BAR space. reg should actually
>>> describe the register space of the SOC. If ranges needs to specify
>>> that, too, they should be able to be redundant. But this looks like
>>> a big hack, to me. Am I missing something?
>>
>> "reg" and "ranges" can never overlap really.
>
> Is this really true, always?
Well think about it. "reg" is the addresses your bridge
device's registers sit at. "ranges" is the addresses your
bridge translates to its child bus.
> What about something like a PReP PCI bridge, which has the registers
> for indirect config-space access in the same range as the ISA IO
> space?
Yeah there are always nasty corner cases that are hard
to express. Like a PHB that is visible as a device on
its own PCI bus -- it would have to be its own child in
the device tree! Such devices are best dealt with on
a one-by-one basis.
Segher
^ permalink raw reply
* Re: [PATCH 09/15] [POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
From: Segher Boessenkool @ 2007-06-28 9:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <66B07304-BE33-4A9E-8C9C-BEC0BCEC79F8@kernel.crashing.org>
>>>>>>>> - ranges = <0 f8000000 00100000>;
>>>>>>>> - reg = <f8000000 00100000>; // CCSRBAR 1M
>>>>>>>> + ranges = <00001000 f8001000 000ff000
>>>>>>>> + reg = <f8000000 00001000>; // CCSRBAR
>>
>>>> There is "BAR" in the name, so it is a movable range? Where
>>>> is the base address set?
>>>
>>> in a MMIO register in the space itself.
>>
>> Oh, *great* design.</sarcasm>
>
> its not that bad ;)
Well there's no way to configure it if the current
configuration is screwed, or you just don't know
what the current configuration is. Anyway, that's
all beside the point here.
>>>> What is the relationship between (in the example) the address
>>>> ranges x'f800_0000+1000 and x'f800_1000+ff000?
>>>
>>> uugh, not sure what that's all about.
>>
>> Reading back I see that the CCSR region is 1MB, and only the
>> first 4kB are for this PHB. What is the rest of this range
>> used for -- devices on this PCI bus, other SoC devices, ...?
>
> No, the first 4kB are SOC/platform level config registers (high level
> window setup, CCSR location, etc).
>
> The PHB registers are somewhere in the middle (0x8000, I think). All
> the children devices (enet, PHBs, etc) live in the 1M block.
So:
-- CCSR doesn't sit on PCI at all
-- It is a SoC register space
-- And it is only needed for configuration, not for normal
operation? ( <-- I so much hope this one is true!)
> I think my original idea was the reg property on the SOC node was for
> the first 4k block that held the SOC config registers. I think what
> Wade did is correct since the reg property on the SOC node isnt going
> to get translated through the ranges property and that they should be
> mutually exclusive.
Yeah but I'm wondering about the other devices on CCSR now...
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Benjamin Herrenschmidt @ 2007-06-28 9:13 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <ce09df5afe642e8f6e9a576306cc1e41@kernel.crashing.org>
> > The erratum says nothing about any HW bugs with L3 cache flush. I just
> > mentioned that the L3 cache flush operation described in MPC7450
> > Reference manual is similar to the L2 using the L3 cache hardware
> > flushing mechanism. For instance, it requires a complete L3 locking
> > before flushing.
>
> Then I think we should use that mechanism in the Linux kernel.
> Anything else is waiting for bugs to bite.
I just figured out ... we actually already have all of that cache flush
code :-) I wrote most of it in fact. It's just that for some (bad)
reasons, it's somewhat hidden in arch/powerpc/platforms/powermac/cache.S
So I think best would be to take it from there and make it more
generic ...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Segher Boessenkool @ 2007-06-28 8:59 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070627071008.GA30648@localhost.localdomain>
> Here is an implementation to allow PReP systems to boot under the
> arch/powerpc codebase, one of the few remaining platforms supported in
> arch/ppc but not so far in arch/powerpc.
> Too big for the list, the patch is at:
> http://ozlabs.org/~dgibson/home/prep-support
Too lazy to split the patch into bite-size chunks, you mean ;-)
Anyway, here goes the DTS bits:
+/*
+ * PReP skeleton device tree
+ *
+ * Paul Mackerras <paulus@samba.org>
+ */
+
+/ {
+ device_type = "prep";
+ model = "IBM,PReP";
Not specific enough, leave it out or fill it in in the bootwrapper.
+ compatible = "prep";
Maybe fill this in, too.
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
Do all (supported) PReP boards have one CPU only?
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <0>; // filled in by bootwrapper
+ bus-frequency = <0>; // filled in by bootwrapper
+ timebase-frequency = <0>; // filled in by bootwrapper
+ i-cache-line-size = <0>; // filled in by bootwrapper
+ d-cache-line-size = <0>; // filled in by bootwrapper
+ d-cache-size = <0>; // filled in by bootwrapper
+ i-cache-size = <0>; // filled in by bootwrapper
+ external-control;
Really?
+ graphics;
+ performance-monitor;
+
+ l2-cache {
+ device_type = "cache";
+ i-cache-size = <00100000>;
+ d-cache-size = <00100000>;
+ i-cache-sets = <00008000>;
+ d-cache-sets = <00008000>;
+ i-cache-line-size = <00000020>;
+ d-cache-line-size = <00000020>;
Drop the leading zeroes, they make my head spin :-)
+ cache-unified;
+ };
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ // dummy range here, zImage wrapper will fill in the actual
+ // amount of memory from the residual data
+ reg = <00000000 00000000>;
+ };
+
+ pci@80000000 {
+ device_type = "pci";
+ compatible = "prep";
Is that specific enough?
+ clock-frequency = <01fca055>;
+ reg = <80000000 7effffff>;
+ 8259-interrupt-acknowledge = <bffffff0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges=<01000000 00000000 00000000 80000000 00000000 00800000
+ 01000000 00000000 00800000 81000000 00000000 3e800000
+ 02000000 00000000 00000000 c0000000 00000000 01000000
+ 02000000 00000000 01000000 c1000000 00000000 3e000000>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <6000 0 0 1 &MPIC 6 0
+ 8000 0 0 1 &MPIC 7 0
+ 9000 0 0 1 &MPIC 2 0
+ b000 0 0 1 &MPIC 1 0>;
I can't believe this "ranges" and interrupt mapping will
work on all PReP systems...
+ isa {
+ device_type = "isa";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <00000001 00000000
+ 01005800 00000000 00000000 00010000
+ 00000000 00000000
+ 02005800 00000000 00000000 01000000>;
+
+ parallel {
+ device_type = "parallel";
+ compatible = "ecp", "pnpPNP,400";
"pnpPNP,401", "pnpPNP,400"
+ reg = <00000001 000003bc 00000008
+ 00000001 000007bc 00000006>;
+ interrupts = <00000007 00000003>;
+ interrupt-parent = <&PIC8259>;
+ };
+
+ serial@3f8 {
+ device_type = "serial";
+ compatible = "pnpPNP,501";
"pnpPNP,501", "pnpPNP,500" I'd say. Many/some device
tree users will only care it is _some_ 8250 family thing.
+ clock-frequency = <001c2000>;
+ reg = <00000001 000003f8 00000008>;
+ interrupts = <00000004 00000003>;
+ interrupt-parent = <&PIC8259>;
+ };
+ serial@2f8 {
+ device_type = "serial";
+ compatible = "pnpPNP,501";
+ clock-frequency = <001c2000>;
+ reg = <00000001 000002f8 00000008>;
+ interrupts = <00000003 00000003>;
+ interrupt-parent = <&PIC8259>;
+ };
+ PIC8259: interrupt-controller {
+ device_type = "i8259";
device_type = "interrupt-controller".
+ compatible = "prep,iic";
+ reg = < 00000001 00000020 00000002
+ 00000001 000000a0 00000002
+ 00000001 000004d0 00000002>;
+ interrupts = <00000000 00000003
+ 00000002 00000003>;
+ interrupt-parent = <&MPIC>;
+ };
+ };
+
+ MPIC: interrupt-controller@d {
+ device_type = "open-pic";
device_type = "interrupt-controller".
+ compatible = "mpic";
+ reg = < 00006800 00000000 00000000 00000000 00000000
+ 02006810 00000000 00000000 00000000 00040000>;
+ assigned-addresses = <
+ 82006810 00000000 3afc0000 00000000 00040000>;
+ };
+ };
+
+ chosen {
+ linux,stdout-path = "/pci/isa/serial@3f8";
+ };
+};
What is the plan here -- have the bootwrapper build the
device tree / fill in the details from the residual data?
Segher
^ permalink raw reply
* Re: [PATCH 2/3] Make more OF-related bootwrapper functions available to non-OF platforms
From: Segher Boessenkool @ 2007-06-28 8:44 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070627065458.60C5ADDF2B@ozlabs.org>
> Commit 2e6016133755eb3cc44e8efab92573d23ed75888 split up
> arch/powerpc/boot/of.c so that some OF functions can be used on
> platforms that don't want to use the overall OF platform boot code.
> This is useful on things like PReP which can have an OF implementation
> which is useful for debugging output, but inadequate for booting.
>
> However, that commit didn't export quite enough things to make a
> usable OF console on a non-OF system. In particular, the device tree
> manipulation performed to initialize the OF console code must
> explicitly use the OF device tree, rather than the flattened device
> tree, even if the system is otherwise booting using a flattened device
> tree. This patch makes it so.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Looks good to me, I assume you tested it? You didn't
mention on what hardware...
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Segher Boessenkool @ 2007-06-28 8:35 UTC (permalink / raw)
To: Vladislav Buzov; +Cc: linuxppc-dev
In-Reply-To: <468010C0.20701@ru.mvista.com>
>>> First, I'm looking for a help and advice why the current _set_L2CR()
>>> implementation may not work for MPC7450 (namely 7448 with 1Mb L2
>>> cache
>>> installed). Is it a bug in _set_L2CR() or a hardware problem.
>>
>> I think that if anyone here could answer this straight
>> away, the source code would have been fixed already ;-)
>
> I think I can try to answer this question. Please, look through my
> thoughts below and correct me if I'm somewhere wrong.
You forgot step 0: the goal of flushing the caches here
is to make sure there is no data at all in there after it
has finished.
> The current scheme of flushing the caches is based on a number of
> consecutive lwz/dcbf instructions. A contiguous memory region (started
> from zero) is read by series of lwz commands and then cache is flushed
> using a sequence of dcbf instructions with addresses from this memory
> range. If I understand correctly, to get this approach working it is
> required to guarantee that after reading the memory region, each line
> in a cache should be used and keep data from this region. Otherwise,
> if some cache lines keep data from another address range they will not
> be flushed by the dcbf instructions sequence.
Yes, you need to ensure there is nothing interfering (SMP
agents, DMA agents, prefetch engines...), and you need to
know the line replacement policy, to make this work;
furthermore, you need to be quite careful in your code to
make sure the intended L2 stores are the _only_ L2 traffic
you generate.
> Further, how cache lines are utilized is dictated by a cache lines
> replacement policy. I didn't go in to details deeply, but on MPC7450
> L1 cache lines replacement policy seems to satisfy the requirement
> above. At least the MPC7450 reference manual describes L1 cache
> flushing algorithm based on a sequence of lwz/dcbf instructions.
>
> But regarding to L2/L3 caches, the manual describes two different
> cache line replacement policies. And the both are pseudo-random
At least on is the "standard" PowerPC pseudo-LRU tree, no?
That one flushes fine using this strategy.
> and differ by implementation of random number generator. It means that
> a cache line in a set is chosen randomly, and that, in turn, means
> that there is a probability that some cache lines are not used during
> reading of the contiguous memory region and not flushed by the dcbf
> instruction sequence.
Knowing that there is no "outside" interference, and knowing
the "random" algorithm, can give plenty guarantees.
> For example, on MPC7448 there is a eight-way set-associative 1Mb L2
> cache that consist of 2048 sets x 8 ways per set. And even if a set N
> has been accessed M times (M > 8) there is a chance that some cache
> line is set N has never been used, but another line has been used
> twice or more. Of course, the probability of such situation decreases
> with increasing of N.
You can make sure, too. Just trying to statistically get
to the point where you are sure the whole cache is flushed
is not going to work *at all*, you need to use deeper knowledge
of how the cache works.
> Current _set_L2CR() implementation reads first 4Mb of memory to flush
> the L2 cache. I have increased this size up to 16 Mb and now things
> work fine. But I don't think that is a right way to fix the problem
> because there is no any way to define the upper limit of memory size
> to guarantee flushing of each cache line. 16Mb is too large though. It
> seems more reasonable to use a stable and guaranteed way to flush the
> cache implemented in hardware.
Yes, use the hardware flush mechanism. Please :-)
[I think the erratum is about insn fetches to L2 that you
have no way too stop. <handwaving>Something like that,
anyway.</handwaving>]
Segher
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Erik Christiansen @ 2007-06-28 8:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070628074430.GC8794@dd.nec.com.au>
On Thu, Jun 28, 2007 at 05:44:30PM +1000, Erik Christiansen wrote:
> Encountering a kernel build error with ARCH=ppc, after configuring as much as
> possible for MPC8248, I've just tried ARCH=powerpc on linux-2.6.21.5, with this
> slightly scary result:
Oh dear. Please excuse the noise. That was clearly acute lack of
familiarity with menuconfig. <blush>
Minus fingerfumbling, ARCH=powerpc starts to build, before coughing up a
bunch of compiler errors:
cpm2_common.c:63: error: 'CPM_MAP_ADDR' undeclared
Is that due to this patch not being accepted?:
http://patchwork.ozlabs.org/linuxppc/patch?id=8891
If the patch's "State Superseded" means something else fixes the build
failure, then how could I lay my grubby paws on that little gem?
Erik
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Segher Boessenkool @ 2007-06-28 8:24 UTC (permalink / raw)
To: Vladislav Buzov; +Cc: linuxppc-dev list
In-Reply-To: <467FCC9D.6010904@ru.mvista.com>
>>> Note that 745x processors have L3 cache installed and may have the
>>> same
>>> problem requiring similar code modifications to use L3 hardware
>>> flushing
>>> mechanism.
>>
>> What does the erratum say?
>
> The erratum says nothing about any HW bugs with L3 cache flush. I just
> mentioned that the L3 cache flush operation described in MPC7450
> Reference manual is similar to the L2 using the L3 cache hardware
> flushing mechanism. For instance, it requires a complete L3 locking
> before flushing.
Then I think we should use that mechanism in the Linux kernel.
Anything else is waiting for bugs to bite.
>> The L3 is a very different beast from the L2, IIRC it is
>> a pure victim cache so it cannot have this problem at all?
>
> I'm not sure if it is a pure victim cache. I read the MPC7450
> reference manual and see that the L3 cache operates similarly to the
> L2. The main difference between those caches is that L3 uses an
> external SRAM memory while L2 is a pure on-chip cache.
Yeah but it isn't involved in any prefetching AFAIK. Anyway,
moot point, since we really should do the recommended flush
algorithm (esp. since we clearly do not sufficiently understand
the details of the L3 operation!)
Segher
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Erik Christiansen @ 2007-06-28 7:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <2DD9CF30-5127-4EC1-8D8E-BC6552A832AE@kernel.crashing.org>
On Wed, Jun 27, 2007 at 08:20:28PM -0500, Kumar Gala wrote:
> On Jun 27, 2007, at 4:41 PM, Bizhan Gholikhamseh ((bgholikh)) wrote:
> > Here are my questions:
> > 1- Should I use ARCH=ppc or ARCH=powerpc to build the kernel?
>
> Move to ARCH=powerpc.
Would that advice be specific to the MPC8541E?
Encountering a kernel build error with ARCH=ppc, after configuring as much as
possible for MPC8248, I've just tried ARCH=powerpc on linux-2.6.21.5, with this
slightly scary result:
>>>
There is no help available for this kernel option.
Symbol: EMBEDDED6xx [=n]
Prompt: Embedded 6xx/7xx/7xxx-based board
Defined at arch/powerpc/Kconfig:384
Depends on: <choice> && PPC32 && (BROKEN || BROKEN_ON_SMP)
Location:
-> Platform support
-> Machine type (<choice> [=y])
<<<
(Note: MPC8248 fits in the 6xx group, architecturally, AFAICT.)
At least I can apply a patch (missing from current kernels), to
fix the immediate MPC8248 problem in ARCH=ppc.
For my case then, ARCH=ppc seems to offer more promise.
Erik
(At this early stage, trying to figure which way is up. :-)
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Zang Roy-r61911 @ 2007-06-28 6:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
On Fri, 2007-06-15 at 12:50, Paul Mackerras wrote:
> I have created a for-2.6.23 branch in the powerpc.git repository
> (git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git)
> where I have started queueing up patches to go in once the 2.6.23
> merge window opens. For now at least it's the same as the master
> branch.
>
> The patches I put in are listed below. If you have a patch that
> should go in but isn't listed, remind me about it.
>
Paul,
These patches should go in 2.6.23.
1 add cuboot for 7448hpc2 board
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
2. Remove redundant pci_read_irq_line() function for 85xx platform
Acked by Ben
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037117.html
3. Fix e500 v2 core reboot bug
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037799.html
4. Document the global utilities node define and example
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038136.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038137.html
Roy
^ permalink raw reply
* RE: [PATCH 3/5 v2] Add the platform device support with RapidIO to MPC8641HPCN platform.
From: Zhang Wei-r63237 @ 2007-06-28 6:42 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev; +Cc: paulus, linux-kernel
In-Reply-To: <200706272256.16418.arnd@arndb.de>
Hi, Arnd,
>=20
> On Wednesday 27 June 2007, Zhang Wei wrote:
> > +static struct of_device_id mpc86xx_of_ids[] =3D {
> > +=A0=A0=A0=A0=A0=A0=A0{ .type =3D "soc", },
> > +=A0=A0=A0=A0=A0=A0=A0{ .compatible =3D "fsl,rapidio-delta", },
> > +=A0=A0=A0=A0=A0=A0=A0{},
> > +};
> > +
> > +static __init int mpc86xx_of_device_init(void)
> > +{
> > +=A0=A0=A0=A0=A0=A0=A0return of_platform_bus_probe(NULL, =
mpc86xx_of_ids, NULL);
> > +}
>=20
> This will add any devices below the "fsl,rapidio-delta" device
> as an of_device. Is that what you actually want? I would guess that
> you want to add the bridge itself, not the devices below it.
>=20
> Is the rapidio device at the root of the device tree, and if so, why
> not under the soc bus?
>=20
RapidIO is rather a bus that a device although these is no other nodes =
defined in its sector now.
Thanks!
Wei.
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Paul Mackerras @ 2007-06-28 6:35 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0706151915580.5979@poirot.grange>
Guennadi Liakhovetski writes:
> These two i2c patches:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
>
> also would be nice to get in, although, they only make sense with an ack
> from Scott Wood and another patch from him, as explained in links above...
Looks OK, but the first of those two patches doesn't have a
Signed-off-by: line, and the description is not suitable.
Please repost that patch with a nice description that describes what
the patch does and why, without references to other web pages. You
don't need to describe what is different from previous patches or who
suggested those changes.
Paul.
^ 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