* Re: RE: atomic operations in user space
From: Olof Johansson @ 2006-08-30 6:33 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <995B09A8299C2C44B59866F6391D263511BB62@zch01exm21.fsl.freescale.net>
On Wed, Aug 30, 2006 at 10:55:39AM +0800, Liu Dave-r63238 wrote:
> Can we do atomic operation in user space as kernel space?
Yes.
-Olof
^ permalink raw reply
* Atomic operations in user space: Yes but No
From: Benjamin Herrenschmidt @ 2006-08-30 7:00 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <20060830063333.GA16468@pb15.lixom.net>
On Wed, 2006-08-30 at 01:33 -0500, Olof Johansson wrote:
> On Wed, Aug 30, 2006 at 10:55:39AM +0800, Liu Dave-r63238 wrote:
>
> > Can we do atomic operation in user space as kernel space?
Ok, let's hope that clarifies it for everybody.
Atomic operations in user space are possible using reservations
(lwarx/stwcx. or their 64 bits counterpart). However they are very much
not recommended.
The reason they work is that the kernel always clears all pending
reservations in the exception path, thus if there is a task switch, an
interrupt or anything that can break the user program flow in the middle
of it's lwarx/stwcx. loop, the kernel will return to userspace with all
reservations cleared, thus causing stwcx. to fail.
However, they are not recommended unless you know VERY WELL what you are
doing. When I say, VERY WELL in all uppercases, I really mean it. That
is examples in books etc... are usually not enough to know very well
what you are doing :) There are three issues at hand at least that I
know about use of lwarx/stwcx, from the less to the most important:
- Processor erratas. For example, the 405 requires a sync in an atomic
loop. The kernel has a mecanism to have those sync's in and eventually
comment them out at runtime. Future processors might have different
erratas regarding those instructions. It's better to keep their usage
local to the kernel and/or glibc to avoid having to fix too much
userland problems when that happens.
- Performance issues and possible livelocks. There are both processor
and bus starvation issues related to the use of atomics. On some
processors, it's very recommended for example, when a lock operation
fails, to go do something else for a while (intentional branch
mispredict for example) before trying again. In general, there are
issues with cache lines used for lwarx/stwcx. ping-ponging all over the
fabric on some heavy duty SMP machines if great care isn't taken with
the way atomics or locks are laid out in memory and shared among
threads.
- Correctness vs. storage ordering. That's the biggest one. Almost
every time I've seen userland code try to do their own atomic stuffs, it
was done without full understanding of the out of order storage model of
the PowerPC architecture and thus without appropriate barriers. This is
a complicated topic and thus I won't get into a long explanation here,
but let's say that outside of pure atomic "counters" that have no
specific ordering requirements or no locking/exclusion semantics vs. the
execution flow, you should _not_ try to do it yourself with atomics, but
instead use some of the primitives provided by glibc. With NPTL,
nowadays, glibc provides pretty fast implementations that do not use the
kernel unless there is contention.
So yes, you can, but most of the time, you should not.
Cheers,
Ben.
^ permalink raw reply
* [POWERPC] iseries: define some more i/o accessor functions
From: Stephen Rothwell @ 2006-08-30 7:11 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
These are merely build fixes that enable (for example) libata and the
ide code to actually build on iSeries. The associated hardware will
never be supported on legacy iSeries, so the code paths don't actually
need to work, but it is useful (especially for a combined kernel) if
the code can build.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/io.h | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
Paul, please consider this for 2.6.18 as it does fix the build if you
happen to enable IDE or SATA on iSeries, currently.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index a9496f3..36c4c34 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -72,6 +72,9 @@ #define outl(data,addr) writel(data,((v
* Neither do the standard versions now, these are just here
* for older code.
*/
+#define insb(port, buf, ns) _insb((u8 __iomem *)((port)+pci_io_base), (buf), (ns))
+#define insw(port, buf, ns) _insw_ns((u8 __iomem *)((port)+pci_io_base), (buf), (ns))
+#define insl(port, buf, nl) _insl_ns((u8 __iomem *)((port)+pci_io_base), (buf), (nl))
#define insw_ns(port, buf, ns) _insw_ns((u16 __iomem *)((port)+pci_io_base), (buf), (ns))
#define insl_ns(port, buf, nl) _insl_ns((u32 __iomem *)((port)+pci_io_base), (buf), (nl))
#else
@@ -137,12 +140,12 @@ #define insl(port, buf, nl) eeh_insl_ns(
#define insw_ns(port, buf, ns) eeh_insw_ns((port), (buf), (ns))
#define insl_ns(port, buf, nl) eeh_insl_ns((port), (buf), (nl))
+#endif
+
#define outsb(port, buf, ns) _outsb((u8 __iomem *)((port)+pci_io_base), (buf), (ns))
#define outsw(port, buf, ns) _outsw_ns((u16 __iomem *)((port)+pci_io_base), (buf), (ns))
#define outsl(port, buf, nl) _outsl_ns((u32 __iomem *)((port)+pci_io_base), (buf), (nl))
-#endif
-
#define readb_relaxed(addr) readb(addr)
#define readw_relaxed(addr) readw(addr)
#define readl_relaxed(addr) readl(addr)
--
1.4.1.1
^ permalink raw reply related
* Re: libnuma interleaving oddness
From: Andi Kleen @ 2006-08-30 7:19 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, linux-mm, lnxninja, Christoph Lameter
In-Reply-To: <20060830002110.GZ5195@us.ibm.com>
mous pages.
>
> The order is (with necessary params filled in):
>
> p = mmap( , newsize, RW, PRIVATE, unlinked_hugetlbfs_heap_fd, );
>
> numa_interleave_memory(p, newsize);
>
> mlock(p, newsize); /* causes all the hugepages to be faulted in */
>
> munlock(p,newsize);
>
> From what I gathered from the numa manpages, the interleave policy
> should take effect on the mlock, as that is "fault-time" in this
> context. We're forcing the fault, that is.
mlock shouldn't be needed at all here. the new hugetlbfs is supposed
to reserve at mmap time and numa_interleave_memory() sets a VMA
policy which will should do the right thing no matter when the fault
occurs.
Hmm, maybe mlock() policy() is broken.
-Andi
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Andi Kleen @ 2006-08-30 7:16 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, Nishanth Aravamudan, lnxninja, linux-mm
In-Reply-To: <Pine.LNX.4.64.0608291655160.22397@schroedinger.engr.sgi.com>
On Wednesday 30 August 2006 01:57, Christoph Lameter wrote:
> On Tue, 29 Aug 2006, Nishanth Aravamudan wrote:
>
> > I don't know if this is a libnuma bug (I extracted out the code from
> > libnuma, it looked sane; and even reimplemented it in libhugetlbfs for
> > testing purposes, but got the same results) or a NUMA kernel bug (mbind
> > is some hairy code...) or a ppc64 bug or maybe not a bug at all.
> > Regardless, I'm getting somewhat inconsistent behavior. I can provide
> > more debugging output, or whatever is requested, but I wasn't sure what
> > to include. I'm hoping someone has heard of or seen something similar?
>
> Are you setting the tasks allocation policy before the allocation or do
> you set a vma based policy? The vma based policies will only work for
> anonymous pages.
They should work for hugetlb/shmfs too. At least when I originally
wrote it. But the original patch I did for hugetlbfs for that was
never merged and I admit I have never rechecked if it worked with
the patchkit that was merged later. The problem originally was
that hugetlbfs needed to be changed to do allocate-on-demand
instead of allocation-on-mmap, because mbind() comes after mmap()
and when mmap() already allocates it can't work.
-Andi
^ permalink raw reply
* booting Linux in Linux using kexec tools
From: Reddy Suneel-ASR125 @ 2006-08-30 7:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
Hi
I am trying to boot Linux (zImage.elf) in Linux using kexec tools.
I am getting the folling crash
sh-2.05b#
sh-2.05b# kexec -e
Shutting down gianfar ethernet
Shutting down gianfar ethernet
Shutting down gianfar ethernet
Starting new kernel
Bye!
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: 2E5C0020 LR: C000A3CC SP: C8D97DF0 REGS: c8d97d40 TRAP: 0400 Not
taintedMSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = c82f84a0[665] 'kexec' THREAD: c8d96000
Last syscall: 88
GPR00: 00000000 C8D97DF0 C82F84A0 2E5C1002 2E5C0000 00000000 00000F35
C0307DBC
GPR08: 2E5C0020 C0350000 00000000 C8D96000 00000000 10030450 00000220
100CBD88
GPR16: FFFFFFFF 00000000 00000000 00000000 00000000 00000000 FFFFFFFF
42202442
GPR24: 100D71C8 100D7508 2E5C1002 C0A8DC80 EE5C0000 2E5C0000 00000000
C0A8DC80
Call trace: [c000a2fc] [c00302d0] [c000206c]
Segmentation fault
sh-2.05b#
I am working on MPC8540 processor.
can any one help me.
Thanks®ards
Suneel
[-- Attachment #2: Type: text/html, Size: 2535 bytes --]
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Nishanth Aravamudan @ 2006-08-30 7:29 UTC (permalink / raw)
To: Andi Kleen; +Cc: linuxppc-dev, linux-mm, lnxninja, Christoph Lameter
In-Reply-To: <200608300919.13125.ak@suse.de>
On 30.08.2006 [09:19:13 +0200], Andi Kleen wrote:
> mous pages.
> >
> > The order is (with necessary params filled in):
> >
> > p = mmap( , newsize, RW, PRIVATE, unlinked_hugetlbfs_heap_fd, );
> >
> > numa_interleave_memory(p, newsize);
> >
> > mlock(p, newsize); /* causes all the hugepages to be faulted in */
> >
> > munlock(p,newsize);
> >
> > From what I gathered from the numa manpages, the interleave policy
> > should take effect on the mlock, as that is "fault-time" in this
> > context. We're forcing the fault, that is.
>
> mlock shouldn't be needed at all here. the new hugetlbfs is supposed
> to reserve at mmap time and numa_interleave_memory() sets a VMA policy
> which will should do the right thing no matter when the fault occurs.
Ok.
> Hmm, maybe mlock() policy() is broken.
I took out the mlock() call, and I get the same results, FWIW.
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Andi Kleen @ 2006-08-30 7:32 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linuxppc-dev, linux-mm, lnxninja, Christoph Lameter
In-Reply-To: <20060830072948.GE5195@us.ibm.com>
On Wednesday 30 August 2006 09:29, Nishanth Aravamudan wrote:
>
> > Hmm, maybe mlock() policy() is broken.
>
> I took out the mlock() call, and I get the same results, FWIW.
Then it's probably some new problem in hugetlbfs. Does it work with shmfs?
The regression test for hugetlbfs is numactl is unfortunately still disabled.
I need to enable it at some point for hugetlbfs now that it reached mainline.
-Andi
^ permalink raw reply
* Re: Linux v2.6.18-rc5
From: Olaf Hering @ 2006-08-30 8:05 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Linus Torvalds, Nathan Lynch,
Linux Kernel Mailing List
In-Reply-To: <17653.11388.637189.113422@cargo.ozlabs.ibm.com>
On Wed, Aug 30, Paul Mackerras wrote:
> This works fine on my G4 tibook. Let me know how it goes on your
> machines.
Works ok on an iBook1.
^ permalink raw reply
* re: PPC405 system slow boot
From: Arvid Staub @ 2006-08-30 8:20 UTC (permalink / raw)
To: Clint Thomas, linuxppc-embedded
hi!
i've recently had a similar situation with a XC2VP50-based custom board.
There was no SystemACE involved, we load the FPGA via a CPLD/serial =
flash.
the problem resided in the interrupt controller, which was not able to =
enable interrupts due to an error in the MHS file.
you should check that your interrupt controller section includes the =
following parameters:
PARAMETER C_HAS_IPR =3D 1
PARAMETER C_HAS_SIE =3D 1
PARAMETER C_HAS_CIE =3D 1
PARAMETER C_HAS_IVR =3D 1
the intc driver uses SIE and CIE to atomically enable and disable =
interrupts.
when the uartlite interrupt was not enabled, the uartlite driver =
encountered timeouts which caused single characters to appear at the =
serial console, similar to what you described.
hope that helps,
arvid staub
________________________________________
Von: linuxppc-embedded-bounces+arvid.staub=3Dmediornet.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+arvid.staub=3Dmediornet.com@ozlabs.org]=
Im Auftrag von Clint Thomas
Gesendet: Montag, 28. August 2006 21:57
An: linuxppc-embedded@ozlabs.org
Betreff: PPC405 system slow boot
Hey guys,
I've run through the loops to try and figure what could be wrong with =
this system. The board in question is modeled after the Xilinx ML300 =
board. It uses a Xilinx System ACE chip to load a FPGA / Kernel image =
from compact flash. Originally, I was trying to use the CompactFlash as =
the root file system, but because of issues in either the design or =
software, this would only work if SysAce was in polled I/O mode. To =
circumvent this, I built my root filesystem into an initrd image and =
built a single ELF file with the Kernel and RFS, then strapped that to =
the FPGA bit file to make a single FPGA/Kernel/RFS SysAce file.
Upon decompression, the Linux kernel boots quickly and loads all of the =
device drivers. However when it gets to the prompt, it starts slowing =
down. Output and input to and from the board becomes very very slow (it =
displays 2 characters roughly every 20 seconds). Originally I believed =
this to be the CPU still polling SystemAce, so I disabled the Linux =
System ACE drivers to remove that as a possibility, however after doing =
this, the problem still persists, even with the RFS in ram! Has anybody =
encountered a similar situation to this before, with possible insight =
towards a solution? Thank you for your time.
=A0
Clinton Thomas
cthomas@soneticom.com
=A0
^ permalink raw reply
* Re: [PATCH 02/13] IB/ehca: includes
From: Hoang-Nam Nguyen @ 2006-08-30 9:13 UTC (permalink / raw)
To: abergman, linux-kernel, linuxppc-dev, openib-general
Cc: Christoph Raisch, Marcus Eder
In-Reply-To: <OFED0915E4.3CED6795-ONC12571CE.0053ECB8-C12571CE.0055546A@LocalDomain>
> Christoph Raisch wrote on 18.08.2006 17:35:54:
> we'll change these EDEBs to a wrapper around dev_err, dev_dbg and
> dev_warn as it's done in the mthca driver.
> All EDEB_EN and EDEB_EX will be removed, that type of tracing can be
> done if needed by kprobes.
> There are a few cases where we won't get to a dev, for these few
> places we'll use a simple wrapper around printk, as done in ipoib.
We incorporated those changes throughout ehca code, which is accessible
from
Roland's git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-2.6.19
Further comments/suggestions are appreciated!
Regards
Hoang-Nam Nguyen
^ permalink raw reply
* Re: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: David Howells @ 2006-08-30 9:09 UTC (permalink / raw)
To: Russell King
Cc: linux-mips, linux-ia64, takata, linux-kernel, paulkf,
linuxppc-embedded
In-Reply-To: <20060828085244.GA13544@flint.arm.linux.org.uk>
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> --- a/arch/frv/kernel/setup.c
> +++ b/arch/frv/kernel/setup.c
> @@ -31,7 +31,6 @@
> #include <linux/serial_reg.h>
>
> #include <asm/setup.h>
> -#include <asm/serial.h>
> #include <asm/irq.h>
> #include <asm/sections.h>
> #include <asm/pgalloc.h>
Acked-By: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: Linux v2.6.18-rc5
From: Mikael Pettersson @ 2006-08-30 9:00 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, Olaf Hering, Nathan Lynch, Linus Torvalds,
Linux Kernel Mailing List
In-Reply-To: <17653.11388.637189.113422@cargo.ozlabs.ibm.com>
Paul Mackerras writes:
> Olaf,
>
> This patch should fix it. The problem was that I was comparing a
> 32-bit quantity with a 64-bit quantity, and consequently time wasn't
> advancing. This makes us use a 64-bit quantity on all platforms,
> which ends up simplifying the code since we can now get rid of the
> tb_last_stamp variable (which actually fixes another bug that Ben H
> and I noticed while going carefully through the code).
>
> This works fine on my G4 tibook. Let me know how it goes on your
> machines.
Thanks. This fixed a kernel hang bug on my G4 eMac with 2.6.18-rc5.
The vanilla kernel ran fine until I tar xvf'd a file from an NFS-mount,
then everything ground to a halt.
/Mikael
^ permalink raw reply
* Re: [PATCH 02/13] IB/ehca: includes
From: Arnd Bergmann @ 2006-08-30 9:43 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, openib-general, Christoph Raisch, Hoang-Nam Nguyen,
Marcus Eder, abergman
In-Reply-To: <OF23CA96AE.C7DBFD52-ONC12571DA.00321849-C12571DA.00324865@de.ibm.com>
On Wednesday 30 August 2006 11:13, Hoang-Nam Nguyen wrote:
> Further comments/suggestions are appreciated!
There are a few places in the driver where you declare
external variables (mostly ehca_module and ehca_debug_level)
from C files instead of a header. This sometimes leads
to bugs when a type changes and is therefore considered
bad style.
ehca_debug_level is already declared in a header so you
should not need any other declaration.
For ehca_module, the usage pattern is very uncommon.
Declaring the structure in a header helps a bit, but I
don't really see the need for this structure at all.
Each member of the struct seems to be used mostly in a
single file, so I would declare it statically in there.
E.g. in drivers/infiniband/hw/ehca/ehca_pd.c, you can do
static struct kmem_cache *ehca_pd_cache;
int ehca_init_pd_cache(void)
{
ehca_pd_cache = kmem_cache_init("ehca_cache_pd",
sizeof(struct ehca_pd), 0, SLAB_HWCACHE_ALIGN,
NULL, NULL);
if (!ehca_pd_cache)
return -ENOMEM;
return 0;
}
void ehca_cleanup_pd_cache(void)
{
if (ehca_pd_cache)
kmem_cache_destroy(ehca_pd_cache);
}
Moreover, for some of your more heavily used caches, you may
want to look into using constructor/destructor calls to
speed up allocation.
Arnd <><
^ permalink raw reply
* Re: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
From: Gerhard Pircher @ 2006-08-30 9:01 UTC (permalink / raw)
To: Marcus Comstedt; +Cc: linuxppc-dev
In-Reply-To: <yf9mz9np82b.fsf@omoikane.mc.pp.se>
-------- Original-Nachricht --------
Datum: Tue, 29 Aug 2006 23:04:44 +0200
Von: Marcus Comstedt <marcus@mc.pp.se>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
Betreff: Re: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
>
> "Gerhard Pircher" <gerhard_pircher@gmx.net> writes:
>
> > Hi Marcus,
> >
> > I guess this message should also be forwarded to
> > linux-usb-devel@lists.sourceforge.net. I hope the developers there can
> > make some comments.
> >
> > Gerhard
>
>
> Well, I figured the first thing to do would be to reach a consensus
> here on whether or not atomic_t:s in DMA memory should be ruled as
> unallowed. Judging from the massive silence, there doesn't seem to be
> any strong opinions either way though...
>
>
> // Marcus
>
You're right. Maybe it's a topic for the linuxppc-embedded mailing list, because mostly embedded platforms use the CONFIG_NOT_COHERENT_CACHE option.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Fwd: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Russell King @ 2006-08-30 9:28 UTC (permalink / raw)
To: linuxppc-dev
Maybe this should've gone to linuxppc-dev? Can PPC folk please look
at the PPC bits of this patch, and also decide whether the following
can also have asm/serial.h removed:
arch/ppc/4xx_io/serial_sicc.c
arch/ppc/boot/simple/mpc52xx_tty.c
arch/ppc/boot/simple/mv64x60_tty.c
Thanks.
----- Forwarded message from Russell King <rmk+lkml@arm.linux.org.uk> -----
Date: Mon, 28 Aug 2006 09:52:44 +0100
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: linux-ia64@vger.kernel.org, linux-mips@linux-mips.org,
linuxppc-embedded@ozlabs.org, paulkf@microgate.com,
takata@linux-m32r.org, linux-kernel@vger.kernel.org
Subject: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
asm/serial.h is supposed to contain the definitions for the architecture
specific 8250 ports for the 8250 driver. It may also define BASE_BAUD,
but this is the base baud for the architecture specific ports _only_.
Therefore, nothing other than the 8250 driver should be including this
header file. In order to move towards this goal, here is a patch which
removes some of the more obvious incorrect includes of the file.
MIPS and PPC has rather a lot of stuff in asm/serial.h, some of it looks
related to non-8250 ports. Hence, it's not trivial to conclude that
these includes are indeed unnecessary, so can mips and ppc people please
test this patch carefully.
Thanks.
diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
--- a/arch/frv/kernel/setup.c
+++ b/arch/frv/kernel/setup.c
@@ -31,7 +31,6 @@
#include <linux/serial_reg.h>
#include <asm/setup.h>
-#include <asm/serial.h>
#include <asm/irq.h>
#include <asm/sections.h>
#include <asm/pgalloc.h>
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -54,7 +54,6 @@
#include <asm/processor.h>
#include <asm/sal.h>
#include <asm/sections.h>
-#include <asm/serial.h>
#include <asm/setup.h>
#include <asm/smp.h>
#include <asm/system.h>
diff --git a/arch/mips/cobalt/setup.c b/arch/mips/cobalt/setup.c
--- a/arch/mips/cobalt/setup.c
+++ b/arch/mips/cobalt/setup.c
@@ -23,7 +23,6 @@
#include <asm/processor.h>
#include <asm/reboot.h>
#include <asm/gt64120.h>
-#include <asm/serial.h>
#include <asm/mach-cobalt/cobalt.h>
diff --git a/arch/mips/lasat/setup.c b/arch/mips/lasat/setup.c
--- a/arch/mips/lasat/setup.c
+++ b/arch/mips/lasat/setup.c
@@ -34,7 +34,6 @@
#include <asm/cpu.h>
#include <asm/bootinfo.h>
#include <asm/irq.h>
-#include <asm/serial.h>
#include <asm/lasat/lasat.h>
#include <asm/lasat/serial.h>
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -51,7 +51,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -38,7 +38,6 @@
#include <asm/nvram.h>
#include <asm/xmon.h>
#include <asm/time.h>
-#include <asm/serial.h>
#include <asm/udbg.h>
#include "setup.h"
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -51,7 +51,6 @@
#include <asm/system.h>
#include <asm/rtas.h>
#include <asm/iommu.h>
-#include <asm/serial.h>
#include <asm/cache.h>
#include <asm/page.h>
#include <asm/mmu.h>
diff --git a/drivers/char/pcmcia/synclink_cs.c b/drivers/char/pcmcia/synclink_cs.c
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -57,7 +57,6 @@
#include <linux/netdevice.h>
#include <linux/vmalloc.h>
#include <linux/init.h>
-#include <asm/serial.h>
#include <linux/delay.h>
#include <linux/ioctl.h>
diff --git a/drivers/char/synclink.c b/drivers/char/synclink.c
--- a/drivers/char/synclink.c
+++ b/drivers/char/synclink.c
@@ -87,7 +87,6 @@
#include <linux/vmalloc.h>
#include <linux/init.h>
-#include <asm/serial.h>
#include <linux/delay.h>
#include <linux/ioctl.h>
diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
--- a/drivers/serial/m32r_sio.c
+++ b/drivers/serial/m32r_sio.c
@@ -76,17 +76,16 @@
*/
#define is_real_interrupt(irq) ((irq) != 0)
-#include <asm/serial.h>
+#define BASE_BAUD 115200
/* Standard COM flags */
#define STD_COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
/*
* SERIAL_PORT_DFNS tells us about built-in ports that have no
* standard enumeration mechanism. Platforms that can find all
* serial ports via mechanisms like ACPI or PCI need not supply it.
*/
-#undef SERIAL_PORT_DFNS
#if defined(CONFIG_PLAT_USRV)
#define SERIAL_PORT_DFNS \
@@ -109,7 +108,7 @@
#endif /* !CONFIG_PLAT_USRV */
static struct old_serial_port old_serial_port[] = {
- SERIAL_PORT_DFNS /* defined in asm/serial.h */
+ SERIAL_PORT_DFNS
};
#define UART_NR ARRAY_SIZE(old_serial_port)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
--
Russell King
^ permalink raw reply
* Re: Fwd: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Paul Mackerras @ 2006-08-30 10:02 UTC (permalink / raw)
To: Russell King; +Cc: linuxppc-dev, trini
In-Reply-To: <20060830092827.GB19689@flint.arm.linux.org.uk>
Russell King writes:
> Maybe this should've gone to linuxppc-dev? Can PPC folk please look
> at the PPC bits of this patch, and also decide whether the following
> can also have asm/serial.h removed:
>
> arch/ppc/4xx_io/serial_sicc.c
> arch/ppc/boot/simple/mpc52xx_tty.c
> arch/ppc/boot/simple/mv64x60_tty.c
The situation is that arch/ppc is the old world. Platforms are being
moved over to arch/powerpc as fast as we can manage, where things will
be much cleaner because the information about type and location of
serial ports (among other things) will be supplied via a device tree
rather than hardcoded in header files. This means, though, that there
isn't much motivation for cleaning up stuff in arch/ppc.
The two users in arch/ppc/boot aren't really part of the kernel
proper. The compressed image bootwrapper uses definitions from
serial.h on some platforms to access a serial port for interaction
with the user. It may be possible to replicate the string of #ifdefs
and #includes from serial.h in those files. Tom Rini can best advise
about that.
The serial_sicc.c code looks like it should be converted to use the
serial_core stuff. I hope that will get done in the process of moving
4xx over to arch/powerpc.
Paul.
^ permalink raw reply
* Re: IPSec kernel oops on ppc64
From: Herbert Xu @ 2006-08-30 11:09 UTC (permalink / raw)
To: Joy Latten, paulus, anton, linuxppc-dev; +Cc: jmorris, gcwilson, davem, netdev
In-Reply-To: <20060829013023.GA5865@gondor.apana.org.au>
Hi:
Thanks to some excellent info from Joy, I've trakced the problem down to
a broken implementation of memmove on ppc64, which in turn is due to a
broken memcpy.
Both memmove and memcpy need to return the destination pointer as per
the C standard. The ppc64 version of memcpy returns a pointer to the
last byte copied instead. Since memmove degenerates into memcpy in
some cases, this makes it broken as well.
Something like the following patch should fix the problem. Be warned
that I know absolutely nothing about ppc assembly so don't come back
to me if this patch eats your disk :)
BTW, I spotted a couple of typos in memcpy_64.S/copyuser_64.S where
"cmpldi cr1,..." became "cmpldi r1,...". So please fix that up while
you ppc64 guys are at it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S
index fd66acf..9e8d9e7 100644
--- a/arch/powerpc/lib/memcpy_64.S
+++ b/arch/powerpc/lib/memcpy_64.S
@@ -11,6 +11,7 @@ #include <asm/ppc_asm.h>
.align 7
_GLOBAL(memcpy)
+ std r3,-8(r1)
mtcrf 0x01,r5
cmpldi cr1,r5,16
neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry
@@ -53,7 +54,8 @@ _GLOBAL(memcpy)
2: bf cr7*4+3,3f
rotldi r9,r9,8
stb r9,0(r3)
-3: blr
+3: ld r3,-8(r1)
+ blr
.Lsrc_unaligned:
srdi r6,r5,3
@@ -167,4 +169,5 @@ _GLOBAL(memcpy)
3: bf cr7*4+3,4f
lbz r0,0(r4)
stb r0,0(r3)
-4: blr
+4: ld r3,-8(r1)
+ blr
^ permalink raw reply related
* DS1302 driver for powerpc
From: Chun Chung Lo @ 2006-08-30 11:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am now doing a STB project and the development board uses a DS1302
(trickle charge timekeeping chip) as a RTC. Our board is a IBM PPC405EP
with a linux kernel 2.4.20 running on it. And the DS1302 is controlled
by 2 GPIO pins instead of I2C.=0D
I would like to ask are there any porting of DS1302 support under ppc
architecture? (I can only find DS1302 is supported under cris
architecture.)
Thanks all.
Best regards,
Lo Chun Chung
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* 2 Ethernet port operating in a PPC405EP system
From: Chun Chung Lo @ 2006-08-30 12:19 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Sorry for such long e-mail.
I am now working on a STB project, and our board is a IBM PPC405EP with
2 ethernet ports. U-Boot 1.0.0 and linux 2.4.20 (from MontaVista) is
used and update is not recommended. Each ethernet port has a RTL8021CP
PHY connected.=0D
Under u-boot environment, only 1 ethernet port is operating. But
sometimes the port is not able to PING other PCs within the same subnet.
Also some modifications are made (under bd_t) to let linux kernel fetch
2 different MAC address when boot into linux kernel.
Error log (U-Boot):
<## snip ##>
Hit any key to stop autoboot: 0
=3D> setenv ipaddr 10.6.64.343
=3D> setenv ipaddr 10.6.64.34
=3D> ping 10.6.64.128
ENET Speed is 100 Mbps - FULL duplex connection
< the board holds here about several seconds >
ping failed; host 10.6.64.128 is not alive
<## snip ##>
Under linux environment, 2 ethernet ports are operating. But sometimes
only ethernet 1 is operating (by running a udhcpc, from
busybox-v1.00-pre8); sometimes both are not operating.=0D
When ethernet 1 is operating (can fetch a IP address from DHCP server,
say 10.6.64.111), then I assigned a static IP address (say,
192.168.1.120) and let the board PING to different subnets at the same
time. But the ethernet 2 cannot PING out while ethernet 1 is operating
...=0D
Error log (Linux):
<## snip ##>
Press CTRL-C to enter shell within 1 sec
~ # udhcpc -i eth0 -s /etc/udhcpc.sh
info, udhcpc (v0.9.9-pre) started
debug, Sending discover...
debug, Sending discover...
< the ethernet port 1 goes wrong and cannot get IP from DHCP server,
until I plug and unplug the ethernet cable several times, it works again
>
debug, Sending discover...
debug, Sending select for 10.6.64.197...
info, Lease of 10.6.64.197 obtained, lease time 691200
deleting routers
SIOCDELRT: No such process
adding dns 10.6.2.11
adding dns 10.6.2.12
~ # ping 10.6.64.128
PING 10.6.64.128 (10.6.64.128): 56 data bytes
64 bytes from 10.6.64.128: icmp_seq=3D0 ttl=3D64 time=3D9.4 ms
64 bytes from 10.6.64.128: icmp_seq=3D1 ttl=3D64 time=3D0.3 ms
64 bytes from 10.6.64.128: icmp_seq=3D2 ttl=3D64 time=3D0.3 ms
--- 10.6.64.128 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max =3D 0.3/3.3/9.4 ms
~ # ifconfig eth1 192.168.1.120
EMAC1 open, with PHY @ 0x13
ibm_ocp_phy.c: cclo - fep->link =3D 1
------ phy: RTL8201CP, mii_parse_anar(0x000001e1), phy=3D0x13 ------
eth1: IBM EMAC: link up, 100 Mbps Full Duplex, auto-negotiation
complete.
eth1: IBM EMAC: MAC cc:0b:20:08:21:b2.
~ # ping 192.168.1.123
PING 192.168.1.123 (192.168.1.123): 56 data bytes
--- 192.168.1.123 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
~ #
<## snip ##>
I also serached something about this issue on internet, I found
something:
http://ozlabs.org/pipermail/linuxppc-embedded/2003-December/012802.html
Are there any updates about this issue? Or my problem is not related to
this?
Please help. Thanks.
Best regards,
Lo Chun Chung
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* Re: 2 Ethernet port operating in a PPC405EP system
From: Wolfgang Denk @ 2006-08-30 13:07 UTC (permalink / raw)
To: Chun Chung Lo; +Cc: linuxppc-embedded
In-Reply-To: <A7B1E4DD46AA7046A4398F745240F29402737D5C@ASPROEXG.astri.local>
In message <A7B1E4DD46AA7046A4398F745240F29402737D5C@ASPROEXG.astri.local> you wrote:
>
> Sorry for such long e-mail.
Actually it's not so long...
> I am now working on a STB project, and our board is a IBM PPC405EP with
> 2 ethernet ports. U-Boot 1.0.0 and linux 2.4.20 (from MontaVista) is
> used and update is not recommended. Each ethernet port has a RTL8021CP
> PHY connected.
... as reading stops here. Both U-Boot 1.0.0 and Linux 2.4.20 are not
only old, they are ancient. Zillions of smaller and bigger bugs have
been fixed since. Do yourself a favour and use current code.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The software required `Windows 95 or better', so I installed Linux.
^ permalink raw reply
* Re: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
From: Hirokazu Takata @ 2006-08-30 13:03 UTC (permalink / raw)
To: linux-ia64, linux-mips, linuxppc-embedded, paulkf, takata,
linux-kernel
In-Reply-To: <20060828085244.GA13544@flint.arm.linux.org.uk>
From: Russell King <rmk+lkml@arm.linux.org.uk>
Subject: [CFT:PATCH] Removing possible wrong asm/serial.h inclusions
Date: Mon, 28 Aug 2006 09:52:44 +0100
> diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
> --- a/drivers/serial/m32r_sio.c
> +++ b/drivers/serial/m32r_sio.c
> @@ -76,17 +76,16 @@
> */
> #define is_real_interrupt(irq) ((irq) != 0)
>
> -#include <asm/serial.h>
> +#define BASE_BAUD 115200
>
> /* Standard COM flags */
> #define STD_COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
>
> /*
> * SERIAL_PORT_DFNS tells us about built-in ports that have no
> * standard enumeration mechanism. Platforms that can find all
> * serial ports via mechanisms like ACPI or PCI need not supply it.
> */
> -#undef SERIAL_PORT_DFNS
> #if defined(CONFIG_PLAT_USRV)
>
> #define SERIAL_PORT_DFNS \
> @@ -109,7 +108,7 @@
> #endif /* !CONFIG_PLAT_USRV */
>
> static struct old_serial_port old_serial_port[] = {
> - SERIAL_PORT_DFNS /* defined in asm/serial.h */
> + SERIAL_PORT_DFNS
> };
>
> #define UART_NR ARRAY_SIZE(old_serial_port)
>
Acked-by: Hirokazu Takata <takata@linux-m32r.org>
Thank you.
-- Takata
^ permalink raw reply
* RE: 2 Ethernet port operating in a PPC405EP system
From: Chun Chung Lo @ 2006-08-30 13:17 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
Hi,
I know my source code is vert old. But since there are lots of
applications developed base on this 2 sets of source code, if the kernel
and U-Boot needs to change, the above applications (tons of codes) also
need to revise ... (lots of multimedia players, drivers, and other
supporting tools). My team cannot afford such great change.
So I say "update is not recommended" ...=0D
Thanks for your quick reply.
Best regards,
Lo Chun Chung
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=0D
Sent: Wednesday, 30 August, 2006 9:07 PM
To: Chun Chung Lo
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 2 Ethernet port operating in a PPC405EP system=0D
In message
<A7B1E4DD46AA7046A4398F745240F29402737D5C@ASPROEXG.astri.local> you
wrote:
>=0D
> Sorry for such long e-mail.
Actually it's not so long...
> I am now working on a STB project, and our board is a IBM PPC405EP=0D
> with 2 ethernet ports. U-Boot 1.0.0 and linux 2.4.20 (from MontaVista)
> is used and update is not recommended. Each ethernet port has a=0D
> RTL8021CP PHY connected.
... as reading stops here. Both U-Boot 1.0.0 and Linux 2.4.20 are not
only old, they are ancient. Zillions of smaller and bigger bugs have
been fixed since. Do yourself a favour and use current code.
Best regards,
Wolfgang Denk
--=0D
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The software required `Windows 95 or better', so I installed Linux.
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* Re: [PATCH] corrected PCI interrupt sense values to level low inmpc8349emds.dts
From: Kumar Gala @ 2006-08-30 13:29 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-dev, Phillips Kim-R1AAHA
In-Reply-To: <995B09A8299C2C44B59866F6391D263511BA03@zch01exm21.fsl.freescale.net>
> Where these IDSEL 0x15~0x18 come from on 8349EMDS board?
> Please expain it.
This is from the docs on the PMC-PCI expansion boards that state what
IDSELs are used and how they are wired up.
- k
^ permalink raw reply
* Re: How to turn off MMU in MPC8540
From: Kumar Gala @ 2006-08-30 13:31 UTC (permalink / raw)
To: Reddy Suneel-ASR125; +Cc: linuxppc-embedded
In-Reply-To: <405ECA8A30557F439A723E52D50838F9D8295F@ZMY16EXM66.ds.mot.com>
On Aug 30, 2006, at 1:25 AM, Reddy Suneel-ASR125 wrote:
> Hi
>
> Can anyone know how to turn off MMU in MPC8540?
You can not turn the MMU off on the MPC8540 or any e500 based
product. You can emulate a 1:1 mapping if you so desire by
preloading TLBs.
- kumar
^ 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