so remove them from the macros.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/platforms/iseries/exception.h |4 ++--
arch/powerpc/platforms/iseries/head.S | 24
2 files changed, 14 insertions(+), 14 deletions(-)
--
Cheers,
Stephen
On Fri, 17 Aug 2007 13:17:18 -0500
Scott Wood wrote:
The existing OF glue code was crufty and broken. Rather than fix it,
it will be removed, and the ethernet driver now talks to the device
tree directly.
A bit short description, I'd rather expect some specific improvements list,
that are
Hi guys,
Just a query here, there was a patch for /chosen/initrd,start and initrd,end
variables gained from firmware or so, which allowed booting without getting
those values into r3/r4, does anyone know the maintainer/author of that
patch?
Also, what are the chances of pushing it for 2.6.23 or
On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote:
Damn, I should use patchwork more efficiently;
http://patchwork.ozlabs.org/linuxppc/patch?q=initrdfilter=noneid=12168
Does anyone have any suggestion on the best way to integrate this so that
it just works on OF platforms? It
Hai,
I am using the kernel 2.6.21. In the file
(arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In
this function it will skip the host birdge. But in the arch/powepc
directory we don't have that types of file and the function
pciauto_bus_scan() also removed.
I want to
Hai,
I am using the kernel 2.6.21. In the file
(arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In
this function it will skip the host birdge. But in the arch/powepc directory
we don't have that types of file and the function pciauto_bus_scan() also
removed.
I want to
David Gibson wrote:
On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote:
Damn, I should use patchwork more efficiently;
http://patchwork.ozlabs.org/linuxppc/patch?q=initrdfilter=noneid=12168
Does anyone have any suggestion on the best way to integrate this so that
it just works on
On Tue, Aug 21, 2007 at 01:36:49PM +0100, Matt Sealey wrote:
David Gibson wrote:
On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote:
Damn, I should use patchwork more efficiently;
http://patchwork.ozlabs.org/linuxppc/patch?q=initrdfilter=noneid=12168
Does anyone have any
David Gibson wrote:
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from arch/powerpc/boot/crt0.S,
immediately before main().
Oh *THAT* platform init.
So I could just drop a
} else {
dt_find_initrd();
}
.. at the end and nobody
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing spidev
with mmc_spi.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc832x_rdb.dts |2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 50
On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
David Gibson wrote:
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from arch/powerpc/boot/crt0.S,
immediately before main().
Oh *THAT* platform init.
So I could just drop
David Gibson wrote:
On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
David Gibson wrote:
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from arch/powerpc/boot/crt0.S,
immediately before main().
Oh *THAT* platform init.
So I
On Tue, Aug 21, 2007 at 05:45:37PM +0400, Anton Vorontsov wrote:
Hi all,
Thanks for the previous reviews, this is v4 against Linus' tree,
as of today.
Okay, here is brand-new, shiny v5. Today and only today it comes
without section mismatch warnings, don't miss your chance. Get it
free of
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing spidev
with mmc_spi.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc832x_rdb.dts |2 +-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 50
David Gibson wrote:
On Mon, Aug 20, 2007 at 12:39:49PM -0500, Scott Wood wrote:
1. ft_create_node was returning the internal pointer rather than a phandle.
2. ft_find_device_rel was treating a top phandle of NULL as an error,
rather than as the root of the tree.
3. Return the node's name when
David Gibson wrote:
On Mon, Aug 20, 2007 at 12:39:55PM -0500, Scott Wood wrote:
Declarations in various users are removed.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
Hrm... it should go in a header, certainly, but I wonder if io.h would
be more suitable than the already rather bloated
On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote:
It's not a question of indivudual files being copied over - things are
done differently in arch/powerpc. Things are gradually being ported
over to arch/powerpc as people get the time - that's why arch/ppc
isn't gone yet.
And
David Gibson wrote:
On Mon, Aug 20, 2007 at 12:40:01PM -0500, Scott Wood wrote:
This allows booting on legacy, non-device-tree aware versions of
U-boot.
Is this really sufficient for all 8xx platforms?
It should be enough for all u-boot-based 8xx boards, barring some u-boot
which needs
David Gibson wrote:
On Mon, Aug 20, 2007 at 12:40:13PM -0500, Scott Wood wrote:
fsl_get_immr() is equivalent to the kernel's get_immrbase() function.
I notice that this function assumes that P==V. Is that true for all
relevant platforms at this point?
Yes. If that ever changes, we'd
On Tue, 21 Aug 2007 09:11:24 -0700
Phil Terry [EMAIL PROTECTED] wrote:
On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote:
It's not a question of indivudual files being copied over - things are
done differently in arch/powerpc. Things are gradually being ported
over to
On Aug 21, 2007, at 11:11 AM, Phil Terry wrote:
On Tue, 2007-08-21 at 17:14 +0200, Segher Boessenkool wrote:
It's not a question of indivudual files being copied over -
things are
done differently in arch/powerpc. Things are gradually being ported
over to arch/powerpc as people get the
Vitaly Bordug wrote:
On Fri, 17 Aug 2007 13:17:18 -0500
Scott Wood wrote:
The existing OF glue code was crufty and broken. Rather than fix it,
it will be removed, and the ethernet driver now talks to the device
tree directly.
A bit short description, I'd rather expect some specific
On Tue, Aug 21, 2007 at 10:12:17AM -0700, Phil Terry wrote:
Sorry guys, this is probably the wrong forum and I didn't mean to sound
like I was trashing anyones efforts here.
I don't think it was taken that way -- rather, we want to know what
hardware people are still using with recent kernels.
So then I get worried, how do I know
who's plan and schedule include/excludes my board/chip/issue?
The arch/ppc - arch/powerpc changeover is exceptional for various
reasons.
First, it is a huge change taking multiple years to complete.
Only recently it has been decided when to finally drop
From: Grant Likely [EMAIL PROTECTED]
arch/ppc/.gitignore shouldn't exclude arch/ppc/boot/include
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- a/arch/ppc/.gitignore
+++ b/arch/ppc/.gitignore
@@ -1 +1 @@
-include
+/include
___
Linuxppc-dev
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : : memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__ (sync : : : memory)
#define read_barrier_depends() do { } while(0)
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__ (sync : : : memory)
#define read_barrier_depends() do { } while(0)
Please pull from 'fixes-2.6.23' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
fixes-2.6.23
to receive the following updates:
arch/powerpc/sysdev/fsl_pci.c |2 ++
include/linux/pci_ids.h |6 --
2 files changed, 6 insertions(+), 2 deletions(-)
On Tue, Aug 21, 2007 at 11:29:15AM -0500, Scott Wood wrote:
David Gibson wrote:
+void planetcore_prepare_table(char *table)
+{
+ int last_was_newline = 0;
+
+ while (*table != 10 || !last_was_newline) {
+ if (*table == 10) {
+ *table = 0;
+
Olof Johansson writes:
Make sure the new timebase value is available by the time take_timebase
completes. Otherwise take_timebase might race with give_timebase,
causing severe badness when the value later is modified (think looong
hang trying to catch up with a very large number of lost
On Tue, Aug 21, 2007 at 03:24:52PM +0100, Matt Sealey wrote:
David Gibson wrote:
On Tue, Aug 21, 2007 at 01:58:31PM +0100, Matt Sealey wrote:
David Gibson wrote:
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from
On Tue, Aug 21, 2007 at 11:20:21AM -0500, Scott Wood wrote:
David Gibson wrote:
On Mon, Aug 20, 2007 at 12:40:01PM -0500, Scott Wood wrote:
This allows booting on legacy, non-device-tree aware versions of
U-boot.
Is this really sufficient for all 8xx platforms?
It should be
On Tue, Aug 21, 2007 at 09:43:17PM +0200, Segher Boessenkool wrote:
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__
Rework timebase handoff to play nice with configurations with more than
2 cores, as well as with CPU hotplug.
Previous scheme just pushed out the current timebase from the giving
core to all cores without caring if they wanted it or not, nor checking
if they'd taken it. The taking side didn't
If this isn't causing any problems maybe there
is some loigic we are overlooking?
The I/O accessor functions enforce the necessary ordering
already I believe.
Ah, it looks like you might be right, IO should appear to go in-order,
in
which case the rmb() would simply need to order
Scott Wood writes:
Previously, the TLB miss handlers assumed that pages above KERNELBASE are
always present and read/write. This assumption is false in the case of
CONFIG_DEBUG_PAGEALLOC.
blt+112f
+ mfspr r2,SPRN_SRR1/* and MSR_PR bit from SRR1 */
+ rlwinm
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/kernel/head_64.S | 86 +
arch/powerpc/platforms/iseries/Makefile|1 +
arch/powerpc/platforms/iseries/exception.S | 114
include/asm-powerpc/ppc_asm.h
It makes head_64.S a bit more readable and will allow us to move the
iSeries excetions elsewhere.
This also removes the last line of the comment:
* The following macros define the code that appears as
* the prologue to each of the exception handlers. They
* are split into two parts to allow
out of head_64.S and into platforms/iseries/exception.S
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/kernel/head_64.S | 136
arch/powerpc/platforms/iseries/exception.S | 136
2 files changed, 136
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/platforms/iseries/exception.S | 15 +++---
arch/powerpc/platforms/iseries/exception.h | 58 ++
include/asm-powerpc/exception.h| 71 +---
3 files changed, 78
so remove them from the macros.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/platforms/iseries/exception.S | 24
arch/powerpc/platforms/iseries/exception.h |4 ++--
2 files changed, 14 insertions(+), 14 deletions(-)
--
Cheers,
Stephen
On Wed, Aug 22, 2007 at 05:29:50AM +0200, Segher Boessenkool wrote:
If this isn't causing any problems maybe there
is some loigic we are overlooking?
The I/O accessor functions enforce the necessary ordering
already I believe.
Ah, it looks like you might be right, IO should appear to go
On Wed, Aug 22, 2007 at 05:33:16AM +0200, Segher Boessenkool wrote:
The I/O accessor functions enforce the necessary ordering
already I believe.
Hmm, I never followed those discussions last year about IO ordering,
and
I can't see where (if) it was documented anywhere :(
The comments in
On Wed, Aug 22, 2007 at 01:52:49PM +1000, Paul Mackerras wrote:
Scott Wood writes:
Previously, the TLB miss handlers assumed that pages above KERNELBASE are
always present and read/write. This assumption is false in the case of
CONFIG_DEBUG_PAGEALLOC.
blt+112f
+ mfspr
Hi,
I'm ignorant when it comes to IO access, so I hope this isn't rubbish (if
it is, I would appreciate being corrected).
It took me more than a glance to see what the difference is supposed to be
between wmb() and mmiowb(). I think especially because mmiowb isn't really
like a write barrier.
45 matches
Mail list logo