* Re: [openib-general] Re: [PATCH 07/16] ehca: interrupt handling routines
From: Shirley Ma @ 2006-05-09 18:44 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder, openib-general-bounces,
Michael S. Tsirkin
In-Reply-To: <adar733avvs.fsf@cisco.com>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
Roland Dreier <rdreier@cisco.com> wrote on 05/09/2006 11:36:07 AM:
> But there's no reason why the two threads can't be pinned to different
> CPUs or given exclusive CPU masks, exactly the same way that ehca
> implements it.
>
> - R.
I could try this. Let's see how much latency increase there.
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578-7638
[-- Attachment #2: Type: text/html, Size: 595 bytes --]
^ permalink raw reply
* IMAP_ADDR on PPC 8xx
From: Kenneth Poole @ 2006-05-09 18:38 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]
In our build, (currently based on 2.6.14.3) we define IMAP_ADDR as
follows:
#define IMAP_ADDR (((bd_t *)__res)->bi_immr_base)
With very few exceptions, nearly all driver code that dereferences
IMAP_ADDR can be used unchanged and the IMMR value is always the value
passed up from the bootloader. We build one image that runs on multiple
platforms and some platforms place the IMMR address space at different
addresses than others. It's not a constant.
Regardless, I see little reason to ioremap() the IMMR address. The MMU
is set up in such a way that IMMR based locations can be accessed
directly.
Ken Poole, MRV Communications, Inc.
> In a related vein, as I alluded to in my previous email, there has
been
> previous discussion on this list about the fact that it is frowned
upon
> for device drivers to directly dereference IMAP_ADDR. Instead, I've
> seen a recommendation that each individual driver perform an
io_remap()
> operation on IMAP_ADDR and save the resulting kernel virtual address
in
> a driver-specific data structure. Is this a universally-accepted
> viewpoint? Is this something that the community agrees "should be
> fixed" and we're just waiting for someone (like me) to volunteer to
fix
> all the drivers?
> Or are there arguments in favor of keeping the direct IMAP_ADDR
> dereferences? For example, if each driver performs its own separate
> io_remap(), doesn't that have potentially negative consequences on the
> VM system for some PPC implementations (e.g. increased contention for
> TLB entries)?
> Are these issues addressed by or otherwise impacted by other ongoing
PPC
> Linux work such as the "ppc" + "ppc64" --> "powerpc" effort / "flat
> device tree" stuff???
[-- Attachment #2: Type: text/html, Size: 6931 bytes --]
^ permalink raw reply
* Re: [openib-general] Re: [PATCH 07/16] ehca: interrupt handling routines
From: Roland Dreier @ 2006-05-09 18:36 UTC (permalink / raw)
To: Shirley Ma
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder, openib-general-bounces,
Michael S. Tsirkin
In-Reply-To: <OF22D08323.20D303C1-ON87257169.0063C980-88257169.006A41AB@us.ibm.com>
Shirley> I have done some patch like that on top of splitting
Shirley> CQ. The problem I found that hardware interrupt favors
Shirley> one CPU. Most of the time these two threads are running
Shirley> on the same cpu according to my debug output. You can
Shirley> easily find out by cat /proc/interrupts and
Shirley> /proc/irq/XXX/smp_affinity. ehca has distributed
Shirley> interrupts evenly on SMP, so it gets the benefits of two
Shirley> threads, and gains much better throughputs.
Yes, an interrupt will likely be delivered to one CPU.
But there's no reason why the two threads can't be pinned to different
CPUs or given exclusive CPU masks, exactly the same way that ehca
implements it.
- R.
^ permalink raw reply
* Re: [PATCH] powerpc: whitespace cleanup in reg.h
From: jschopp @ 2006-05-09 18:34 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060509163419.E4E1767A04@ozlabs.org>
> In reg.h we mostly have #define<space> but there are a few #define<tab>
> around. Clean these up so we use space exclusively.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
nack
> +#define SPRN_HID6 0x3F9 /* BE HID 6 */
> +#define HID6_LB (0x0F<<12) /* Concurrent Large Page Modes */
> +#define HID6_DLP (1<<20) /* Disable all large page modes (4K only) */
> +#define SPRN_TSC_CELL 0x399 /* Thread switch control on Cell */
> +#define TSC_CELL_DEC_ENABLE_0 0x400000 /* Decrementer Interrupt */
> +#define TSC_CELL_DEC_ENABLE_1 0x200000 /* Decrementer Interrupt */
> +#define TSC_CELL_EE_ENABLE 0x100000 /* External Interrupt */
> +#define TSC_CELL_EE_BOOST 0x080000 /* External Interrupt Boost */
> +#define SPRN_TSC 0x3FD /* Thread switch control on others */
> +#define SPRN_TST 0x3FC /* Thread switch timeout on others */
OK, the tab to space for lines like SPRN_HID6 I understand. But then you seem to be
trying to do indenting with 3 spaces instead of tabs. And your values don't line up, and
your comments don't line up.
I'm just saying, either fix the formatting right or don't fix it at all. Moving it from
one ugly to another ugly is not worth the trouble.
^ permalink raw reply
* system hang in early_init
From: Chris Dumoulin @ 2006-05-09 17:55 UTC (permalink / raw)
To: linuxppc-embedded
It seems that my PPC405 V2Pro system is hanging in the function
early_init, in arch/ppc/kernel/setup.c. Using LEDs, I've been able to
determine that the following line seems to be where it dies:
memset_io(PTRRELOC(&__bss_start), 0, _end - __bss_start);
Looking in System.map, I see that __bss_start is 0xC013F000 and _end is
0xC014DA60, with a whole bunch of stuff in between.
Any idea what might cause this?
Regards,
Chris
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: IMAP_ADDR on PPC 8xx
From: Walter L. Wimer III @ 2006-05-09 17:14 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060508224653.C4B48352B0C@atlas.denx.de>
Hi All,
Thanks for you response, Wolfgang.
On Tue, 2006-05-09 at 00:46 +0200, Wolfgang Denk wrote:
> In message <1147108983.27101.63.camel@excalibur.timesys.com> you wrote:
> >
> > In particular, I have an MPC885ADS board running "U-Boot 1.1.3 (Apr 19
> > 2005 - 13:39:58)". It will boot neither 2.6.15 nor 2.6.16.11. After
> > U-Boot decompresses the kernel, I get no kernel output at all; it just
> > hangs.
>
> Probably you forgot to specify a correct console device with your
> boot arguments.
Excellent point, but unfortunately this (at least by itself) didn't
help.
> > After some debugging, I think things go awry when the code starts
> > dereferencing IMAP_ADDR as a direct pointer. IMAP_ADDR is defined to be
> > 0xFF000000, but the MPC885ADS documentation says that the internal
>
> Correct.
>
> > memory map is supposed to at 0x22000000. In addition, when I look at
> > the bd_t pointer from U-Boot, it's saying that 0x22000000 is the correct
> > address.
>
> No. U-Boot uses 0xFF000000. At least the official U-Boot source tree
> does. I don't know where you got yours from, or who might have broken
> it.
>
> > Why is this a problem for us and apparently not for anyone else on this
> > list? Is no one else using U-Boot? Or does everyone else's U-Boot use
> > 0xFF000000 instead of 0x22000000? Or do I have a different problem
>
> Most probably everybody else who uses U-Boot uses a good version with
> a high mapping.
Interesting. Thanks for the info. I'm not certain where this U-Boot
came from -- it was already loaded onto the board when the board "landed
in my lap". I suspect that this U-Boot may have come from Freescale.
> > While reading through the archives, I see that using IMAP_ADDR the way
> > it is currently used is somewhat frowned upon anyway. Is this one of
> > those things that we (the PPC Linux community) should fix the "right
> > way" once and for all? I'm happy to submit a patch once I understand
> > what the "right way" is... :-)
>
> The memory map requirements of PowerPC systems have been explained
> many times before, so a little search in the archives, HOWTOs etc.
> should point you quickly for good description why a low mapping like
> 0x22000000 cannot work.
Thanks again for the advice. Interestingly, I gave the wrong address
above. It wasn't 0x22000000, it was 0x02200000 (i.e. even lower!). And
yet with the "io_remap()'ed global variable" patch, 2.6.11.7 does indeed
work on this board with this U-Boot.... Perhaps this works because this
particular board only has 8MiB of RAM....
I'll definitely investigate switching to a U-Boot built from official
sources.
Interestingly, I ran into a similar problem on a completely different
Freescale board about a year ago. We have an MPC8272ADS board that
definitely has a Freescale copy of U-Boot and it fails to boot vanilla
kernels due to different definitions for the BCSR addresses (which if I
recall correctly are within the internal memory map and thus controlled
by the IMMR register). At that time, Kumar appealed to the community on
this mailing list to figure out the "right" solution to the discrepancy.
I didn't have time to do the "right" thing, so I merely #ifdef'd out the
offending code in the kernel and the problem magically went away (I
suspect that the Freescale U-Boot had already initialized things
sufficiently that it wasn't strictly _necessary_ for the kernel to
re-initialize the same registers (even if it might have been
_desired_)).
Bottom line: I'm wondering what the Linux PPC community thinks is the
correct long term solution to these discrepancies. Should we the
community declare "Freescale U-Boots are considered harmful; never use
them; always use the official U-Boot sources" ???
Or should we create a kernel mechanism to automatically adapt to the
different U-Boot flavors?
In a related vein, as I alluded to in my previous email, there has been
previous discussion on this list about the fact that it is frowned upon
for device drivers to directly dereference IMAP_ADDR. Instead, I've
seen a recommendation that each individual driver perform an io_remap()
operation on IMAP_ADDR and save the resulting kernel virtual address in
a driver-specific data structure. Is this a universally-accepted
viewpoint? Is this something that the community agrees "should be
fixed" and we're just waiting for someone (like me) to volunteer to fix
all the drivers?
Or are there arguments in favor of keeping the direct IMAP_ADDR
dereferences? For example, if each driver performs its own separate
io_remap(), doesn't that have potentially negative consequences on the
VM system for some PPC implementations (e.g. increased contention for
TLB entries)?
Are these issues addressed by or otherwise impacted by other ongoing PPC
Linux work such as the "ppc" + "ppc64" --> "powerpc" effort / "flat
device tree" stuff???
> Best regards,
>
> Wolfgang Denk
Thanks!!!
Walt Wimer
TimeSys Corporation
^ permalink raw reply
* Re: Viable PPC platform?
From: Eugene Surovegin @ 2006-05-09 17:15 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded, geneSmith
In-Reply-To: <20060509174101.389c67c0.ajz@cambridgebroadband.com>
On Tue, May 09, 2006 at 05:41:01PM +0100, Alex Zeffertt wrote:
> On Tue, 09 May 2006 10:38:19 -0400
> geneSmith <gd.smth@gmail.com> wrote:
>
> > I have a ppc405gpr system with 64M ram and 4Meg flash in a
> > AM29LV320. Is this a viable platform for linux? Can a filesystem
> > (JFFS2?) be put this flash type?
> >
>
> I would create an initrd and put every file that doesn't need
> to be changed persistently into it instead of JFFS2.
After many years of doing embedded Linux stuff I still don't
understand why people are so fond of initrd.
For temporary stuff - tempfs is much better and flexible. For r/o
stuff - just make separate MTD partition (cramfs, squashfs) and mount
it directly as root. Both options will waste significantly less
memory.
--
Eugene
^ permalink raw reply
* Re: [PATCH 07/16] ehca: interrupt handling routines
From: Michael S. Tsirkin @ 2006-05-09 16:49 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <adalktbcgl1.fsf@cisco.com>
Quoting r. Roland Dreier <rdreier@cisco.com>:
> The trivial way to do it would be to use the same idea as the current
> ehca driver: just create a thread for receive CQ events and a thread
> for send CQ events, and defer CQ polling into those two threads.
For RX, isn't this basically what NAPI is doing?
Only NAPI seems better, avoiding interrupts completely and avoiding latency hit
by only getting triggered on high load ...
--
MST
^ permalink raw reply
* Re: Viable PPC platform?
From: Alex Zeffertt @ 2006-05-09 16:41 UTC (permalink / raw)
To: geneSmith; +Cc: linuxppc-embedded
In-Reply-To: <e3q9gu$vq8$1@sea.gmane.org>
On Tue, 09 May 2006 10:38:19 -0400
geneSmith <gd.smth@gmail.com> wrote:
> I have a ppc405gpr system with 64M ram and 4Meg flash in a
> AM29LV320. Is this a viable platform for linux? Can a filesystem
> (JFFS2?) be put this flash type?
>
I would create an initrd and put every file that doesn't need
to be changed persistently into it instead of JFFS2.
The reason for this is that if JFFS2 becomes too full (less than 5
free blocks) you may find that writes to it hang.
Alex
> --
> Lit up like Levy's
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] powerpc: whitespace cleanup in reg.h
From: Michael Neuling @ 2006-05-09 16:33 UTC (permalink / raw)
To: linuxppc-dev, paulus
In reg.h we mostly have #define<space> but there are a few #define<tab>
around. Clean these up so we use space exclusively.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
It's clear this patch is fundamental to our future prosperity!
include/asm-powerpc/reg.h | 46 +++++++++++++++++++++++-----------------------
1 files changed, 23 insertions(+), 23 deletions(-)
Index: linux-2.6-powerpc/include/asm-powerpc/reg.h
===================================================================
--- linux-2.6-powerpc.orig/include/asm-powerpc/reg.h
+++ linux-2.6-powerpc/include/asm-powerpc/reg.h
@@ -153,7 +153,7 @@
#define SPRN_DABR 0x3F5 /* Data Address Breakpoint Register */
#define DABR_TRANSLATION (1UL << 2)
#define SPRN_DAR 0x013 /* Data Address Register */
-#define SPRN_DSISR 0x012 /* Data Storage Interrupt Status Register */
+#define SPRN_DSISR 0x012 /* Data Storage Interrupt Status Register */
#define DSISR_NOHPTE 0x40000000 /* no translation found */
#define DSISR_PROTFAULT 0x08000000 /* protection fault */
#define DSISR_ISSTORE 0x02000000 /* access was a store */
@@ -258,16 +258,16 @@
#define SPRN_IABR 0x3F2 /* Instruction Address Breakpoint Register */
#define SPRN_HID4 0x3F4 /* 970 HID4 */
#define SPRN_HID5 0x3F6 /* 970 HID5 */
-#define SPRN_HID6 0x3F9 /* BE HID 6 */
-#define HID6_LB (0x0F<<12) /* Concurrent Large Page Modes */
-#define HID6_DLP (1<<20) /* Disable all large page modes (4K only) */
-#define SPRN_TSC_CELL 0x399 /* Thread switch control on Cell */
-#define TSC_CELL_DEC_ENABLE_0 0x400000 /* Decrementer Interrupt */
-#define TSC_CELL_DEC_ENABLE_1 0x200000 /* Decrementer Interrupt */
-#define TSC_CELL_EE_ENABLE 0x100000 /* External Interrupt */
-#define TSC_CELL_EE_BOOST 0x080000 /* External Interrupt Boost */
-#define SPRN_TSC 0x3FD /* Thread switch control on others */
-#define SPRN_TST 0x3FC /* Thread switch timeout on others */
+#define SPRN_HID6 0x3F9 /* BE HID 6 */
+#define HID6_LB (0x0F<<12) /* Concurrent Large Page Modes */
+#define HID6_DLP (1<<20) /* Disable all large page modes (4K only) */
+#define SPRN_TSC_CELL 0x399 /* Thread switch control on Cell */
+#define TSC_CELL_DEC_ENABLE_0 0x400000 /* Decrementer Interrupt */
+#define TSC_CELL_DEC_ENABLE_1 0x200000 /* Decrementer Interrupt */
+#define TSC_CELL_EE_ENABLE 0x100000 /* External Interrupt */
+#define TSC_CELL_EE_BOOST 0x080000 /* External Interrupt Boost */
+#define SPRN_TSC 0x3FD /* Thread switch control on others */
+#define SPRN_TST 0x3FC /* Thread switch timeout on others */
#if !defined(SPRN_IAC1) && !defined(SPRN_IAC2)
#define SPRN_IAC1 0x3F4 /* Instruction Address Compare 1 */
#define SPRN_IAC2 0x3F5 /* Instruction Address Compare 2 */
@@ -362,7 +362,7 @@
#endif
#define SPRN_PTEHI 0x3D5 /* 981 7450 PTE HI word (S/W TLB load) */
#define SPRN_PTELO 0x3D6 /* 982 7450 PTE LO word (S/W TLB load) */
-#define SPRN_PURR 0x135 /* Processor Utilization of Resources Reg */
+#define SPRN_PURR 0x135 /* Processor Utilization of Resources Reg */
#define SPRN_PVR 0x11F /* Processor Version Register */
#define SPRN_RPA 0x3D6 /* Required Physical Address Register */
#define SPRN_SDA 0x3BF /* Sampled Data Address Register */
@@ -559,20 +559,20 @@
/* 64-bit processors */
/* XXX the prefix should be PVR_, we'll do a global sweep to fix it one day */
-#define PV_NORTHSTAR 0x0033
-#define PV_PULSAR 0x0034
-#define PV_POWER4 0x0035
-#define PV_ICESTAR 0x0036
-#define PV_SSTAR 0x0037
-#define PV_POWER4p 0x0038
+#define PV_NORTHSTAR 0x0033
+#define PV_PULSAR 0x0034
+#define PV_POWER4 0x0035
+#define PV_ICESTAR 0x0036
+#define PV_SSTAR 0x0037
+#define PV_POWER4p 0x0038
#define PV_970 0x0039
-#define PV_POWER5 0x003A
+#define PV_POWER5 0x003A
#define PV_POWER5p 0x003B
#define PV_970FX 0x003C
-#define PV_630 0x0040
-#define PV_630p 0x0041
-#define PV_970MP 0x0044
-#define PV_BE 0x0070
+#define PV_630 0x0040
+#define PV_630p 0x0041
+#define PV_970MP 0x0044
+#define PV_BE 0x0070
/*
* Number of entries in the SLB. If this ever changes we should handle
^ permalink raw reply
* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Roland Dreier @ 2006-05-09 16:23 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <44608C90.30909@de.ibm.com>
Heiko> Yes, I agree. It would not be an optimal solution, because
Heiko> other upper level protocols (e.g. SDP, SRP, etc.) or
Heiko> userspace verbs would not be affected by this
Heiko> changes. Nevertheless, how can an improved "scaling" or
Heiko> "SMP" version of IPoIB look like. How could it be
Heiko> implemented?
The trivial way to do it would be to use the same idea as the current
ehca driver: just create a thread for receive CQ events and a thread
for send CQ events, and defer CQ polling into those two threads.
Something even better may be possible by specializing to IPoIB of course.
- R.
^ permalink raw reply
* Re: Viable PPC platform?
From: Matt Porter @ 2006-05-09 15:34 UTC (permalink / raw)
To: geneSmith; +Cc: linuxppc-embedded
In-Reply-To: <e3q9gu$vq8$1@sea.gmane.org>
On Tue, May 09, 2006 at 10:38:19AM -0400, geneSmith wrote:
> I have a ppc405gpr system with 64M ram and 4Meg flash in a AM29LV320. Is
> this a viable platform for linux? Can a filesystem (JFFS2?) be put this
> flash type?
Yes. (Yes) Yes.
-Matt
^ permalink raw reply
* Viable PPC platform?
From: geneSmith @ 2006-05-09 14:38 UTC (permalink / raw)
To: linuxppc-embedded
I have a ppc405gpr system with 64M ram and 4Meg flash in a AM29LV320. Is
this a viable platform for linux? Can a filesystem (JFFS2?) be put this
flash type?
--
Lit up like Levy's
^ permalink raw reply
* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Christoph Hellwig @ 2006-05-09 13:15 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4450A196.2050901@de.ibm.com>
> +#include <linux/interrupt.h>
> +#include <asm/atomic.h>
> +#include <asm/types.h>
Please don't use <asm/types.h> directly ever. Always include
<linux/types.h>
^ permalink raw reply
* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Heiko J Schick @ 2006-05-09 12:35 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <adafyjomsrd.fsf@cisco.com>
Roland Dreier wrote:
> Heiko> Originaly, we had the same idea as you mentioned, that it
> Heiko> would be better to do this in the higher levels. The point
> Heiko> is that we can't see so far any simple posibility how this
> Heiko> can done in the OpenIB stack, the TCP/IP network layer or
> Heiko> somewhere in the Linux kernel.
>
> Heiko> For example: For IPoIB we get the best throughput when we
> Heiko> do the CQ callbacks on different CPUs and not to stay on
> Heiko> the same CPU.
>
> So why not do it in IPoIB then? This approach is not optimal
> globally. For example, uverbs event dispatch is just going to queue
> an event and wake up the process waiting for events, and doing this on
> some random CPU not related to the where the process will run is
> clearly the worst possible way to dispatch the event.
Yes, I agree. It would not be an optimal solution, because other upper
level protocols (e.g. SDP, SRP, etc.) or userspace verbs would not be
affected by this changes. Nevertheless, how can an improved "scaling"
or "SMP" version of IPoIB look like. How could it be implemented?
> Heiko> In other papers and slides (see [1]) you can see similar
> Heiko> approaches.
>
> Heiko> [1]: Speeding up Networking, Van Jacobson and Bob
> Heiko> Felderman,
> Heiko> http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf
> I think you've misunderstood this paper. It's about maximizing CPU
> locality and pushing processing directly into the consumer. In the
> context of slide 9, what you've done is sort of like adding another
> control loop inside the kernel, since you dispatch from interrupt
> handler to driver thread to final consumer. So I would argue that
> your approach is exactly the opposite of what VJ is advocating.
Sorry, my idea was not to use the *.pdf file how it should be
implemented. I only wanted to show that other people are also thinking
about how TCP/IP performance could be increased and where the bottlenecks
(e.g. SOFTIRQs) are. :)
Regards,
Heiko
^ permalink raw reply
* Re: MPC8540 experience
From: Clemens Koller @ 2006-05-09 9:41 UTC (permalink / raw)
To: Mark Chambers; +Cc: groer, linuxppc-embedded
In-Reply-To: <008001c6477e$6a760a50$6401a8c0@CHUCK2>
Hello, Mark!
Sorry, for my late reply, I wasn't reading the mailing lists for a while
because I am pretty busy with hardware development.
> Hallo Herr Koller,
> ich habe heute ihre EMail
> (http://ozlabs.org/pipermail/linuxppc-embedded/2004-October/015851.html)
> gelesen. Hatten sie bereits Erfolg?
> Ich habe ein ähnliches Problem. Wir beutzen bei uns ebenfalls einen PPC und
> haben das Problem mit Big und Littel-Endian im XServer.
English, please.
You are looking for the SM501 graphics controller working on the PCI Bus
on the MPC8540 as far as I got your mail.
Yes, the last status I got is that the endianess is an issue for the X-server
if the SM501 is on PCI. However there are patches for the framebuffer/X
driver environment which takes care about the RGBA's somewhere out there.
There are also accelerated native X drivers available but I haven't used
those. Additionally, we have the option to swap the colors in hardware,
just in case anything goes wrong. :-)
> Have you seen the work done at Denx (www.denx.de) with the MPC5200 and
> SM501?
Yes. But AFAIK they have the SM501 on the Local Bus of the MPC5200 which
is a different thing. Check their hardware documentation, if available.
Maybe there are more updates in the meanwhile... Updates are very welcome.
I will have to investigate that further if I come back to the software
layer of my project.
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-05-09 9:13 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from the "merge" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
There are two commits there, both small bug-fixes for ARCH=ppc.
Thanks,
Paul.
arch/ppc/kernel/head_8xx.S | 4 ----
include/asm-ppc/page.h | 1 +
2 files changed, 1 insertions(+), 4 deletions(-)
commit c51e078f82096a7d35ac8ec2416272e843a0e1c4
Author: Marcelo Tosatti <marcelo@kvack.org>
Date: Fri May 5 17:09:29 2006 -0300
[PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
Instantiation of 8MB pages on the TLB cache for the kernel static
mapping trashes r3 register on !CONFIG_8xx_CPU6 configurations.
This ensures r3 gets saved and restored.
Signed-off-by: Marcelo Tosatti <marcelo@kvack.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit e4de00215c3af02116db3d486bf53700dfe10619
Author: Paul Mackerras <paulus@samba.org>
Date: Tue May 9 16:00:59 2006 +1000
powerpc/32: Define an is_kernel_addr() to fix ARCH=ppc compilation
My commit 6bfd93c32a5065d0e858780b3beb0b667081601c broke the ARCH=ppc
compilation by using the is_kernel_addr() macro in asm/uaccess.h.
This fixes it by defining a suitable is_kernel_addr() for ARCH=ppc.
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH 6/6] Break out memory initialisation code from page_alloc.c to mem_init.c
From: Mel Gorman @ 2006-05-09 8:24 UTC (permalink / raw)
To: Nick Piggin
Cc: akpm, davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <445FF4B3.7020101@yahoo.com.au>
On Tue, 9 May 2006, Nick Piggin wrote:
> Mel Gorman wrote:
>
>> page_alloc.c contains a large amount of memory initialisation code. This
>> patch
>> breaks out the initialisation code to a separate file to make page_alloc.c
>> a bit easier to read.
>>
>
> I realise this is at the wrong end of your queue, but if you _can_ easily
> break it out and submit it first, it would be a nice cleanup and would help
> shrink your main patchset.
>
The split-out potentially affects 10 other patches currently in -mm and is
a merge headache for Andrew. My current understanding is that he wants to
drop patch 6/6 until a later time. I guess this would be still true if the
patch was at the other end of the queue.
> Also, we're recently having some problems with architectures not aligning
> zones correctly. Would it make sense to add these sorts of sanity checks,
> and possibly forcing alignment corrections into your generic code?
>
Yes, it is easy to force alignment corrections into the generic code. From
that thread, there was this comment from Andy Whitcroft and your response;
> >1) check the alignment of the zones matches the implied alignment
> > constraints and correct it as we go.
> Yes. And preferably have checks in the generic page allocator setup
> code, so we can do something sane if the arch code gets it wrong.
With this patchset, it is trivial to move the start of highmem during
setup. free_area_init_nodes() is passed the PFN each zone starts at by the
architecture. If one wanted to force HIGHMEM to aligned, the
arch_max_high_pfn value could be rounded down to MAX_ORDER alignment in
free_area_init_nodes() before it calls free_area_init_node(). It doesn't
matter if the PFN is in a hole. From there, an aligned mem_map should be
allocated and memmap_init() will set the correct zone flags.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: ELDK for MPC8260
From: Wolfgang Denk @ 2006-05-09 7:14 UTC (permalink / raw)
To: Srinivas Murthy; +Cc: linuxppc-dev
In-Reply-To: <7cb1293c0605081846w2a94d60ara83511f5e6bd30e7@mail.gmail.com>
In message <7cb1293c0605081846w2a94d60ara83511f5e6bd30e7@mail.gmail.com> you wrote:
>
> What is the current status of the ELDK support for the MPC8260 processor?
It has always been supported right from the very first version of the
ELDK, and still is.
> Is there a current POWERQuicc based processor board for which we have the
> ELDK support?
Yes, there are several such boards.
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
How many QA engineers does it take to screw in a lightbulb? 3: 1 to
screw it in and 2 to say "I told you so" when it doesn't work.
^ permalink raw reply
* [PATCH] powerpc: Make early debugging options behave with oldconfig
From: Michael Ellerman @ 2006-05-09 6:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
If you undefine all the early debugging options and then run make oldconfig,
you don't get prompted to see if you want to enable any of them. This is
annoying.
AFAICT we can't do this just with a choice, because the choice is either
optional, in which case we don't get prompted, or not in which case we _must_
select early debugging.
So add a bool which controls whether we have early debugging at all, and then
if that's enabled provide the choice. The extra bool will actually be useful
in another patch I have lying around, so this is a win-win.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig.debug | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
Index: to-merge/arch/powerpc/Kconfig.debug
===================================================================
--- to-merge.orig/arch/powerpc/Kconfig.debug
+++ to-merge/arch/powerpc/Kconfig.debug
@@ -110,13 +110,16 @@ config SERIAL_TEXT_DEBUG
depends on 4xx || LOPEC || MV64X60 || PPLUS || PRPMC800 || \
PPC_GEN550 || PPC_MPC52xx
+config PPC_EARLY_DEBUG
+ bool "Early debugging (dangerous)"
+
choice
- prompt "Early debugging (dangerous)"
- bool
- optional
+ prompt "Early debugging console"
+ depends on PPC_EARLY_DEBUG
help
- Enable early debugging. Careful, if you enable debugging for the
- wrong type of machine your kernel _will not boot_.
+ Use the selected console for early debugging. Careful, if you
+ enable debugging for the wrong type of machine your kernel
+ _will not boot_.
config PPC_EARLY_DEBUG_LPAR
bool "LPAR HV Console"
^ permalink raw reply
* Re: [patch] powerpc: remove do-nothing cpu setup routines
From: Geoff Levand @ 2006-05-09 2:49 UTC (permalink / raw)
To: Geoff Levand; +Cc: Arnd Bergmann, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <44600047.2010401@am.sony.com>
Sorry, the last patch accidentally removed the preprocessor
conditionals on the 32 bit declarations.
Updated patch below.
-Geoff
Removed the do-nothing routines __setup_cpu_power3 and
__setup_cpu_power4 and replaced them with a null pointer check
in the caller. Also removed the Cell processor specific
routine __setup_cpu_be which improperly accessed the
hypervisor page size configuration at SPR HID6.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Index: cell--alp--3/arch/powerpc/kernel/cpu_setup_power4.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/cpu_setup_power4.S 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/cpu_setup_power4.S 2006-05-08 19:18:45.000000000 -0700
@@ -73,23 +73,6 @@
isync
blr
-_GLOBAL(__setup_cpu_power4)
- blr
-
-_GLOBAL(__setup_cpu_be)
- /* Set large page sizes LP=0: 16MB, LP=1: 64KB */
- addi r3, 0, 0
- ori r3, r3, HID6_LB
- sldi r3, r3, 32
- nor r3, r3, r3
- mfspr r4, SPRN_HID6
- and r4, r4, r3
- addi r3, 0, 0x02000
- sldi r3, r3, 32
- or r4, r4, r3
- mtspr SPRN_HID6, r4
- blr
-
_GLOBAL(__setup_cpu_ppc970)
mfspr r0,SPRN_HID0
li r11,5 /* clear DOZE and SLEEP */
Index: cell--alp--3/arch/powerpc/kernel/cputable.c
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/cputable.c 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/cputable.c 2006-05-08 19:43:37.000000000 -0700
@@ -30,11 +30,7 @@
* part of the cputable though. That has to be fixed for both ppc32
* and ppc64
*/
-#ifdef CONFIG_PPC64
-extern void __setup_cpu_power3(unsigned long offset, struct cpu_spec* spec);
-extern void __setup_cpu_power4(unsigned long offset, struct cpu_spec* spec);
-extern void __setup_cpu_be(unsigned long offset, struct cpu_spec* spec);
-#else
+#ifdef CONFIG_PPC32
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
@@ -80,7 +76,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/power3",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "power3",
@@ -94,7 +89,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/power3",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "power3",
@@ -108,7 +102,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -122,7 +115,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -136,7 +128,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -150,7 +141,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -164,7 +154,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power4,
.oprofile_cpu_type = "ppc64/power4",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power4",
@@ -178,7 +167,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power4,
.oprofile_cpu_type = "ppc64/power4",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power4",
@@ -244,7 +232,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .cpu_setup = __setup_cpu_power4,
.oprofile_cpu_type = "ppc64/power5",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power5",
@@ -258,7 +245,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .cpu_setup = __setup_cpu_power4,
.oprofile_cpu_type = "ppc64/power5+",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power5+",
@@ -273,7 +259,6 @@
PPC_FEATURE_SMT,
.icache_bsize = 128,
.dcache_bsize = 128,
- .cpu_setup = __setup_cpu_be,
.platform = "ppc-cell-be",
},
{ /* default match */
@@ -285,7 +270,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .cpu_setup = __setup_cpu_power4,
.platform = "power4",
}
#endif /* CONFIG_PPC64 */
Index: cell--alp--3/arch/powerpc/kernel/misc_32.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/misc_32.S 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/misc_32.S 2006-05-08 19:18:45.000000000 -0700
@@ -216,7 +216,7 @@
lwz r4,0(r4)
add r4,r4,r3
lwz r5,CPU_SPEC_SETUP(r4)
- cmpi 0,r5,0
+ cmpwi 0,r5,0
add r5,r5,r3
beqlr
mtctr r5
Index: cell--alp--3/arch/powerpc/kernel/misc_64.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/misc_64.S 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/misc_64.S 2006-05-08 19:18:45.000000000 -0700
@@ -482,7 +482,9 @@
sub r0,r3,r5
std r0,0(r4)
ld r4,CPU_SPEC_SETUP(r3)
+ cmpdi 0,r4,0
add r4,r4,r5
+ beqlr
ld r4,0(r4)
add r4,r4,r5
mtctr r4
@@ -768,9 +770,6 @@
#endif /* CONFIG_ALTIVEC */
-_GLOBAL(__setup_cpu_power3)
- blr
-
_GLOBAL(execve)
li r0,__NR_execve
sc
^ permalink raw reply
* Re: [patch] powerpc: remove do-nothing cpu setup routines
From: Geoff Levand @ 2006-05-09 2:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Levand, Geoffrey, Arnd Bergmann, linuxppc-dev, cbe-oss-dev
In-Reply-To: <BE9739CD-B66A-43A4-B5E9-2DE49CEDE5B7@kernel.crashing.org>
Segher Boessenkool wrote:
>>> Removes the processor specific do-nothing routines
>>> __setup_cpu_power3 and
>>> __setup_cpu_power4 with the generic routine __setup_cpu_null.
>>
>> Why not just change the caller to test for NULL ?
>
> Yes, please do (as Paul suggested already).
Paul, here is an updated patch. This version makes my other
patch 'cell: remove broken __setup_cpu_be function', send by
Arnd, obsolete.
-Geoff
Removed the do-nothing routines __setup_cpu_power3 and
__setup_cpu_power4 and replaced them with a null pointer check
in the caller. Also removed the Cell processor specific
routine __setup_cpu_be which improperly accessed the
hypervisor page size configuration at SPR HID6.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Index: cell--alp--3/arch/powerpc/kernel/cpu_setup_power4.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/cpu_setup_power4.S 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/cpu_setup_power4.S 2006-05-08 18:51:55.000000000 -0700
@@ -73,23 +73,6 @@
isync
blr
-_GLOBAL(__setup_cpu_power4)
- blr
-
-_GLOBAL(__setup_cpu_be)
- /* Set large page sizes LP=0: 16MB, LP=1: 64KB */
- addi r3, 0, 0
- ori r3, r3, HID6_LB
- sldi r3, r3, 32
- nor r3, r3, r3
- mfspr r4, SPRN_HID6
- and r4, r4, r3
- addi r3, 0, 0x02000
- sldi r3, r3, 32
- or r4, r4, r3
- mtspr SPRN_HID6, r4
- blr
-
_GLOBAL(__setup_cpu_ppc970)
mfspr r0,SPRN_HID0
li r11,5 /* clear DOZE and SLEEP */
Index: cell--alp--3/arch/powerpc/kernel/cputable.c
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/cputable.c 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/cputable.c 2006-05-08 18:51:55.000000000 -0700
@@ -30,11 +30,6 @@
* part of the cputable though. That has to be fixed for both ppc32
* and ppc64
*/
-#ifdef CONFIG_PPC64
-extern void __setup_cpu_power3(unsigned long offset, struct cpu_spec* spec);
-extern void __setup_cpu_power4(unsigned long offset, struct cpu_spec* spec);
-extern void __setup_cpu_be(unsigned long offset, struct cpu_spec* spec);
-#else
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
@@ -43,7 +38,6 @@
extern void __setup_cpu_7400(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_7410(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_745x(unsigned long offset, struct cpu_spec* spec);
-#endif /* CONFIG_PPC32 */
extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
/* This table only contains "desktop" CPUs, it need to be filled with embedded
@@ -80,7 +74,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/power3",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "power3",
@@ -94,7 +87,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/power3",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "power3",
@@ -108,7 +100,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -122,7 +113,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -136,7 +126,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -150,7 +139,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -164,7 +152,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power4,
.oprofile_cpu_type = "ppc64/power4",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power4",
@@ -178,7 +165,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power4,
.oprofile_cpu_type = "ppc64/power4",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power4",
@@ -244,7 +230,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .cpu_setup = __setup_cpu_power4,
.oprofile_cpu_type = "ppc64/power5",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power5",
@@ -258,7 +243,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .cpu_setup = __setup_cpu_power4,
.oprofile_cpu_type = "ppc64/power5+",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power5+",
@@ -273,7 +257,6 @@
PPC_FEATURE_SMT,
.icache_bsize = 128,
.dcache_bsize = 128,
- .cpu_setup = __setup_cpu_be,
.platform = "ppc-cell-be",
},
{ /* default match */
@@ -285,7 +268,6 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .cpu_setup = __setup_cpu_power4,
.platform = "power4",
}
#endif /* CONFIG_PPC64 */
Index: cell--alp--3/arch/powerpc/kernel/misc_32.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/misc_32.S 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/misc_32.S 2006-05-08 18:57:44.000000000 -0700
@@ -216,7 +216,7 @@
lwz r4,0(r4)
add r4,r4,r3
lwz r5,CPU_SPEC_SETUP(r4)
- cmpi 0,r5,0
+ cmpwi 0,r5,0
add r5,r5,r3
beqlr
mtctr r5
Index: cell--alp--3/arch/powerpc/kernel/misc_64.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/misc_64.S 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/misc_64.S 2006-05-08 19:00:13.000000000 -0700
@@ -482,7 +482,9 @@
sub r0,r3,r5
std r0,0(r4)
ld r4,CPU_SPEC_SETUP(r3)
+ cmpdi 0,r4,0
add r4,r4,r5
+ beqlr
ld r4,0(r4)
add r4,r4,r5
mtctr r4
@@ -768,9 +770,6 @@
#endif /* CONFIG_ALTIVEC */
-_GLOBAL(__setup_cpu_power3)
- blr
-
_GLOBAL(execve)
li r0,__NR_execve
sc
^ permalink raw reply
* ELDK for MPC8260
From: Srinivas Murthy @ 2006-05-09 1:46 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 195 bytes --]
Hi,
What is the current status of the ELDK support for the MPC8260 processor?
Is there a current POWERQuicc based processor board for which we have the
ELDK support?
Thanks.
Srinivas
[-- Attachment #2: Type: text/html, Size: 312 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] Break out memory initialisation code from page_alloc.c to mem_init.c
From: Nick Piggin @ 2006-05-09 1:47 UTC (permalink / raw)
To: Mel Gorman
Cc: akpm, davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060508141231.26912.52976.sendpatchset@skynet>
Mel Gorman wrote:
>page_alloc.c contains a large amount of memory initialisation code. This patch
>breaks out the initialisation code to a separate file to make page_alloc.c
>a bit easier to read.
>
I realise this is at the wrong end of your queue, but if you _can_ easily
break it out and submit it first, it would be a nice cleanup and would help
shrink your main patchset.
Also, we're recently having some problems with architectures not aligning
zones correctly. Would it make sense to add these sorts of sanity checks,
and possibly forcing alignment corrections into your generic code?
Nick
--
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply
* Re: [patch] powerpc: remove do-nothing cpu setup routines
From: Segher Boessenkool @ 2006-05-09 0:47 UTC (permalink / raw)
To: Geoff Levand; +Cc: Paul Mackerras, cbe-oss-dev, Arnd Bergmann, linuxppc-dev
In-Reply-To: <445FDF62.2030008@am.sony.com>
> lwz r5,CPU_SPEC_SETUP(r4)
> cmpi 0,r5,0
> add r5,r5,r3
> beqlr
> mtctr r5
> bctr
>
> But, could this also be:
>
> lwz r5,CPU_SPEC_SETUP(r4)
> cmpi 0,r5,0
> beqlr
> add r5,r5,r3
> mtctr r5
> bctr
Sure. Except it should be cmpwi cr0,r5,0 or cmpwi r5,0 --
cmpi with three arguments is not valid PowerPC assembler code.
Segher
^ 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