* Re: [PATCH 6/9] [POWERPC] prpmc2800: clean up dts properties
From: David Gibson @ 2008-04-01 2:22 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Olof Johansson, linuxppc-dev, paulus
In-Reply-To: <20080331164302.GC13750@farnsworth.org>
On Mon, Mar 31, 2008 at 09:43:02AM -0700, Dale Farnsworth wrote:
> On Sun, Mar 30, 2008 at 09:11:28PM +1100, David Gibson wrote:
> > On Sat, Mar 29, 2008 at 04:59:42PM -0500, Olof Johansson wrote:
> > > On Fri, Mar 28, 2008 at 04:49:00PM -0700, Dale Farnsworth wrote:
> > > > From: Mark A. Greer <mgreer@mvista.com>
> > > >
> > > > Remove several unused (or software config only) properties.
> > > > Rename marvel node to "soc". Technically, it's not an SOC,
> > > > but its organization is the same as an SOC. Also, rename the
> > > > "block-index" property to "cell-index" to conform to current
> > > > practice.
> > >
> > > I see this rename as purely misleading. It isn't an soc, so it shouldn't
> > > be named as such. Call it system-controller or something. Pretty much
> > > any other name is better. :-)
> >
> > I agree. system-controller, host-bridge, north-bridge, maybe, but not
> > soc. With current conventions, the node name is primarily for the
> > benefit of human readers, so if it misleads it has failed entirely in
> > its purpose.
>
> I'm convinced. I'll change it to system-controller.
>
> However, I can't resist pointing out that in the existing devtrees
> with a "soc" node, the name is also misleading. That node doesn't
> refer to the SOC itself, but to the part of the SOC containing the
> peripherals. Whether the system is implemented on one or two chips
> is an implementation detail irrelevant to the drivers or device
> tree.
Well, quite so. It's not even all of the peripherals on the SOC, just
the ones on Freescale SoCs that are relocatable by the IMMR register.
Which is why 4xx SoCs don't use /soc and instead have separate nodes
for the on-chip busses.
However, /soc is established now, but let's not accrete it with any
more badly named examples.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Josh Boyer @ 2008-04-01 3:15 UTC (permalink / raw)
To: michael; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1207011862.7490.5.camel@concordia.ozlabs.ibm.com>
On Tue, 2008-04-01 at 12:04 +1100, Michael Ellerman wrote:
> > > > I'm assuming you pass a dtb to the virtual guest when you start it up.
> > > > Could you define a property in the CPU node there that can be parsed to
> > > > use the power_save function instead of always making it the default?
> > >
> > > Actually, you probably don't want this as a property in the device
> > > tree. It doesn't describe hardware. A Kconfig option might be
> > > warranted though.
> >
> > I'll go with the Kconfig option.
>
> Go with a device-tree check. The pseries kernel supports both bare-metal
> and hypervisor in the same kernel image, and it works out which it's
> running on by looking at the device-tree. This seems equivalent to me?
After some back and forth on IRC, we decided on that as well. I love
being right, then wrong, then right again.
/me needs more sleep.
josh
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Michael Ellerman @ 2008-04-01 3:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <1207019732.12155.81.camel@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]
On Mon, 2008-03-31 at 22:15 -0500, Josh Boyer wrote:
> On Tue, 2008-04-01 at 12:04 +1100, Michael Ellerman wrote:
> > > > > I'm assuming you pass a dtb to the virtual guest when you start it up.
> > > > > Could you define a property in the CPU node there that can be parsed to
> > > > > use the power_save function instead of always making it the default?
> > > >
> > > > Actually, you probably don't want this as a property in the device
> > > > tree. It doesn't describe hardware. A Kconfig option might be
> > > > warranted though.
> > >
> > > I'll go with the Kconfig option.
> >
> > Go with a device-tree check. The pseries kernel supports both bare-metal
> > and hypervisor in the same kernel image, and it works out which it's
> > running on by looking at the device-tree. This seems equivalent to me?
>
> After some back and forth on IRC, we decided on that as well. I love
> being right, then wrong, then right again.
>
> /me needs more sleep.
Better to be right twice rather than once, no?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
From: Paul Mackerras @ 2008-04-01 3:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0803281338360.15109@blarg.am.freescale.net>
Kumar Gala writes:
> Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in
> places that before would have caused recursive includes.
>
> For example to use phys_addr_t in <asm/page.h> we would have included
> <asm/mmu.h> which would have possibly included <asm/mmu-hash64.h> which
> includes <asm/page.h>. Wheeee recursive include.
In general this looks fine. I wonder if you should use u64 rather
than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit machines
(which is itself somewhat counterintuitive) we will actually use
unsigned long on 64-bit machines, so it matters less than I originally
thought, but it would be worth explaining that in a comment and/or the
commit message.
Paul.
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Paul Mackerras @ 2008-04-01 4:00 UTC (permalink / raw)
To: Josh Boyer; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <20080331130518.2a6b0264@zod.rchland.ibm.com>
Josh Boyer writes:
> Actually, you probably don't want this as a property in the device
> tree. It doesn't describe hardware. A Kconfig option might be
> warranted though.
In general it is valid to have properties in the device tree that
describe the hypervisor or the kernel's interface to it, since they
are aspects of the platform, i.e. the virtual "hardware" that the
kernel is running on.
Paul.
^ permalink raw reply
* Re: [patch 06/24] lmb: add lmb_alloc_nid()
From: Paul Mackerras @ 2008-04-01 4:15 UTC (permalink / raw)
To: akpm; +Cc: mingo, tglx, davem, linuxppc-dev
In-Reply-To: <200803282121.m2SLLBso010683@imap1.linux-foundation.org>
akpm@linux-foundation.org writes:
> From: David Miller <davem@davemloft.net>
>
> A variant of lmb_alloc() that tries to allocate memory on a specified NUMA
> node 'nid' but falls back to normal lmb_alloc() if that fails.
...
> +static u64 __init lmb_alloc_nid_unreserved(u64 start, u64 end,
> + u64 size, u64 align)
> +{
> + u64 base;
> + long j;
> +
> + base = lmb_align_down((end - size), align);
> + while (start <= base &&
> + ((j = lmb_overlaps_region(&lmb.reserved, base, size)) >= 0))
> + base = lmb_align_down(lmb.reserved.region[j].base - size,
> + align);
How do we know that lmb.reserved.region[j].base is >= size at this
point? If it isn't, then base could end up as some extremely large
unsigned value, which would be a Bad Thing.
Paul.
^ permalink raw reply
* Unable to handle kernel paging request for instruction fetch???
From: 郭劲 @ 2008-04-01 4:18 UTC (permalink / raw)
To: linuxppc-embedded
Hi,all,
I run the iperf tool to test the ethernet throughput for my MPC8360E board, after
about 20 minutes, the exception is happened. Could you tell me why?
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x4e800020
Oops: Kernel access of bad area, sig: 11 [#1]
MPC836x MDS
Modules linked in: encoder mpc_sync k_spi(P)
NIP: 4e800020 LR: c01a08d4 CTR: 00000000
REGS: ef6e3b10 TRAP: 0400 Tainted: P (2.6.22)
MSR: 20009032 <EE,ME,IR,DR> CR: 22848284 XER: 00000000
TASK = c0232810[56] 'iperf' THREAD: ef6e2000
GPR00: 4e800020 ef6e3bc0 c0232810 ef6e1100 00000000 00000000 00000020 00000000
GPR08: 00000000 c0024570 0c9dcf08 00000000 42848288 1002668c 0fffe000 007fff00
GPR16: c026c9bc ef6e3e30 c0232810 00000001 00000000 00000000 00000000 00002000
GPR24: ef6e1160 00000000 00000014 cff213c8 cff213a0 00000020 ef6e1100 00000000
Call Trace:
[ef6e3bc0] [c0247a00] (unreliable)
[ef6e3c00] [c01a3af4]
[ef6e3c20] [c019e8a0]
[ef6e3c30] [c019efe0]
[ef6e3c60] [c01a6ad0]
[ef6e3c80] [c01966a0]
[ef6e3ca0] [c0196d38]
[ef6e3d00] [c016a2e8]
[ef6e3d20] [c0165a14]
[ef6e3e20] [c0166f44]
[ef6e3f00] [c01677ec]
[ef6e3f40] [c000f3e8]
--- Exception: c01Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 180 seconds..
^ permalink raw reply
* Re: [patch 06/24] lmb: add lmb_alloc_nid()
From: David Miller @ 2008-04-01 5:21 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, akpm, tglx, mingo
In-Reply-To: <18417.46834.753849.815163@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Tue, 1 Apr 2008 15:15:46 +1100
> akpm@linux-foundation.org writes:
>
> > From: David Miller <davem@davemloft.net>
> >
> > A variant of lmb_alloc() that tries to allocate memory on a specified NUMA
> > node 'nid' but falls back to normal lmb_alloc() if that fails.
>
> ...
>
> > +static u64 __init lmb_alloc_nid_unreserved(u64 start, u64 end,
> > + u64 size, u64 align)
> > +{
> > + u64 base;
> > + long j;
> > +
> > + base = lmb_align_down((end - size), align);
> > + while (start <= base &&
> > + ((j = lmb_overlaps_region(&lmb.reserved, base, size)) >= 0))
> > + base = lmb_align_down(lmb.reserved.region[j].base - size,
> > + align);
>
> How do we know that lmb.reserved.region[j].base is >= size at this
> point? If it isn't, then base could end up as some extremely large
> unsigned value, which would be a Bad Thing.
The same exact issue exists in the existing code, from which this is
derived, in __lmb_alloc_base().
This situation can occur any time a region is smaller than the 'size'
argument, in both functions.
^ permalink raw reply
* Re: JFFS2 root-fs
From: Georg Schardt @ 2008-04-01 6:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <EE63F03D9E04774997AEBCD21FC77F251E9878@ccomm-ex1.ccomm.com>
Sugathan, Rupesh schrieb:
>
> It seems to me, that the kernel does not find ANY file. because the
> /dev/console file is in the image, but the initial console is not found
> too
>
> 1) You should probably unpack and mount the jffs2 image on your host
> directory to ensure that you see all files in place.
>
i see all the files with the u-boot jffs2 commands, but will try to
mount the jffs image on the host
> 2) Check to see if your designated flash partition can hold all of your
> jffs2 image.
>
yes, its big enough
> Were you able to use the 'same' rootfs in any other way (nfs mount or
> ramdisk) on the target?
>
i will try this
Thanks
Georg
> Thanks
> --
> Rupesh Sugathan
>
>
-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
^ permalink raw reply
* [PATCH] Make #include <sysdev/foo.h> work for 64-bit powerpc
From: Michael Ellerman @ 2008-04-01 6:39 UTC (permalink / raw)
To: linuxppc-dev
We currently have inconsistent settings between 32 & 64-bit which means
32-bit code can #include <sysdev/foo.h> but 64-bit code can't.
So make the (C|A|CPP)FLAGS settings to allow this common. Doing so makes
the CPPFLAGS-y and AFLAGS-y variables unnecessary, so just fold them into
KBUILD_CPPFLAGS and KBUILD_AFLAGS respectively.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Makefile | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
This is 26 material.
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 1c6ce35..aa9829a 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -71,13 +71,11 @@ endif
LDFLAGS_vmlinux := -Bstatic
-CPPFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH)
-AFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH)
CFLAGS-$(CONFIG_PPC64) := -mminimal-toc -mtraceback=none -mcall-aixdesc
-CFLAGS-$(CONFIG_PPC32) := -Iarch/$(ARCH) -ffixed-r2 -mmultiple
-KBUILD_CPPFLAGS += $(CPPFLAGS-y)
-KBUILD_AFLAGS += $(AFLAGS-y)
-KBUILD_CFLAGS += -msoft-float -pipe $(CFLAGS-y)
+CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 -mmultiple
+KBUILD_CPPFLAGS += -Iarch/$(ARCH)
+KBUILD_AFLAGS += -Iarch/$(ARCH)
+KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y)
CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS += -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [RFC/PATCH 1/4] Move xics_setup_8259_cascade() into platforms/pseries/setup.c
From: Michael Ellerman @ 2008-04-01 6:42 UTC (permalink / raw)
To: linuxppc-dev
The code in xics.c to setup the i8259 cascaded irq handler is not really
xics specific, so move it into setup.c - we will clean this up further in
a subsequent patch.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/setup.c | 53 +++++++++++++++++++++++++++++++-
arch/powerpc/platforms/pseries/xics.c | 48 -----------------------------
arch/powerpc/platforms/pseries/xics.h | 3 --
3 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index fdb9b1c..43e4801 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -127,6 +127,51 @@ void pseries_8259_cascade(unsigned int irq, struct irq_desc *desc)
desc->chip->eoi(irq);
}
+static void __init xics_setup_8259_cascade(void)
+{
+ struct device_node *np, *old, *found = NULL;
+ int cascade, naddr;
+ const u32 *addrp;
+ unsigned long intack = 0;
+
+ for_each_node_by_type(np, "interrupt-controller")
+ if (of_device_is_compatible(np, "chrp,iic")) {
+ found = np;
+ break;
+ }
+ if (found == NULL) {
+ printk(KERN_DEBUG "xics: no ISA interrupt controller\n");
+ return;
+ }
+ cascade = irq_of_parse_and_map(found, 0);
+ if (cascade == NO_IRQ) {
+ printk(KERN_ERR "xics: failed to map cascade interrupt");
+ return;
+ }
+ pr_debug("xics: cascade mapped to irq %d\n", cascade);
+
+ for (old = of_node_get(found); old != NULL ; old = np) {
+ np = of_get_parent(old);
+ of_node_put(old);
+ if (np == NULL)
+ break;
+ if (strcmp(np->name, "pci") != 0)
+ continue;
+ addrp = of_get_property(np, "8259-interrupt-acknowledge", NULL);
+ if (addrp == NULL)
+ continue;
+ naddr = of_n_addr_cells(np);
+ intack = addrp[naddr-1];
+ if (naddr > 1)
+ intack |= ((unsigned long)addrp[naddr-2]) << 32;
+ }
+ if (intack)
+ printk(KERN_DEBUG "xics: PCI 8259 intack at 0x%016lx\n", intack);
+ i8259_init(found, intack);
+ of_node_put(found);
+ set_irq_chained_handler(cascade, pseries_8259_cascade);
+}
+
static void __init pseries_mpic_init_IRQ(void)
{
struct device_node *np, *old, *cascade = NULL;
@@ -206,6 +251,12 @@ static void __init pseries_mpic_init_IRQ(void)
set_irq_chained_handler(cascade_irq, pseries_8259_cascade);
}
+static void __init pseries_xics_init_IRQ(void)
+{
+ xics_init_IRQ();
+ xics_setup_8259_cascade();
+}
+
static void pseries_lpar_enable_pmcs(void)
{
unsigned long set, reset;
@@ -235,7 +286,7 @@ static void __init pseries_discover_pic(void)
smp_init_pseries_mpic();
return;
} else if (strstr(typep, "ppc-xicp")) {
- ppc_md.init_IRQ = xics_init_IRQ;
+ ppc_md.init_IRQ = pseries_xics_init_IRQ;
setup_kexec_cpu_down_xics();
smp_init_pseries_xics();
return;
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index ca52b58..5a72f27 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -655,52 +655,6 @@ static void __init xics_init_one_node(struct device_node *np,
}
}
-
-static void __init xics_setup_8259_cascade(void)
-{
- struct device_node *np, *old, *found = NULL;
- int cascade, naddr;
- const u32 *addrp;
- unsigned long intack = 0;
-
- for_each_node_by_type(np, "interrupt-controller")
- if (of_device_is_compatible(np, "chrp,iic")) {
- found = np;
- break;
- }
- if (found == NULL) {
- printk(KERN_DEBUG "xics: no ISA interrupt controller\n");
- return;
- }
- cascade = irq_of_parse_and_map(found, 0);
- if (cascade == NO_IRQ) {
- printk(KERN_ERR "xics: failed to map cascade interrupt");
- return;
- }
- pr_debug("xics: cascade mapped to irq %d\n", cascade);
-
- for (old = of_node_get(found); old != NULL ; old = np) {
- np = of_get_parent(old);
- of_node_put(old);
- if (np == NULL)
- break;
- if (strcmp(np->name, "pci") != 0)
- continue;
- addrp = of_get_property(np, "8259-interrupt-acknowledge", NULL);
- if (addrp == NULL)
- continue;
- naddr = of_n_addr_cells(np);
- intack = addrp[naddr-1];
- if (naddr > 1)
- intack |= ((unsigned long)addrp[naddr-2]) << 32;
- }
- if (intack)
- printk(KERN_DEBUG "xics: PCI 8259 intack at 0x%016lx\n", intack);
- i8259_init(found, intack);
- of_node_put(found);
- set_irq_chained_handler(cascade, pseries_8259_cascade);
-}
-
void __init xics_init_IRQ(void)
{
struct device_node *np;
@@ -733,8 +687,6 @@ void __init xics_init_IRQ(void)
xics_setup_cpu();
- xics_setup_8259_cascade();
-
ppc64_boot_msg(0x21, "XICS Done");
}
diff --git a/arch/powerpc/platforms/pseries/xics.h b/arch/powerpc/platforms/pseries/xics.h
index c26bcff..1c5321a 100644
--- a/arch/powerpc/platforms/pseries/xics.h
+++ b/arch/powerpc/platforms/pseries/xics.h
@@ -28,7 +28,4 @@ struct xics_ipi_struct {
extern struct xics_ipi_struct xics_ipi_message[NR_CPUS] __cacheline_aligned;
-struct irq_desc;
-extern void pseries_8259_cascade(unsigned int irq, struct irq_desc *desc);
-
#endif /* _POWERPC_KERNEL_XICS_H */
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [RFC/PATCH 2/4] Turn xics_setup_8259_cascade() into a generic pseries_setup_i8259_cascade()
From: Michael Ellerman @ 2008-04-01 6:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <6840627eab063b5246ec661968986a4ae2d7be61.1207032121.git.michael@ellerman.id.au>
Remove the xics references from xics_setup_8259_cascade(), and merge the
good bits from the almost identical logic in pseries_mpic_init_IRQ().
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/setup.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 43e4801..1e1faa1 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -127,28 +127,32 @@ void pseries_8259_cascade(unsigned int irq, struct irq_desc *desc)
desc->chip->eoi(irq);
}
-static void __init xics_setup_8259_cascade(void)
+static void __init pseries_setup_i8259_cascade(void)
{
struct device_node *np, *old, *found = NULL;
- int cascade, naddr;
+ unsigned int cascade;
const u32 *addrp;
unsigned long intack = 0;
+ int naddr;
- for_each_node_by_type(np, "interrupt-controller")
+ for_each_node_by_type(np, "interrupt-controller") {
if (of_device_is_compatible(np, "chrp,iic")) {
found = np;
break;
}
+ }
+
if (found == NULL) {
- printk(KERN_DEBUG "xics: no ISA interrupt controller\n");
+ printk(KERN_DEBUG "pic: no ISA interrupt controller\n");
return;
}
+
cascade = irq_of_parse_and_map(found, 0);
if (cascade == NO_IRQ) {
- printk(KERN_ERR "xics: failed to map cascade interrupt");
+ printk(KERN_ERR "pic: failed to map cascade interrupt");
return;
}
- pr_debug("xics: cascade mapped to irq %d\n", cascade);
+ pr_debug("pic: cascade mapped to irq %d\n", cascade);
for (old = of_node_get(found); old != NULL ; old = np) {
np = of_get_parent(old);
@@ -166,7 +170,7 @@ static void __init xics_setup_8259_cascade(void)
intack |= ((unsigned long)addrp[naddr-2]) << 32;
}
if (intack)
- printk(KERN_DEBUG "xics: PCI 8259 intack at 0x%016lx\n", intack);
+ printk(KERN_DEBUG "pic: PCI 8259 intack at 0x%016lx\n", intack);
i8259_init(found, intack);
of_node_put(found);
set_irq_chained_handler(cascade, pseries_8259_cascade);
@@ -254,7 +258,7 @@ static void __init pseries_mpic_init_IRQ(void)
static void __init pseries_xics_init_IRQ(void)
{
xics_init_IRQ();
- xics_setup_8259_cascade();
+ pseries_setup_i8259_cascade();
}
static void pseries_lpar_enable_pmcs(void)
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [RFC/PATCH 3/4] Use pseries_setup_i8259_cascade() in pseries_mpic_init_IRQ()
From: Michael Ellerman @ 2008-04-01 6:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <6840627eab063b5246ec661968986a4ae2d7be61.1207032121.git.michael@ellerman.id.au>
pseries_mpic_init_IRQ() implements the same logic as the xics code did to
find the i8259 cascade irq. Now that we've pulled that logic out into
pseries_setup_i8259_cascade() we can use it in the mpic code.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/setup.c | 43 +------------------------------
1 files changed, 2 insertions(+), 41 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 1e1faa1..22c047c 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -178,12 +178,9 @@ static void __init pseries_setup_i8259_cascade(void)
static void __init pseries_mpic_init_IRQ(void)
{
- struct device_node *np, *old, *cascade = NULL;
- const unsigned int *addrp;
- unsigned long intack = 0;
+ struct device_node *np;
const unsigned int *opprop;
unsigned long openpic_addr = 0;
- unsigned int cascade_irq;
int naddr, n, i, opplen;
struct mpic *mpic;
@@ -216,43 +213,7 @@ static void __init pseries_mpic_init_IRQ(void)
mpic_init(mpic);
/* Look for cascade */
- for_each_node_by_type(np, "interrupt-controller")
- if (of_device_is_compatible(np, "chrp,iic")) {
- cascade = np;
- break;
- }
- if (cascade == NULL)
- return;
-
- cascade_irq = irq_of_parse_and_map(cascade, 0);
- if (cascade_irq == NO_IRQ) {
- printk(KERN_ERR "mpic: failed to map cascade interrupt");
- return;
- }
-
- /* Check ACK type */
- for (old = of_node_get(cascade); old != NULL ; old = np) {
- np = of_get_parent(old);
- of_node_put(old);
- if (np == NULL)
- break;
- if (strcmp(np->name, "pci") != 0)
- continue;
- addrp = of_get_property(np, "8259-interrupt-acknowledge",
- NULL);
- if (addrp == NULL)
- continue;
- naddr = of_n_addr_cells(np);
- intack = addrp[naddr-1];
- if (naddr > 1)
- intack |= ((unsigned long)addrp[naddr-2]) << 32;
- }
- if (intack)
- printk(KERN_DEBUG "mpic: PCI 8259 intack at 0x%016lx\n",
- intack);
- i8259_init(cascade, intack);
- of_node_put(cascade);
- set_irq_chained_handler(cascade_irq, pseries_8259_cascade);
+ pseries_setup_i8259_cascade();
}
static void __init pseries_xics_init_IRQ(void)
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* [RFC/PATCH 4/4] Simplify xics direct/lpar irq_host setup
From: Michael Ellerman @ 2008-04-01 6:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <6840627eab063b5246ec661968986a4ae2d7be61.1207032121.git.michael@ellerman.id.au>
The xics code currently has a direct and lpar variant of xics_host_map, the
only difference being which irq_chip they use. If we remember which irq_chip
we're using we can combine these two routines. That also allows us to have a
single irq_host_ops instead of two.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/pseries/xics.c | 39 ++++++++++----------------------
1 files changed, 12 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index 5a72f27..2fd8088 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -516,6 +516,8 @@ static struct irq_chip xics_pic_lpar = {
.set_affinity = xics_set_affinity
};
+/* Points to the irq_chip we're actually using */
+static struct irq_chip *xics_irq_chip;
static int xics_host_match(struct irq_host *h, struct device_node *node)
{
@@ -526,23 +528,13 @@ static int xics_host_match(struct irq_host *h, struct device_node *node)
return !of_device_is_compatible(node, "chrp,iic");
}
-static int xics_host_map_direct(struct irq_host *h, unsigned int virq,
- irq_hw_number_t hw)
+static int xics_host_map(struct irq_host *h, unsigned int virq,
+ irq_hw_number_t hw)
{
- pr_debug("xics: map_direct virq %d, hwirq 0x%lx\n", virq, hw);
+ pr_debug("xics: map virq %d, hwirq 0x%lx\n", virq, hw);
get_irq_desc(virq)->status |= IRQ_LEVEL;
- set_irq_chip_and_handler(virq, &xics_pic_direct, handle_fasteoi_irq);
- return 0;
-}
-
-static int xics_host_map_lpar(struct irq_host *h, unsigned int virq,
- irq_hw_number_t hw)
-{
- pr_debug("xics: map_direct virq %d, hwirq 0x%lx\n", virq, hw);
-
- get_irq_desc(virq)->status |= IRQ_LEVEL;
- set_irq_chip_and_handler(virq, &xics_pic_lpar, handle_fasteoi_irq);
+ set_irq_chip_and_handler(virq, xics_irq_chip, handle_fasteoi_irq);
return 0;
}
@@ -561,27 +553,20 @@ static int xics_host_xlate(struct irq_host *h, struct device_node *ct,
return 0;
}
-static struct irq_host_ops xics_host_direct_ops = {
+static struct irq_host_ops xics_host_ops = {
.match = xics_host_match,
- .map = xics_host_map_direct,
- .xlate = xics_host_xlate,
-};
-
-static struct irq_host_ops xics_host_lpar_ops = {
- .match = xics_host_match,
- .map = xics_host_map_lpar,
+ .map = xics_host_map,
.xlate = xics_host_xlate,
};
static void __init xics_init_host(void)
{
- struct irq_host_ops *ops;
-
if (firmware_has_feature(FW_FEATURE_LPAR))
- ops = &xics_host_lpar_ops;
+ xics_irq_chip = &xics_pic_lpar;
else
- ops = &xics_host_direct_ops;
- xics_host = irq_alloc_host(NULL, IRQ_HOST_MAP_TREE, 0, ops,
+ xics_irq_chip = &xics_pic_direct;
+
+ xics_host = irq_alloc_host(NULL, IRQ_HOST_MAP_TREE, 0, &xics_host_ops,
XICS_IRQ_SPURIOUS);
BUG_ON(xics_host == NULL);
irq_set_default_host(xics_host);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* Re: [PATCH] Make #include <sysdev/foo.h> work for 64-bit powerpc
From: Stephen Rothwell @ 2008-04-01 6:54 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <be85035fa2cb015a8020e63b40c6d5375aaff866.1207031915.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 428 bytes --]
Hi Michael,
On Tue, 1 Apr 2008 17:39:11 +1100 (EST) Michael Ellerman <michael@ellerman.id.au> wrote:
>
> We currently have inconsistent settings between 32 & 64-bit which means
> 32-bit code can #include <sysdev/foo.h> but 64-bit code can't.
Kumar sent a very similar (if not identical) patch earlier today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Patch: FW:Xilinx: BSP: Updated ML405 to matchhardwareusedfortesting
From: Guillaume Dargaud @ 2008-04-01 7:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080328160614.6018DF68050@mail116-sin.bigfish.com>
>> I should add that I've tried several things:
>> - compile the Xilinx kernel as indicated in my previous message.
>> - compile it with just the xparameters_ml*.h files added
>
> This should work.
It doesn't... Which makes me wonder if my problem may be with the boot
itself.
Once I have my zImage properly (?) compiled, I create an ACE file thus:
$ xmd -tcl genace.tcl -jprog -board ml405 -target ppc_hw -hw system.bit -elf
zImage -ace Kernel26.ace
But then nothing happens when I boot with it.
[...]
>> .config:773:warning: trying to assign nonexistent symbol XILINX_ML40x
>
> Did you check out the head of the tree?
You mean svn head ? Yes.
Something escapes me here. I pull the complete kernel git tree from Xilinx
and
when I menuconfig it, it removes the Xilinx additions ('nonexistent symbol
')...
I'm not very knowledgeable of the kernel organization, so I don't know what
this means, but I imagine there's a relation between 'XILINX_ML40x=y' in
.config, Kconfig which holds the help text and the .h/.c driver files
themselves. How can I check that the whole package is sane ?
>> Two more things:
>>
>> $ make ARCH=ppc ml405_defconfig
>> cp .config
>> cp: missing destination file operand after `.config'
>> Try `cp --help' for more information.
>> make: *** [ml405_defconfig] Error 1
>
> I'd suggest starting over with a fresh tree.
> 1) Copy the xparameters file, overwriting the appropriate xparameters
> file in the git tree.
> 2) make ARCH=ppc ml405_defconfig
> 3) make ARCH=ppc all
One detail, I'm not doing 'make' from the kernel directory, but from the
buildroot directory, this way I'm sure it's compiled with the appropriate
cross-compiler and environment. Maybe targets such as ml405_defconfig are
not transmitted properly from one make to the other. Anyone who knows
buildroot care to
comment on that ?
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: [PATCHv2] powerpc: Describe memory-mapped RAM&ROM chips OF bindings
From: Laurent Pinchart @ 2008-04-01 8:47 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <47F11A19.4050305@ru.mvista.com>
On Monday 31 March 2008 19:06, Sergei Shtylyov wrote:
> Hello.
>=20
> Laurent Pinchart wrote:
>=20
> > Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> > ---
> > Documentation/powerpc/booting-without-of.txt | 13 ++++++++++++-
> > 1 files changed, 12 insertions(+), 1 deletions(-)
> >=20
> > diff --git a/Documentation/powerpc/booting-without-of.txt=20
b/Documentation/powerpc/booting-without-of.txt
> > index 7b4e8a7..3e1963b 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -57,7 +57,8 @@ Table of Contents
> > n) 4xx/Axon EMAC ethernet nodes
> > o) Xilinx IP cores
> > p) Freescale Synchronous Serial Interface
> > - q) USB EHCI controllers
> > + q) USB EHCI controllers
> > + r) Memory-mapped RAM & ROM
>=20
> Memory-mapped RA/RO Memory again? Should better drop this. :-)
You're quite picky, aren't you ? :-)
I suppose "Memory-mapped RA & RO" won't be accepted, so what about "Auxilia=
ry=20
RAM & ROM" ?
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: Ethernet Jumbo Frames
From: Norbert van Bolhuis @ 2008-04-01 8:54 UTC (permalink / raw)
To: LinuxPPC-Embedded; +Cc: Darcy Watkins
In-Reply-To: <D61182AC8012EA4EBC531B3AF23BE109582F00@tranzeo-mail2.12stewart.tranzeo.com>
We've done it for our 2.4 based kernel that runs on a Freescale MPC8270.
10/100/1000 doesn't really make any difference. For us the trick was to
support receving jumbo frames in multiple RX BufDescriptors (because our
MPC8270 FCC eth driver pre-allocates 2k buffers per RX BD).
For transmitting hardly any changes were necessary.
From linux (driver) standpoint there should be no problems,
the question is whether your ethernet MAC (IBM EMAC) properly supports it.
hth,
N. van Bolhuis.
Darcy Watkins wrote:
> Has anyone on this list ever been given a requirement to implement
> support for ethernet frames larger than the standard MTU of 1500? ...
>
> ... for normal 10/100 Ethernet? ... not gigabit.
>
> The application is to support certain encapsulation protocols without
> imposing smaller than 1500 byte MTU restrictions on the innermost
> protocol.
>
> I have been tasked to investigate this for a system based on PPC405EP.
> Can it be done using the IBM EMAC, Linux drivers, etc?
>
> Regards,
>
> Darcy
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
This message has been scanned for viruses and is believed to be clean
^ permalink raw reply
* Re: [PATCHv2] powerpc: Describe memory-mapped RAM&ROM chips OF bindings
From: Trent Piepho @ 2008-04-01 9:18 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, MTD mailing list
In-Reply-To: <200804011047.42971.laurentp@cse-semaphore.com>
On Tue, 1 Apr 2008, Laurent Pinchart wrote:
> On Monday 31 March 2008 19:06, Sergei Shtylyov wrote:
>>> p) Freescale Synchronous Serial Interface
>>> - q) USB EHCI controllers
>>> + q) USB EHCI controllers
>>> + r) Memory-mapped RAM & ROM
>>
>> Memory-mapped RA/RO Memory again? Should better drop this. :-)
>
> You're quite picky, aren't you ? :-)
>
> I suppose "Memory-mapped RA & RO" won't be accepted, so what about "Auxiliary
> RAM & ROM" ?
Direct-mapped?
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Paul Mackerras @ 2008-04-01 10:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1207015715-31496-2-git-send-email-galak@kernel.crashing.org>
Kumar Gala writes:
> Normally we assume kernel images will be loaded at offset 0. However
> there are situations, like when the kernel itself is running at a non-zero
> physical address, that we don't want to load it at 0.
>
> Allow the wrapper to take an offset. We use this when building u-boot images.
This makes it a bit harder to build a kernel and then wrap it later
on, since one would have to know what -m value to give. Would it
possible for either the wrapper script or mkimage to peek in the ELF
header of the vmlinux to work out what physical address to use?
Paul.
^ permalink raw reply
* Re: [PATCH 04/11 v2] [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
From: Paul Mackerras @ 2008-04-01 10:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1207015715-31496-5-git-send-email-galak@kernel.crashing.org>
Kumar Gala writes:
> For the sub-arches that support relocatable interrupt vectors (book-e) its
> reasonable to have memory start at a non-zero physical address. For those
> cases use the variable memstart_addr instead of the #define PPC_MEMSTART
> since the only uses of PPC_MEMSTART are for initialization and in the
> future we can set memstart_addr at runtime to have a relocatable kernel.
In those cases, is it still true that the kernel sits at the start of
the usable memory, or might there be usable memory before _stext?
In other words, is PAGE_OFFSET == KERNELBASE still true or not?
Paul.
^ permalink raw reply
* Commits added to powerpc.git master/powerpc-next branches
From: Paul Mackerras @ 2008-04-01 10:59 UTC (permalink / raw)
To: linuxppc-dev
I have updated the master and powerpc-next branches of the powerpc.git
repository with the following commits, including some pulled from Josh
Boyer and Kumar Gala.
Paul.
Alexandr Smirnov (4):
[POWERPC] 85xx: Emerson KSI8560 base support
[POWERPC] 85xx: Emerson KSI8560 bootwrapper
[POWERPC] 85xx: Emerson KSI8560 default config
[POWERPC] 85xx: Emerson KSI8560 device tree
Badari Pulavarty (1):
[POWERPC] Add error return from htab_remove_mapping()
David Gibson (1):
[POWERPC] Start removing linux,network-index in favour of aliases
Geert Uytterhoeven (4):
[POWERPC] PS3: Save power in busy loops on halt
[POWERPC] move_device_tree() should be __init
[POWERPC] arch_add_memory() cannot be __devinit
[POWERPC] PS3: Split device setup for static vs. dynamic devices
Geoff Levand (2):
[POWERPC] PS3: Bootwrapper improvements
[POWERPC] PS3: Sys-manager Wake-on-LAN support
Harvey Harrison (2):
[POWERPC] Replace remaining __FUNCTION__ occurrences
[POWERPC] ppc: Replace remaining __FUNCTION__ occurrences
Johannes Weiner (2):
[POWERPC] Remove redundant display of free swap space in show_mem()
[POWERPC] ppc: Remove redundant display of free swap space in show_mem()
Josh Boyer (3):
[POWERPC] 4xx: Add AMCC 440EP Yosemite DTS
[POWERPC] 4xx: Add platform support for the AMCC Yosemite board
[POWERPC] 4xx: Add bootwrapper for AMCC Yosemite board
Julia Lawall (1):
[POWERPC] Use FIELD_SIZEOF in drivers/block/viodasd.c
Masakazu Mokuno (1):
[POWERPC] PS3: Gelic network driver Wake-on-LAN support
Robert Brose (1):
[POWERPC] Add kernel parameter to set l3cr for MPC745x
Roel Kluin (1):
[POWERPC] PS3: Fix unlikely typo in ps3_get_irq
Stefan Roese (10):
[POWERPC] 4xx: Add AMCC 460EX/460GT support to cputable.c & cpu_setup_44x.S
[POWERPC] 4xx: Add AMCC Canyonlands 460EX eval board support to platforms/44x
[POWERPC] 4xx: Add Canyonlands DTS
[POWERPC] 4xx: Add 460EX PCIe support to 4xx pci driver
[POWERPC] 4xx: Add Canyonlands defconfig file
[POWERPC] 4xx: Add TAH support to taishan dts
[POWERPC] 4xx: Add AMCC Glacier 460GT eval board dts
[POWERPC] 4xx: Add "amcc, haleakala" to the toplevel compatible property
[POWERPC] 4xx: Add PPC4xx L2-cache support (440GX)
[POWERPC] 4xx: Add L2 cache node to AMCC Taishan dts file
Stephen Neuendorffer (3):
[POWERPC] Xilinx: hwicap: Refactor status handling code.
[POWERPC] Xilinx: hwicap: Verify sync before reading idcode.
[POWERPC] Xilinx: hwicap: Use fixed device major.
Takashi Yamamoto (1):
[POWERPC] PS3: Add ps3_get_speid routine
Valentine Barshak (2):
[POWERPC] 4xx: Add dcri_clrset() for locked read/modify/write functionality
[POWERPC] 4xx: Use dcri_clrset() for PCIe indirect dcr read/modify/write access
Documentation/kernel-parameters.txt | 2
Documentation/powerpc/booting-without-of.txt | 16
arch/powerpc/Kconfig | 3
arch/powerpc/boot/Makefile | 4
arch/powerpc/boot/bamboo.c | 3
arch/powerpc/boot/cuboot-rainier.c | 3
arch/powerpc/boot/cuboot-sequoia.c | 3
arch/powerpc/boot/cuboot-taishan.c | 3
arch/powerpc/boot/cuboot-warp.c | 2
arch/powerpc/boot/cuboot-yosemite.c | 44 +
arch/powerpc/boot/dts/bamboo.dts | 2
arch/powerpc/boot/dts/canyonlands.dts | 391 +++++++++
arch/powerpc/boot/dts/ebony.dts | 2
arch/powerpc/boot/dts/glacier.dts | 464 +++++++++++
arch/powerpc/boot/dts/haleakala.dts | 2
arch/powerpc/boot/dts/ksi8560.dts | 267 ++++++
arch/powerpc/boot/dts/rainier.dts | 2
arch/powerpc/boot/dts/sequoia.dts | 2
arch/powerpc/boot/dts/taishan.dts | 27 +
arch/powerpc/boot/dts/walnut.dts | 1
arch/powerpc/boot/dts/warp.dts | 1
arch/powerpc/boot/dts/yosemite.dts | 304 +++++++
arch/powerpc/boot/ebony.c | 3
arch/powerpc/boot/libfdt-wrapper.c | 2
arch/powerpc/boot/ps3-head.S | 25 -
arch/powerpc/boot/ps3.c | 23 -
arch/powerpc/boot/treeboot-walnut.c | 2
arch/powerpc/boot/wrapper | 23 -
arch/powerpc/configs/canyonlands_defconfig | 721 +++++++++++++++++
arch/powerpc/configs/ksi8560_defconfig | 899 +++++++++++++++++++++
arch/powerpc/kernel/cpu_setup_44x.S | 5
arch/powerpc/kernel/cputable.c | 28 +
arch/powerpc/kernel/ibmebus.c | 12
arch/powerpc/kernel/iommu.c | 4
arch/powerpc/kernel/isa-bridge.c | 2
arch/powerpc/kernel/lparcfg.c | 12
arch/powerpc/kernel/prom.c | 2
arch/powerpc/kernel/rtas.c | 2
arch/powerpc/kernel/rtas_flash.c | 2
arch/powerpc/kernel/rtas_pci.c | 10
arch/powerpc/kernel/setup_32.c | 12
arch/powerpc/kernel/vio.c | 10
arch/powerpc/math-emu/fabs.c | 2
arch/powerpc/math-emu/fadd.c | 2
arch/powerpc/math-emu/fadds.c | 2
arch/powerpc/math-emu/fcmpo.c | 2
arch/powerpc/math-emu/fcmpu.c | 2
arch/powerpc/math-emu/fctiw.c | 2
arch/powerpc/math-emu/fctiwz.c | 2
arch/powerpc/math-emu/fdiv.c | 6
arch/powerpc/math-emu/fdivs.c | 6
arch/powerpc/math-emu/fmadd.c | 2
arch/powerpc/math-emu/fmadds.c | 2
arch/powerpc/math-emu/fmr.c | 2
arch/powerpc/math-emu/fmsub.c | 2
arch/powerpc/math-emu/fmsubs.c | 2
arch/powerpc/math-emu/fmul.c | 2
arch/powerpc/math-emu/fmuls.c | 2
arch/powerpc/math-emu/fnabs.c | 2
arch/powerpc/math-emu/fneg.c | 2
arch/powerpc/math-emu/fnmadd.c | 2
arch/powerpc/math-emu/fnmadds.c | 2
arch/powerpc/math-emu/fnmsub.c | 2
arch/powerpc/math-emu/fnmsubs.c | 2
arch/powerpc/math-emu/fres.c | 2
arch/powerpc/math-emu/frsp.c | 2
arch/powerpc/math-emu/frsqrte.c | 2
arch/powerpc/math-emu/fsel.c | 2
arch/powerpc/math-emu/fsqrt.c | 2
arch/powerpc/math-emu/fsqrts.c | 2
arch/powerpc/math-emu/fsub.c | 2
arch/powerpc/math-emu/fsubs.c | 2
arch/powerpc/math-emu/lfd.c | 2
arch/powerpc/math-emu/lfs.c | 2
arch/powerpc/math-emu/mcrfs.c | 4
arch/powerpc/math-emu/mffs.c | 2
arch/powerpc/math-emu/mtfsb0.c | 2
arch/powerpc/math-emu/mtfsb1.c | 2
arch/powerpc/math-emu/mtfsf.c | 2
arch/powerpc/math-emu/mtfsfi.c | 2
arch/powerpc/math-emu/stfd.c | 2
arch/powerpc/math-emu/stfiwx.c | 2
arch/powerpc/math-emu/stfs.c | 2
arch/powerpc/mm/hash_utils_64.c | 14
arch/powerpc/mm/init_32.c | 2
arch/powerpc/mm/init_64.c | 2
arch/powerpc/mm/mem.c | 3
arch/powerpc/oprofile/cell/spu_task_sync.c | 12
arch/powerpc/oprofile/cell/vma_map.c | 10
arch/powerpc/oprofile/op_model_cell.c | 14
arch/powerpc/platforms/44x/Kconfig | 28 +
arch/powerpc/platforms/44x/Makefile | 2
arch/powerpc/platforms/44x/canyonlands.c | 64 +
arch/powerpc/platforms/52xx/lite5200.c | 4
arch/powerpc/platforms/85xx/Kconfig | 7
arch/powerpc/platforms/85xx/Makefile | 1
arch/powerpc/platforms/85xx/ksi8560.c | 257 ++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 2
arch/powerpc/platforms/cell/iommu.c | 8
arch/powerpc/platforms/cell/pervasive.c | 2
arch/powerpc/platforms/cell/ras.c | 10
arch/powerpc/platforms/cell/spu_base.c | 8
arch/powerpc/platforms/cell/spu_callbacks.c | 2
arch/powerpc/platforms/cell/spu_manage.c | 8
arch/powerpc/platforms/cell/spufs/file.c | 4
arch/powerpc/platforms/cell/spufs/run.c | 10
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 10
arch/powerpc/platforms/ps3/device-init.c | 78 +-
arch/powerpc/platforms/ps3/interrupt.c | 2
arch/powerpc/platforms/ps3/setup.c | 14
arch/powerpc/platforms/ps3/spu.c | 7
arch/powerpc/platforms/pseries/pci_dlpar.c | 2
arch/powerpc/platforms/pseries/reconfig.c | 12
arch/powerpc/sysdev/Makefile | 1
arch/powerpc/sysdev/cpm1.c | 2
arch/powerpc/sysdev/cpm2.c | 2
arch/powerpc/sysdev/ppc4xx_pci.c | 127 +++
arch/powerpc/sysdev/ppc4xx_pci.h | 59 +
arch/powerpc/sysdev/ppc4xx_soc.c | 189 ++++
arch/powerpc/sysdev/qe_lib/qe_io.c | 2
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 32 -
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 18
arch/powerpc/sysdev/tsi108_dev.c | 4
arch/powerpc/sysdev/tsi108_pci.c | 4
arch/ppc/8xx_io/fec.c | 4
arch/ppc/mm/init.c | 1
arch/ppc/platforms/radstone_ppc7d.c | 8
drivers/block/viodasd.c | 2
drivers/char/xilinx_hwicap/buffer_icap.c | 22 -
drivers/char/xilinx_hwicap/buffer_icap.h | 5
drivers/char/xilinx_hwicap/fifo_icap.c | 31 +
drivers/char/xilinx_hwicap/fifo_icap.h | 1
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 63 +
drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 +
drivers/net/ps3_gelic_net.c | 81 ++
drivers/net/ps3_gelic_net.h | 20
drivers/ps3/ps3-sys-manager.c | 74 +-
drivers/ps3/sys-manager-core.c | 16
include/asm-powerpc/dcr-native.h | 17
include/asm-powerpc/dcr-regs.h | 78 ++
include/asm-powerpc/ps3.h | 7
include/asm-powerpc/sparsemem.h | 2
142 files changed, 4563 insertions(+), 371 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-yosemite.c
create mode 100644 arch/powerpc/boot/dts/canyonlands.dts
create mode 100644 arch/powerpc/boot/dts/glacier.dts
create mode 100644 arch/powerpc/boot/dts/ksi8560.dts
create mode 100644 arch/powerpc/boot/dts/yosemite.dts
create mode 100644 arch/powerpc/configs/canyonlands_defconfig
create mode 100644 arch/powerpc/configs/ksi8560_defconfig
create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
create mode 100644 arch/powerpc/platforms/85xx/ksi8560.c
create mode 100644 arch/powerpc/sysdev/ppc4xx_soc.c
^ permalink raw reply
* Re: [PATCH] Add idle power save for ppc 4xx
From: Josh Boyer @ 2008-04-01 11:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: kvm-ppc-devel, linuxppc-dev
In-Reply-To: <18417.45926.65587.820132@cargo.ozlabs.ibm.com>
On Tue, 1 Apr 2008 15:00:38 +1100
Paul Mackerras <paulus@samba.org> wrote:
> Josh Boyer writes:
>
> > Actually, you probably don't want this as a property in the device
> > tree. It doesn't describe hardware. A Kconfig option might be
> > warranted though.
>
> In general it is valid to have properties in the device tree that
> describe the hypervisor or the kernel's interface to it, since they
> are aspects of the platform, i.e. the virtual "hardware" that the
> kernel is running on.
Yep, we reached that conclusion already.
josh
^ permalink raw reply
* Re: Using FEC on a MPC5200 with default PHY configuration
From: Wolfgang Grandegger @ 2008-04-01 11:06 UTC (permalink / raw)
To: Grant Likely; +Cc: ppc-dev
In-Reply-To: <fa686aa40803310633w5f7ddbccq6960b38d00e9381d@mail.gmail.com>
Grant Likely wrote:
> On Mon, Mar 31, 2008 at 3:44 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Wolfgang Grandegger wrote:
>> > Hello,
>> >
>> > is it possible to use the FEC on a MPC5200 with the default hardware PHY
>> > configuration. I mean running the link with a default speed without
>> > handling or even touching the PHY like U-Boot does. I removed the PHY
>> > entries from the DTS file and disabled CONFIG_FEC_MPC52xx_MDIO but it
>> > did not work.
>>
>> To be more precise, I want to support a 3-Port managed switch with PHY
>> from Micrel using the direct switch link.
>
> I'm actually working on this exact problem at the moment. I'll get a
> patch out shortly to do so.
Great, if I can help with testing, please let me know.
Wolfgang.
^ permalink raw reply
* Re: [PATCHv3 2/4] cpm-serial: Relocate CPM buffer descriptors and SMC parameter ram.
From: Laurent Pinchart @ 2008-04-01 11:55 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47F13735.40207@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 3761 bytes --]
On Monday 31 March 2008 21:10, Scott Wood wrote:
> Laurent Pinchart wrote:
> > This patch relocates the buffer descriptors and the SMC parameter RAM at the
> > end of the first CPM muram chunk, as described in the device tree. This allows
> > device trees to stop excluding SMC parameter ram allocated by the boot loader
> > from the CPM muram node.
>
> It's usually a good idea to state that something is untested if that's
> the case. :-)
Sorry. I'll state it clearly next time.
> This patch cannot work as is.
>
> > +static int cpm_get_virtual_address(void *devp, void **addr, int ncells)
> > +{
> > + unsigned long xaddr;
> > + int n;
> > +
> > + n = getprop(devp, "virtual-reg", addr, ncells * sizeof *addr);
> > + if (n < ncells * sizeof *addr) {
>
> You must cast the sizeof to a signed int; otherwise, a negative return
> from getprop will be "bigger" than the unsigned size, and you'll return
> garbage as the address.
>
> > + for (n = 0; n < ncells; n++) {
> > + if (!dt_xlate_reg(devp, n, &xaddr, NULL))
> > + return -1;
> > +
> > + addr[n] = (void*)xaddr;
>
> (void *)
>
> > + }
> > + }
> > +
> > + return ncells;
> > +}
>
> This could be a generic bootwrapper function. It should return the
> number of resources (ncells is a misnomer) actually found, though,
> rather than failing if there are fewer than asked for. Let the caller
> decide if it's fatal.
Ok. I'll move it to devtree.c.
> > @@ -202,63 +243,62 @@ int cpm_console_init(void *devp, struct serial_console_data *scdp)
> > else
> > do_cmd = cpm1_cmd;
> >
> > - n = getprop(devp, "fsl,cpm-command", &cpm_cmd, 4);
> > - if (n < 4)
> > + if (getprop(devp, "fsl,cpm-command", &cpm_cmd, 4) < sizeof cpm_cmd)
> > return -1;
>
> Standard kernel style is sizeof(foo), not sizeof foo.
Ok.
> Plus, if you're going to replace 4 with sizeof(cpm_cmd), do it both
> places. I don't really see the need, though; a cell is always 4 bytes.
Ok, I'll keep 4.
> > - n = getprop(parent, "virtual-reg", reg_virt, sizeof(reg_virt));
> > - if (n < (int)sizeof(reg_virt)) {
> > - if (!dt_xlate_reg(parent, 0, ®_phys, NULL))
> > - return -1;
> > -
> > - reg_virt[0] = (void *)reg_phys;
> > - }
> > -
> > - cpcr = reg_virt[0];
> > + if (cpm_get_virtual_address(devp, &cpcr, 1) < 0)
> > + return -1;
>
> s/devp/parent/
>
> > muram = finddevice("/soc/cpm/muram/data");
> > if (!muram)
> > return -1;
> >
> > /* For bootwrapper-compatible device trees, we assume that the first
> > - * entry has at least 18 bytes, and that #address-cells/#data-cells
> > + * entry has at least 128 bytes, and that #address-cells/#data-cells
> > * is one for both parent and child.
> > */
> >
> > - n = getprop(muram, "virtual-reg", reg_virt, sizeof(reg_virt));
> > - if (n < (int)sizeof(reg_virt)) {
> > - if (!dt_xlate_reg(muram, 0, ®_phys, NULL))
> > - return -1;
> > + if (cpm_get_virtual_address(devp, &muram_addr, 1) < 0)
> > + return -1;
>
> s/devp/muram/
>
> > +
> > + if (getprop(muram, "reg", reg, sizeof reg) < sizeof reg)
> > + return -1;
>
> Should read into array of u32, not void *.
Ok.
> > + if (is_cpm2 && is_smc) {
> > + u16 *smc_base = (u16*)param;
>
> (u16 *)
>
> > + u16 pram_offset;
> >
> > - muram_start = reg_virt[0];
> > + pram_offset = cbd_offset - 64;
> > + pram_offset = _ALIGN_DOWN(pram_offset, 64);
> > + *smc_base = pram_offset;
>
> Use out_be16().
>
> The SMC should be stopped before you do this.
Right.
New patch comming.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox