* Re: RFC: MPC5200 PSC AC97 driver
From: Grant Likely @ 2008-04-19 16:03 UTC (permalink / raw)
To: Peter Czanik; +Cc: linuxppc-dev
In-Reply-To: <4808C1BE.1050607@fang.fa.gau.hu>
On Fri, Apr 18, 2008 at 9:43 AM, Peter Czanik <pczanik@fang.fa.gau.hu> wrote:
> Hello,
>
> factory:/usr/src/linux-2.6.25 # diff -u
> arch/powerpc/kernel/prom_init.c.orig arch/powerpc/kernel/prom_init.c
> --- arch/powerpc/kernel/prom_init.c.orig 2008-04-18
> 13:55:07.000000000 +0200
> +++ arch/powerpc/kernel/prom_init.c 2008-04-18 16:26:51.000000000 +0200
> @@ -2212,6 +2212,7 @@
>
> static void __init fixup_device_tree_efika(void)
> {
> + int sound_ci = 1;
> int sound_irq[3] = { 2, 2, 0 };
> int bcomm_irq[3*16] = { 3,0,0, 3,1,0, 3,2,0, 3,3,0,
> 3,4,0, 3,5,0, 3,6,0, 3,7,0,
> @@ -2257,6 +2258,8 @@
> rv = prom_getprop(node, "interrupts", prop, sizeof(prop));
> if (rv == PROM_ERROR) {
> prom_printf("Adding sound interrupts property\n");
> + prom_setprop(node, "/builtin/sound", "cell-index",
> + &sound_ci, sizeof(int));
> prom_setprop(node, "/builtin/sound", "interrupts",
> sound_irq, sizeof(sound_irq));
> }
This probably isn't the ideal solution; but I've got no objection to
bringing it in as a work around until someone can make the driver
cleaner.
However, this change needs to be more robust. It must first check if
the cell-index property already exists before trying to create it
(just like how adding the interrupts property works).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC/POWERPC] mpc5200: remove "mpc5200b-*" from compatible lists in dts files
From: Grant Likely @ 2008-04-19 16:23 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, m8
In-Reply-To: <50bbe43673e46cc8d3a02eb4c03d87e9@kernel.crashing.org>
On Sat, Apr 19, 2008 at 3:23 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> > The mpc5200b is a bug fix of the mpc5200 with a few incompatible changes.
> > By rights, the current dts trees are the most "correct", but in practical
> > purposes there is no value in the 5200b devices having 2 compatible
> > entries for each internal peripheral node. Freescale has done a good job
> > of documenting exactly where the incompatibilities lie, so it restrict
> > the extra compatible properties to devices with *documented* changes.
> >
>
> And what happens when later an "undocumented change" is found? The
> device tree should always list the exact version of device used, even
> if all clients (i.e., the Linux kernel) only use the less-specific
> "compatible" value; that way, if a need to distinguish arises later
> (e.g., a model-specific bug workaround), a client can detect the exact
> model of device without needing a new device tree (that the client in
> general has no control over).
Yes, I fully agree and understand that. However, even that doesn't
fully solve the problem. At what level do you stop trying to describe
the device versions in the device tree? What about the case where an
earlier silicon version has an undocumented errata? At some point,
compatible doesn't help us and we need to resort to looking at other
factors (like PVR/SVR) to determine what the device really is.
Early on I decided to differentiate between the 5200 and the 5200b;
however, from a practical sense they really are the same part and
there is no practical advantage to differentiating between them.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Add compat handler for PTRACE_GETSIGINFO
From: Andreas Schwab @ 2008-04-19 16:25 UTC (permalink / raw)
To: linuxppc-dev
Current versions of gdb require a working implementation of
PTRACE_GETSIGINFO for proper watchpoint support. Since struct siginfo
contains pointers it must be converted when passed to a 32-bit debugger.
Signed-off-by: Andreas Schwab <schwab@suse.de>
---
arch/powerpc/kernel/ppc32.h | 2 ++
arch/powerpc/kernel/ptrace32.c | 27 +++++++++++++++++++++++++++
2 files changed, 29 insertions(+)
--- linux-2.6.25.orig/arch/powerpc/kernel/ppc32.h 2006-01-03 17:04:01.000000000 +0100
+++ linux-2.6.25/arch/powerpc/kernel/ppc32.h 2008-04-18 19:28:55.000000000 +0200
@@ -135,4 +135,6 @@ struct ucontext32 {
struct mcontext32 uc_mcontext;
};
+extern int copy_siginfo_to_user32(struct compat_siginfo __user *d, siginfo_t *s);
+
#endif /* _PPC64_PPC32_H */
--- linux-2.6.25.orig/arch/powerpc/kernel/ptrace32.c 2008-02-11 19:12:25.000000000 +0100
+++ linux-2.6.25/arch/powerpc/kernel/ptrace32.c 2008-04-18 19:31:20.000000000 +0200
@@ -29,12 +29,15 @@
#include <linux/security.h>
#include <linux/signal.h>
#include <linux/compat.h>
+#include <linux/elf.h>
#include <asm/uaccess.h>
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/system.h>
+#include "ppc32.h"
+
/*
* does not yet catch signals sent when the child dies.
* in exit.c or in signal.c.
@@ -64,6 +67,27 @@ static long compat_ptrace_old(struct tas
return -EPERM;
}
+static int compat_ptrace_getsiginfo(struct task_struct *child, compat_siginfo_t __user *data)
+{
+ siginfo_t lastinfo;
+ int error = -ESRCH;
+
+ read_lock(&tasklist_lock);
+ if (likely(child->sighand != NULL)) {
+ error = -EINVAL;
+ spin_lock_irq(&child->sighand->siglock);
+ if (likely(child->last_siginfo != NULL)) {
+ lastinfo = *child->last_siginfo;
+ error = 0;
+ }
+ spin_unlock_irq(&child->sighand->siglock);
+ }
+ read_unlock(&tasklist_lock);
+ if (!error)
+ return copy_siginfo_to_user32(data, &lastinfo);
+ return error;
+}
+
long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
{
@@ -282,6 +306,9 @@ long compat_arch_ptrace(struct task_stru
0, PT_REGS_COUNT * sizeof(compat_long_t),
compat_ptr(data));
+ case PTRACE_GETSIGINFO:
+ return compat_ptrace_getsiginfo(child, compat_ptr(data));
+
case PTRACE_GETFPREGS:
case PTRACE_SETFPREGS:
case PTRACE_GETVRREGS:
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Grant Likely @ 2008-04-19 16:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, LinuxPPC-Embedded
In-Reply-To: <D713F373-AE2A-4341-9C29-EF65B9399B36@kernel.crashing.org>
On Sat, Apr 19, 2008 at 9:30 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> This is intended as a reminder that we plan on getting rid of arch/ppc this
> summer. I'm guessing based on kernel release times that will be 2.6.27.
> That would mean 2.6.26 will be the last kernel to support arch/ppc.
>
> If people have boards that like ported over please let us know and work
> with us to port this over to arch/powerpc.
>
> Here is a list based on arch/ppc/platforms. Its not intended to be
> complete but a general idea of what's left in arch/ppc.
>
> LITE5200 52xx
This is in arch/powerpc
> XILINX_ML300 40x
> XILINX_ML403 40x
These are also supported in arch/powerpc; we just don't have .dts
files for the reference designs merged yet.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jochen Friedrich @ 2008-04-19 16:43 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev list, Alessandro Zummo, i2c, rtc-linux
In-Reply-To: <20080419162358.746b714c@hyperion.delvare>
Jean Delvare wrote:
> On Sat, 19 Apr 2008 15:09:55 +0200, Jochen Friedrich wrote:
>> Hi Jean,
>>
>>>>> Is the new-style driver conversion patch in 2.6.25-rc8-mm2 scheduled for
>>>>> 2.6.26 ?
>>>> hope so! :)
>>> Note that this patch depends on i2c patches which aren't upstream yet.
>> Is there any chance they will got to 2.6.26?
>
> I'm not sure. I didn't have the time to look at it myself, but I am
> under the impression that the powerpc folks are tired of having to wait
> for me and may push it to Linus through their tree? That would be fine
> with me, as I don't want to be the one delaying something many
> developers want (but I also can't sign patches I've not even read.)
The required patches are:
http://patchwork.ozlabs.org/linuxppc/patch?id=17833
http://patchwork.ozlabs.org/linuxppc/patch?id=17834
which are just the forward ported patches you sent to the poweprc mailing list some time ago:
http://patchwork.ozlabs.org/linuxppc/patch?id=16282
http://patchwork.ozlabs.org/linuxppc/patch?id=16283
Thanks,
Jochen
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Josh Boyer @ 2008-04-19 18:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, LinuxPPC-Embedded
In-Reply-To: <D713F373-AE2A-4341-9C29-EF65B9399B36@kernel.crashing.org>
On Sat, 2008-04-19 at 10:30 -0500, Kumar Gala wrote:
> This is intended as a reminder that we plan on getting rid of arch/ppc
> this summer. I'm guessing based on kernel release times that will be
> 2.6.27. That would mean 2.6.26 will be the last kernel to support
> arch/ppc.
>
> If people have boards that like ported over please let us know and
> work with us to port this over to arch/powerpc.
>
> Here is a list based on arch/ppc/platforms. Its not intended to be
> complete but a general idea of what's left in arch/ppc.
>
<snip>
> OCOTEA 44x
I have one of these. I'll port it eventually.
josh
^ permalink raw reply
* Re: [PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
From: Grant Likely @ 2008-04-19 18:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804191051420.20132@blarg.am.freescale.net>
On Sat, Apr 19, 2008 at 9:52 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> We have a board port in arch/powerpc so we dont need this one anymore.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Personally, I'd rather not do the piecemeal removal of board ports
from arch/ppc. We've only got one release left anyway. Removing them
just generates more churn and has the risk of causing other side
effects.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format
From: Matt Sealey @ 2008-04-19 18:49 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev, m8, Sascha Hauer, Wolfram Sang
In-Reply-To: <20080419133658.GJ13814@pengutronix.de>
I wholeheartedly agree, although the difference between gpt and timer
and pic vs interrupt-controller (actually interrupt-controller is meant
to be a property of the interrupt controller, not a device type.. weird)
was chosen because they did not conflict with what might be considered
"standard device_types" with real OF (Forth, CIS) interfaces like read,
write, ping, world-peace etc.
However since Linux doesn't care about the interface provided by the
firmware and only reads the tree, and real OF interfaces MIGHT need
to be provided by these items on real OF firmwares, I don't see why
they should not be used.
A problem arises; how do you decide when you name something after what
it is rather than the documentation acronym? What does the 5200B CDM
turn into? The XLB arbiter module? What about the rest of the SIU?
There really needs to be a standards committee for this, that has good
experience with device trees and BSPs, and can work with the device
vendors and board manufacturers (Freescale for example) directly, with
them on the committee, who can give the docs a run though before any
board ever hits the streets...
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Robert Schwebel wrote:
> On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote:
>> Update dts files to current format
>
> Is it somehow possible that this device tree stuff is *not* changed over
> and over again and break everything out there? When people have not even
> agreed on basic things like decimal vs. hex numbers, the whole idea
> should be developed out-of-tree, then stabilize and *then* be submitted
> to the Linux mainline.
>
> Is it also really necessary to change like "gpt" vs. "timer" and "pic"
> vs. "interrupt-controller" all the time? If you compare the last
> mainline kernels, each one got a fundamental change in the naming, each
> time breaking anyone who doesn't have his stuff in the mainline yet.
>
> Sorry, but this is simply annoying, and the whole "the only thing we
> have to do is to define it once and be done then" is crap.
>
> Robert
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Chuck Meade @ 2008-04-19 20:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <D713F373-AE2A-4341-9C29-EF65B9399B36@kernel.crashing.org>
> This is intended as a reminder that we plan on getting rid of arch/ppc
> this summer. I'm guessing based on kernel release times that will be
> 2.6.27. That would mean 2.6.26 will be the last kernel to support
> arch/ppc.
>
> If people have boards that like ported over please let us know and
> work with us to port this over to arch/powerpc.
>
> Here is a list based on arch/ppc/platforms. Its not intended to be
> complete but a general idea of what's left in arch/ppc.
It would be nice to see the mbx860 get forward-ported. I just have not
had any time to get to it.
Chuck
^ permalink raw reply
* [PATCH] powerpc copy_siginfo_from_user32
From: Roland McGrath @ 2008-04-19 22:19 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard; +Cc: linuxppc-dev
Hi. I posted this before, but I don't see it in any of your powerpc.git
trees. Can you push this upstream ASAP? It would make life easier for me
trying to merge some more generic changes (that would break powerpc builds
without this going in first).
Thanks,
Roland
---
[PATCH] powerpc copy_siginfo_from_user32
Define the copy_siginfo_from_user32 entry point for powerpc, so
that generic CONFIG_COMPAT code can call it. We already had the
code rolled into compat_sys_rt_sigqueueinfo, this just moves it
out into the canonical function that other arch's define.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/signal_32.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index d840bc7..ad69434 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -621,6 +621,18 @@ int copy_siginfo_to_user32(struct compat_siginfo __user *d, siginfo_t *s)
#define copy_siginfo_to_user copy_siginfo_to_user32
+int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from)
+{
+ memset(to, 0, sizeof *to);
+
+ if (copy_from_user(to, from, 3*sizeof(int)) ||
+ copy_from_user(to->_sifields._pad,
+ from->_sifields._pad, SI_PAD_SIZE32))
+ return -EFAULT;
+
+ return 0;
+}
+
/*
* Note: it is necessary to treat pid and sig as unsigned ints, with the
* corresponding cast to a signed int to insure that the proper conversion
@@ -634,9 +646,10 @@ long compat_sys_rt_sigqueueinfo(u32 pid, u32 sig, compat_siginfo_t __user *uinfo
int ret;
mm_segment_t old_fs = get_fs();
- if (copy_from_user (&info, uinfo, 3*sizeof(int)) ||
- copy_from_user (info._sifields._pad, uinfo->_sifields._pad, SI_PAD_SIZE32))
- return -EFAULT;
+ ret = copy_siginfo_from_user32(&info, uinfo);
+ if (unlikely(ret))
+ return ret;
+
set_fs (KERNEL_DS);
/* The __user pointer cast is valid becasuse of the set_fs() */
ret = sys_rt_sigqueueinfo((int)pid, (int)sig, (siginfo_t __user *) &info);
^ permalink raw reply related
* Re: removal of arch/ppc in 2.6.27?
From: Dwayne Fontenot @ 2008-04-20 0:39 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <D713F373-AE2A-4341-9C29-EF65B9399B36@kernel.crashing.org>
Kumar Gala <galak <at> kernel.crashing.org> writes:
>
> This is intended as a reminder that we plan on getting rid of arch/ppc
> this summer. I'm guessing based on kernel release times that will be
> 2.6.27. That would mean 2.6.26 will be the last kernel to support
> arch/ppc.
>
> If people have boards that like ported over please let us know and
> work with us to port this over to arch/powerpc.
>
> Here is a list based on arch/ppc/platforms. Its not intended to be
> complete but a general idea of what's left in arch/ppc.
>
...
> MVME5100 e6xx
I would very much like to see mvme5100 move to powerpc.
I'll help any way I can including trying to port it myself.
Is it significant that in arch/powerpc/platforms/prep/Kconfig
PPC_PREP depends on BROKEN ?
What are the implications of that?
Thanks,
Dwayne
^ permalink raw reply
* mpc8349, gb ethernet, bridging
From: R. Ebersole (VTI - new) @ 2008-04-20 5:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi.
We are having some issues regarding bridging the 2 ethernet ports of an
mpc8349, and are
trying to determine what is going on.
We are attempting to daisy-chain several mpc8349-based boards via the 2
ethernet ports
on each 8349. When we enable bridging for the units, we (sometimes)
start seeing the following
on one of the interior bridge's (mostly on the root bridge) console(s):
NETDEV WATCHDOG: eth1 : transmit timed out
We then see the bridge output messages that indicate that is is going
through a topology
state change.
This situation keeps recurring.
At some point, the message from the bridge that it is entering a
disabled state for port #2
(eth1) is followed by garbage (actually, it appears to be some pointers
and/or memory
addresses printed out), and the system hangs.
We are using NAPI and the skbuff-recycling for the gianfar driver.
We use ring(s) of 32 buffers.
The gianfar's watchdog is set to 1Hz (once a seond ?)
We are not sure if/how affect things:
Port #1 of the 'root' bridge is attached directly to our LAN
Port #1 of the 'root' bridge runs at 10 Mbs
Port #2 of the 'root' bridge runs at 1Gbs
All other ports in the chain are 1Gbs
We are using CAT-5 cables for all connections
We have an application on each bridge in the chain that periodically
sends several hundred bytes
'up the chain', towards its head (ie, towards our LAN). This
application is typically running
when the issue is seen.
Setting the bridge's forwarding delay to 0 and hellotime to 6,000
helped, but did
not solve the issue.
???
--
Sometimes I feel like a red shirt in the Star Trek episode of life.
--
This message contains confidential information and is intended only for the
individual named. If you are not the intended recipient you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
^ permalink raw reply
* Re: [PATCH] [POWERPC KVM] Kconfig fixes
From: Avi Kivity @ 2008-04-20 7:35 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: kvm-devel, kvm-ppc-devel, linuxppc-dev
In-Reply-To: <a607ae1a7c8c4d674678.1208447016@localhost.localdomain>
Hollis Blanchard wrote:
> 1 file changed, 5 insertions(+), 6 deletions(-)
> arch/powerpc/kvm/Kconfig | 11 +++++------
>
>
> Don't allow building as a module (asm-offsets dependencies).
>
> Also, automatically select KVM_BOOKE_HOST until we better separate the guest
> and host layers.
>
>
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply
* Please pull powerpc.git master branch
From: Paul Mackerras @ 2008-04-20 11:03 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master
to get a powerpc update.
Thanks,
Paul.
Documentation/kernel-parameters.txt | 2
Documentation/powerpc/booting-without-of.txt | 622 +++++++++++++-
Documentation/powerpc/phyp-assisted-dump.txt | 127 +++
arch/powerpc/Kconfig | 82 +-
arch/powerpc/Kconfig.debug | 2
arch/powerpc/Makefile | 12
arch/powerpc/boot/Makefile | 40 +
arch/powerpc/boot/bamboo.c | 3
arch/powerpc/boot/cpm-serial.c | 117 ++-
arch/powerpc/boot/cuboot-pq2.c | 27 -
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/devtree.c | 20
arch/powerpc/boot/dts/bamboo.dts | 2
arch/powerpc/boot/dts/canyonlands.dts | 402 +++++++++
arch/powerpc/boot/dts/ebony.dts | 2
arch/powerpc/boot/dts/ep8248e.dts | 5
arch/powerpc/boot/dts/ep88xc.dts | 73 +-
arch/powerpc/boot/dts/glacier.dts | 467 ++++++++++
arch/powerpc/boot/dts/haleakala.dts | 4
arch/powerpc/boot/dts/katmai.dts | 2
arch/powerpc/boot/dts/kilauea.dts | 4
arch/powerpc/boot/dts/ksi8560.dts | 267 ++++++
arch/powerpc/boot/dts/kuroboxHD.dts | 83 +-
arch/powerpc/boot/dts/kuroboxHG.dts | 83 +-
arch/powerpc/boot/dts/makalu.dts | 4
arch/powerpc/boot/dts/mpc7448hpc2.dts | 97 +-
arch/powerpc/boot/dts/mpc8272ads.dts | 132 ++-
arch/powerpc/boot/dts/mpc832x_mds.dts | 7
arch/powerpc/boot/dts/mpc832x_rdb.dts | 4
arch/powerpc/boot/dts/mpc836x_mds.dts | 4
arch/powerpc/boot/dts/mpc8540ads.dts | 173 ++--
arch/powerpc/boot/dts/mpc8541cds.dts | 161 ++--
arch/powerpc/boot/dts/mpc8544ds.dts | 299 ++++---
arch/powerpc/boot/dts/mpc8548cds.dts | 289 +++---
arch/powerpc/boot/dts/mpc8555cds.dts | 161 ++--
arch/powerpc/boot/dts/mpc8560ads.dts | 209 ++---
arch/powerpc/boot/dts/mpc8568mds.dts | 291 +++----
arch/powerpc/boot/dts/mpc8572ds.dts | 383 ++++-----
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 2
arch/powerpc/boot/dts/mpc866ads.dts | 58 +
arch/powerpc/boot/dts/mpc885ads.dts | 77 +-
arch/powerpc/boot/dts/pq2fads.dts | 126 +--
arch/powerpc/boot/dts/prpmc2800.dts | 336 ++++----
arch/powerpc/boot/dts/rainier.dts | 6
arch/powerpc/boot/dts/sbc8641d.dts | 352 ++++++++
arch/powerpc/boot/dts/sequoia.dts | 6
arch/powerpc/boot/dts/taishan.dts | 31 +
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/mpc52xx-psc.c | 9
arch/powerpc/boot/mpsc.c | 2
arch/powerpc/boot/mv64x60.c | 4
arch/powerpc/boot/mv64x60_i2c.c | 2
arch/powerpc/boot/ns16550.c | 10
arch/powerpc/boot/ops.h | 1
arch/powerpc/boot/prpmc2800.c | 23 -
arch/powerpc/boot/ps3-head.S | 25 -
arch/powerpc/boot/ps3.c | 23 -
arch/powerpc/boot/serial.c | 2
arch/powerpc/boot/simpleboot.c | 84 ++
arch/powerpc/boot/treeboot-walnut.c | 2
arch/powerpc/boot/virtex405-head.S | 30 +
arch/powerpc/boot/wrapper | 32 -
arch/powerpc/configs/40x/ep405_defconfig | 0
arch/powerpc/configs/40x/kilauea_defconfig | 0
arch/powerpc/configs/40x/makalu_defconfig | 0
arch/powerpc/configs/40x/walnut_defconfig | 0
arch/powerpc/configs/44x/bamboo_defconfig | 0
arch/powerpc/configs/44x/canyonlands_defconfig | 138 ---
arch/powerpc/configs/44x/ebony_defconfig | 0
arch/powerpc/configs/44x/katmai_defconfig | 0
arch/powerpc/configs/44x/rainier_defconfig | 0
arch/powerpc/configs/44x/sequoia_defconfig | 0
arch/powerpc/configs/44x/taishan_defconfig | 0
arch/powerpc/configs/44x/warp_defconfig | 0
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 8
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 0
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 0
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 0
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 0
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 0
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 0
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 0
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 0
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 0
arch/powerpc/configs/83xx/sbc834x_defconfig | 0
arch/powerpc/configs/85xx/ksi8560_defconfig | 250 +++---
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 0
arch/powerpc/configs/85xx/mpc8544_ds_defconfig | 17
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 0
arch/powerpc/configs/85xx/mpc8568mds_defconfig | 0
arch/powerpc/configs/85xx/mpc8572_ds_defconfig | 0
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 0
arch/powerpc/configs/85xx/sbc8548_defconfig | 0
arch/powerpc/configs/85xx/sbc8560_defconfig | 0
arch/powerpc/configs/85xx/stx_gp3_defconfig | 0
arch/powerpc/configs/85xx/tqm8540_defconfig | 0
arch/powerpc/configs/85xx/tqm8541_defconfig | 0
arch/powerpc/configs/85xx/tqm8555_defconfig | 0
arch/powerpc/configs/85xx/tqm8560_defconfig | 0
arch/powerpc/configs/chrp32_defconfig | 7
arch/powerpc/configs/g5_defconfig | 7
arch/powerpc/configs/iseries_defconfig | 7
arch/powerpc/configs/maple_defconfig | 131 +++
arch/powerpc/configs/mpc83xx_defconfig | 164 ++++
arch/powerpc/configs/pmac32_defconfig | 7
arch/powerpc/configs/ppc40x_defconfig | 31 -
arch/powerpc/configs/ppc44x_defconfig | 14
arch/powerpc/configs/ppc64_defconfig | 8
arch/powerpc/configs/pseries_defconfig | 8
arch/powerpc/configs/sbc8641d_defconfig | 937 +++++++++++----------
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/asm-offsets.c | 10
arch/powerpc/kernel/btext.c | 3
arch/powerpc/kernel/cpu_setup_44x.S | 5
arch/powerpc/kernel/cputable.c | 28 +
arch/powerpc/kernel/crash.c | 3
arch/powerpc/kernel/crash_dump.c | 3
arch/powerpc/kernel/entry_32.S | 30 -
arch/powerpc/kernel/entry_64.S | 30 +
arch/powerpc/kernel/head_32.S | 22
arch/powerpc/kernel/head_44x.S | 4
arch/powerpc/kernel/head_64.S | 69 +-
arch/powerpc/kernel/head_booke.h | 33 -
arch/powerpc/kernel/head_fsl_booke.S | 44 +
arch/powerpc/kernel/ibmebus.c | 12
arch/powerpc/kernel/iommu.c | 4
arch/powerpc/kernel/irq.c | 18
arch/powerpc/kernel/isa-bridge.c | 6
arch/powerpc/kernel/lparcfg.c | 12
arch/powerpc/kernel/machine_kexec.c | 3
arch/powerpc/kernel/paca.c | 34 -
arch/powerpc/kernel/ppc32.h | 2
arch/powerpc/kernel/ppc_ksyms.c | 7
arch/powerpc/kernel/process.c | 33 -
arch/powerpc/kernel/prom.c | 120 ++-
arch/powerpc/kernel/prom_init.c | 8
arch/powerpc/kernel/ptrace32.c | 27 +
arch/powerpc/kernel/rtas.c | 4
arch/powerpc/kernel/rtas_flash.c | 2
arch/powerpc/kernel/rtas_pci.c | 29 -
arch/powerpc/kernel/setup-common.c | 11
arch/powerpc/kernel/setup_32.c | 14
arch/powerpc/kernel/setup_64.c | 8
arch/powerpc/kernel/signal_32.c | 19
arch/powerpc/kernel/stacktrace.c | 47 +
arch/powerpc/kernel/sys_ppc32.c | 5
arch/powerpc/kernel/vdso.c | 3
arch/powerpc/kernel/vio.c | 10
arch/powerpc/kernel/vmlinux.lds.S | 51 +
arch/powerpc/lib/rheap.c | 4
arch/powerpc/lib/string.S | 14
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/40x_mmu.c | 2
arch/powerpc/mm/44x_mmu.c | 2
arch/powerpc/mm/Makefile | 2
arch/powerpc/mm/fsl_booke_mmu.c | 48 -
arch/powerpc/mm/hash_utils_64.c | 32 +
arch/powerpc/mm/init_32.c | 27 -
arch/powerpc/mm/init_64.c | 7
arch/powerpc/mm/lmb.c | 357 --------
arch/powerpc/mm/mem.c | 21
arch/powerpc/mm/mmu_decl.h | 4
arch/powerpc/mm/numa.c | 3
arch/powerpc/mm/pgtable_32.c | 5
arch/powerpc/mm/ppc_mmu_32.c | 15
arch/powerpc/mm/stab.c | 4
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/40x/ep405.c | 2
arch/powerpc/platforms/40x/kilauea.c | 4
arch/powerpc/platforms/40x/makalu.c | 2
arch/powerpc/platforms/40x/virtex.c | 2
arch/powerpc/platforms/40x/walnut.c | 4
arch/powerpc/platforms/44x/44x.h | 1
arch/powerpc/platforms/44x/Kconfig | 27 +
arch/powerpc/platforms/44x/Makefile | 4
arch/powerpc/platforms/44x/bamboo.c | 15
arch/powerpc/platforms/44x/canyonlands.c | 63 +
arch/powerpc/platforms/44x/ebony.c | 5
arch/powerpc/platforms/44x/idle.c | 67 ++
arch/powerpc/platforms/44x/katmai.c | 5
arch/powerpc/platforms/44x/misc_44x.S | 11
arch/powerpc/platforms/44x/rainier.c | 4
arch/powerpc/platforms/44x/sequoia.c | 4
arch/powerpc/platforms/44x/taishan.c | 5
arch/powerpc/platforms/44x/warp-nand.c | 3
arch/powerpc/platforms/44x/warp.c | 6
arch/powerpc/platforms/52xx/lite5200.c | 4
arch/powerpc/platforms/82xx/Kconfig | 3
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 1
arch/powerpc/platforms/83xx/mpc83xx.h | 2
arch/powerpc/platforms/83xx/usb.c | 12
arch/powerpc/platforms/85xx/Kconfig | 13
arch/powerpc/platforms/85xx/Makefile | 1
arch/powerpc/platforms/85xx/ksi8560.c | 257 ++++++
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 2
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 15
arch/powerpc/platforms/86xx/Kconfig | 8
arch/powerpc/platforms/86xx/Makefile | 1
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 4
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14
arch/powerpc/platforms/86xx/sbc8641d.c | 164 ++++
arch/powerpc/platforms/8xx/Kconfig | 4
arch/powerpc/platforms/8xx/m8xx_setup.c | 7
arch/powerpc/platforms/Kconfig | 8
arch/powerpc/platforms/Kconfig.cputype | 2
arch/powerpc/platforms/cell/iommu.c | 10
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/coredump.c | 8
arch/powerpc/platforms/cell/spufs/file.c | 8
arch/powerpc/platforms/cell/spufs/run.c | 14
arch/powerpc/platforms/cell/spufs/switch.c | 2
arch/powerpc/platforms/celleb/beat.c | 17
arch/powerpc/platforms/celleb/beat.h | 4
arch/powerpc/platforms/celleb/beat_wrapper.h | 3
arch/powerpc/platforms/celleb/htab.c | 7
arch/powerpc/platforms/celleb/interrupt.c | 26 -
arch/powerpc/platforms/celleb/scc_epci.c | 8
arch/powerpc/platforms/celleb/scc_sio.c | 4
arch/powerpc/platforms/celleb/spu_priv1.c | 3
arch/powerpc/platforms/celleb/udbg_beat.c | 5
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 10
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 4
arch/powerpc/platforms/iseries/exception.S | 12
arch/powerpc/platforms/iseries/ipl_parms.h | 2
arch/powerpc/platforms/iseries/lpardata.c | 121 ++-
arch/powerpc/platforms/iseries/naca.h | 2
arch/powerpc/platforms/iseries/pci.c | 3
arch/powerpc/platforms/iseries/release_data.h | 2
arch/powerpc/platforms/iseries/spcomm_area.h | 2
arch/powerpc/platforms/iseries/vpd_areas.h | 4
arch/powerpc/platforms/maple/pci.c | 47 -
arch/powerpc/platforms/maple/setup.c | 4
arch/powerpc/platforms/pasemi/dma_lib.c | 144 +++
arch/powerpc/platforms/pasemi/iommu.c | 19
arch/powerpc/platforms/powermac/setup.c | 2
arch/powerpc/platforms/ps3/device-init.c | 78 +-
arch/powerpc/platforms/ps3/htab.c | 3
arch/powerpc/platforms/ps3/interrupt.c | 2
arch/powerpc/platforms/ps3/mm.c | 3
arch/powerpc/platforms/ps3/os-area.c | 3
arch/powerpc/platforms/ps3/setup.c | 14
arch/powerpc/platforms/ps3/spu.c | 7
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/eeh.c | 5
arch/powerpc/platforms/pseries/lpar.c | 25 -
arch/powerpc/platforms/pseries/pci_dlpar.c | 2
arch/powerpc/platforms/pseries/phyp_dump.c | 507 +++++++++++
arch/powerpc/platforms/pseries/pseries.h | 2
arch/powerpc/platforms/pseries/reconfig.c | 12
arch/powerpc/platforms/pseries/scanlog.c | 37 -
arch/powerpc/platforms/pseries/setup.c | 105 +-
arch/powerpc/platforms/pseries/xics.c | 87 --
arch/powerpc/platforms/pseries/xics.h | 3
arch/powerpc/sysdev/Makefile | 2
arch/powerpc/sysdev/cpm1.c | 114 ---
arch/powerpc/sysdev/cpm2.c | 105 --
arch/powerpc/sysdev/cpm_common.c | 3
arch/powerpc/sysdev/dart_iommu.c | 2
arch/powerpc/sysdev/fsl_lbc.c | 129 +++
arch/powerpc/sysdev/fsl_soc.c | 611 +-------------
arch/powerpc/sysdev/fsl_soc.h | 1
arch/powerpc/sysdev/mpic.c | 41 -
arch/powerpc/sysdev/mv64x60_dev.c | 78 +-
arch/powerpc/sysdev/mv64x60_pci.c | 6
arch/powerpc/sysdev/mv64x60_pic.c | 4
arch/powerpc/sysdev/mv64x60_udbg.c | 2
arch/powerpc/sysdev/ppc4xx_pci.c | 133 +++
arch/powerpc/sysdev/ppc4xx_pci.h | 59 +
arch/powerpc/sysdev/ppc4xx_soc.c | 200 ++++
arch/powerpc/sysdev/qe_lib/qe.c | 13
arch/powerpc/sysdev/qe_lib/qe_io.c | 7
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 32 -
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 18
arch/powerpc/sysdev/rtc_cmos_setup.c | 2
arch/powerpc/sysdev/tsi108_dev.c | 4
arch/powerpc/sysdev/tsi108_pci.c | 4
arch/powerpc/xmon/xmon.c | 24 -
arch/ppc/8xx_io/commproc.c | 2
arch/ppc/8xx_io/fec.c | 4
arch/ppc/kernel/head.S | 17
arch/ppc/mm/init.c | 1
arch/ppc/platforms/radstone_ppc7d.c | 8
arch/ppc/syslib/mpc52xx_setup.c | 2
arch/sparc64/Kconfig | 1
drivers/block/viodasd.c | 2
drivers/char/hvc_beat.c | 4
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/mtd/nand/fsl_elbc_nand.c | 219 -----
drivers/net/Makefile | 3
drivers/net/iseries_veth.c | 3
drivers/net/pasemi_mac.c | 355 +++++++-
drivers/net/pasemi_mac.h | 35 +
drivers/net/pasemi_mac_ethtool.c | 159 ++++
drivers/net/ps3_gelic_net.c | 81 ++
drivers/net/ps3_gelic_net.h | 20
drivers/net/ucc_geth.c | 8
drivers/net/ucc_geth_mii.c | 11
drivers/of/Kconfig | 12
drivers/of/Makefile | 2
drivers/of/base.c | 26 +
drivers/of/gpio.c | 242 +++++
drivers/of/of_i2c.c | 115 +++
drivers/ps3/ps3-sys-manager.c | 74 +-
drivers/ps3/sys-manager-core.c | 16
drivers/serial/cpm_uart/cpm_uart.h | 3
drivers/serial/cpm_uart/cpm_uart_core.c | 19
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 14
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 52 +
drivers/serial/of_serial.c | 4
drivers/serial/ucc_uart.c | 16
include/asm-powerpc/Kbuild | 2
include/asm-powerpc/abs_addr.h | 3
include/asm-powerpc/bitops.h | 32 -
include/asm-powerpc/cpm.h | 14
include/asm-powerpc/cpm1.h | 13
include/asm-powerpc/cpm2.h | 11
include/asm-powerpc/cputhreads.h | 2
include/asm-powerpc/dcr-native.h | 17
include/asm-powerpc/dcr-regs.h | 78 ++
include/asm-powerpc/exception.h | 6
include/asm-powerpc/fsl_lbc.h | 311 +++++++
include/asm-powerpc/gpio.h | 56 +
include/asm-powerpc/hw_irq.h | 13
include/asm-powerpc/immap_qe.h | 3
include/asm-powerpc/irqflags.h | 37 +
include/asm-powerpc/iseries/alpaca.h | 31 +
include/asm-powerpc/iseries/it_lp_reg_save.h | 85 --
include/asm-powerpc/lmb.h | 82 --
include/asm-powerpc/machdep.h | 5
include/asm-powerpc/macio.h | 2
include/asm-powerpc/mmu-40x.h | 2
include/asm-powerpc/mmu-44x.h | 2
include/asm-powerpc/mmu-8xx.h | 2
include/asm-powerpc/mmu-fsl-booke.h | 6
include/asm-powerpc/mmu-hash32.h | 2
include/asm-powerpc/mmu-hash64.h | 3
include/asm-powerpc/paca.h | 12
include/asm-powerpc/page.h | 1
include/asm-powerpc/page_32.h | 2
include/asm-powerpc/pasemi_dma.h | 77 ++
include/asm-powerpc/pci-bridge.h | 4
include/asm-powerpc/pgtable-ppc32.h | 8
include/asm-powerpc/phyp_dump.h | 47 +
include/asm-powerpc/pmi.h | 2
include/asm-powerpc/ppc4xx.h | 18
include/asm-powerpc/ps3.h | 7
include/asm-powerpc/ptrace.h | 9
include/asm-powerpc/qe.h | 12
include/asm-powerpc/rwsem.h | 35 +
include/asm-powerpc/sparsemem.h | 1
include/asm-powerpc/spinlock.h | 1
include/asm-powerpc/string.h | 2
include/asm-powerpc/system.h | 1
include/asm-powerpc/types.h | 7
include/asm-sparc64/lmb.h | 10
include/linux/lmb.h | 85 ++
include/linux/of.h | 1
include/linux/of_gpio.h | 69 ++
include/linux/of_i2c.h | 24 +
lib/Kconfig | 3
lib/Makefile | 2
lib/lmb.c | 428 ++++++++++
421 files changed, 11370 insertions(+), 5221 deletions(-)
create mode 100644 Documentation/powerpc/phyp-assisted-dump.txt
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/sbc8641d.dts
create mode 100644 arch/powerpc/boot/dts/yosemite.dts
create mode 100644 arch/powerpc/boot/simpleboot.c
create mode 100644 arch/powerpc/boot/virtex405-head.S
rename arch/powerpc/configs/{ep405_defconfig => 40x/ep405_defconfig} (100%)
rename arch/powerpc/configs/{kilauea_defconfig => 40x/kilauea_defconfig} (100%)
rename arch/powerpc/configs/{makalu_defconfig => 40x/makalu_defconfig} (100%)
copy arch/powerpc/configs/{walnut_defconfig => 40x/walnut_defconfig} (100%)
rename arch/powerpc/configs/{bamboo_defconfig => 44x/bamboo_defconfig} (100%)
copy arch/powerpc/configs/{taishan_defconfig => 44x/canyonlands_defconfig} (82%)
rename arch/powerpc/configs/{ebony_defconfig => 44x/ebony_defconfig} (100%)
rename arch/powerpc/configs/{katmai_defconfig => 44x/katmai_defconfig} (100%)
rename arch/powerpc/configs/{rainier_defconfig => 44x/rainier_defconfig} (100%)
rename arch/powerpc/configs/{sequoia_defconfig => 44x/sequoia_defconfig} (100%)
rename arch/powerpc/configs/{taishan_defconfig => 44x/taishan_defconfig} (100%)
rename arch/powerpc/configs/{warp_defconfig => 44x/warp_defconfig} (100%)
rename arch/powerpc/configs/{mpc8313_rdb_defconfig => 83xx/mpc8313_rdb_defconfig} (99%)
rename arch/powerpc/configs/{mpc8315_rdb_defconfig => 83xx/mpc8315_rdb_defconfig} (100%)
rename arch/powerpc/configs/{mpc832x_mds_defconfig => 83xx/mpc832x_mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc832x_rdb_defconfig => 83xx/mpc832x_rdb_defconfig} (100%)
rename arch/powerpc/configs/{mpc834x_itx_defconfig => 83xx/mpc834x_itx_defconfig} (100%)
rename arch/powerpc/configs/{mpc834x_itxgp_defconfig => 83xx/mpc834x_itxgp_defconfig} (100%)
rename arch/powerpc/configs/{mpc834x_mds_defconfig => 83xx/mpc834x_mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc836x_mds_defconfig => 83xx/mpc836x_mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc837x_mds_defconfig => 83xx/mpc837x_mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc837x_rdb_defconfig => 83xx/mpc837x_rdb_defconfig} (100%)
rename arch/powerpc/configs/{sbc834x_defconfig => 83xx/sbc834x_defconfig} (100%)
copy arch/powerpc/configs/{mpc8560_ads_defconfig => 85xx/ksi8560_defconfig} (85%)
rename arch/powerpc/configs/{mpc8540_ads_defconfig => 85xx/mpc8540_ads_defconfig} (100%)
rename arch/powerpc/configs/{mpc8544_ds_defconfig => 85xx/mpc8544_ds_defconfig} (99%)
rename arch/powerpc/configs/{mpc8560_ads_defconfig => 85xx/mpc8560_ads_defconfig} (100%)
rename arch/powerpc/configs/{mpc8568mds_defconfig => 85xx/mpc8568mds_defconfig} (100%)
rename arch/powerpc/configs/{mpc8572_ds_defconfig => 85xx/mpc8572_ds_defconfig} (100%)
rename arch/powerpc/configs/{mpc85xx_cds_defconfig => 85xx/mpc85xx_cds_defconfig} (100%)
rename arch/powerpc/configs/{sbc8548_defconfig => 85xx/sbc8548_defconfig} (100%)
rename arch/powerpc/configs/{sbc8560_defconfig => 85xx/sbc8560_defconfig} (100%)
copy arch/powerpc/configs/{stx_gp3_defconfig => 85xx/stx_gp3_defconfig} (100%)
rename arch/powerpc/configs/{tqm8540_defconfig => 85xx/tqm8540_defconfig} (100%)
rename arch/powerpc/configs/{tqm8541_defconfig => 85xx/tqm8541_defconfig} (100%)
rename arch/powerpc/configs/{tqm8555_defconfig => 85xx/tqm8555_defconfig} (100%)
rename arch/powerpc/configs/{tqm8560_defconfig => 85xx/tqm8560_defconfig} (100%)
rename arch/powerpc/configs/{walnut_defconfig => ppc40x_defconfig} (97%)
rename arch/powerpc/configs/{stx_gp3_defconfig => sbc8641d_defconfig} (61%)
create mode 100644 arch/powerpc/kernel/stacktrace.c
delete mode 100644 arch/powerpc/mm/lmb.c
create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
create mode 100644 arch/powerpc/platforms/44x/idle.c
create mode 100644 arch/powerpc/platforms/85xx/ksi8560.c
create mode 100644 arch/powerpc/platforms/86xx/sbc8641d.c
create mode 100644 arch/powerpc/platforms/pseries/phyp_dump.c
create mode 100644 arch/powerpc/sysdev/fsl_lbc.c
create mode 100644 arch/powerpc/sysdev/ppc4xx_soc.c
create mode 100644 drivers/net/pasemi_mac_ethtool.c
create mode 100644 drivers/of/gpio.c
create mode 100644 drivers/of/of_i2c.c
create mode 100644 include/asm-powerpc/fsl_lbc.h
create mode 100644 include/asm-powerpc/gpio.h
create mode 100644 include/asm-powerpc/iseries/alpaca.h
delete mode 100644 include/asm-powerpc/iseries/it_lp_reg_save.h
create mode 100644 include/asm-powerpc/phyp_dump.h
create mode 100644 include/asm-powerpc/ppc4xx.h
create mode 100644 include/asm-sparc64/lmb.h
create mode 100644 include/linux/lmb.h
create mode 100644 include/linux/of_gpio.h
create mode 100644 include/linux/of_i2c.h
create mode 100644 lib/lmb.c
Adrian Bunk (1):
[POWERPC] Add MODULE_LICENSE to powerpc/sysdev/rtc_cmos_setup.c
Alexander van Heukelum (1):
[POWERPC] Use asm-generic/bitops/find.h in bitops.h
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
Andreas Schwab (1):
[POWERPC] Add compat handler for PTRACE_GETSIGINFO
Anton Vorontsov (12):
[POWERPC] 8xx: Timebase frequency should not depend on bus-frequency
[POWERPC] OF helpers for the GPIO API
[POWERPC] Implement support for the GPIO LIB API
[POWERPC] QE: UCC nodes cleanup
[POWERPC] fsl_elbc_nand: factor out localbus defines
[POWERPC] fsl_lbc: implement few UPM routines
[POWERPC] QE: implement qe_muram_offset
[POWERPC] QE: immap_qe.h should include asm/io.h
[POWERPC] QE: export qe_get_brg_clk()
[POWERPC] QE: fix sparse warnings
[POWERPC] 83xx: mpc837x_rdb: add simple-bus compatible matching
[POWERPC] 83xx: mpc8315 - fix USB UTMI Host setup
Badari Pulavarty (2):
[POWERPC] Add code for removing HPTEs for parts of the linear mapping
[POWERPC] Add error return from htab_remove_mapping()
Becky Bruce (1):
[LMB]: Make lmb support large physical addressing
Benjamin Herrenschmidt (7):
[POWERPC] Fix thinko in cpu_thread_mask_to_cores()
[POWERPC] Initialize paca->current earlier
[POWERPC] Fixup softirq preempt count
[POWERPC] properly declare onstack completion in iseries veth
[POWERPC] Fix device-tree locking vs. interrupts
[POWERPC] Move stackframe definitions to common header
[POWERPC] irqtrace support for 64-bit powerpc
Christoph Hellwig (1):
[POWERPC] Stacktrace support for lockdep
Dale Farnsworth (6):
[POWERPC] Remove dead code at KernelAltiVec
[POWERPC] prpmc2800: Fix frequencies in prpmc2800.dts
[POWERPC] mv64x60: Remove device tree absolute path references
[POWERPC] mv643xx_eth: Prepare to support multiple silicon blocks
[POWERPC] Document the mv64x60 device tree bindings
[POWERPC] prpmc2800 needs a dtbImage
David Gibson (1):
[POWERPC] Start removing linux,network-index in favour of aliases
David S. Miller (3):
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
[LMB]: Fix bug in __lmb_alloc_base().
[LMB] Add lmb_alloc_nid()
David Woodhouse (1):
[POWERPC] Efika: Really, don't pretend to be CHRP
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
Gerhard Stenzel (1):
[POWERPC] spufs: fix incorrect file descriptors in SPU coredump note names
Grant Likely (2):
[POWERPC] add target for building .dtb files
[POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
Haiying Wang (1):
[POWERPC] 85xx: Fix the size of qe muram for MPC8568E
Harvey Harrison (2):
[POWERPC] Replace remaining __FUNCTION__ occurrences
[POWERPC] ppc: Replace remaining __FUNCTION__ occurrences
Ionut Nicu (1):
[POWERPC] Fix kernel panic in arch_arm_kprobe
Ishizaki Kou (2):
[POWERPC] celleb: Coding style cleanup
[POWERPC] hvcbeat: Fix buffer manipulation
Jeremy Kerr (3):
[POWERPC] spufs: add newline to signal{1,2}_type files
[POWERPC] spufs: reacquire LS pointer in spu_process_callback
[POWERPC] spufs: save MFC command channel before purging MFC queue
Jerone Young (1):
[POWERPC] 4xx: Add idle wait support for 44x platforms
Jochen Friedrich (2):
[POWERPC] i2c: OF helpers for the i2c API
[POWERPC] i2c: Fix build breakage introduced by OF helpers
Johannes Berg (1):
[POWERPC] mpic: Make sparse happy
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 (7):
[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
[POWERPC] 4xx: Add Canyonlands and Yosemite to multi-board defconfig
[POWERPC] Add of_device_is_available function
[POWERPC] 4xx: Reorganize 4xx defconfigs
[POWERPC] 4xx: Add ppc40x_defconfig
Julia Lawall (2):
[POWERPC] Use FIELD_SIZEOF in arch/ppc
[POWERPC] Use FIELD_SIZEOF in drivers/block/viodasd.c
Kumar Gala (23):
[LMB]: Fix initial lmb add region with a non-zero base
[LMB]: Fix lmb_add_region if region should be added at the head
[POWERPC] Remove Kconfig option BOOT_LOAD
[POWERPC] Provide access to arch/powerpc include path on ppc64
[POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr
[POWERPC] Introduce lowmem_end_addr to distinguish from total_lowmem
[POWERPC] 85xx: Cleanup TLB initialization
[POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32
[POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr
[POWERPC] Clean up some linker and symbol usage
[POWERPC] Move phys_addr_t definition into asm/types.h
[POWERPC] Update linker script to properly set physical addresses
[POWERPC] bootwrapper: Use physical address in PHDR for uImage
[POWERPC] Cleanup pgtable-ppc32.h
[POWERPC] Remove unused machine call outs
[POWERPC] Rework Book-E debug exception handling
[POWERPC] 83xx/85xx: Reorganize defconfigs
[POWERPC] Make Book-E debug handling SMP safe
[POWERPC] 83xx: Enable FCM NAND and OF partitions in defconfig
[POWERPC] 85xx: Fix compile warning
[POWERPC] 85xx: Convert dts to v1 syntax
[POWERPC] 85xx: minor .dts cleanups
[POWERPC] fsl: Convert dts to v1 syntax
Laurent Pinchart (6):
[POWERPC] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
[POWERPC] Add bootwrapper function to get virtual reg from the device tree.
[POWERPC] cpm-serial: Relocate CPM buffer descriptors and SMC parameter ram.
[POWERPC] ep8248e: Reference SMC parameter RAM base in the device tree.
[POWERPC] CPM2: Reset the CPM when early debugging is not enabled.
[POWERPC] CPM: Move opcodes common to CPM1 and CPM2 to include/asm-powerpc/cpm.h
Manish Ahuja (11):
[POWERPC] pseries: phyp dump: Documentation
[POWERPC] pseries: phyp dump: Reserve and release memory
[POWERPC] pseries: phyp dump: Use sysfs to release reserved mem
[POWERPC] pseries: phyp dump: Register dump area
[POWERPC] pseries: phyp dump: Debugging print routines
[POWERPC] pseries: phyp dump: Invalidate and print dump areas
[POWERPC] pseries: phyp dump: Tracking memory range freed
[POWERPC] pseries: phyp dump: Add Kconfig file option
[POWERPC] pseries: phyp dump: Disable phyp-dump through boot-var
[POWERPC] pseries: phyp dump: Inform kdump when phyp-dump is loaded
[POWERPC] pseries/phyp dump: Reserve a variable amount of space at boot
Marian Balakowicz (1):
[POWERPC] Add 'model: ...' line to common show_cpuinfo()
Mark A. Greer (3):
[POWERPC] prpmc2800: Convert DTS to v1 and add labels
[POWERPC] mv64x60: Fix FDT compatible names: mv64x60 => mv64360
[POWERPC] prpmc2800: Clean up dts properties
Masakazu Mokuno (1):
[POWERPC] PS3: Gelic network driver Wake-on-LAN support
Michael Ellerman (6):
[POWERPC] Move prototype for find_udbg_vterm() into a header file
[POWERPC] Always add preferred consoles in platforms/pseries/lpar.c
[POWERPC] Move xics_setup_8259_cascade() into platforms/pseries/setup.c
[POWERPC] Turn xics_setup_8259_cascade() into a generic pseries_setup_i8259_cascade()
[POWERPC] Use pseries_setup_i8259_cascade() in pseries_mpic_init_IRQ()
[POWERPC] Simplify xics direct/lpar irq_host setup
Nate Case (1):
pasemi_mac: Netpoll support
Nathan Lynch (5):
[POWERPC] maple: Use platform name in define_machine()
[POWERPC] maple: Kill fixup_maple_ide
[POWERPC] maple: Enable ipr driver in defconfig
[POWERPC] scanlog_init cleanup and minor fixes
[POWERPC] Convert pci and eeh code to of_device_is_available
Olof Johansson (9):
pasemi_mac: Move RX/TX section enablement to dma_lib
[POWERPC] pasemi: Add flag management functions to dma_lib
[POWERPC] pasemi: Add function engine management functions to dma_lib
pasemi_mac: jumbo frame support
pasemi_mac: Enable GSO by default
pasemi_mac: basic ethtool support
pasemi_mac: Jumbo frame bugfixes
[POWERPC] pasemi: Minor iommu cleanup
[POWERPC] Remove unused __max_memory variable
Paul Gortmaker (5):
[POWERPC] 86xx: Add support for Wind River SBC8641D board
[POWERPC] 86xx: Add defconfig for Wind River SBC8641D board
[POWERPC] 86xx: Add device tree source for Wind River SBC8641D
[POWERPC] 86xx: mark functions static, other minor cleanups
[POWERPC] 86xx: mpc86xx_hpcn - Temporarily accept old dts node identifier.
Paul Mackerras (5):
[POWERPC] Fix handling of unrecoverable SLB miss interrupts
[LMB] Fix some whitespace and other formatting issues, use pr_debug
[LMB] Restructure allocation loops to avoid unsigned underflow
[POWERPC] Optimize fls64() on 64-bit processors
[POWERPC] Fix compile breakage for 64-bit UP configs
Robert Brose (1):
[POWERPC] Add kernel parameter to set l3cr for MPC745x
Robert P. J. Day (2):
[POWERPC] Move a.out.h to header-y since it doesn't check __KERNEL__
[POWERPC] Use __SPIN_LOCK_UNLOCKED macro in mpc52xx_set_psc_clkdiv
Roel Kluin (2):
[POWERPC] PS3: Fix unlikely typo in ps3_get_irq
[POWERPC] Replace logical-AND by bit-AND in pci_process_ISA_OF_ranges()
Roland McGrath (3):
[POWERPC] Don't touch PT_DTRACE in exec
[POWERPC] powerpc32: Remove asm-offsets ptrace cruft
[POWERPC] Define copy_siginfo_from_user32
S.
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Marvin @ 2008-04-20 11:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <D713F373-AE2A-4341-9C29-EF65B9399B36@kernel.crashing.org>
Hi,
On Saturday 19 April 2008 17:30:10 Kumar Gala wrote:
> This is intended as a reminder that we plan on getting rid of arch/ppc
> this summer. I'm guessing based on kernel release times that will be
> 2.6.27. That would mean 2.6.26 will be the last kernel to support
> arch/ppc.
>
> If people have boards that like ported over please let us know and
> work with us to port this over to arch/powerpc.
>
> Here is a list based on arch/ppc/platforms. Its not intended to be
> complete but a general idea of what's left in arch/ppc.
>
> PPC_PREP e6xx
will this be the end of life for all the PReP's ? I remember a patch posted
some month ago, but didn't heard anything since then. Any news? Or just let
it die quietly?
Marvin
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Paul Mackerras @ 2008-04-20 12:27 UTC (permalink / raw)
To: Marvin; +Cc: linuxppc-dev
In-Reply-To: <200804201314.47311.marvin24@gmx.de>
Marvin writes:
> will this be the end of life for all the PReP's ? I remember a patch posted
> some month ago, but didn't heard anything since then. Any news? Or just let
> it die quietly?
No, I'm still planning on getting PReP support over to arch/powerpc,
but getting time to work on it has been the difficulty.
What sort of PReP do you have?
Paul.
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Gabriel Paubert @ 2008-04-20 12:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18443.13999.770734.826892@cargo.ozlabs.ibm.com>
On Sun, Apr 20, 2008 at 10:27:27PM +1000, Paul Mackerras wrote:
> Marvin writes:
>
> > will this be the end of life for all the PReP's ? I remember a patch posted
> > some month ago, but didn't heard anything since then. Any news? Or just let
> > it die quietly?
>
> No, I'm still planning on getting PReP support over to arch/powerpc,
> but getting time to work on it has been the difficulty.
>
> What sort of PReP do you have?
On my side, I have MVME2[467]xx boards. But these are actually PPLUS
board but the residual data and boot methods are so similar to PreP
that they could be merged. The host bridge is flexible (the MVME5100
has the same PHB but a completely different layout set up by the
firmware IIRC). I have local patches in the tree I use (still 2.2)
that make the memory map more CHRP like (to have more PCI memory
space and less I/O space).
The main problem is that I'm short on cycles to work on porting
them to 2.6 (the other is that I'm not sure that it's worth
putting 2.6 on machines with 16MB of RAM, current kernels
with extremely stripped down configs are still much larger
than the ones I run on these boards).
Gabriel
^ permalink raw reply
* Re: removal of arch/ppc in 2.6.27?
From: Marvin @ 2008-04-20 13:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18443.13999.770734.826892@cargo.ozlabs.ibm.com>
Hi Paul,
On Sunday 20 April 2008 14:27:27 Paul Mackerras wrote:
> Marvin writes:
> > will this be the end of life for all the PReP's ? I remember a patch
> > posted some month ago, but didn't heard anything since then. Any news? Or
> > just let it die quietly?
>
> No, I'm still planning on getting PReP support over to arch/powerpc,
> but getting time to work on it has been the difficulty.
>
> What sort of PReP do you have?
IBM 7248 (aka Carolina) and Motorola Powerstack II (aka Utah) - currently
running Debian with 2.6.18 kernel.
Marvin
^ permalink raw reply
* git.secretlab.ca doubts
From: rodolfo @ 2008-04-20 14:02 UTC (permalink / raw)
To: Linuxppc embedded, rodolfo__17
Hi,
Did I had to use uartlite.c from "Uartlite: Make console output actually
work." topic in git server instead of driver/serial/uartlite.c in mmy
kernel tree?
and about Makefile from "Linux 2.6.25-rc7 v2.6.25-rc7" topic in git
server, Did I had to replace for my Makefile (2.6.25 from kernel.org) ??
When I have to use the files from git server?
^ permalink raw reply
* [PATCH] ptrace: compat_ptrace_request siginfo
From: Roland McGrath @ 2008-04-20 20:10 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Anton Blanchard,
Ingo Molnar, Thomas Gleixner
I posted this before, but I hope it can go in now.
It's a prerequisite for some x86 ptrace cleanups I'd like to submit.
For powerpc, it requires this patch that's in Paul's queue:
commit 9c0c44dbd9bc380bee53e2f768c4ad5410b8aae2
Author: Roland McGrath <roland@redhat.com>
Date: Sun Apr 20 08:19:24 2008 +1000
[POWERPC] Define copy_siginfo_from_user32
Note: that change plus the patch below obviates the need for this one:
commit e4cc58944c1e2ce41e3079d4eb60c95e7ce04b2b
Author: Andreas Schwab <schwab@suse.de>
Date: Sun Apr 20 02:25:13 2008 +1000
[POWERPC] Add compat handler for PTRACE_GETSIGINFO
Thanks,
Roland
---
[PATCH] ptrace: compat_ptrace_request siginfo
This adds support for PTRACE_GETSIGINFO and PTRACE_SETSIGINFO in
compat_ptrace_request. It relies on existing arch definitions for
copy_siginfo_to_user32 and copy_siginfo_from_user32.
On powerpc, this fixes a longstanding regression of 32-bit ptrace
calls on 64-bit kernels vs native calls (64-bit calls or 32-bit
kernels). This can be seen in a 32-bit call using PTRACE_GETSIGINFO
to examine e.g. siginfo_t.si_addr from a signal that sets it.
(This was broken as of 2.6.24 and, I presume, many or all prior versions.)
Signed-off-by: Roland McGrath <roland@redhat.com>
---
kernel/ptrace.c | 48 +++++++++++++++++++++++++++++++++++-------------
1 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index fdb34e8..67e392e 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -323,9 +323,8 @@ static int ptrace_setoptions(struct task_struct *child, long data)
return (data & ~PTRACE_O_MASK) ? -EINVAL : 0;
}
-static int ptrace_getsiginfo(struct task_struct *child, siginfo_t __user * data)
+static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
{
- siginfo_t lastinfo;
int error = -ESRCH;
read_lock(&tasklist_lock);
@@ -333,31 +332,25 @@ static int ptrace_getsiginfo(struct task_struct *child, siginfo_t __user * data)
error = -EINVAL;
spin_lock_irq(&child->sighand->siglock);
if (likely(child->last_siginfo != NULL)) {
- lastinfo = *child->last_siginfo;
+ *info = *child->last_siginfo;
error = 0;
}
spin_unlock_irq(&child->sighand->siglock);
}
read_unlock(&tasklist_lock);
- if (!error)
- return copy_siginfo_to_user(data, &lastinfo);
return error;
}
-static int ptrace_setsiginfo(struct task_struct *child, siginfo_t __user * data)
+static int ptrace_setsiginfo(struct task_struct *child, const siginfo_t *info)
{
- siginfo_t newinfo;
int error = -ESRCH;
- if (copy_from_user(&newinfo, data, sizeof (siginfo_t)))
- return -EFAULT;
-
read_lock(&tasklist_lock);
if (likely(child->sighand != NULL)) {
error = -EINVAL;
spin_lock_irq(&child->sighand->siglock);
if (likely(child->last_siginfo != NULL)) {
- *child->last_siginfo = newinfo;
+ *child->last_siginfo = *info;
error = 0;
}
spin_unlock_irq(&child->sighand->siglock);
@@ -424,6 +417,7 @@ int ptrace_request(struct task_struct *child, long request,
long addr, long data)
{
int ret = -EIO;
+ siginfo_t siginfo;
switch (request) {
case PTRACE_PEEKTEXT:
@@ -442,12 +436,22 @@ int ptrace_request(struct task_struct *child, long request,
case PTRACE_GETEVENTMSG:
ret = put_user(child->ptrace_message, (unsigned long __user *) data);
break;
+
case PTRACE_GETSIGINFO:
- ret = ptrace_getsiginfo(child, (siginfo_t __user *) data);
+ ret = ptrace_getsiginfo(child, &siginfo);
+ if (!ret)
+ ret = copy_siginfo_to_user((siginfo_t __user *) data,
+ &siginfo);
break;
+
case PTRACE_SETSIGINFO:
- ret = ptrace_setsiginfo(child, (siginfo_t __user *) data);
+ if (copy_from_user(&siginfo, (siginfo_t __user *) data,
+ sizeof siginfo))
+ ret = -EFAULT;
+ else
+ ret = ptrace_setsiginfo(child, &siginfo);
break;
+
case PTRACE_DETACH: /* detach a process that was attached. */
ret = ptrace_detach(child, data);
break;
@@ -616,6 +620,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
{
compat_ulong_t __user *datap = compat_ptr(data);
compat_ulong_t word;
+ siginfo_t siginfo;
int ret;
switch (request) {
@@ -638,6 +643,23 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
ret = put_user((compat_ulong_t) child->ptrace_message, datap);
break;
+ case PTRACE_GETSIGINFO:
+ ret = ptrace_getsiginfo(child, &siginfo);
+ if (!ret)
+ ret = copy_siginfo_to_user32(
+ (struct compat_siginfo __user *) datap,
+ &siginfo);
+ break;
+
+ case PTRACE_SETSIGINFO:
+ memset(&siginfo, 0, sizeof siginfo);
+ if (copy_siginfo_from_user32(
+ &siginfo, (struct compat_siginfo __user *) datap))
+ ret = -EFAULT;
+ else
+ ret = ptrace_setsiginfo(child, &siginfo);
+ break;
+
default:
ret = ptrace_request(child, request, addr, data);
}
^ permalink raw reply related
* Re: pci issue - wrong detection of pci ressources
From: Christian Ehrhardt @ 2008-04-20 20:36 UTC (permalink / raw)
To: benh, Johan Borkhuis; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <1208566122.6958.425.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 6882 bytes --]
Johan Borkhuis wrote:
> Hello Christian,
>
> Christian Ehrhardt wrote:
>> Hi,
>> I tried to use a radeon r200 based graphic card on a sequoia ppc
>> (440epx) board. I wondered about the initialization of radeonfb that
>> failed with
>> __ioremap(): phys addr 0x0 is RAM lr c029cf80
>> radeonfb (0000:00:0a.0): cannot map MMIO
>> radeonfb: probe of 0000:00:0a.0 failed with error -5
>>
[...]
>
> I came across a similar problem, which (ultimately) was caused by a lack
> of memory reserved for PCI. I moved from 2.6.14(ppc) to 2.6.20(powerpc),
> and suddenly some cards stopped working: the BAR registers were not
> initialized, so it was not possible to access the cards.
> Have a look at the boot-time messages, especially the early messages, as
> the PCI subsystem is started very early in the boot process. You could
> also try switching on PCI-debugging, and have a look at the debug
> messages, or add some extra debugging info to the pci-initialization code.
Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources.
And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem.
Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ?
With DEBUG in pci-common.c enabled (bad kernel) and a extension showing which functions alloc fails (put a %s for __func__):
PCI host bridge /plb/pci@1ec000000 (primary) ranges:
MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
Try to map irq for 0000:00:00.0...
-> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for 0000:00:0a.0...
-> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for 0000:00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0363060 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0363038 (PCI mem)
PCI: Assigning unassigned resouces...
PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #1:10000@190000000 for 0000:00:0a.1
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
########
To be complete for the case we might need it I answer all the other questions:
Benjamin Herrenschmidt wrote:
> On Fri, 2008-04-18 at 14:07 +0200, Christian Ehrhardt wrote:
>> => Region 2 is not detected with our kernel, this later break things
>> like radeonfb initialization.
>
> I'll need some information here:
>
> - Your device-tree (is that the base sequoia one ?)
DTS File is the normal sequoia.dts file in arch/powerpc/boot/dts with the latest change being:
user: Stefan Roese <sr@denx.de>
date: Fri Feb 15 21:35:30 2008 -0600
summary: [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts
> - Enable DEBUG in arch/powerpc/kernel/pci-common.c and pci_32.c
> - Send me the resulting dmesg log
done - full dmesg attached
> - Also include the output of /proc/iomem
/proc/iomem - bad kernel
root@sequoia:~# cat /proc/iomem
e0000300-e000038f : ehci_hcd
180000000-18fffffff : /plb/pci@1ec000000
180000000-187ffffff : 0000:00:0a.0
188000000-18fffffff : 0000:00:0a.1
1ef600300-1ef600307 : serial
1ef600400-1ef600407 : serial
1ef600500-1ef600507 : serial
1ef600600-1ef600607 : serial
1fc000000-1ffffffff : 1fc000000.nor_flash
/proc/iomem - good kernel
root@sequoia:~# cat /proc/iomem
80000000-8fffffff : PCI host bridge
80000000-8000ffff : 0000:00:0a.1
80020000-8003ffff : 0000:00:0a.0
87ff0000-87ffffff : 0000:00:0a.0
87ff0000-87ffffff : radeonfb mmio
88000000-8fffffff : 0000:00:0a.0
88000000-8fffffff : radeonfb framebuffer
d0000000-d0001fff : ndfc-nand.0
e0000100-e000017f : musbhsfc_udc.0
e0000100-e000017f : musbhsfc_udc
e0000300-e00003ff : ppc-soc-ehci.0
e0000400-e00004ff : ppc-soc-ohci.0
fc000000-ffffffff : physmap-flash.0
fc000000-ffffffff : physmap-flash.0
> Actually, there's a bug in radeonfb:
>
> In radeonfb.h, try changing
>
> unsigned long mmio_base_phys;
> unsigned long fb_base_phys;
>
> To
>
> resource_size_t mmio_base_phys;
> resource_size_t fb_base_phys;
This did not fix the issue, as we have seen that it is caused earlier in pci initialization.
But that fix corrects the code if it is useful in my case or not ;-)
########
Sergei Shtylyov wrote:
> Christian Ehrhardt wrote:
>
[...]
>> Bad kernel:
>> 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon
>> 9200 PRO] (rev 01) (prog-if 00 [VGA])
>> Subsystem: PC Partner Limited Unknown device 0250
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 128 (2000ns min)
>> Interrupt: pin A routed to IRQ 16
>> Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
>
> That's beyond 4 GB, seems correct. That should be the address
> assigned by bootloader? BTW, what's your bootloader, U-Boot?
Yes a modified u-boot
>
>> Region 1: I/O ports at 1000 [size=256]
>> Region 2: Memory at <ignored> (32-bit, non-prefetchable)
>
> Hm... what could this mean? Could you post the result of 'lspci -x'?
lspci -xvvv (bad kernel)
00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA])
Subsystem: PC Partner Limited Unknown device 0250
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at 1000 [size=256]
Region 2: Memory at <ignored> (32-bit, non-prefetchable)
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 02 10 60 59 07 00 90 02 01 00 00 03 00 80 80 00
10: 08 00 00 80 01 10 00 00 00 00 00 88 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 50 02
30: 00 00 00 00 50 00 00 00 00 00 00 00 43 01 08 00
[-- Attachment #2: pci_resource_alocation_fails.dmesg.txt --]
[-- Type: text/plain, Size: 10968 bytes --]
Using Sequoia machine description
Linux version 2.6.25-rc9-dirty (paelzer@HeliosPrime.boeblingen.de.ibm.com) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #7 Sun Apr 20 21:14:50 CEST 2008
Found legacy serial port 0 for /plb/opb/serial@ef600300
mem=1ef600300, taddr=1ef600300, irq=0, clk=11059200, speed=115200
Found legacy serial port 1 for /plb/opb/serial@ef600400
mem=1ef600400, taddr=1ef600400, irq=0, clk=11059200, speed=0
Found legacy serial port 2 for /plb/opb/serial@ef600500
mem=1ef600500, taddr=1ef600500, irq=0, clk=4385964, speed=0
Found legacy serial port 3 for /plb/opb/serial@ef600600
mem=1ef600600, taddr=1ef600600, irq=0, clk=4385964, speed=0
console [udbg0] enabled
Entering add_active_range(0, 0, 65536) 0 entries of 256 used
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
On node 0 totalpages: 65536
DMA zone: 512 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 65024 pages, LIFO batch:15
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyS0,115200 ip=dhcp nfsroot=192.168.1.2:/home/paelzer/ubuntu_ppc root=/dev/nfs rw
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 666.666660 MHz
time_init: processor frequency = 666.666660 MHz
clocksource: timebase mult[600000] shift[22] registered
clockevent: decrementer mult[aaaa] shift[16] cpu[0]
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 255744k/262144k available (3448k kernel code, 6052k reserved, 152k data, 153k bss, 156k init)
Calibrating delay loop... 1331.20 BogoMIPS (lpj=2662400)
Mount-cache hash table entries: 512
net_namespace: 440 bytes
NET: Registered protocol family 16
PCI host bridge /plb/pci@1ec000000 (primary) ranges:
MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
Try to map irq for 0000:00:00.0...
-> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for 0000:00:0a.0...
-> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
-> mapped to linux irq 16
Try to map irq for 0000:00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0363060 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0363038 (PCI mem)
PCI: Assigning unassigned resouces...
PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #1:10000@190000000 for 0000:00:0a.1
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
radeonfb_pci_register BEGIN
radeonfb_pci_register - resource0 0x1 - 0x80000000
radeonfb_pci_register - resource1 0x0 - 0x1000
radeonfb_pci_register - resource2 0x0 - 0x0
radeonfb_pci_register - got pci ressources fb_base_phys 0x1 mmio_base_phys 0x80000000
radeonfb_pci_register - call ioremap for base 0 and size 0
__ioremap(): phys addr 0x0 is RAM lr c029cf88 - mem_init_done 1 highmem@10000000
radeonfb (0000:00:0a.0): cannot map MMIO
radeonfb: probe of 0000:00:0a.0 failed with error -5
Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized radeon 1.28.0 20060524 on minor 0
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x1ef600300 (irq = 17) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0x1ef600400 (irq = 18) is a 16550A
serial8250.0: ttyS2 at MMIO 0x1ef600500 (irq = 19) is a 16550A
serial8250.0: ttyS3 at MMIO 0x1ef600600 (irq = 20) is a 16550A
1ef600300.serial: ttyS0 at MMIO 0x1ef600300 (irq = 17) is a 16550A
1ef600400.serial: ttyS1 at MMIO 0x1ef600400 (irq = 18) is a 16550A
1ef600500.serial: ttyS2 at MMIO 0x1ef600500 (irq = 19) is a 16550A
1ef600600.serial: ttyS3 at MMIO 0x1ef600600 (irq = 20) is a 16550A
brd: module loaded
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 2 TX channels, 2 RX channels
ZMII /plb/opb/emac-zmii@ef600d00 initialized
RGMII /plb/opb/emac-rgmii@ef601000 initialized with MDIO support
/plb/opb/emac-rgmii@ef601000: input 0 in RGMII mode
eth0: EMAC-0 /plb/opb/ethernet@ef600e00, MAC 00:10:ec:00:e2:3e
eth0: found Marvell 88E1111 Ethernet PHY (0x00)
/plb/opb/emac-rgmii@ef601000: input 1 in RGMII mode
eth1: EMAC-1 /plb/opb/ethernet@ef600f00, MAC 00:10:ec:80:e2:3e
eth1: found Marvell 88E1111 Ethernet PHY (0x01)
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Driver 'sd' needs updating - please use bus_type methods
1fc000000.nor_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
1fc000000.nor_flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
of-flash: probe of 1fc000000.nor_flash failed with error -22
ppc-of-ehci e0000300.ehci: OF EHCI
ppc-of-ehci e0000300.ehci: new USB bus registered, assigned bus number 1
ppc-of-ehci e0000300.ehci: irq 32, io mem 0xe0000300
ppc-of-ehci e0000300.ehci: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: OF EHCI
usb usb1: Manufacturer: Linux 2.6.25-rc9-dirty ehci_hcd
usb usb1: SerialNumber: PPC-OF USB
USB Universal Host Controller Interface driver v3.0
Initializing USB Mass Storage driver...
usb 1-1: new high speed USB device using ppc-of-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB2.0 Hub
usb 1-1.1: new low speed USB device using ppc-of-ehci and address 3
usb 1-1.1: configuration #1 chosen from 1 choice
usb 1-1.1: New USB device found, idVendor=04b3, idProduct=310c
usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 1-1.1: Product: USB Optical Mouse
usb 1-1.2: new full speed USB device using ppc-of-ehci and address 4
usb 1-1.2: configuration #1 chosen from 1 choice
hub 1-1.2:1.0: USB hub found
hub 1-1.2:1.0: 2 ports detected
usb 1-1.2: New USB device found, idVendor=04b3, idProduct=3022
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2: Product: IBM Preferred Pro USB Fingerprint Keyboard
usb 1-1.2: Manufacturer: Chicony
usb 1-1.2.1: new full speed USB device using ppc-of-ehci and address 5
usb 1-1.2.1: configuration #1 chosen from 1 choice
usb 1-1.2.1: New USB device found, idVendor=04b3, idProduct=3021
usb 1-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2.1: Product: IBM Preferred Pro USB Fingerprint Keyboard
usb 1-1.2.1: Manufacturer: Chicony
usb 1-1.2.2: new full speed USB device using ppc-of-ehci and address 6
usb 1-1.2.2: configuration #1 chosen from 1 choice
usb 1-1.2.2: New USB device found, idVendor=0483, idProduct=2016
usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2.2: Product: Biometric Coprocessor
usb 1-1.2.2: Manufacturer: STMicroelectronics
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
mice: PS/2 mouse device common for all mice
input: USB Optical Mouse as /class/input/input0
input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-PPC-OF USB-1.1
input: Chicony IBM Preferred Pro USB Fingerprint Keyboard as /class/input/input1
input: USB HID v1.10 Keyboard [Chicony IBM Preferred Pro USB Fingerprint Keyboard] on usb-PPC-OF USB-1.2.1
HID device claimed by neither input, hiddev nor hidraw
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
oprofile: using timer interrupt.
Netfilter messages via NETLINK v0.30.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Bridge firewalling registered
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
eth0: link is up, 100 FDX, pause enabled
eth1: link is up, 100 FDX, pause enabled
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.1.2, my address is 192.168.1.3
IP-Config: Complete:
device=eth0, addr=192.168.1.3, mask=255.255.255.0, gw=192.168.1.2,
host=192.168.1.3, domain=local-devnet, nis-domain=(none),
bootserver=192.168.1.2, rootserver=192.168.1.2, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.2
Looking up port of RPC 100005/1 on 192.168.1.2
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 156k init
eth1: link is up, 100 FDX, pause enabled
swapon: swapfile has holes
warning: `avahi-daemon' uses 32-bit capabilities (legacy support in use)
Machine check in kernel mode.
Data Read PLB Error
Machine check in kernel mode.
Data Read PLB Error
Machine check in kernel mode.
Data Read PLB Error
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
lockd_up: makesock failed, error=-5
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
^ permalink raw reply
* Re: pci issue - wrong detection of pci ressources
From: Benjamin Herrenschmidt @ 2008-04-20 21:36 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: Hollis Blanchard, linuxppc-dev
In-Reply-To: <480BA937.7050603@linux.vnet.ibm.com>
> Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources.
> And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem.
> Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ?
Hrm... I was expecting to see a lot more output here, make sure you have
"debug" on your command line (or enable early debug output, same
effect).
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Grant Likely @ 2008-04-20 22:42 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, netdev
In-Reply-To: <200804161640.42693.laurentp@cse-semaphore.com>
On Wed, Apr 16, 2008 at 8:40 AM, Laurent Pinchart
<laurentp@cse-semaphore.com> wrote:
> This patch converts the MII bitband driver to use GPIO lib for GPIO access.
> The driver can now handle MDC and MDIO on different GPIO banks.
>
> The patch depends on Anton Vorontsov GPIO lib support scheduled for 2.6.26.
> It is by no means complete, I just would like to get some feedback on the
> approach. I'll resubmit it when the CPM2 GPIO support patches will be
> available in the powerpc git tree.
I agree with Anton; nice rework. This would be useful on other
platforms too. Comment below.
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2030,21 +2030,19 @@ platforms are moved over to use the flattened-device-tree model.
> fsl,cpm2-mdio-bitbang (reg is port C registers)
>
> Properties for fsl,cpm2-mdio-bitbang:
> - fsl,mdio-pin : pin of port C controlling mdio data
> - fsl,mdc-pin : pin of port C controlling mdio clock
> + gpios : GPIOs controlling mdio clock and mdio data (in that order).
>
> Example:
>
> - mdio@10d40 {
> + mdio {
> device_type = "mdio";
> compatible = "fsl,mpc8272ads-mdio-bitbang",
> "fsl,mpc8272-mdio-bitbang",
> "fsl,cpm2-mdio-bitbang";
I think it would be better for the defined binding to use something
like "virtual,mdio-bitbang" or "gpio-mdio". (I like the first better,
but there is already some precedence with the "gpio-led" driver. I
think there is less chance of namespace conflicts with the first)
Of course; the *driver* could also accept these additional compatible
values for backwards compatibility.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: UartLite
From: Grant Likely @ 2008-04-20 23:02 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-dev
In-Reply-To: <480BA62D.5020904@dlasys.net>
BTW, you should really be asking these questions on the linuxppc mailing list
On Sun, Apr 20, 2008 at 2:23 PM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> I have been looking more and more at the kernel uartlite driver.
> Somewhere along the line while I was not watching PK's driver has
> developed alot stronger resemblance to most normal serial drivers. I am
> seriously thinking of putting some effort into getting it working for
> me, and then pushing my polling patch for interrupt free implimentations.
>
> But I have tripped over several things that trouble me. Though I am not
> a serial driver expert.
>
> The first is that all the Uartlite related definitions tend to create a
> BaseAddress+3 definition.
> This really bothers me, it presumes that the registers are all 4 bytes
> apart - I know that is the norm
> and I have never actually seen a different implimentation, but I do not
> think it is set in stone.
> It also is basically a cleaver trick to get readb/writeb to work without
> adjustment.
> Endian issues tend to give me headaches, but somehow I think there is an
> endian issue in this.
> All the port offsets are defined with the presumption the registers are
> 4 bytes apart.
> Despite the fact that all the offsets masks and bits are needed in
> several files, they are not in a header.
Yes, I'm not a big fan of the +3 either; but it is expedient. I think
the best solution is to encode it into the device tree by adding
optional "reg-stride" and "reg-offset" properties (at least for memory
mapped implementations).
We can define another binding for the DCR version.
> If I can manage to get the thing to work for me,
> Am I going to be stepping on any toes if I make changes to adress my
> concerns above ?
I've got no problem reworking the register accessor functions.
> I really want to migrate all the direct IO to a ulite_in() and
> ulite_out() routine.
> Letting those two routines deal with all the issues of BaseAddress,
> register size, endianness, register shift,
> and even whether access is via DCR - I have seen atleast one
> implimentation that was DCR.
>
> I would like to remove the +3 from all the macro's etc. as it seems to
> me to confuse what is actually going on.
>
> I did a diff merge against my own driver a few days ago and aside from
> these issues, order of functions, some naming issues, the absence of OF
> support in my driver, and the presence of polling in mine, the code now
> very very strongly parallels my code now. So it should not be alot of
> work to merge my code into the standard driver now.
>
> I will be happy to do this - presuming I am not going to be stepping on
> any toes.
> I would be happy to not have to support a separate driver, but the stock
> driver has to work with my hardware.
> It still does not, but I think the code is now close enough for me to
> track down and kill the problem.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Xilinx PowerPC
From: David H. Lynch Jr. @ 2008-04-20 23:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40804201548o503e9b19p4081cec653a1acd2@mail.gmail.com>
Thanks,
I have alot of work to do on our stuff, I might as well see if I can
move to the powerpc tree at the same time.
BTW is there even the beginings of a non-xilinx lltemac driver out
there ? There were hints on the list, but I have not seen anything.
I would be happy to help advance the ball on anything anyone has
started.
Grant Likely wrote:
> On Sun, Apr 20, 2008 at 2:31 PM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>> Thanks.
>>
>> I am running linus's 2.6.25-rc9, but I can pull the Xilinx tree or
>> yours - when your server is up.
>>
>> I can not find any Xilinx powerpc configs in arch/powerpc/config
>> Do I just need to do a
>> make ARCH=powerpc menuconfig and create one from scratch ?
>>
>
> That's right; I haven't merged any defconfigs. Roll your own.
>
>
>> Is simpleboot in your tree or the xilinx tree, if can not find it
>> in Linus's ?
>>
>
> If you want to use the "simpleboot" wrapper; then you'll need to pull
> paulus' tree (Linus hasn't yet pulled his tree; but he probably will
> any moment now).
>
> Cheers,
> g.
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ 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