* interrupt handlers PowerPC via GCC
From: Tehn Yit Chin @ 2008-03-20 0:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Apologies for such a basic question. I am trying to write an ISR on a
MPC551x. When I tried to use the interrupt attribute with
powerpc-eabi-gcc such as
_attribute_((interrupt_handler)) foobarISR(void)
{
}
it complains of a syntax error. Upon further investigation in the GCC,
it appears that the interrupt attribute is not supported by
powerpc-eabi-gcc.
Am I missing something fundamental here? How are the current interrupt
service routines created at the moment?
Any pointers would be appreciated.
tyc
^ permalink raw reply
* Re: simple MPC5200B system
From: Wolfgang Denk @ 2008-03-20 0:14 UTC (permalink / raw)
To: Andre Schwarz; +Cc: linux-ppc list
In-Reply-To: <47DF821B.6090600@matrix-vision.de>
In message <47DF821B.6090600@matrix-vision.de> you wrote:
>
> I've pulled the latest git and built a mpc5200_simple system with a
> minimal dts.
> There's not a single char put on the console ....
You did build your device tree with "-b 0", didn't you?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
EMACS belongs in <sys/errno.h>: Editor too big!
^ permalink raw reply
* Re: simple MPC5200B system
From: David Gibson @ 2008-03-20 0:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Andre Schwarz, linux-ppc list
In-Reply-To: <20080320001445.C03DD24A8B@gemini.denx.de>
On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
> In message <47DF821B.6090600@matrix-vision.de> you wrote:
> >
> > I've pulled the latest git and built a mpc5200_simple system with a
> > minimal dts.
> > There's not a single char put on the console ....
>
> You did build your device tree with "-b 0", didn't you?
Ugh.. I really need to fix dtc to pick the default boot cpu value more
sensibly, don't I.
--
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
* unprivileged use of MSR_SE
From: Roland McGrath @ 2008-03-20 0:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Are there any powerpc instructions that can read or change the MSR
explicitly from user mode? Any that can see or affect the MSR_SE bit?
e.g. x86 has pushf/popf unprivileged instructions, with which a user
program can both see the single-step flag set, and enable single-step for
its own next instruction (presumably when it has a handler for SIGTRAP).
This actually gets used in arcane places.
I recall being told before there's no unprivileged way to see or touch
MSR_SE. But it looks to me like a user program can set the bit in a
sigcontext and sigreturn to set it. Is that intentionally supported?
Or could sigreturn ignore the MSR_SE bit without breaking any strange user?
On x86 do we some machinations so that PTRACE_GETREGS et al show the
single-step bit set if user-mode itself had set it, but not if
PTRACE_SINGLESTEP set it. If you use PTRACE_SETREGS et al to set the
single-step bit, then it stays set even if you use PTRACE_CONT.
I'd like to clean this up for powerpc too. If there is no way at all for
user-mode to set MSR_SE, then it doesn't much matter whether it shows up
when ptrace reads it--ptrace just needs to ignore attempts to set it. So
if there's no reason not to, what I would do is remove MSR_SE from the
MSR_DEBUGCHANGE mask and make sigreturn always clear MSR_SE.
Does that make sense?
Thanks,
Roland
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-03-20 0:43 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 merge
to get some more bug-fixes and a defconfig update for various powerpc
platforms. The defconfig update only updates 9 of the defconfigs but
still dominates the diffstat, since the bug-fixes are all fairly
small.
Thanks,
Paul.
arch/powerpc/boot/Makefile | 4 -
arch/powerpc/boot/wrapper | 4 -
arch/powerpc/configs/cell_defconfig | 141 ++++++++++++++---------
arch/powerpc/configs/celleb_defconfig | 117 ++++++++++++-------
arch/powerpc/configs/chrp32_defconfig | 165 +++++++++++----------------
arch/powerpc/configs/g5_defconfig | 137 ++++++++++++++--------
arch/powerpc/configs/iseries_defconfig | 99 +++++++++++-----
arch/powerpc/configs/pmac32_defconfig | 195 ++++++++++++++++++++------------
arch/powerpc/configs/ppc64_defconfig | 169 +++++++++++++++++-----------
arch/powerpc/configs/ps3_defconfig | 103 ++++++++++-------
arch/powerpc/configs/pseries_defconfig | 136 +++++++++++++---------
arch/powerpc/kernel/process.c | 6 +
arch/powerpc/kernel/ptrace.c | 10 +-
arch/powerpc/mm/slb.c | 6 +
arch/powerpc/platforms/cell/iommu.c | 41 ++++---
arch/powerpc/platforms/cell/setup.c | 36 ++++++
16 files changed, 835 insertions(+), 534 deletions(-)
commit 93ce4e2d2d7404e80d5612fb1cc13d4aad5e42fc
Author: Paul Mackerras <paulus@samba.org>
Date: Thu Mar 20 11:21:32 2008 +1100
[POWERPC] Update some defconfigs
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ebf3a6509299e46c531f88ee727372bd95cf542a
Author: Michael Ellerman <michael@ellerman.id.au>
Date: Wed Mar 19 17:10:55 2008 +1100
[POWERPC] Hide resources on Axon PCIE root complex nodes
The PCI bridge representing the PCIE root complex on Axon, contains
device BARs for a memory range and ROM that define inbound accesses.
This confuses the kernel resource management code -- the resources
need to be hidden when Axon is a host bridge.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 3a4295d101d9654ca909b64c786f9da6ca1bf37a
Author: Michael Ellerman <michael@ellerman.id.au>
Date: Fri Mar 14 16:47:39 2008 +1100
[POWERPC] Fix cell IOMMU code to cope with empty dma-ranges and non-PCI devices
The cell IOMMU code to parse the dma-ranges properties, used for the fixed
mapping, was broken in two ways for some devices.
Firstly it didn't cope with empty dma-ranges properties. An empty property
implies no translation so can be safely skipped.
The code also wrongly assumed it would be looking at PCI devices, and hard
coded the number of address and size cells.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit a72a6f53ddb95723960bb64c011457e9739941d7
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Tue Mar 18 16:13:10 2008 +1100
[POWERPC] Fix build failure for tqm8540 and sbc85xx defconfigs
The wrapper script didn't have entries for the TQM8540 board and the
SBC8548 or SBC8560 boards. I've assumed that the TQM8540 console is
8250 based and not CPM based by looking at its defconfig. There was
also a trailing * on the TQM8555 entry that I removed too.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 44387e9ff25267c78a99229aca55ed750e9174c7
Author: Anton Blanchard <anton@samba.org>
Date: Mon Mar 17 15:27:09 2008 +1100
[POWERPC] Fix PMU + soft interrupt disable bug
Since the PMU is an NMI now, it can come at any time we are only soft
disabled. We must hard disable around the two places we allow the kernel
stack SLB and r1 to go out of sync. Otherwise the PMU exception can
force a kernel stack SLB into another slot, which can lead to it
getting evicted, which can lead to a nasty unrecoverable SLB miss
in the exception entry code.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit c2372eb9bcafdd149b26987a8c25bbed92fd2775
Author: Roland McGrath <roland@redhat.com>
Date: Thu Mar 13 19:25:35 2008 +1100
[POWERPC] user_regset PTRACE_SETREGS regression fix
The PTRACE_SETREGS request was only recently added on powerpc,
and gdb does not use it. So it slipped through without getting
all the testing it should have had.
The user_regset changes had a simple bug in storing to all of
the 32-bit general registers block on 64-bit kernels. This bug
only comes up with PTRACE_SETREGS, not PPC_PTRACE_SETREGS.
It causes a BUG_ON to hit, so this fix needs to go in ASAP.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
From: Linus Torvalds @ 2008-03-20 2:40 UTC (permalink / raw)
To: Roland McGrath
Cc: linux-arch, tony.luck, linux-ia64, linux-kernel, David Miller,
linuxppc-dev, Thomas Gleixner, sparclinux, Paul Mackerras,
Andrew Morton, Ingo Molnar, Richard Henderson
In-Reply-To: <20080319212024.EA03126F995@magilla.localdomain>
On Wed, 19 Mar 2008, Roland McGrath wrote:
>
> The arch_ptrace and compat_arch_ptrace functions can now return
> -ENOSYS for requests they do not actually implement in arch
> code.
Hmm.. I see the whole series, and I see this patch, but I think it adds
new code and new complexity, and I don't really see *why*.
So I'm obviously not going to apply it outside the merge window anyway,
but even for later I'd really like to know what you're building up
towards, because without understanding the upsides it just feels like it
adds ugly code and unnecessary infrastructure without any real point to
it.
And I have to say, I really hate that
ret = arch_ptrace(child, request, addr, data);
if (ret == -ENOSYS && !forced_successful_syscall_return())
ret = ptrace_request(child, request, addr, data);
thing. Instead of doing it that ugly way (return value and a special
per-arch forced_successful_syscall_return() thing), this really smells
like you just want to change the calling conventions for "arch_ptrace()"
instead.
Wouldn't it be nicer to just let "arch_ptrace()" return a flag saying
whether it handled things or not?
Linus
^ permalink raw reply
* linux-next: Tree for March 20
From: Stephen Rothwell @ 2008-03-20 3:39 UTC (permalink / raw)
To: linux-next
Cc: Theodore Tso, Greg KH, Dan, LKML, linuxppc-dev, Paul Mackerras,
Williams
[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]
Hi all,
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(tar balls at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64.
I have started this tree by reverting the following:
driver-core/driver-core-remove-no-longer-used-struct-class_device.patch
should be merged late
driver-core/ib-convert-struct-class_device-to-struct-device.patch
conflicts with the infiniband tree
driver-core/pm-make-wakeup-flags-available-whenever-config_pm-is-set.patch
breaks non CONFIG_PM builds of drivers/serial/serial_core.c
There were a few merge conflicts (fairly trivial).
I have added POWERPC-really-export-empty_zero_page.patch and reverted
async-tx commit 9974693221954ef1019f87d32ae26a0757d2ee85 ("dmaengine: ack
to flags: make use of the unused bits in the 'ack' field") as these are
still needed to make powerpc allmodconfig build (in particular ext4 and
drivers/dma/fsldma.c). These have been reported previously.
We are up to 48 trees, more are welcome (even if they are currently
empty). The influx of new trees has slowed completely. Thanks to those
who have contributed, and to those who haven't, please do.
In particular, I have very few of the architecture trees ....
Status of my local build tests is at
http://kisskb.ellerman.id.au/linux-next. If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: unprivileged use of MSR_SE
From: Paul Mackerras @ 2008-03-20 4:10 UTC (permalink / raw)
To: Roland McGrath; +Cc: linuxppc-dev
In-Reply-To: <20080320002407.D911C26F995@magilla.localdomain>
Roland McGrath writes:
> Are there any powerpc instructions that can read or change the MSR
> explicitly from user mode? Any that can see or affect the MSR_SE bit?
No and no.
> e.g. x86 has pushf/popf unprivileged instructions, with which a user
> program can both see the single-step flag set, and enable single-step for
> its own next instruction (presumably when it has a handler for SIGTRAP).
> This actually gets used in arcane places.
On ppc32 there is a sys_debug_setcontext system call that is there to
allow a process to debug itself. It does a setcontext and optionally
sets the MSR_SE or MSR_BE bit. We don't have it on ppc64 for some
reason (we should add it).
> I recall being told before there's no unprivileged way to see or touch
> MSR_SE. But it looks to me like a user program can set the bit in a
> sigcontext and sigreturn to set it. Is that intentionally supported?
The only MSR bit that sigreturn copies from the signal frame back into
the MSR is the MSR_LE (little-endian) bit. I just checked the various
forms (rt/non-rt, 32/64 bit) and they all do that as far as I can
see. If you see a path where we restore more than that let me know.
We do also use the MSR_VEC and MSR_SPE bits in the MSR image in the
signal frame to indicate whether the frame contains altivec or SPE
bits, but those bits don't get put back into the MSR on signal return.
> Or could sigreturn ignore the MSR_SE bit without breaking any strange user?
It already does AFAICS.
> On x86 do we some machinations so that PTRACE_GETREGS et al show the
> single-step bit set if user-mode itself had set it, but not if
> PTRACE_SINGLESTEP set it. If you use PTRACE_SETREGS et al to set the
> single-step bit, then it stays set even if you use PTRACE_CONT.
>
> I'd like to clean this up for powerpc too. If there is no way at all for
> user-mode to set MSR_SE, then it doesn't much matter whether it shows up
> when ptrace reads it--ptrace just needs to ignore attempts to set it. So
> if there's no reason not to, what I would do is remove MSR_SE from the
> MSR_DEBUGCHANGE mask and make sigreturn always clear MSR_SE.
MSR_DEBUGCHANGE is already gone. I don't mind making sigreturn clear
MSR_SE (should setcontext do so too?), but please give me a nice
detailed explanation why we should do that, and why we don't want to
do what we do at present, which is that sigreturn doesn't affect the
process's MSR at all (well, just the LE bit).
Paul.
^ permalink raw reply
* Re: unprivileged use of MSR_SE
From: Paul Mackerras @ 2008-03-20 4:15 UTC (permalink / raw)
To: Roland McGrath; +Cc: linuxppc-dev
In-Reply-To: <20080320002407.D911C26F995@magilla.localdomain>
Roland McGrath writes:
> I'd like to clean this up for powerpc too. If there is no way at all for
> user-mode to set MSR_SE, then it doesn't much matter whether it shows up
> when ptrace reads it--ptrace just needs to ignore attempts to set it. So
> if there's no reason not to, what I would do is remove MSR_SE from the
> MSR_DEBUGCHANGE mask and make sigreturn always clear MSR_SE.
OK, I found MSR_DEBUGCHANGE, it's in ptrace.c. :) So it only applies
to attempts to change the MSR of a process using ptrace. So, what you
want is just to disallow changing MSR via PTRACE_POKEUSR or
equivalent, then?
Paul.
^ permalink raw reply
* Re: linux-next: Tree for March 20
From: Randy Dunlap @ 2008-03-20 4:21 UTC (permalink / raw)
To: Stephen Rothwell, v4l-dvb-maintainer
Cc: Theodore Tso, Greg KH, LKML, linuxppc-dev, linux-next,
Paul Mackerras, Dan Williams
In-Reply-To: <20080320143953.8d6b5a60.sfr@canb.auug.org.au>
On Thu, 20 Mar 2008 14:39:53 +1100 Stephen Rothwell wrote:
> Hi all,
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> (tar balls at
> http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).
gcc doesn't like nested /* comments:
next-20080320/drivers/media/video/bt8xx/bttv-cards.c:3030:38: warning: "/*" within comment
next-20080320/drivers/media/video/bt8xx/bttv-cards.c:3032:20: warning: "/*" within comment
---
~Randy
^ permalink raw reply
* [PATCH 2/2] Force 4K IOPages when eHEA is present in the machine.
From: Tony Breeds @ 2008-03-20 4:33 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: Olof Johansson, Jan-Bernd Themann
In-Reply-To: <63cdefde19cb2a4adc17ed771f21261673428ce7.1205987625.git.tony@bakeyournoodle.com>
eHEA doesn't work with 64k iopages, If an eHEA /can/ be present in the system
limit iopages to 4k.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/mm/hash_utils_64.c | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 590f1f6..4fd5e8a 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -302,14 +302,37 @@ static int __init htab_dt_scan_page_sizes(unsigned long node,
return 0;
}
+#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_PPC_64K_PAGES)
+static int __init scan_dt_for_ehea(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ if (depth != 0)
+ return 0;
+
+ if (of_flat_dt_search(node, "HEA ", "ibm,drc-names"))
+ return 1;
+
+ return 0;
+}
+#endif
+
+
static void __init htab_init_page_sizes(void)
{
int rc;
+#ifdef CONFIG_PPC_64K_PAGES
+ int has_ehea = 0;
+#endif
/* Default to 4K pages only */
memcpy(mmu_psize_defs, mmu_psize_defaults_old,
sizeof(mmu_psize_defaults_old));
+#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_PPC_64K_PAGES)
+ /* Scan to see if this system can have an EHEA, if so we'll
+ * demote io_psize to 4K */
+ has_ehea = of_scan_flat_dt(scan_dt_for_ehea, NULL);
+#endif
/*
* Try to find the available page sizes in the device-tree
*/
@@ -351,9 +374,10 @@ static void __init htab_init_page_sizes(void)
mmu_vmalloc_psize = MMU_PAGE_64K;
if (mmu_linear_psize == MMU_PAGE_4K)
mmu_linear_psize = MMU_PAGE_64K;
- if (cpu_has_feature(CPU_FTR_CI_LARGE_PAGE))
- mmu_io_psize = MMU_PAGE_64K;
- else
+ if (cpu_has_feature(CPU_FTR_CI_LARGE_PAGE)) {
+ if (!has_ehea)
+ mmu_io_psize = MMU_PAGE_64K;
+ } else
mmu_ci_restrictions = 1;
}
#endif /* CONFIG_PPC_64K_PAGES */
--
1.5.4.3
^ permalink raw reply related
* [PATCH 1/2] Implement of_flat_dt_search() and use it for of_flat_dt_is_compatible.
From: Tony Breeds @ 2008-03-20 4:33 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: Olof Johansson, Jan-Bernd Themann
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/prom.c | 21 ++++++++++++++-------
include/asm-powerpc/prom.h | 2 ++
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index eac97f4..f73e18b 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -205,25 +205,32 @@ void* __init of_get_flat_dt_prop(unsigned long node, const char *name,
} while(1);
}
-int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
+int __init of_flat_dt_search(unsigned long node, const char *str,
+ const char *prop_name)
{
- const char* cp;
- unsigned long cplen, l;
+ const char *cp;
+ unsigned long plen, l;
- cp = of_get_flat_dt_prop(node, "compatible", &cplen);
+ cp = of_get_flat_dt_prop(node, prop_name, &plen);
if (cp == NULL)
return 0;
- while (cplen > 0) {
- if (strncasecmp(cp, compat, strlen(compat)) == 0)
+ while (plen > 0) {
+ if (strncasecmp(cp, str, strlen(str)) == 0)
return 1;
l = strlen(cp) + 1;
cp += l;
- cplen -= l;
+ plen -= l;
}
return 0;
}
+int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
+{
+
+ return of_flat_dt_search(node, compat, "compatible");
+}
+
static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
unsigned long align)
{
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 78b7b0d..7b587f1 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -134,6 +134,8 @@ extern int __init of_scan_flat_dt(int (*it)(unsigned long node,
void *data);
extern void* __init of_get_flat_dt_prop(unsigned long node, const char *name,
unsigned long *size);
+extern int __init of_flat_dt_search(unsigned long node, const char *str,
+ const char *prop_name);
extern int __init of_flat_dt_is_compatible(unsigned long node, const char *name);
extern unsigned long __init of_get_flat_dt_root(void);
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] Linux >=2.6.24 support for FEC on MPC5200 (not B!)
From: Grant Likely @ 2008-03-20 5:06 UTC (permalink / raw)
To: René Bürgel; +Cc: linuxppc-dev
In-Reply-To: <47D827A5.8040701@unicontrol.de>
On Wed, Mar 12, 2008 at 12:57 PM, Ren=E9 B=FCrgel <r.buergel@unicontrol.de>=
wrote:
> Here is a patch for the lite5200 to get the FEC working again for kernel
> >=3D2.6.24. It was created against Linux 2.6.24.
>
> The FEC driver is also compatible with the MPC5200, not only with the
> MPC5200B, so an according entry was added to the drivers matching list.
> Furthermore the settings for the PHY were entered in the dts file for
> the Lite5200. Note, that this is not exactly the same as in the
> Lite5200B, because the PHY is located at f0003000:01 for the 5200, and
> at :00 for the 5200B. I could test the patch on a Lite5200 and a
> Lite5200B, both booted a kernel via tftp and mounted the root via nfs
> successfully.
> I hope, you can include the patch into the official tree.
Oops, I spoke too soon on picking this up. The patch looks mostly
good, but it does not apply to the head of the tree. Can you please
rebase it on top of Linus' current tree and repost? While you're at
it, I've got a couple of minor comments below that should be
addressed:
> + mdio@3000 {
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> + device_type =3D "mdio";
Drop the device_type property
> + compatible =3D "mpc5200-fec-phy";
should be "mpc5200-mdio" (see current lite5200 for the example)
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: linux-next: Tree for March 20
From: Greg KH @ 2008-03-20 4:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Theodore Tso, LKML, linuxppc-dev, linux-next, Paul Mackerras,
Dan Williams
In-Reply-To: <20080320143953.8d6b5a60.sfr@canb.auug.org.au>
On Thu, Mar 20, 2008 at 02:39:53PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> (tar balls at
> http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).
>
> You can see which trees have been included by looking in the Next/Trees
> file in the source. There are also quilt-import.log and merge.log files
> in the Next directory. Between each merge, the tree was built with
> a ppc64_defconfig for powerpc and an allmodconfig for x86_64.
>
> I have started this tree by reverting the following:
> driver-core/driver-core-remove-no-longer-used-struct-class_device.patch
> should be merged late
> driver-core/ib-convert-struct-class_device-to-struct-device.patch
> conflicts with the infiniband tree
> driver-core/pm-make-wakeup-flags-available-whenever-config_pm-is-set.patch
> breaks non CONFIG_PM builds of drivers/serial/serial_core.c
These should be fixed tomorrow, I have new ones in my inbox to solve
these issues (I hope...)
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: Tree for March 20
From: Stephen Rothwell @ 2008-03-20 6:17 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Tso, Dan, LKML, linuxppc-dev, linux-next, Paul Mackerras,
Williams
In-Reply-To: <20080320045719.GA26938@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On Wed, 19 Mar 2008 21:57:19 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Thu, Mar 20, 2008 at 02:39:53PM +1100, Stephen Rothwell wrote:
> >
> > I have started this tree by reverting the following:
> > driver-core/driver-core-remove-no-longer-used-struct-class_device.patch
> > should be merged late
> > driver-core/ib-convert-struct-class_device-to-struct-device.patch
> > conflicts with the infiniband tree
> > driver-core/pm-make-wakeup-flags-available-whenever-config_pm-is-set.patch
> > breaks non CONFIG_PM builds of drivers/serial/serial_core.c
>
> These should be fixed tomorrow, I have new ones in my inbox to solve
> these issues (I hope...)
Great, I look forward to it.
--
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
* [PATCH v2] [POWERPC] Add AMCC Glacier 460GT eval board dts
From: Stefan Roese @ 2008-03-20 6:34 UTC (permalink / raw)
To: linuxppc-dev
The patch adds the Glacier dts. The Glacier is nearly identical to the
Canyonlands (460EX). Here the differences:
- 4 ethernet ports instead of 2
- no SATA port
- no USB port
Signed-off-by: Stefan Roese <sr@denx.de>
---
This version adds "amcc,glacier" to the toplevel compatible property.
arch/powerpc/boot/dts/glacier.dts | 464 +++++++++++++++++++++++++++++++++++++
1 files changed, 464 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/glacier.dts
diff --git a/arch/powerpc/boot/dts/glacier.dts b/arch/powerpc/boot/dts/glacier.dts
new file mode 100644
index 0000000..7381cdd
--- /dev/null
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -0,0 +1,464 @@
+/*
+ * Device Tree Source for AMCC Glacier (460GT)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,glacier";
+ compatible = "amcc,glacier", "amcc,canyonlands";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ ethernet2 = &EMAC2;
+ ethernet3 = &EMAC3;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,460GT";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <a 4 b 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460gt","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0f0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <10 4 11 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460gt";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460gt";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460gt", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-460gt", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-460gt", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <4>;
+ num-rx-chans = <20>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = < /*TXEOB*/ 6 4
+ /*RXEOB*/ 7 4
+ /*SERR*/ 3 4
+ /*TXDE*/ 4 4
+ /*RXDE*/ 5 4>;
+ desc-base-addr-high = <8>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-460gt", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <b0000000 4 b0000000 50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-460gt", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ interrupts = <6 4>;
+ interrupt-parent = <&UIC1>;
+ };
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1d 4>;
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1e 4>;
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic-460gt", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <3 4>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ compatible = "ibm,zmii-460gt", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601500 8>;
+ has-mdio;
+ };
+
+ RGMII1: emac-rgmii@ef601600 {
+ compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+ reg = <ef601600 8>;
+ has-mdio;
+ };
+
+ TAH0: emac-tah@ef601350 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601350 30>;
+ };
+
+ TAH1: emac-tah@ef601450 {
+ compatible = "ibm,tah-460gt", "ibm,tah";
+ reg = <ef601450 30>;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 10 4
+ /*Wake*/ 1 &UIC2 14 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 11 4
+ /*Wake*/ 1 &UIC2 15 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <8>;
+ cell-index = <1>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ tah-device = <&TAH1>;
+ tah-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC2: ethernet@ef601100 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC2>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 12 4
+ /*Wake*/ 1 &UIC2 16 4>;
+ reg = <ef601100 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <2>;
+ mal-rx-channel = <10>;
+ cell-index = <2>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC3: ethernet@ef601200 {
+ device_type = "network";
+ compatible = "ibm,emac-460gt", "ibm,emac4";
+ interrupt-parent = <&EMAC3>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 13 4
+ /*Wake*/ 1 &UIC2 17 4>;
+ reg = <ef601200 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <3>;
+ mal-rx-channel = <18>;
+ cell-index = <3>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ rgmii-device = <&RGMII1>;
+ rgmii-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIX0: pci@c0ec00000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pcix-460gt", "ibm,plb-pcix";
+ primary;
+ large-inbound-windows;
+ enable-msi-hole;
+ reg = <c 0ec00000 8 /* Config space access */
+ 0 0 0 /* no IACK cycles */
+ c 0ed00000 4 /* Special cycles */
+ c 0ec80000 100 /* Internal registers */
+ c 0ec80100 fc>; /* Internal messaging registers */
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
+ 01000000 0 00000000 0000000c 08000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 0 to 0x3f */
+ bus-range = <0 3f>;
+
+ /* All PCI interrupts are routed to ext IRQ 2 -> UIC1-0 */
+ interrupt-map-mask = <0000 0 0 0>;
+ interrupt-map = < 0000 0 0 0 &UIC1 0 8 >;
+ };
+
+ PCIE0: pciex@d00000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <d 00000000 20000000 /* Config space access */
+ c 08010000 00001000>; /* Registers */
+ dcr-reg = <100 020>;
+ sdr-base = <300>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
+ 01000000 0 00000000 0000000f 80000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 40 to 0x7f */
+ bus-range = <40 7f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 c 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 d 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 e 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
+ };
+
+ PCIE1: pciex@d20000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <1>; /* port number */
+ reg = <d 20000000 20000000 /* Config space access */
+ c 08011000 00001000>; /* Registers */
+ dcr-reg = <120 020>;
+ sdr-base = <340>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
+ 01000000 0 00000000 0000000f 80010000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 80 to 0xbf */
+ bus-range = <80 bf>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 10 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 11 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 12 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.4
^ permalink raw reply related
* Re: [PATCH 1/2] [POWERPC] Add PPC4xx L2-cache support (440GX & 460EX/GT)
From: Stefan Roese @ 2008-03-20 6:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080320102710.4b6d8060.sfr@canb.auug.org.au>
Hi Stephan,
On Thursday 20 March 2008, Stephen Rothwell wrote:
> Just a few trivial things ...
Thanks. Will fix and resubmit.
Best regards,
Stefan
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Olaf Hering @ 2008-03-20 6:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18400.41990.995316.729968@cargo.ozlabs.ibm.com>
On Wed, Mar 19, Paul Mackerras wrote:
> Olaf Hering writes:
>
> > I cant reproduce this bug on my board, but:
> >
> > The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
> > ipic_init() fails. init_ipic_sysfs() will crash in that case.
> >
> > Something like this may fix it:
>
> Is this needed for 2.6.25? Is the system at all usable if ipic_init
> fails?
CONFIG_PPC_MPC51* needs to be disabled for pmac/chrp/bplan .configs.
A full featured ppc32_defconfig will probably catch such errors.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add PPC4xx L2-cache support (440GX & 460EX/GT)
From: Benjamin Herrenschmidt @ 2008-03-20 6:54 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1205847389-17771-1-git-send-email-sr@denx.de>
On Tue, 2008-03-18 at 14:36 +0100, Stefan Roese wrote:
> This patch adds support for the 256k L2 cache found on some IBM/AMCC
> 4xx PPC's. It introduces a common 4xx SoC file (sysdev/ppc4xx_soc.c)
> which currently "only" adds the L2 cache init code. Other common 4xx
> stuff can be added later here.
>
> The L2 cache handling code is just a copy of Eugene's code in arch/ppc
> with small modifications.
>
> Tested on AMCC Taishan 440GX and Canyonlands 460EX.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
It's my understanding that on some 44x platforms, the l2 needs to be
explicitely invalidated on DMAs. Do we know more about that ? I think it
depends on something like the number of masters on the PLB4 or so. I
don't remember the details.
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add PPC4xx L2-cache support (440GX & 460EX/GT)
From: Stefan Roese @ 2008-03-20 7:12 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1205996092.26869.420.camel@pasglop>
On Thursday 20 March 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-03-18 at 14:36 +0100, Stefan Roese wrote:
> > This patch adds support for the 256k L2 cache found on some IBM/AMCC
> > 4xx PPC's. It introduces a common 4xx SoC file (sysdev/ppc4xx_soc.c)
> > which currently "only" adds the L2 cache init code. Other common 4xx
> > stuff can be added later here.
> >
> > The L2 cache handling code is just a copy of Eugene's code in arch/ppc
> > with small modifications.
> >
> > Tested on AMCC Taishan 440GX and Canyonlands 460EX.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
>
> It's my understanding that on some 44x platforms, the l2 needs to be
> explicitely invalidated on DMAs.
Correct.
> Do we know more about that ? I think it
> depends on something like the number of masters on the PLB4 or so. I
> don't remember the details.
The L2 cache on the 440GX is cache coherent (via snooping). On the
440SP/440SPe the L2 cache is partially coherent. The LL (Low Latency) PLB
segment is coherent and the HB (High Bandwidth) PLB segment is unfortunately
not. Here an except from the 440SPe users manual:
"
Cache coherency is limited to the Low Latency (LL) PLB bus and is managed by a
hardware snoop mechanism or software (software that is similar to the
existing CPU L1 cache)
"
So we will need to add something to handle the L2 cache on those platforms
correctly. Not needed on 440GX though.
As for 460EX/GT this is currently not clear yet. I'm working on it with AMCC
right now.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 2/2] Force 4K IOPages when eHEA is present in the machine.
From: Nathan Lynch @ 2008-03-20 7:18 UTC (permalink / raw)
To: Tony Breeds
Cc: Johansson, linuxppc-dev, Paul Mackerras, Olof, Jan-Bernd Themann
In-Reply-To: <262bc32afdde978922b9500c2a83f7c7ed6e4043.1205987625.git.tony@bakeyournoodle.com>
Tony Breeds wrote:
>
> +#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_PPC_64K_PAGES)
> +static int __init scan_dt_for_ehea(unsigned long node, const char *uname,
> + int depth, void *data)
> +{
> + if (depth != 0)
> + return 0;
> +
> + if (of_flat_dt_search(node, "HEA ", "ibm,drc-names"))
> + return 1;
> +
> + return 0;
> +}
> +#endif
Searching ibm,drc-names is necessary, but is it sufficient? That is,
can there be a system that has an HEA adapter without that property
being present? Thinking in particular about single-partition systems
that run without an HMC attached.
> static void __init htab_init_page_sizes(void)
> {
> int rc;
> +#ifdef CONFIG_PPC_64K_PAGES
> + int has_ehea = 0;
> +#endif
>
> /* Default to 4K pages only */
> memcpy(mmu_psize_defs, mmu_psize_defaults_old,
> sizeof(mmu_psize_defaults_old));
>
> +#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_PPC_64K_PAGES)
> + /* Scan to see if this system can have an EHEA, if so we'll
> + * demote io_psize to 4K */
> + has_ehea = of_scan_flat_dt(scan_dt_for_ehea, NULL);
> +#endif
I'm wondering if some of the ifdef stuff could be avoided if you used
a firmware feature bit to signify the limitation (or the lack of it).
The bit could be set during pSeries_probe. Just an idea; I don't feel
that strongly about it.
^ permalink raw reply
* Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
From: Christoph Hellwig @ 2008-03-20 7:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-arch, tony.luck, linux-ia64, linux-kernel, David Miller,
linuxppc-dev, Thomas Gleixner, sparclinux, Paul Mackerras,
Andrew Morton, Ingo Molnar, Roland McGrath, Richard Henderson
In-Reply-To: <alpine.LFD.1.00.0803191935080.3020@woody.linux-foundation.org>
On Wed, Mar 19, 2008 at 07:40:25PM -0700, Linus Torvalds wrote:
>
> And I have to say, I really hate that
>
> ret = arch_ptrace(child, request, addr, data);
> if (ret == -ENOSYS && !forced_successful_syscall_return())
> ret = ptrace_request(child, request, addr, data);
>
> thing. Instead of doing it that ugly way (return value and a special
> per-arch forced_successful_syscall_return() thing), this really smells
> like you just want to change the calling conventions for "arch_ptrace()"
> instead.
>
> Wouldn't it be nicer to just let "arch_ptrace()" return a flag saying
> whether it handled things or not?
I think the easiest and cleanest would be to just drop this whole
series. There's no inherent advantage of
ret = -ENOSYS;
in the arch_ptrace default case over
ret = ptrace_request(...);
^ permalink raw reply
* Re: unprivileged use of MSR_SE
From: Roland McGrath @ 2008-03-20 7:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18401.58282.992971.923754@cargo.ozlabs.ibm.com>
> No and no.
Good and good!
> On ppc32 there is a sys_debug_setcontext system call that is there to
> allow a process to debug itself. It does a setcontext and optionally
> sets the MSR_SE or MSR_BE bit. We don't have it on ppc64 for some
> reason (we should add it).
Wacky. I only looked in signal_64.c, so I didn't notice this.
> The only MSR bit that sigreturn copies from the signal frame back into
> the MSR is the MSR_LE (little-endian) bit.
So it is. I looked right at that and saw something different. It must
have been my psychic abilities trying to tell me about sys_debug_setcontext.
> > Or could sigreturn ignore the MSR_SE bit without breaking any strange user?
>
> It already does AFAICS.
But sys_debug_setcontext doesn't. That is, it has user semantics
(sig_dbg_op.dbg_value) that mean setting MSR_SE. I take it you mean to
preserve that user feature. For the issue I've been talking about that
makes it equivalent to the x86 popf case.
For example, use syscall tracing to stop at the exit from
sys_debug_setcontext (in a call with dbg->dbg_value!=0).
MSR_SE is set, as it should be. Now using PTRACE_CONT or PTRACE_SYSCALL
will clear MSR_SE and resume, breaking the user's behavior.
For the analogous problem on x86, we keep a flag saying whether MSR_SE was
set "artificially" by ptrace or was set "for real" in the user state. We
use a TIF bit, but whatever is optimal. In user_enable_single_step, set
the forced-SE flag if MSR_SE was clear and don't if it was already set.
In user_disable_single_step, clear the forced-SE flag and only if it was
set, clear MSR_SE. With that, debugger-step and user-self-step can cooexist.
> OK, I found MSR_DEBUGCHANGE, it's in ptrace.c. :) So it only applies
> to attempts to change the MSR of a process using ptrace. So, what you
> want is just to disallow changing MSR via PTRACE_POKEUSR or
> equivalent, then?
If there is no way like sys_debug_setcontext to set MSR_SE as proper user
state, then yes. If it is possible for a user task to set its own MSR_SE,
then I'd like the forced-SE flag as above. Then get_user_msr should mask
off MSR_SE when forced-SE is set, and set_user_msr should clear forced-SE
when MSR_SE is set via user_regset (ptrace). That way user_regset calls
can fetch and restore the complete user-visible state, including the state
just after executing a sys_debug_setcontext requesting self-step.
Thanks,
Roland
^ permalink raw reply
* [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc
From: Kamalesh Babulal @ 2008-03-20 7:43 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: jfs-discussion, linuxppc-dev, shaggy, Andrew Morton, linux-ext4,
Balbir Singh
In-Reply-To: <alpine.LFD.1.00.0803161651350.3020@woody.linux-foundation.org>
When filesystem stress on ext2/3 mounted partition with the 2.6.25-rc6 kernel
over the powerpc box, following calls traces are seen for more than 1000 times.
And when the file system stress in run on jfs mounted partition kernel bug is
seen.
INFO: task fsstress:30559 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000ec09f580] [c0000000ec09f620] 0xc0000000ec09f620 (unreliable)
[c0000000ec09f750] [c0000000000108ec] .__switch_to+0x11c/0x154
[c0000000ec09f7e0] [c0000000004a644c] .schedule+0x7a4/0x888
[c0000000ec09f8d0] [c000000000111adc] .inode_wait+0x10/0x28multiple
[c0000000ec09f950] [c0000000004a6e64] .__wait_on_bit+0xa0/0x114
[c0000000ec09fa00] [c00000000011fc10] .__writeback_single_inode+0x124/0x360
[c0000000ec09faf0] [c000000000120308] .sync_sb_inodes+0x220/0x358
[c0000000ec09fba0] [c00000000012051c] .sync_inodes_sb+0xdc/0x120
[c0000000ec09fc80] [c000000000120614] .__sync_inodes+0xb4/0x164
[c0000000ec09fd20] [c00000000012419c] .do_sync+0x74/0xc0
[c0000000ec09fdb0] [c0000000001241fc] .sys_sync+0x14/0x28
[c0000000ec09fe30] [c000000000008734] syscall_exit+0x0/0x40
INFO: task fsstress:30853 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c000000096f1f1c0] [c000000096f1f280] 0xc000000096f1f280 (unreliable)
[c000000096f1f390] [c0000000000108ec] .__switch_to+0x11c/0x154
[c000000096f1f420] [c0000000004a644c] .schedule+0x7a4/0x888
[c000000096f1f510] [c0000000004a6a2c] .io_schedule+0x7c/0xe8
[c000000096f1f5a0] [c000000000126ce8] .sync_buffer+0x68/0x80
[c000000096f1f620] [c0000000004a6c80] .__wait_on_bit_lock+0x8c/0x110
[c000000096f1f6c0] [c0000000004a6d98] .out_of_line_wait_on_bit_lock+0x94/0xc0
[c000000096f1f7b0] [c000000000126fc0] .__lock_buffer+0x48/0x60
[c000000096f1f830] [c000000000128e24] .__bread+0x64/0x108
[c000000096f1f8b0] [c0000000001f0664] .ext2_get_inode+0xf8/0x194
[c000000096f1f950] [c0000000001f0764] .ext2_update_inode+0x64/0x4e4
[c000000096f1fa20] [c00000000011fcf0] .__writeback_single_inode+0x204/0x360
[c000000096f1fb10] [c000000000120af4] .sync_inode+0x44/0x88
[c000000096f1fba0] [c0000000001f0550] .ext2_sync_inode+0x44/0x60
[c000000096f1fc70] [c0000000001eee90] .ext2_sync_file+0x54/0x84
[c000000096f1fd00] [c000000000123f50] .do_fsync+0x90/0x10c
[c000000096f1fda0] [c000000000124000] .__do_fsync+0x34/0x60
[c000000096f1fe30] [c000000000008734] syscall_exit+0x0/0x40
INFO: task fsstress:30859 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000b228f240] [c0000000b228f2e0] 0xc0000000b228f2e0 (unreliable)
[c0000000b228f410] [c0000000000108ec] .__switch_to+0x11c/0x154
[c0000000b228f4a0] [c0000000004a644c] .schedule+0x7a4/0x888
[c0000000b228f590] [c0000000004a6a2c] .io_schedule+0x7c/0xe8
[c0000000b228f620] [c000000000126ce8] .sync_buffer+0x68/0x80
[c0000000b228f6a0] [c0000000004a6e64] .__wait_on_bit+0xa0/0x114
[c0000000b228f750] [c0000000004a6f6c] .out_of_line_wait_on_bit+0x94/0xc0
[c0000000b228f840] [c000000000126bac] .__wait_on_buffer+0x30/0x48
[c0000000b228f8c0] [c00000000012a30c] .sync_dirty_buffer+0xf0/0x160
[c0000000b228f950] [c0000000001f0af8] .ext2_update_inode+0x3f8/0x4e4
[c0000000b228fa20] [c00000000011fcf0] .__writeback_single_inode+0x204/0x360
[c0000000b228fb10] [c000000000120af4] .sync_inode+0x44/0x88
[c0000000b228fba0] [c0000000001f0550] .ext2_sync_inode+0x44/0x60
[c0000000b228fc70] [c0000000001eee90] .ext2_sync_file+0x54/0x84
[c0000000b228fd00] [c000000000123f50] .do_fsync+0x90/0x10c
[c0000000b228fda0] [c000000000124000] .__do_fsync+0x34/0x60
[c0000000b228fe30] [c000000000008734] syscall_exit+0x0/0x40
INFO: task fsstress:30863 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000b239f250] [c0000000b239f340] 0xc0000000b239f340 (unreliable)
[c0000000b239f420] [c0000000000108ec] .__switch_to+0x11c/0x154
[c0000000b239f4b0] [c0000000004a644c] .schedule+0x7a4/0x888
[c0000000b239f5a0] [c0000000004a6a2c] .io_schedule+0x7c/0xe8
[c0000000b239f630] [c000000000126ce8] .sync_buffer+0x68/0x80
[c0000000b239f6b0] [c0000000004a6c80] .__wait_on_bit_lock+0x8c/0x110
[c0000000b239f750] [c0000000004a6d98] .out_of_line_wait_on_bit_lock+0x94/0xc0
[c0000000b239f840] [c000000000126fc0] .__lock_buffer+0x48/0x60
[c0000000b239f8c0] [c00000000012a28c] .sync_dirty_buffer+0x70/0x160
[c0000000b239f950] [c0000000001f0af8] .ext2_update_inode+0x3f8/0x4e4
[c0000000b239fa20] [c00000000011fcf0] .__writeback_single_inode+0x204/0x360
[c0000000b239fb10] [c000000000120af4] .sync_inode+0x44/0x88
[c0000000b239fba0] [c0000000001f0550] .ext2_sync_inode+0x44/0x60
[c0000000b239fc70] [c0000000001eee90] .ext2_sync_file+0x54/0x84
[c0000000b239fd00] [c000000000123f50] .do_fsync+0x90/0x10c
[c0000000b239fda0] [c000000000124000] .__do_fsync+0x34/0x60
[c0000000b239fe30] [c000000000008734] syscall_exit+0x0/0x40
(gdb) p __switch_to
$1 = {struct task_struct *(struct task_struct *, struct task_struct *)} 0xc0000000000107d0 <__switch_to>
(gdb) p/x 0xc0000000000107d0+0x11c
$2 = 0xc0000000000108ec
(gdb) l *0xc0000000000108ec
0xc0000000000108ec is in __switch_to (arch/powerpc/kernel/process.c:356).
351
352 account_system_vtime(current);
353 account_process_vtime(current);
354 calculate_steal_time();
355
356 last = _switch(old_thread, new_thread);
357
358 local_irq_restore(flags);
359
360 return last;
(gdb) p schedule
$3 = {void (void)} 0xc0000000004a5ca8 <.schedule>
(gdb) p/x 0xc0000000004a5ca8+0x7a4
$4 = 0xc0000000004a644c
(gdb) l *0xc0000000004a644c
0xc0000000004a644c is at include/asm/current.h:22.
17
18 static inline struct task_struct *get_current(void)
19 {
20 struct task_struct *task;
21
22 __asm__ __volatile__("ld %0,%1(13)"
23 : "=r" (task)
24 : "i" (offsetof(struct paca_struct, __current)));
25
26 return task;
kernel BUG at fs/mpage.c:476!
cpu 0x0: Vector: 700 (Program Check) at [c0000000c28debd0]
pc: c00000000012f588: .__mpage_writepage+0xd0/0x618
lr: c0000000000c79c0: .write_cache_pages+0x228/0x3e8
sp: c0000000c28dee50
msr: 8000000000029032
current = 0xc000000060ac5850
paca = 0xc000000000663b00
pid = 5254, comm = fsstress
kernel BUG at fs/mpage.c:476!
enter ? for help
[c0000000c28df3d0] c0000000000c79c0 .write_cache_pages+0x228/0x3e8
[c0000000c28df540] c00000000012fb84 .mpage_writepages+0x54/0x8c
[c0000000c28df5e0] c0000000001fe748 .jfs_writepages+0x1c/0x34
[c0000000c28df660] c0000000000c7c20 .do_writepages+0x68/0xa4
[c0000000c28df6e0] c0000000000bfbc0 .__filemap_fdatawrite_range+0x88/0xb8
[c0000000c28df7d0] c0000000000bfe9c .filemap_write_and_wait+0x2c/0x68
[c0000000c28df860] c0000000000c0848 .generic_file_buffered_write+0x65c/0x6c8
[c0000000c28df9a0] c0000000000c0bb4 .__generic_file_aio_write_nolock+0x300/0x3ec
[c0000000c28dfaa0] c0000000000c0d20 .generic_file_aio_write+0x80/0x114
[c0000000c28dfb60] c0000000000f7d7c .do_sync_write+0xc4/0x124
[c0000000c28dfcf0] c0000000000f85b0 .vfs_write+0xd8/0x1a4
[c0000000c28dfd90] c0000000000f8f3c .sys_write+0x4c/0x8c
[c0000000c28dfe30] c000000000008734 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff0d8c8
SP (ffb4c8a0) is in userspace
(gdb) p write_cache_pages
$1 = {int (struct address_space *, struct writeback_control *, writepage_t, void *)} 0xc0000000000c7798 <write_cache_pages>
(gdb) p/x 0xc0000000000c7798+0x228
$2 = 0xc0000000000c79c0
(gdb) l *0xc0000000000c79c0
0xc0000000000c79c0 is in write_cache_pages (mm/page-writeback.c:867).
862 !clear_page_dirty_for_io(page)) {
863 unlock_page(page);
864 continue;
865 }
866
867 ret = (*writepage)(page, wbc, data);
868
869 if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE)) {
870 unlock_page(page);
871 ret = 0;
(gdb) p __mpage_writepage
$3 = {int (struct page *, struct writeback_control *, void *)} 0xc00000000012f4b8 <__mpage_writepage>
(gdb) p/x 0xc00000000012f4b8+0xd0
$4 = 0xc00000000012f588
(gdb) l *0xc00000000012f588
0xc00000000012f588 is in __mpage_writepage (fs/mpage.c:476).
471 struct buffer_head *bh = head;
472
473 /* If they're all mapped and dirty, do it */
474 page_block = 0;
475 do {
476 BUG_ON(buffer_locked(bh));
477 if (!buffer_mapped(bh)) {
478 /*
479 * unmapped dirty buffers are created by
480 * __set_page_dirty_buffers -> mmapped data
(gdb)
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: simple MPC5200B system
From: André Schwarz @ 2008-03-20 7:48 UTC (permalink / raw)
To: Wolfgang Denk, Andre Schwarz, linux-ppc list
In-Reply-To: <20080320002149.GD19616@localhost.localdomain>
David Gibson schrieb:
> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>> In message <47DF821B.6090600@matrix-vision.de> you wrote:
>>> I've pulled the latest git and built a mpc5200_simple system with a=20
>>> minimal dts.
>>> There's not a single char put on the console ....
>> You did build your device tree with "-b 0", didn't you?
>=20
> Ugh.. I really need to fix dtc to pick the default boot cpu value more
> sensibly, don't I.
>=20
I didn't specify "-b 0". This shouldn't be neccessary on a single=20
processor system ! After all it's an option ... "0" should be default.
-->"./dtc -I dts -O dtb -o /mnt/tftpboot/mvbc.dtb -S 8192 dts/mvbc.dts"
The system is running fine (please see discussions with Grant).
regards,
Andr=E9 Schwarz
MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ 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