* Re: [RFC,PATCH] scripts/package: add powerpc images to tarball
From: Milton Miller @ 2008-07-26 17:20 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel, Jeremy Kerr
In-Reply-To: <fa686aa40807252155l4f785920qdb14d117067b30f4@mail.gmail.com>
On Jul 25, 2008, at 11:55 PM, Grant Likely wrote:
> On Thu, Jul 24, 2008 at 9:08 PM, Milton Miller <miltonm@bga.com> wrote:
>>> Add support for powerpc builds in the buildtar script, to include
>>> a few default images.
>>> ---
>>> RFC: any requests for more/less boot images?
>> ..
>>> + for img in zImage zImage.pseries zImage.iseries \
>>> + dtbImage dtbImage.ps3
>>
>> Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
>> that are newer than vmlinux?
>
> dtbImage is not a buildable image. Neither is cuImage, treeImage or
> simpleImage. All of those targets embed a device tree which is
> specified by adding the .dts filename to the target name.
I intended "all dtbImage" as a wildcard for dtbImage.*, etc.
> so, for example, 'make cuImage' fails. Instead you do 'make
> cuImage.lite5200b' which pulls in dts/lite5200b.dts.
The user does make zImage which makes cuImage.lite5200b based on
Kconfig. Or it was that way until your change in 2.6.25 to allow the
later, but they can still do the former.
Hmm, we really need to fix our calls to make boot images with make -j.
Something for my todo list.
> Also, zImage is a 'meta' target that builds all the default image
> targets (the $image-y list). The zImage is actually just a symlink to
> the first file in the list of default images. So zImage can actually
> point to any kind of kernel image depending on how the kernel is
> configured. I wonder if we should just remove the zImage file
> entirely, or at least make it always linked to one particular image
> type.
I think its fine as it is. It says "make what is configured" that
lets cross-platform building scripts be dumb and not need to know
specificially what image makes sense to make. Perhaps we should make
it default to our additional target in Kconfig if specified, this
allowing the user to specify which version he gets.
milton
^ permalink raw reply
* [PATCH 2/2] [PPC64] change powerpc Makefile to use the new tuning options
From: Marvin @ 2008-07-26 16:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: olof, miltonm, arnd
In-Reply-To: <200807261833.55994.marvin24@gmx.de>
This patch modifies the Makefile to use the new tuning options. Most of the
work
is done in Kconfig now, so this looks a little bit more clearly (except the
broken altivec hack).
Subject: [PATCH 2/2] [PPC64] change powerpc Makefile to use the new tuning
options
---
arch/powerpc/Makefile | 24 +++++-------------------
1 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 9155c93..dc189e7 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -75,29 +75,15 @@ CPP = $(CC) -E $(KBUILD_CFLAGS)
CHECKFLAGS
+= -m$(CONFIG_WORD_SIZE) -D__powerpc__ -D__powerpc$(CONFIG_WORD_SIZE)__
ifeq ($(CONFIG_PPC64),y)
-GCC_BROKEN_VEC := $(shell if [ $(call cc-version) -lt 0400 ] ; then echo "y";
fi)
-
-ifeq ($(CONFIG_POWER4_ONLY),y)
-ifeq ($(CONFIG_ALTIVEC),y)
-ifeq ($(GCC_BROKEN_VEC),y)
- KBUILD_CFLAGS += $(call cc-option,-mcpu=970)
-else
- KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
-endif
-else
- KBUILD_CFLAGS += $(call cc-option,-mcpu=power4)
-endif
-else
- KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
-endif
+KBUILD_CFLAGS += $(call cc-option, -mcpu=$(CONFIG_OPT_CPU) )
+KBUILD_CFLAGS += $(call cc-option, -mtune=$(CONFIG_TUNE_CPU) )
+ifeq ($(shell if [ $(call cc-version) -lt 0400 ] ; then echo "y"; fi),y)
+ KBUILD_CFLAGS := $(subst mcpu=970,mcpu=power4,$(KBUILD_CFLAGS))
+endif
else
LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
endif
-ifeq ($(CONFIG_TUNE_CELL),y)
- KBUILD_CFLAGS += $(call cc-option,-mtune=cell)
-endif
-
# No AltiVec instruction when building kernel
KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
--
1.5.6.2
^ permalink raw reply related
* [PATCH 0/2] tuning options for PPC64
From: Marvin @ 2008-07-26 16:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: olof, miltonm, arnd
Hi,
this is my second attempt to introduce some tuning options for PPC64. These
patches are much less invasive as the previous patchset.
Because the power cpus seem to have various features I don't know/understand I
didn't touch any feature flags/config options this time, but focused only on
the compiler flags.
Nevertheless feature flags and cleanups can be added later based on the cpu
selection as Milton suggested. I will try this if these patches receive
a "GO!".
Also, as Arndt suggested, I used separate mcpu and mtune options but didn't
force the user to use it.
As always, comments are welcome.
Greetings
Marvin
^ permalink raw reply
* [PATCH 1/2] [PPC64] add tuning options to Kconfig.cputype
From: Marvin @ 2008-07-26 16:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: olof, miltonm, arnd
In-Reply-To: <200807261833.55994.marvin24@gmx.de>
This patch adds CPU selection to Kconfig.cputype. I did my best to make oldconfig
happy, but some things just don't work ;-) Maybe more CPUs and help texts can be
added, but it should be enough for now.
Subject: [PATCH 1/2] [PPC64] add tuning options to Kconfig.cputype
---
arch/powerpc/platforms/Kconfig.cputype | 133 ++++++++++++++++++++++++++++---
1 files changed, 120 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 7f65127..f528748 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -56,8 +56,127 @@ config E200
endchoice
+config TUNE_OPT_CPU
+ depends on PPC64
+ def_bool n
+ prompt "Tune/optimize for a specific CPU"
+ help
+ This option enables a sub-menu where you can choose a certain
+ CPU to tune (via -mtune) or optimize (via -mcpu) for.
+
+choice
+ depends on TUNE_OPT_CPU
+ prompt "Choose the CPU to tune for"
+ default TUNE_POWER4
+ help
+ Choosing this will make the code run faster on the selected CPU,
+ but somehow slower on others.
+
+ This option only changes the scheduling of instructions, not the
+ selection of instructions itself, so the resulting kernel will keep
+ running on all other machines.
+
+ The default is to tune for power4.
+
+config TUNE_RS64
+ bool "RS64"
+
+config TUNE_POWER3
+ bool "POWER3"
+
+config TUNE_POWER4
+ bool "POWER4/G5/970"
+ help
+ Cause the compiler to tune for the POWER4 and derivates CPUS, like
+ G5 and other PPC970 variants.
+
+config TUNE_POWER5
+ bool "POWER5"
+
+config TUNE_POWER6
+ bool "POWER6"
+
+config TUNE_CELL
+ bool "Cell Broadband Engine"
+ help
+ Cause the compiler to optimize for the PPE of the Cell Broadband
+ Engine. This will make the code run considerably faster on Cell
+ but somewhat slower on other machines. This option only changes
+ the scheduling of instructions, not the selection of instructions
+ itself, so the resulting kernel will keep running on all other
+ machines.
+
+endchoice
+
+choice
+ depends on TUNE_OPT_CPU
+ default OPT_NONE
+ prompt "Choose the CPU to optimize for"
+ help
+ Choosing this will make the code run significant faster on the
+ selected CPU by selecting the scheduling and the instruction set
+ for the specific CPU. It will propably not run on earlier gernerations
+ but should run on newer ones.
+
+ The default is not to optimize for a specific CPU.
+
+config OPT_NONE
+ bool "none"
+
+config OPT_RS64
+ bool "RS64"
+
+config OPT_POWER3
+ bool "POWER3"
+ select POWER3
+
+config OPT_POWER4
+ bool "POWER4"
+ select POWER4_ONLY
+ ---help---
+ Cause the compiler to optimize for POWER4 processors. The resulting
+ binary will not work on POWER3 or RS64 processors when compiled
+ with binutils 2.15 or later.
+
+config OPT_PPC970
+ bool "G5/PPC970"
+ select POWER4_ONLY
+
+config OPT_POWER5
+ bool "POWER5"
+ select POWER4_ONLY
+
+config OPT_POWER6
+ bool "POWER6"
+ select POWER4_ONLY
+
+endchoice
+
+config OPT_CPU
+ depends on PPC64
+ string
+ default "rs64" if OPT_RS64
+ default "power3" if OPT_POWER3
+ default "power4" if OPT_POWER4
+ default "970" if OPT_PPC970
+ default "power5" if OPT_POWER5
+ default "power6" if OPT_POWER6
+ default "cell" if OPT_CELL
+ default ""
+
+config TUNE_CPU
+ depends on PPC64
+ string
+ default "rs64" if TUNE_RS64
+ default "power3" if TUNE_POWER3
+ default "power5" if TUNE_POWER5
+ default "power6" if TUNE_POWER6
+ default "cell" if TUNE_CELL
+ default "power4"
+
config POWER4_ONLY
- bool "Optimize for POWER4"
+ bool
+ prompt "Optimize for POWER4" if !TUNE_OPT_CPU
depends on PPC64
default n
---help---
@@ -74,18 +193,6 @@ config POWER4
depends on PPC64
def_bool y
-config TUNE_CELL
- bool "Optimize for Cell Broadband Engine"
- depends on PPC64
- help
- Cause the compiler to optimize for the PPE of the Cell Broadband
- Engine. This will make the code run considerably faster on Cell
- but somewhat slower on other machines. This option only changes
- the scheduling of instructions, not the selection of instructions
- itself, so the resulting kernel will keep running on all other
- machines. When building a kernel that is supposed to run only
- on Cell, you should also select the POWER4_ONLY option.
-
# this is temp to handle compat with arch=ppc
config 8xx
bool
--
1.5.6.2
^ permalink raw reply related
* Re: linux-next: kbuild tree build failure
From: Stephen Rothwell @ 2008-07-26 12:40 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Benjamin, Milton Miller, linuxppc-dev, linux-next, Mackerras,
Paul
In-Reply-To: <20080726100631.GA3714@uranus.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
Hi Sam,
On Sat, 26 Jul 2008 12:06:32 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> I removed the offending commits from kbuild-next before I
> sent the pull request.
> I will though revisit the issue after -rc1.
Thanks again.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mpc5200: Fix locking on mpc52xx_spi driver
From: Daniel Walker @ 2008-07-26 12:35 UTC (permalink / raw)
To: Grant Likely; +Cc: spi-devel-general, dbrownell, linuxppc-dev
In-Reply-To: <20080726062226.10506.65539.stgit@trillian.secretlab.ca>
On Sat, 2008-07-26 at 02:24 -0400, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Locking was incorrect for the state machine processing since there are
> conditions where both the work queue and the IRQ can be active. This
> patch fixes the handling to ensure the spin lock is held whenever the
> state machine is being processed.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Hi Daniel,
>
> Here is the incremental change to the mpc52xx_spi driver to fix up the
> locking. It should be safe and unambiguous now.
Thank you, it looks much better..
Daniel
^ permalink raw reply
* Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text]
From: Benjamin Herrenschmidt @ 2008-07-26 12:36 UTC (permalink / raw)
To: Hugh Dickins
Cc: Linuxppc-dev, Ingo Molnar, the arch/x86 maintainers, linux-kernel,
Mike Travis
In-Reply-To: <Pine.LNX.4.64.0807261122430.20543@blonde.site>
On Sat, 2008-07-26 at 12:02 +0100, Hugh Dickins wrote:
>
> Hmm, perhaps it is doing sibling calls differently even without the
> explicit -fno-optimize-sibling-calls (but when I add that option,
> the vmlinux size does go up another 4400).
>
> Sorry, I'm most probably fussing over nothing,
> and wasting your time with my ignorance.
No you aren't, there is indeed something happening. It looks like gcc is
keeping a copy of each stack frame in r31, thus forcing to save/restore
that register, along function calls, possibly to help get reliable
frames for leaf functions. I don't think we use that "feature" in our
backtrace code though... so it won't harm in the sense that it won't
break things, but it will indeed bloat the code a little bit.
Maybe we should totally disable -fno-omit-frame-pointers on powerpc ...
either that or see about actually using that r31 linkage, though I'm not
sure it would be that useful.
I'll have to talk to our toolchain folks to figure out exactly what's
going on there.
Cheers,
Ben.
^ permalink raw reply
* ucc_geth_ethtool.c: removed duplicated include
From: Huang Weiyi @ 2008-07-26 11:37 UTC (permalink / raw)
To: leoli; +Cc: linuxppc-dev
Removed duplicated include <asm/uaccess.h> in
drivers/net/ucc_geth_ethtool.c.
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
--- a/drivers/net/ucc_geth_ethtool.c 2008-05-10 08:41:10.000000000 +0800
+++ b/drivers/net/ucc_geth_ethtool.c 2008-05-10 08:41:42.000000000 +0800
@@ -37,7 +37,6 @@
#include <asm/irq.h>
#include <asm/uaccess.h>
#include <asm/types.h>
-#include <asm/uaccess.h>
#include "ucc_geth.h"
#include "ucc_geth_mii.h"
^ permalink raw reply
* Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text]
From: Hugh Dickins @ 2008-07-26 11:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linuxppc-dev, Ingo Molnar, the arch/x86 maintainers, linux-kernel,
Mike Travis
In-Reply-To: <1217022373.11188.115.camel@pasglop>
On Sat, 26 Jul 2008, Benjamin Herrenschmidt wrote:
> On Fri, 2008-07-25 at 19:45 +0100, Hugh Dickins wrote:
> >
> > I've Cc'ed Ben and linuxppc-dev because I wonder if they're aware
> > that several options (I got it from LATENCYTOP, but I think LOCKDEP
> > and FTRACE and some others) are doing a "select FRAME_POINTER",
> > which forces CONFIG_FRAME_POINTER=y on PowerPC, even though
> > FRAME_POINTER is not an option offered on PowerPC. The
> > resulting kernels appear to run okay, but I was surprised.
>
> Because the option just does nothing for us ? :-) We always have frame
> pointers on powerpc except in some case for leaf functions. I don't know
> if the option has any actual effect on the later, but I don't think we
> have a case where doing either way would break things.
Thanks, that's reassuring.
I raised the question partly because I'd noticed CONFIG_FRAME_POINTER=y
does increase the size of powerpc kernels: part of that will have been
because of the -fno-optimize-sibling-calls bundled in, but when I edit
that out of the Makefile I'm left with
text data bss dec hex filename
4773061 856632 232052 5861745 597171 FPN/vmlinux
4943653 856632 232052 6032337 5c0bd1 FPY/vmlinux
Going to the first divergence between them,
the 2.6.26-git6 vmlinux built without CONFIG_FRAME_POINTER has
c000000000008024 <.run_init_process>:
c000000000008024: 7c 08 02 a6 mflr r0
c000000000008028: fb c1 ff f0 std r30,-16(r1)
c00000000000802c: eb c2 80 48 ld r30,-32696(r2)
c000000000008030: f8 01 00 10 std r0,16(r1)
c000000000008034: f8 21 ff 81 stdu r1,-128(r1)
c000000000008038: e9 3e 80 10 ld r9,-32752(r30)
c00000000000803c: f8 69 00 00 std r3,0(r9)
c000000000008040: 7d 24 4b 78 mr r4,r9
c000000000008044: 38 a9 01 10 addi r5,r9,272
c000000000008048: 48 01 70 4d bl c00000000001f094
<.kernel_execve>
c00000000000804c: 60 00 00 00 nop
c000000000008050: 38 21 00 80 addi r1,r1,128
c000000000008054: e8 01 00 10 ld r0,16(r1)
c000000000008058: eb c1 ff f0 ld r30,-16(r1)
c00000000000805c: 7c 08 03 a6 mtlr r0
c000000000008060: 4e 80 00 20 blr
Whereas the vmlinux built with -fno-omit-frame_pointer has
c000000000008024 <.run_init_process>:
c000000000008024: 7c 08 02 a6 mflr r0
c000000000008028: fb c1 ff f0 std r30,-16(r1)
c00000000000802c: eb c2 80 48 ld r30,-32696(r2)
c000000000008030: fb e1 ff f8 std r31,-8(r1)
c000000000008034: f8 01 00 10 std r0,16(r1)
c000000000008038: f8 21 ff 81 stdu r1,-128(r1)
c00000000000803c: e9 3e 80 10 ld r9,-32752(r30)
c000000000008040: f8 69 00 00 std r3,0(r9)
c000000000008044: 7d 24 4b 78 mr r4,r9
c000000000008048: 38 a9 01 10 addi r5,r9,272
c00000000000804c: 7c 3f 0b 78 mr r31,r1
c000000000008050: 48 01 8c 91 bl c000000000020ce0
<.kernel_execve>
c000000000008054: 60 00 00 00 nop
c000000000008058: e8 21 00 00 ld r1,0(r1)
c00000000000805c: e8 01 00 10 ld r0,16(r1)
c000000000008060: eb c1 ff f0 ld r30,-16(r1)
c000000000008064: eb e1 ff f8 ld r31,-8(r1)
c000000000008068: 7c 08 03 a6 mtlr r0
c00000000000806c: 4e 80 00 20 blr
That's for
static void run_init_process(char *init_filename)
{
argv_init[0] = init_filename;
kernel_execve(init_filename, argv_init, envp_init);
}
Hmm, perhaps it is doing sibling calls differently even without the
explicit -fno-optimize-sibling-calls (but when I add that option,
the vmlinux size does go up another 4400).
Sorry, I'm most probably fussing over nothing,
and wasting your time with my ignorance.
Hugh
^ permalink raw reply
* Re: [PATCH] Memset the kernel copy of rtas args before using
From: Sergei Shtylyov @ 2008-07-26 10:52 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <488A44DB.7090400@austin.ibm.com>
Hello.
Nathan Fontenot wrote:
> Index: linux-2.6.git/arch/powerpc/kernel/rtas.c
> ===================================================================
> --- linux-2.6.git.orig/arch/powerpc/kernel/rtas.c 2008-07-22
> 09:34:03.000000000 -0500
> +++ linux-2.6.git/arch/powerpc/kernel/rtas.c 2008-07-25
> 16:06:00.000000000 -0500
> @@ -775,6 +775,8 @@
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> + memset(&args, 0, sizeof(args));
> +
You could use memzero() directly -- memset(x, 0, sizeof(x))l should
boil down to it anyway...
> if (copy_from_user(&args, uargs, 3 * sizeof(u32)) != 0)
> return -EFAULT;
WBR, Sergei
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Sam Ravnborg @ 2008-07-26 10:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Milton Miller, linuxppc-dev, linux-next, Paul Mackerras
In-Reply-To: <20080725141330.c58e0a07.sfr@canb.auug.org.au>
On Fri, Jul 25, 2008 at 02:13:30PM +1000, Stephen Rothwell wrote:
> Hi Sam,
>
> On Mon, 7 Jul 2008 18:40:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> > arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> > arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
>
> This still fails in linux-next today. We need some solution before you
> send these commits to Linus.
I removed the offending commits from kbuild-next before I
sent the pull request.
I will though revisit the issue after -rc1.
Sam
^ permalink raw reply
* Re: [RFC PATCH] of_gpio: implement of_get_gpio_flags()
From: Trent Piepho @ 2008-07-26 8:26 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080725164815.GA23228@polina.dev.rtsoft.ru>
On Fri, 25 Jul 2008, Anton Vorontsov wrote:
>
> The name seems a bit unfortunate though, because one could read the
> function as it gets gpio flags only (though, we might implement
> this instead, but this way average driver will end up with parsing
> gpios = <> twice).
It is kind of a confusing name. I'd be tempted to just change of_get_gpio,
it's a new function and it's only called from four places so it's not that
hard to change.
^ permalink raw reply
* [PATCH] powerpc/mpc5200: Fix locking on mpc52xx_spi driver
From: Grant Likely @ 2008-07-26 6:24 UTC (permalink / raw)
To: dwalker, spi-devel-general, dbrownell, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Locking was incorrect for the state machine processing since there are
conditions where both the work queue and the IRQ can be active. This
patch fixes the handling to ensure the spin lock is held whenever the
state machine is being processed.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Hi Daniel,
Here is the incremental change to the mpc52xx_spi driver to fix up the
locking. It should be safe and unambiguous now.
Cheers,
g.
drivers/spi/mpc52xx_spi.c | 44 +++++++++++++++++++++++++-------------------
1 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/spi/mpc52xx_spi.c b/drivers/spi/mpc52xx_spi.c
index a4afc56..ab7be43 100644
--- a/drivers/spi/mpc52xx_spi.c
+++ b/drivers/spi/mpc52xx_spi.c
@@ -149,17 +149,10 @@ mpc52xx_spi_fsmstate_idle(int irq, struct mpc52xx_spi *ms, u8 status, u8 data)
dev_err(&ms->master->dev, "spurious irq, status=0x%.2x\n",
status);
- /* Check if there is another transfer waiting. It is safe to do
- * this here without holding the spinlock because this is the only
- * function where messages are dequeued and this function will
- * only get called by the IRQ or by the workqueue. The IRQ and
- * the workqueue will not be enabled at the same time. */
+ /* Check if there is another transfer waiting. */
if (list_empty(&ms->queue))
return FSM_STOP;
- /* Get the next message */
- spin_lock(&ms->lock);
-
/* Call the pre-message hook with a pointer to the next
* message. The pre-message hook may enqueue a new message for
* changing the chip select value to the head of the queue */
@@ -168,10 +161,9 @@ mpc52xx_spi_fsmstate_idle(int irq, struct mpc52xx_spi *ms, u8 status, u8 data)
ms->premessage(m, ms->premessage_context);
/* reget the head of the queue (the premessage hook may have enqueued
- * something before it.) and drop the spinlock */
+ * something before it.) */
ms->message = list_first_entry(&ms->queue, struct spi_message, queue);
list_del_init(&ms->message->queue);
- spin_unlock(&ms->lock);
/* Setup the controller parameters */
ctrl1 = SPI_CTRL1_SPIE | SPI_CTRL1_SPE | SPI_CTRL1_MSTR;
@@ -326,36 +318,50 @@ mpc52xx_spi_fsmstate_wait(int irq, struct mpc52xx_spi *ms, u8 status, u8 data)
return FSM_CONTINUE;
}
-/*
- * IRQ handler
+/**
+ * mpc52xx_spi_fsm_process - Finite State Machine iteration function
+ * @irq: irq number that triggered the FSM; NO_IRQ for workqueue polling
+ * @ms: pointer to mpc52xx_spi driver data
*/
-static irqreturn_t mpc52xx_spi_irq(int irq, void *_ms)
+static void mpc52xx_spi_fsm_process(int irq, struct mpc52xx_spi *ms)
{
- struct mpc52xx_spi *ms = _ms;
int rc = FSM_CONTINUE;
u8 status, data;
while (rc == FSM_CONTINUE) {
/* Interrupt cleared by read of STATUS followed by
- * read of DATA registers*/
+ * read of DATA registers */
status = readb(ms->regs + SPI_STATUS);
- data = readb(ms->regs + SPI_DATA); /* clear status */
+ data = readb(ms->regs + SPI_DATA);
rc = ms->state(irq, ms, status, data);
}
if (rc == FSM_POLL)
schedule_work(&ms->work);
+}
+/**
+ * mpc52xx_spi_irq - IRQ handler
+ */
+static irqreturn_t mpc52xx_spi_irq(int irq, void *_ms)
+{
+ struct mpc52xx_spi *ms = _ms;
+ spin_lock(&ms->lock);
+ mpc52xx_spi_fsm_process(irq, ms);
+ spin_unlock(&ms->lock);
return IRQ_HANDLED;
}
-/*
- * Workqueue method of running the state machine
+/**
+ * mpc52xx_spi_wq - Workqueue function for polling the state machine
*/
static void mpc52xx_spi_wq(struct work_struct *work)
{
struct mpc52xx_spi *ms = container_of(work, struct mpc52xx_spi, work);
- mpc52xx_spi_irq(NO_IRQ, ms);
+ unsigned long flags;
+ spin_lock_irqsave(&ms->lock, flags);
+ mpc52xx_spi_fsm_process(NO_IRQ, ms);
+ spin_unlock_irqrestore(&ms->lock, flags);
}
/*
^ permalink raw reply related
* Re: [PATCH v3 4/4] powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver
From: Grant Likely @ 2008-07-26 5:20 UTC (permalink / raw)
To: Daniel Walker
Cc: dbrownell, linux-kernel, linuxppc-dev, spi-devel-general, akpm
In-Reply-To: <1217047659.3970.14.camel@localhost.localdomain>
On Sat, Jul 26, 2008 at 12:47 AM, Daniel Walker <dwalker@mvista.com> wrote:
> On Fri, 2008-07-25 at 22:45 -0400, Grant Likely wrote:
>> On Fri, Jul 25, 2008 at 2:19 PM, Daniel Walker <dwalker@mvista.com> wrote:
>> > On Fri, 2008-07-25 at 03:33 -0400, Grant Likely wrote:
>> >
>> >> + if (status && (irq != NO_IRQ))
>> >> + dev_err(&ms->master->dev, "spurious irq, status=0x%.2x\n",
>> >> + status);
>> >> +
>> >> + /* Check if there is another transfer waiting */
>> >> + if (list_empty(&ms->queue))
>> >> + return FSM_STOP;
>> >
>> > I don't think doing list_empty outside the critical section is totally
>> > safe.. You might want to move it down inside the spin_lock() section.
>>
>> This should be fine. This is the only place where items are dequeued,
>> and it will only ever be called from the ISR or the work queue. The
>> work queue and IRQ will never be active at the same time (I'll add a
>> comment to the fact). It also looks like list_empty is perfectly safe
>> to call without the protection of a spin lock (but somebody correct me
>> if I'm out to lunch). It doesn't dereference any of the pointers in
>> the list_head structure.
>
> The list_empty wouldn't crash, but the result isn't necessarily
> accurate.
It doesn't need to be accurate because the spinlock is obtained before
actually trying to dequeue anything. Even if it held the spinlock
there would still be uncertainty depending on which routine ran first.
If this function ran first, then it's going to stop the state machine
regardless and the enqueue function will have to kick it off again
anyway.
But, I've taken a look at the code, and you're right, the spin lock
does need to be held while running the state machine because I do have
a case where the IRQ and workqueue could get executed at the same
time. I'll fix it up.
>
>> >
>> >> + /* Get the next message */
>> >> + spin_lock(&ms->lock);
>> >
>> > The part that's a little confusing here is that the interrupt can
>> > actually activate the workqueue .. So I'm wondering if maybe you could
>> > have this interrupt driven any workqueue driven at the same time? If you
>> > could then you would need the above to be
>> > spin_lock_irq/spin_lock_irqsave ..
>>
>> Ditto here, since the irq and workqueue are not enabled at the same
>> time there is no worry about collision.
>
> Why are you waking up the work queue from inside the irq handler? You
> might also want to break out the handling from inside the irq handler
> and call that from the workqueue, instead of re-calling the irq handler
> function from the workqueue.. It's a little confusing from a context
> perspective.
Sure, I can rework that. The irq handler would then just simply be a
straight call into the state machine runner. I just dropped the
additional 4 lines of code for conciseness, but I can change it around
for clarity... actually, with the spin lock stuff above I need to do
this rework.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC,PATCH] scripts/package: add powerpc images to tarball
From: Grant Likely @ 2008-07-26 4:55 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, Jeremy Kerr, linux-kernel
In-Reply-To: <200807250108.m6P18f4B099179@sullivan.realtime.net>
On Thu, Jul 24, 2008 at 9:08 PM, Milton Miller <miltonm@bga.com> wrote:
>
>> Currently, tarball builds for powerpc kernels don't have any boot
>> images (other than vmlinux) present.
>>
>> Add support for powerpc builds in the buildtar script, to include
>> a few default images.
>>
>> Signed-off-by: Jeremy Kerr <jk at ozlabs.org>
>>
>> ---
>> RFC: any requests for more/less boot images?
>>
> ..
>> + for img in zImage zImage.pseries zImage.iseries \
>> + dtbImage dtbImage.ps3
>
> Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
> that are newer than vmlinux?
dtbImage is not a buildable image. Neither is cuImage, treeImage or
simpleImage. All of those targets embed a device tree which is
specified by adding the .dts filename to the target name.
so, for example, 'make cuImage' fails. Instead you do 'make
cuImage.lite5200b' which pulls in dts/lite5200b.dts.
Also, zImage is a 'meta' target that builds all the default image
targets (the $image-y list). The zImage is actually just a symlink to
the first file in the list of default images. So zImage can actually
point to any kind of kernel image depending on how the kernel is
configured. I wonder if we should just remove the zImage file
entirely, or at least make it always linked to one particular image
type.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] reorganize cputypes for PPC64
From: Milton Miller @ 2008-07-26 4:50 UTC (permalink / raw)
To: Marvin; +Cc: ppcdev, Arnd Bergmann
In-Reply-To: <200807131420.29235.marvin24@gmx.de>
On Sun Jul 13 22:20:28 EST 2008, Marvin wrote:
> On Saturday 12 July 2008 20:00:05 Arnd Bergmann wrote:
>> On Saturday 12 July 2008, Marvin wrote:
>>> attached patch introduces a "processor type" menu similar to ppc32.
>>> It _should_ not change anything upto now.
>>>
>>> The aim is to allow future fine graded cpu optimizations via
>>> mcpu/mtune compiler flags and also to clean up the arch
>>> Makefile/Kconfig.cputypes (I know this is a minefield).
>>
>> I tried something similar last year, but failed miserably, because
>> the complexity cannot really be contained. I still think it's a good
>> idea, but I'm not sure whether your patch will help at all.
>
> Before I try to change something, I like to get some feedback about
> the direction to take. Therefore your comments are more than welcome.
>
>>> diff --git a/arch/powerpc/platforms/Kconfig.cputype
>>> b/arch/powerpc/platforms/Kconfig.cputype
>>> index f7efaa9..eebde6c 100644
>>> --- a/arch/powerpc/platforms/Kconfig.cputype
>>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>>> @@ -54,35 +54,65 @@ config E200
>>>
>>> endchoice
>>>
>>> -config POWER4_ONLY
>>> - bool "Optimize for POWER4"
>>> +choice
>>> + prompt "Processor Type"
>>> depends on PPC64
>>> + default TUNE_POWER4
>>> + help
>>> + There are serveral families of 64 bit PowerPC chips
>>> supported.
>>> + These include the Power3 to Power6 series, 970, and Cell
>>> BE based
>>> + CPUs made be IBM.
>>> +
>>> + If unsure, select Power4.
>>> +
>>> +config TUNE_POWER3
>>> + bool "Power3"
...
>>> +
>>> +config TUNE_CELL
>>> + bool "Cell Broadband Engine"
>>> + help
>>> + Cause the compiler to optimize for the PPE of the Cell
>>> Broadband
>>> + Engine. This will make the code run considerably faster on
>>> Cell
>>> + but somewhat slower on other machines. If the resulting
>>> kernel is
>>> + built to run only on Cell BE machines, select also
>>> OPT_EXCLUSIVE.
>>> +
>>> +endchoice
>>
>> What about the other CPUs? There is also RS64, Power5+, PA6T and
>> Power7.
>
> I grepped the source (especially the defconfigs) and it seems, that
> there is only one distinction between the different PPC64 archs named
> POWER3. POWER4 is always set on PPC64 archs, POWER3 is not set on G5,
> maple and pasemi.
>
> Grepping further reveals, that POWER3 is mentioned in mm/pgtable_32.c
> only, where is used to define HAVE_BATS (it exists also in
> asm/cputable.h, which is a candidate for cleanup -> replace !POWER4 &&
> !POWER3 by !PPC64).
>
> My daring conclusion is therefore:
> 1. POWER3 could be replaced by HAVE_BATS
> 2. POWER4 could be replaced by PPC64
No, this is the wrong approach. Don't figure out what to call things
by looking at where you see them used. See below for why.
> The only processor dependant config left is the tuning option. gcc has
> no special option for power7 or pa6t yet, but the reorg should be
> flexible, so new tuning options can be added easily. RS64 could be
> added to the tuneing options.
Let me give you a hint why you find the current usage.
POWER4 is is the first PowerPC-2.x architecture processor.
POWER3 and the RS64 series implement various versions of the PowerPC
1.x architecture. RS64 decided it didn't need bats.
While for the most part there have only been additions, the biggest
change as far as the operating system is the removal of the BAT and the
replacement of the STAB with the SLB.
That said, there are subtile compatibility problems. There are bits
that are defined in current instructions that should have been ignored
but are not. For example, mtocrf causes a fault on POWER3 but makes
POWER4 and later run mach faster. Also, the encoding of branch
prediction was changed.
POWER4_ONLY says go ahead and compile a kernel that will not run on a
POWER3. However, currently, it still runs on RS64, as we don't
conditionally compile SLB or STAB code.
The reason I said replacing POWER3 to HVAE_BATS is that that is the
wrong interface for the user. The user will know his cpu but will not
know technical things like POWER3 has bats and later ones do not.
That said, I think its perfectly reasonable to have POWER3 select
HAVE_BATS and make the code depend on that FEATURE type config.
>>> +
>>> +config OPT_EXCLUSIVE
>>> + bool "Optimize to run exclusive on selected CPU"
>>> default n
>>> - ---help---
>>> - Cause the compiler to optimize for POWER4/POWER5/PPC970
>>> processors.
>>> - The resulting binary will not work on POWER3 or RS64
>>> processors
>>> - when compiled with binutils 2.15 or later.
>>> + help
>>> + Cause the compiler to optimize to run exclusive on the
>>> selected
>>> + CPU. The resulting binary will probably not work on other
>>> CPUs.
>>> +
>>> + If the compiler/binutils combination does not support the
>>> exclusive
>>> + optimization, it will try to tune only or fail.
>>> +
>>> + If you are unsure, select no.
>>
>> Almost all CPUs are backwards compatible, so the option should not be
>> labelled 'exclusive'. In general, if you build for PowerX, it will
>> also run on Power(X+1). 970 is backwards compatible to Power4, Cell
>> and PA6T are backwards compatible to 970, Power6 is backwards
>> compatible to both of these.
>>
>> Also, there are good reasons to have the -mcpu option different from
>> -mtune. E.g. you may want to use Power4 compatible instructions but
>> tune for Power6 in a typical distro kernel.
>
> ok. That would mean to have two config menus:
> - optimize to run exclusive on cpu_x or higher
> - tune for cpu_y, and use instruction set for cpu_x, where x<=y
>
> That seems to be rather complex and I think this is also unrealistic,
> because there are often only two cases:
> - a distro doesn't want to maintain one kernel per cpu. So
> they always choose common instructions and tune for some higher cpu
> (likely power4).
> - a high end user (or specilized distro), who wants to compile
> his own kernel for maximum performance compiles exlusive only (e.g.
> for cell be).
>
> This is why I choosed "select cpu" menu and a bool for exclusive (use
> mcpu) or not (use mtune). Another option would be to add a string
> prompt, so the user can enter his own tuning options "-mcpu=cpu_x
> -mtune=cpu_y", but I think this is undesired.
>
>>> config POWER3
>>> - bool
>>> depends on PPC64
>>> - default y if !POWER4_ONLY
>>> + def_bool y if !POWER4_ONLY
>>>
>>> config POWER4
>>> depends on PPC64
>>> def_bool y
>>>
>>> -config TUNE_CELL
>>> - bool "Optimize for Cell Broadband Engine"
>>> +config POWER4_ONLY
>>> depends on PPC64
>>> - help
>>> - Cause the compiler to optimize for the PPE of the Cell
>>> Broadband
>>> - Engine. This will make the code run considerably faster on
>>> Cell
>>> - but somewhat slower on other machines. This option only
>>> changes
>>> - the scheduling of instructions, not the selection of
>>> instructions
>>> - itself, so the resulting kernel will keep running on all
>>> other
>>> - machines. When building a kernel that is supposed to run
>>> only
>>> - on Cell, you should also select the POWER4_ONLY option.
>>> + def_bool y if TUNE_POWER4 && OPT_EXCLUSIVE
>>>
>>> config 6xx
>>> bool
>>
>> Tuning for Cell gives a significant performance bonus on cell based
>> machines with a new compiler, and again, you would typically want to
>> use the Power4 instruction set, but not restrict to Power3 or use all
>> of the Cell instructions.
>
> That's again the "distro/high end user" question discussed above. I
> think this was raised several times in the past on this list without a
> common conclusion. A small survey shows, that distros are shipping
> kernels for ppc32 (sometimes prep and chrp) and ppc64 (common,
> iseries, pseries, and ps3) for installation only and provide a single
> image for updates. Maybe this would change if there is a choice....
[My appoligies for the late reply, it seems to have gotten left in my
drafts folder. Probably because apple mail did a harrible job wrappig
lines in all the wrong places. I have made all the discussion flow
into paragraphs with what I hope is the proper indenting/attribution.
Perhaps the patch has a singnificant amount of lines with trailing
whitespace?]
milton
^ permalink raw reply
* Re: [PATCH v3 4/4] powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver
From: Daniel Walker @ 2008-07-26 4:47 UTC (permalink / raw)
To: Grant Likely
Cc: dbrownell, linux-kernel, linuxppc-dev, spi-devel-general, akpm
In-Reply-To: <fa686aa40807251945t26a1656ep7a57ca71faa096c4@mail.gmail.com>
On Fri, 2008-07-25 at 22:45 -0400, Grant Likely wrote:
> On Fri, Jul 25, 2008 at 2:19 PM, Daniel Walker <dwalker@mvista.com> wrote:
> > On Fri, 2008-07-25 at 03:33 -0400, Grant Likely wrote:
> >
> >> + if (status && (irq != NO_IRQ))
> >> + dev_err(&ms->master->dev, "spurious irq, status=0x%.2x\n",
> >> + status);
> >> +
> >> + /* Check if there is another transfer waiting */
> >> + if (list_empty(&ms->queue))
> >> + return FSM_STOP;
> >
> > I don't think doing list_empty outside the critical section is totally
> > safe.. You might want to move it down inside the spin_lock() section.
>
> This should be fine. This is the only place where items are dequeued,
> and it will only ever be called from the ISR or the work queue. The
> work queue and IRQ will never be active at the same time (I'll add a
> comment to the fact). It also looks like list_empty is perfectly safe
> to call without the protection of a spin lock (but somebody correct me
> if I'm out to lunch). It doesn't dereference any of the pointers in
> the list_head structure.
The list_empty wouldn't crash, but the result isn't necessarily
accurate.
> >
> >> + /* Get the next message */
> >> + spin_lock(&ms->lock);
> >
> > The part that's a little confusing here is that the interrupt can
> > actually activate the workqueue .. So I'm wondering if maybe you could
> > have this interrupt driven any workqueue driven at the same time? If you
> > could then you would need the above to be
> > spin_lock_irq/spin_lock_irqsave ..
>
> Ditto here, since the irq and workqueue are not enabled at the same
> time there is no worry about collision.
Why are you waking up the work queue from inside the irq handler? You
might also want to break out the handling from inside the irq handler
and call that from the workqueue, instead of re-calling the irq handler
function from the workqueue.. It's a little confusing from a context
perspective.
Daniel
^ permalink raw reply
* Re: [git pull] Please pull from powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2008-07-26 4:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, akpm, Linux Kernel list
In-Reply-To: <alpine.LFD.1.10.0807251734030.4188@nehalem.linux-foundation.org>
On Fri, 2008-07-25 at 17:38 -0700, Linus Torvalds wrote:
>
> On Sat, 26 Jul 2008, Benjamin Herrenschmidt wrote:
> >
> > Please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>
> What odd character do you have there before the 'git://' and why?
Hrm... no idea... must be some weirdo evolution thing...
> It cuts-and-pastes into some whitespace that isn't space, and that the
> shell thus makes part of that word when parsing. It seems to be U+FEFF,
> which is "zero-width non-break space", but what the heck is the point of
> that kind of garbage in email?
No idea how it got there.
> Is this some new way for Evolution to screw up?
Quite possibly. I'll do some tests to see if I can reproduce locally...
it could be the result of a key combo that leaves that in the mail but
isn't visible... weird.
Sorry about that,
Cheers,
Ben.
^ permalink raw reply
* [PATCH] Memset the kernel copy of rtas args before using
From: Milton Miller @ 2008-07-26 4:17 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: ppcdev, Paul Mackerras
In-Reply-To: <488A44DB.7090400@austin.ibm.com>
On Sat Jul 26 at 07:25:47 EST in 2008, Nathan Fontenot wrote:
> The kernel copy of the rtas args struct that is read in from
> user space is a stack variable. This structure should be
> zero'ed out before we do any reads/writes to/from the user
> when handling a rtas call request. This patch adds a memset
> to do this.
Why bother to zero the data before copying from the user? We
check that they supply data for the whole input range needed.
> I am seeing an issue in testing partition mobility, where the
> parts of the rtas args struct that return status top the user
> contain stale data.
Please change the patch to just clear the output arg range.
(I"m fine not trusting firmware to set all output args based
on what the user suggested the return arg count would be).
And we can do it after we decide not to return an error:
792 if (args.token == RTAS_UNKNOWN_SERVICE)
793 return -EINVAL;
794
795 /* Need to handle ibm,suspend_me call specially */
milton
^ permalink raw reply
* Please pull mpc52xx-next
From: Grant Likely @ 2008-07-26 4:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, Paul Mackerras
Hey Ben, here are a few more patches for .27. I would have had this
stuff in earlier, but they depended on another patch that I didn't
feel like I should push that was in Andrew's queue.
Thanks,
g.
The following changes since commit 1ff8419871ea757ae0298aa296bcff9b2ca48561:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git next
Grant Likely (4):
of: adapt of_find_i2c_driver() to be usable by SPI also
spi: split up spi_new_device() to allow two stage registration.
spi: Add OF binding support for SPI busses
powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver
drivers/of/Kconfig | 6 +
drivers/of/Makefile | 1 +
drivers/of/base.c | 88 ++++++
drivers/of/of_i2c.c | 64 +----
drivers/of/of_spi.c | 93 ++++++
drivers/spi/Kconfig | 8 +
drivers/spi/Makefile | 1 +
drivers/spi/mpc52xx_spi.c | 602 +++++++++++++++++++++++++++++++++++++++
drivers/spi/spi.c | 139 ++++++---
include/linux/of.h | 1 +
include/linux/of_spi.h | 18 ++
include/linux/spi/mpc52xx_spi.h | 10 +
include/linux/spi/spi.h | 12 +
13 files changed, 938 insertions(+), 105 deletions(-)
create mode 100644 drivers/of/of_spi.c
create mode 100644 drivers/spi/mpc52xx_spi.c
create mode 100644 include/linux/of_spi.h
create mode 100644 include/linux/spi/mpc52xx_spi.h
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC,PATCH] scripts/package: add powerpc images to tarball
From: Milton Miller @ 2008-07-26 3:59 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200807251111.26673.jk@ozlabs.org>
On Jul 24, 2008, at 8:11 PM, Jeremy Kerr wrote:
> Milton,
>
>> Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
>> that are newer than vmlinux?
>
> The existing arch code doesn't do any checks for timestamps, perhaps
> this would be better implemented as an arch-independent change?
The problem is some people might want to add intermediate files that are
younger than vmlinux (eg .config). We know our boot-image should be
newer. But I don't know how one would express the expected ages.
The reason I suggested the check was to eliminate images that are not
in the current config. I figured a test for relative file age could
be done in the for loop -- possibly replace shell wildcard with
find arch/$(ARCH)/boot/{zImage*,dtbImage*,uImage*,cuImage*,treeboot*}
-newer vmlinux -print.
> (but would you like me to add treeboot and cuboot?)
I don't see why we should prefer the workstations and servers over the
embedded boards. zImage is just a link to the first boot image, but
one can build a multiple formats and the order is somewhat arbitrary.
So I see it as fairness. Otherwise, there are a few other platforms
that are "user" based vs embedded (like efkia, no?).
milton
^ permalink raw reply
* Re: 82xx performance
From: Milton Miller @ 2008-07-26 3:47 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04BC5B2A@ismail.innsys.innovsys.com>
On Jul 25, 2008, at 3:41 PM, Rune Torgersen wrote:
>> From: Arnd Bergmann [mailto:arnd@arndb.de]
>> On Thursday 17 July 2008, Rune Torgersen wrote:
>>> Arnd Bergmann wrote:
>>>> So again, nothing conclusive. I'm running out of ideas.
>>>
>>> Is the syscall path different or the same on ppc and powerpc?
>>> Any differences in the task switching, irq handling or page fault
>>> handling?
>>>
>>
>> It's all different in suble ways, but those changes should only
>> show up in the system time accounting, not user time accounting.
>
> I've been running the workload this board will see. On a 2.6.18 kernel
> %idle is ~50% and %wa (waiting for IO) is less than 1% most of the
> time.
> On 2.6.25, the idle% is lower (by about 10-15%) and the %wa is
> consistently hovering around 20-30% sometimes spiking to 100%.
>
> The workload involves quite a bit of socket IO (TCP, UDP, Unix Sockets
> and TIPC) and disk IO.
> Any easy way of finding what is causing the wait for IO?
>
> (Ive been trying to get lttng to work, but not any good results so
> far).
In both idle and wait, the cpu is in the idle loop waiting for something
to do. The difference is that a cpu is considered in disk wait if the
there is a task in uninterruptible sleep that is not being counted as
waiting on another cpu.
With a significant change in wait time, I would suggest restating the
current observations to the linux-mm community, probably with a cc
to linux-kernel.
Be sure to state what you have done to equalize the comparison (eg
highmen, ram size left, etc).
There may be some tunables that could adjust the behavior.
milton
^ permalink raw reply
* Re: [PATCH v3 4/4] powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver
From: Grant Likely @ 2008-07-26 2:45 UTC (permalink / raw)
To: Daniel Walker
Cc: dbrownell, linux-kernel, linuxppc-dev, spi-devel-general, akpm
In-Reply-To: <1217009954.13539.23.camel@localhost.localdomain>
On Fri, Jul 25, 2008 at 2:19 PM, Daniel Walker <dwalker@mvista.com> wrote:
> On Fri, 2008-07-25 at 03:33 -0400, Grant Likely wrote:
>
>> + if (status && (irq != NO_IRQ))
>> + dev_err(&ms->master->dev, "spurious irq, status=0x%.2x\n",
>> + status);
>> +
>> + /* Check if there is another transfer waiting */
>> + if (list_empty(&ms->queue))
>> + return FSM_STOP;
>
> I don't think doing list_empty outside the critical section is totally
> safe.. You might want to move it down inside the spin_lock() section.
This should be fine. This is the only place where items are dequeued,
and it will only ever be called from the ISR or the work queue. The
work queue and IRQ will never be active at the same time (I'll add a
comment to the fact). It also looks like list_empty is perfectly safe
to call without the protection of a spin lock (but somebody correct me
if I'm out to lunch). It doesn't dereference any of the pointers in
the list_head structure.
>
>> + /* Get the next message */
>> + spin_lock(&ms->lock);
>
> The part that's a little confusing here is that the interrupt can
> actually activate the workqueue .. So I'm wondering if maybe you could
> have this interrupt driven any workqueue driven at the same time? If you
> could then you would need the above to be
> spin_lock_irq/spin_lock_irqsave ..
Ditto here, since the irq and workqueue are not enabled at the same
time there is no worry about collision.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Warp DTS changes
From: Sean MacLennan @ 2008-07-26 1:50 UTC (permalink / raw)
To: linuxppc-dev
Added support for the new at24 eeprom driver.
Documented a new fpga section, the DMA scatter gather list.
Removed index from i2c. No longer needed.
Fixed the leds section.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index 340018c..7300736 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -139,6 +139,11 @@
interrupt-parent = <&UIC0>;
};
+ fpga@2,2000 {
+ compatible = "pika,fpga-sgl";
+ reg = <0x00000002 0x00002000 0x00000200>;
+ };
+
fpga@2,4000 {
compatible = "pika,fpga-sd";
reg = <0x00000002 0x00004000 0x00000A00>;
@@ -181,7 +186,6 @@
reg = <0xef600700 0x00000014>;
interrupt-parent = <&UIC0>;
interrupts = <0x2 0x4>;
- index = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
@@ -191,6 +195,12 @@
interrupts = <0x19 0x8>;
interrupt-parent = <&UIC0>;
};
+
+ /* This will create 52 and 53 */
+ at24@52 {
+ compatible = "at,24c04";
+ reg = <0x52>;
+ };
};
GPIO0: gpio@ef600b00 {
@@ -209,7 +219,13 @@
led@31 {
compatible = "linux,gpio-led";
linux,name = ":green:";
- gpios = <&GPIO1 0x30 0>;
+ gpios = <&GPIO1 31 0>;
+ };
+
+ led@30 {
+ compatible = "linux,gpio-led";
+ linux,name = ":red:";
+ gpios = <&GPIO1 30 0>;
};
};
^ permalink raw reply related
* Cleanup for i2c driver changes.
From: Sean MacLennan @ 2008-07-26 1:45 UTC (permalink / raw)
To: linuxppc-dev
This patch removes the i2c code which is now obsolete due to the new
ibm iic driver walking the device tree for child nodes.
There are two other small cleanups that came indirectly from the ad7414
code review. Make sure Tlow is correct and handle the case where
i2c_smbus_read_word_data fails.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 9565995..960edf8 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -30,18 +30,6 @@ static __initdata struct of_device_id warp_of_bus[] = {
{},
};
-static __initdata struct i2c_board_info warp_i2c_info[] = {
- { I2C_BOARD_INFO("ad7414", 0x4a) }
-};
-
-static int __init warp_arch_init(void)
-{
- /* This should go away once support is moved to the dts. */
- i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
- return 0;
-}
-machine_arch_initcall(warp, warp_arch_init);
-
static int __init warp_device_probe(void)
{
of_platform_bus_probe(NULL, warp_of_bus, NULL);
@@ -223,7 +211,7 @@ static void pika_setup_critical_temp(struct i2c_client *client)
/* These registers are in 1 degree increments. */
i2c_smbus_write_byte_data(client, 2, 65); /* Thigh */
- i2c_smbus_write_byte_data(client, 3, 55); /* Tlow */
+ i2c_smbus_write_byte_data(client, 3, 0); /* Tlow */
np = of_find_compatible_node(NULL, NULL, "adi,ad7414");
if (np == NULL) {
@@ -289,8 +277,15 @@ found_it:
printk(KERN_INFO "PIKA DTM thread running.\n");
while (!kthread_should_stop()) {
- u16 temp = swab16(i2c_smbus_read_word_data(client, 0));
- out_be32(fpga + 0x20, temp);
+ int val;
+
+ val = i2c_smbus_read_word_data(client, 0);
+ if (val < 0)
+ dev_dbg(&client->dev, "DTM read temp failed.\n");
+ else {
+ s16 temp = swab16(val);
+ out_be32(fpga + 0x20, temp);
+ }
pika_dtm_check_fan(fpga);
^ 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