* 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
* Re: [patch] powerpc: remove do-nothing cpu setup routines
From: Benjamin Herrenschmidt @ 2006-05-09 0:28 UTC (permalink / raw)
To: Geoff Levand; +Cc: Arnd Bergmann, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <445FDF62.2030008@am.sony.com>
On Mon, 2006-05-08 at 17:16 -0700, Geoff Levand wrote:
> 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 ?
>
> OK, I see the 32 bit version already does this, but I'm
> wondering if there is some restriction on the instruction
> sequence between the compare and the branch. Here's what's
> there:
>
> 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
Just an optimisation for a code path that doesn't really need any :)
Blame habits...
Ben.
^ permalink raw reply
* Re: [patch] powerpc: remove do-nothing cpu setup routines
From: Geoff Levand @ 2006-05-09 0:16 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Levand, Geoffrey, Arnd Bergmann, linuxppc-dev, Paul Mackerras,
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 ?
OK, I see the 32 bit version already does this, but I'm
wondering if there is some restriction on the instruction
sequence between the compare and the branch. Here's what's
there:
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
-Geoff
^ permalink raw reply
* Re: BDI2000 help
From: Steve Iribarne (GMail) @ 2006-05-08 23:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060508231923.DB201352B0C@atlas.denx.de>
> Ummm... if you want to use the BDI2000 with a MPC8260 processor you
> need a firmware version for such a CPU. Abatron always ships these
> with manual included (both on paper copy and on floppy disk).
>
> > outdated. I couldn't readily find the newer manual. So when all else
> > fails. Ask. :)
>
> Before asking, search. You should be able to find
> http://www.abatron.ch/, and then
> http://www.abatron.ch/Files/ManGdbCOP-2000C.pdf
>
Thanks. And yes I got this all legal its just that some people in the
company quit and I'm still trying to find everything.
^ permalink raw reply
* Re: BDI2000 help
From: Wolfgang Denk @ 2006-05-08 23:19 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690605081559u7d03cb73m733a50ac2825fc27@mail.gmail.com>
In message <b4b98b690605081559u7d03cb73m733a50ac2825fc27@mail.gmail.com> you wrote:
>
> > > The question I have is what "type" do I select for my MPC8260. As you
...
> Funny Wolfgang. I did read it but we only have a very outdated
> version. So it only talks about the MPC8xx/MCP5xx. So it's a bit
Ummm... if you want to use the BDI2000 with a MPC8260 processor you
need a firmware version for such a CPU. Abatron always ships these
with manual included (both on paper copy and on floppy disk).
> outdated. I couldn't readily find the newer manual. So when all else
> fails. Ask. :)
Before asking, search. You should be able to find
http://www.abatron.ch/, and then
http://www.abatron.ch/Files/ManGdbCOP-2000C.pdf
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 more data I punch in this card, the lighter it becomes, and the
lower the mailing cost."
- Stan Kelly-Bootle, "The Devil's DP Dictionary"
^ permalink raw reply
* Re: BDI2000 help
From: Dan Malek @ 2006-05-08 23:13 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690605081559u7d03cb73m733a50ac2825fc27@mail.gmail.com>
On May 8, 2006, at 6:59 PM, Steve Iribarne (GMail) wrote:
> .... So it only talks about the MPC8xx/MCP5xx. So it's a bit
> outdated. I couldn't readily find the newer manual. So when all else
> fails. Ask. :)
Well, if you legally obtained the 82xx firmware for the
BDI, you should also have the matching manual. The 8xx
and 82xx are separate products and manuals.
-- Dan
^ permalink raw reply
* Re: Information for setting up SMT related parameters on linux 2.6.16 on POWER5
From: Segher Boessenkool @ 2006-05-08 23:04 UTC (permalink / raw)
To: will_schmidt; +Cc: linuxppc-dev, Arnd Bergmann, linux-kernel, cbe-oss-dev
In-Reply-To: <1147118619.8664.44.camel@localhost.localdomain>
> the HMT_* macros are telling firmware that "this processor thread
> should
> run at this priority". Typically used when we're waiting on a
> spinlock.
> I.e. When we are waiting on a spinlock, we hit the HMT_low macro to
> drop
> our threads priority, allowing the other thread to use those extra
> cycles finish it's stuff quicker, and maybe even release the lock
> we're
> waiting for. HMT_* is all within the kernel though, no
> exposure
> to userspace apps.
Actually, those macros translate straight into a single machine insn.
No firmware is involved. See include/asm-powerpc/processor.h. For
example:
#define HMT_very_low() asm volatile("or 31,31,31 # very low
priority")
You can use those same macros from user space, although it is CPU
implementation dependent which priorities you can actually set (you
probably can do low and medium priority).
Segher
^ permalink raw reply
* Re: BDI2000 help
From: Steve Iribarne (GMail) @ 2006-05-08 22:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060508224758.3A56C352B0C@atlas.denx.de>
On 5/8/06, Wolfgang Denk <wd@denx.de> wrote:
> In message <b4b98b690605081527u9001aandfd6f54733c2a09d@mail.gmail.com> yo=
u wrote:
> >
> > The question I have is what "type" do I select for my MPC8260. As you
> > can see I'm new to this part of the PPC world. I'm usually a bit
> > higher up and someone has already set this up for me.
>
> Well, maybe you can come down a bit and start reading the manual that
> comes with the BDI2000?
>
>
Funny Wolfgang. I did read it but we only have a very outdated
version. So it only talks about the MPC8xx/MCP5xx. So it's a bit
outdated. I couldn't readily find the newer manual. So when all else
fails. Ask. :)
> 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
> For every complex problem, there is a solution that is simple, neat,
> and wrong. -- H. L. Mencken
>
^ permalink raw reply
* Re: BDI2000 help
From: Wolfgang Denk @ 2006-05-08 22:47 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690605081527u9001aandfd6f54733c2a09d@mail.gmail.com>
In message <b4b98b690605081527u9001aandfd6f54733c2a09d@mail.gmail.com> you wrote:
>
> The question I have is what "type" do I select for my MPC8260. As you
> can see I'm new to this part of the PPC world. I'm usually a bit
> higher up and someone has already set this up for me.
Well, maybe you can come down a bit and start reading the manual that
comes with the BDI2000?
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
For every complex problem, there is a solution that is simple, neat,
and wrong. -- H. L. Mencken
^ permalink raw reply
* Re: IMAP_ADDR on PPC 8xx
From: Wolfgang Denk @ 2006-05-08 22:46 UTC (permalink / raw)
To: Walter L. Wimer III; +Cc: linuxppc-embedded
In-Reply-To: <1147108983.27101.63.camel@excalibur.timesys.com>
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.
> 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.
> 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.
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
Hokey religions and ancient weapons are no substitute for a good
blaster at your side. - Han Solo
^ permalink raw reply
* [PATCH] Add PVR for new Rev C 440EP
From: John Otken @ 2006-05-08 22:32 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Stefan Roese
Here's a patch to add the PVR for the AMCC 440EP Rev C:
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e4e8137..a2967b6 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -938,6 +938,16 @@ struct cpu_spec cpu_specs[] = {
.dcache_bsize = 32,
.platform = "ppc440",
},
+ {
+ .pvr_mask = 0xf0000fff,
+ .pvr_value = 0x400008d4,
+ .cpu_name = "440EP Rev. C",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .platform = "ppc440",
+ },
{ /* 440GP Rev. B */
.pvr_mask = 0xf0000fff,
.pvr_value = 0x40000440,
^ permalink raw reply related
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