* Re: "leds: Add openfirmware platform device support" breaks sparc
From: David Miller @ 2009-03-04 0:37 UTC (permalink / raw)
To: smaclennan; +Cc: sparclinux, linuxppc-dev, akpm, tpiepho, rpurdie
In-Reply-To: <20090303192932.31705cf7@lappy.seanm.ca>
From: Sean MacLennan <smaclennan@pikatech.com>
Date: Tue, 3 Mar 2009 19:29:32 -0500
> It has been..... uhhhh carry the two... longer than I want to admit
> since I worked on a sparc. Would GPIO based LEDS make sense on a sparc
> platform? Is sparc used much in the embedded world?
>
> If yes, the of_register_platform_driver is just a nice wrapper. It
> would be trivial to either change it to work on sparc, or add the
> wrapper to the sparc includes.
We generally create the platform devices by hand for LED
devices on sparc64.
I'd CONFIG_POWERPC depend this thing for now.
^ permalink raw reply
* Re: "leds: Add openfirmware platform device support" breaks sparc
From: Julian Calaby @ 2009-03-04 0:40 UTC (permalink / raw)
To: Sean MacLennan
Cc: linuxppc-dev, Richard Purdie, sparclinux, Andrew Morton,
Trent Piepho
In-Reply-To: <20090303192932.31705cf7@lappy.seanm.ca>
On Wed, Mar 4, 2009 at 11:29, Sean MacLennan <smaclennan@pikatech.com> wrote:
> On Tue, 3 Mar 2009 16:09:06 -0800
> "Andrew Morton" <akpm@linux-foundation.org> wrote:
>
>> afacit that interface is powerpc-only.
>
> Yes it is. You might want a CONFIG_PPC with that.
>
> It has been..... uhhhh carry the two... longer than I want to admit
> since I worked on a sparc. Would GPIO based LEDS make sense on a sparc
> platform? Is sparc used much in the embedded world?
>
> If yes, the of_register_platform_driver is just a nice wrapper. It
> would be trivial to either change it to work on sparc, or add the
> wrapper to the sparc includes.
These inconsistencies are causing more problems with PPC drivers
depending on the generic infrastructure.
See: http://lkml.org/lkml/2009/1/11/376 for a similar issue.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: Linux 2.6.29-rc6 bombs while compiling a kernel for a linkstation/kurobox
From: Rogério Brito @ 2009-03-04 1:04 UTC (permalink / raw)
To: Guennadi Liakhovetski, Tony Breeds, Rafael J. Wysocki,
Kernel Testers List, Kumar Gala, paulus
Cc: linuxppc-dev, linux-kernel, Anton Blanchard
In-Reply-To: <Pine.LNX.4.64.0903040103440.5059@axis700.grange>
On Mar 04 2009, Guennadi Liakhovetski wrote:
> Yes, linkstation and storcenter have to migrate to the "physmap-flash"
> platform driver. For now you can define in your .config
>
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP_COMPAT=y
> CONFIG_MTD_PHYSMAP_START=0xffc00000
> CONFIG_MTD_PHYSMAP_LEN=0x400000
> CONFIG_MTD_PHYSMAP_BANKWIDTH=1
I did that already yesterday. Please, see my patch at
http://marc.info/?l=linux-kernel&m=123606933628020&w=4
And the entry at bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=12811
> (I hope the numbers are correct, just found them in my local tree, don't
> remember any more what exactly they configure, please, double-check.)
Yes, I had them in my tree also. And it is tested already, up and
running and in production for 17 hours.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
rbrito@lutz:~$ uptime
22:03:16 up 17:06, 1 user, load average: 0.16, 0.03, 0.01
rbrito@lutz:~$
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> And yes, it must be fixed in the mainline. I'll see if I find time for
> this, maybe tomorrow (actually, already today.)
Please, Cc me any relevant patches, as I'm not subscribed to all those
lists.
Regards, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
^ permalink raw reply
* [PATCH] ppc: detect sbc610 boards and only fixup nec usb on them
From: Kyle McMartin @ 2009-03-04 1:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
From: Kyle McMartin <kyle@redhat.com>
Bug #486511 in Fedora, this is getting applied to any machine with a NEC
USB pci device if this CONFIG_GEF_SBC610 is on (as it was in Fedora.)
Obviously this isn't appropriate to do in any more than the SBC610
case..., so flag that we're a sbc610 board, and skip the fixup if we're
not.
(Fedora: Should fix USB on Mac G4/G5...)
Signed-off-by: Kyle McMartin <kyle@redhat.com>
---
diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c b/arch/powerpc/platforms/86xx/gef_sbc610.c
index fb371f5..54afda2 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc610.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
@@ -51,6 +51,8 @@
void __iomem *sbc610_regs;
+static int is_sbc610;
+
static void __init gef_sbc610_init_irq(void)
{
struct device_node *cascade_node = NULL;
@@ -142,6 +144,9 @@ static void __init gef_sbc610_nec_fixup(struct pci_dev *pdev)
{
unsigned int val;
+ if (!is_sbc610)
+ return;
+
printk(KERN_INFO "Running NEC uPD720101 Fixup\n");
/* Ensure ports 1, 2, 3, 4 & 5 are enabled */
@@ -166,8 +171,10 @@ static int __init gef_sbc610_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "gef,sbc610"))
+ if (of_flat_dt_is_compatible(root, "gef,sbc610")) {
+ is_sbc610 = 1;
return 1;
+ }
return 0;
}
^ permalink raw reply related
* Re: [PATCH RFC] powerpc/83xx: Move gianfar mdio nodes under the ethernet nodes
From: Li Yang @ 2009-03-04 3:10 UTC (permalink / raw)
To: avorontsov; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20090303193833.GA8941@oksana.dev.rtsoft.ru>
On Wed, Mar 4, 2009 at 3:38 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> Currently it doesn't matter where the mdio nodes are placed, but with
> power management support (i.e. when sleep =3D <> properties will take
> effect), mdio nodes placement will become important: mdio controller
> is a part of the ethernet block, so the mdio nodes should be placed
> correctly. Otherwise we may wrongly assume that MDIO controllers are
> available during sleep.
>
> Suggested-by: Scott Wood <scottwood@freescale.com>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> On Tue, Mar 03, 2009 at 12:39:38PM -0600, Scott Wood wrote:
>> Anton Vorontsov wrote:
>>> On Tue, Mar 03, 2009 at 11:57:46AM -0600, Scott Wood wrote:
>>>> On Tue, Mar 03, 2009 at 07:02:01PM +0300, Anton Vorontsov wrote:
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mdio@24520 {
>>>>> @@ -226,6 +244,8 @@
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
interrupt-parent =3D <&ipic>;
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
tbi-handle =3D <&tbi0>;
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
phy-handle =3D <&phy2>;
>>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sleep=
=3D <&pmc 0xc0000000>;
>>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fsl,m=
agic-packet;
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};
>>>> Note that this makes it look to the kernel like enet0 can be put to sl=
eep
>>>> without putting the mdio (which is shared with enet1) to sleep. =C2=A0=
This is
>>>> why I moved mdio under the ethernet node on 8313erdb.
>>>
>>> And that isn't absolutely correct either, since enet1 depends on
>>> net0... If enet0's mdio goes into sleep mode before enet1, then
>>> enet1 will fail to send power-down command to its PHY...
>>
>> But the kernel knows that enet1 depends on mdio0. =C2=A0Getting the kern=
el to
>> act on that knowledge isn't the device tree's problem.
>
> Well, that makes sense. I'd like to move mdio nodes in a separate
> patch though, since the original patch becomes difficult to review
> because of too many changes...
>
> A question though... do we want real addr translation via ranges, or
> the dummy "ranges;" are OK?
>
> Here is the RFC. It's tested to work on MPC8377-RDB.
Last time I brought up a similar issue with a MPC8313 patch. Looks
like the consensus is that we shouldn't use compatible =3D "simple-bus"
for gianfar nodes.
- Leo
^ permalink raw reply
* Re: [PATCH] ppc: detect sbc610 boards and only fixup nec usb on them
From: Tony Breeds @ 2009-03-04 3:59 UTC (permalink / raw)
To: Kyle McMartin, Kumar Gala, Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20090304012229.GN28503@bombadil.infradead.org>
On Tue, Mar 03, 2009 at 08:22:29PM -0500, Kyle McMartin wrote:
> From: Kyle McMartin <kyle@redhat.com>
>
> Bug #486511 in Fedora, this is getting applied to any machine with a NEC
> USB pci device if this CONFIG_GEF_SBC610 is on (as it was in Fedora.)
> Obviously this isn't appropriate to do in any more than the SBC610
> case..., so flag that we're a sbc610 board, and skip the fixup if we're
> not.
>
> (Fedora: Should fix USB on Mac G4/G5...)
>
> Signed-off-by: Kyle McMartin <kyle@redhat.com>
>
> ---
> diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c b/arch/powerpc/platforms/86xx/gef_sbc610.c
> index fb371f5..54afda2 100644
> --- a/arch/powerpc/platforms/86xx/gef_sbc610.c
> +++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
> @@ -51,6 +51,8 @@
>
> void __iomem *sbc610_regs;
>
> +static int is_sbc610;
I came up with this as well, but used the machine_is() infrasturcture.
Subject: [PATCH] Run fixup code only on the appropriate platform.
commit a969e76a7101bf5f3d369563df1ca1253dd6131b (powerpc: Correct USB
support for GE Fanuc SBC610) introduced a fixup for NEC usb controllers.
This fixup should only run on GEF SBC610 boards.
Fixes Fedora bug #486511.
(https://bugzilla.redhat.com/show_bug.cgi?id=486511)
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/86xx/gef_sbc610.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c b/arch/powerpc/platforms/86xx/gef_sbc610.c
index fb371f5..d6b772b 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc610.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
@@ -142,6 +142,10 @@ static void __init gef_sbc610_nec_fixup(struct pci_dev *pdev)
{
unsigned int val;
+ /* Do not do the fixup on other platforms! */
+ if (!machine_is(gef_sbc610))
+ return;
+
printk(KERN_INFO "Running NEC uPD720101 Fixup\n");
/* Ensure ports 1, 2, 3, 4 & 5 are enabled */
--
1.6.0.6
Yours Tony
^ permalink raw reply related
* Re: [patch 1/2] powerpc: optimise smp_mb
From: Benjamin Herrenschmidt @ 2009-03-04 4:03 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, paulus
In-Reply-To: <20090219171229.GJ1747@wotan.suse.de>
Allright, sorry for the delay, I had those stored into my "need more
than half a brain cell for review" list and only got to them today :-)
On Thu, 2009-02-19 at 18:12 +0100, Nick Piggin wrote:
> Using lwsync, isync sequence in a microbenchmark is 5 times faster on my G5 than
> using sync for smp_mb. Although it takes more instructions.
>
> Running tbench with 4 clients on my 4 core G5 (20 times) gives the
> following:
>
> unpatched AVG=920.33 STD=2.36
> patched AVG=921.27 STD=2.77
>
> So not a big improvement here, actually it could even be in the noise.
> But other workloads or systems might see a bigger win, and the patch
> maybe is interesting or could be improved, so I'll ask for comments.
So not a huge objection here, however I have some doubts as to whether
this will be worthwhile on power5,6,7 since those optimized somewhat the
behaviour of the full sync. Since anything older than power4 doesn't
have lwsync, that potentially makes it not worth the pain.
But I need to measure to be sure... it might be that newer embedded
processors that support lwsync and SMP (and that are using a different
pipeline structure) might benefit from this. I'll try to run some tests
later this week or next week, but ping me in case I forget.
Now what would be worth doing is to also try using a twi;isync sequence
like we do to order MMIO reads, see if it's any better than cmp/branch
Cheers,
Ben.
> ---
> Index: linux-2.6/arch/powerpc/include/asm/system.h
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/include/asm/system.h 2009-02-20 01:51:24.000000000 +1100
> +++ linux-2.6/arch/powerpc/include/asm/system.h 2009-02-20 02:09:41.000000000 +1100
> @@ -52,7 +52,16 @@
> # define SMPWMB eieio
> #endif
>
> +#ifdef __powerpc64__
> +#define smp_mb() __asm__ __volatile__ ( \
> + "1: lwsync \n" \
> + " cmpw 0,%%r0,%%r0 \n" \
> + " bne- 1b \n" \
> + " isync \n" \
> + : : : "memory")
> +#else
> #define smp_mb() mb()
> +#endif
> #define smp_rmb() __asm__ __volatile__ (stringify_in_c(LWSYNC) : : :"memory")
> #define smp_wmb() __asm__ __volatile__ (stringify_in_c(SMPWMB) : : :"memory")
> #define smp_read_barrier_depends() read_barrier_depends()
^ permalink raw reply
* Re: [patch 2/2] powerpc: replace isync with lwsync
From: Benjamin Herrenschmidt @ 2009-03-04 4:04 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, paulus
In-Reply-To: <20090219172133.GK1747@wotan.suse.de>
On Thu, 2009-02-19 at 18:21 +0100, Nick Piggin wrote:
> OK, here is this patch again. You didn't think I'd let a 2% performance
> improvement be forgotten? :)
>
> Anyway, patch won't work well on architecture without lwsync, but I won't
> bother fixing that kind of thing and making it merge worthy until you
> guys say something positive about it.
>
> 20 runs of tbench on the G5
>
> unpatched AVG=920.37 STD=2.36
> patched AVG=938.89 STD=3.33
>
> (throughput in MB/s) This is a 1.9% throughput increase.
Definitely worth it believe. We could use a macro that uses michael new
improvements on the CPU features code pathing so that the isync gets
changed to lwsync on some CPUs based on the availability of it.
Cheers,
Ben.
> ---
>
> Index: linux-2.6/arch/powerpc/include/asm/atomic.h
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/include/asm/atomic.h 2009-02-20 01:50:20.000000000 +1100
> +++ linux-2.6/arch/powerpc/include/asm/atomic.h 2009-02-20 02:13:22.000000000 +1100
> @@ -55,7 +55,7 @@
> PPC405_ERR77(0,%2)
> " stwcx. %0,0,%2 \n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (t)
> : "r" (a), "r" (&v->counter)
> : "cc", "memory");
> @@ -91,7 +91,7 @@
> PPC405_ERR77(0,%2)
> " stwcx. %0,0,%2 \n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (t)
> : "r" (a), "r" (&v->counter)
> : "cc", "memory");
> @@ -125,7 +125,7 @@
> PPC405_ERR77(0,%1)
> " stwcx. %0,0,%1 \n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (t)
> : "r" (&v->counter)
> : "cc", "xer", "memory");
> @@ -169,7 +169,7 @@
> PPC405_ERR77(0,%1)
> " stwcx. %0,0,%1\n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (t)
> : "r" (&v->counter)
> : "cc", "xer", "memory");
> @@ -202,7 +202,7 @@
> PPC405_ERR77(0,%2)
> " stwcx. %0,0,%1 \n\
> bne- 1b \n"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> " subf %0,%2,%0 \n\
> 2:"
> : "=&r" (t)
> @@ -235,7 +235,7 @@
> PPC405_ERR77(0,%1)
> " stwcx. %0,0,%1\n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> "\n\
> 2:" : "=&b" (t)
> : "r" (&v->counter)
> @@ -291,7 +291,7 @@
> add %0,%1,%0\n\
> stdcx. %0,0,%2 \n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (t)
> : "r" (a), "r" (&v->counter)
> : "cc", "memory");
> @@ -325,7 +325,7 @@
> subf %0,%1,%0\n\
> stdcx. %0,0,%2 \n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (t)
> : "r" (a), "r" (&v->counter)
> : "cc", "memory");
> @@ -357,7 +357,7 @@
> addic %0,%0,1\n\
> stdcx. %0,0,%1 \n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (t)
> : "r" (&v->counter)
> : "cc", "xer", "memory");
> @@ -399,7 +399,7 @@
> addic %0,%0,-1\n\
> stdcx. %0,0,%1\n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (t)
> : "r" (&v->counter)
> : "cc", "xer", "memory");
> @@ -425,7 +425,7 @@
> blt- 2f\n\
> stdcx. %0,0,%1\n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> "\n\
> 2:" : "=&r" (t)
> : "r" (&v->counter)
> @@ -458,7 +458,7 @@
> add %0,%2,%0 \n"
> " stdcx. %0,0,%1 \n\
> bne- 1b \n"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> " subf %0,%2,%0 \n\
> 2:"
> : "=&r" (t)
> Index: linux-2.6/arch/powerpc/include/asm/bitops.h
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/include/asm/bitops.h 2009-02-20 01:50:20.000000000 +1100
> +++ linux-2.6/arch/powerpc/include/asm/bitops.h 2009-02-20 02:13:22.000000000 +1100
> @@ -139,7 +139,7 @@
> PPC405_ERR77(0,%3)
> PPC_STLCX "%1,0,%3 \n"
> "bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (old), "=&r" (t)
> : "r" (mask), "r" (p)
> : "cc", "memory");
> @@ -160,7 +160,7 @@
> PPC405_ERR77(0,%3)
> PPC_STLCX "%1,0,%3 \n"
> "bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (old), "=&r" (t)
> : "r" (mask), "r" (p)
> : "cc", "memory");
> @@ -182,7 +182,7 @@
> PPC405_ERR77(0,%3)
> PPC_STLCX "%1,0,%3 \n"
> "bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (old), "=&r" (t)
> : "r" (mask), "r" (p)
> : "cc", "memory");
> @@ -204,7 +204,7 @@
> PPC405_ERR77(0,%3)
> PPC_STLCX "%1,0,%3 \n"
> "bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (old), "=&r" (t)
> : "r" (mask), "r" (p)
> : "cc", "memory");
> Index: linux-2.6/arch/powerpc/include/asm/futex.h
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/include/asm/futex.h 2009-02-20 01:50:20.000000000 +1100
> +++ linux-2.6/arch/powerpc/include/asm/futex.h 2009-02-20 02:13:22.000000000 +1100
> @@ -97,7 +97,7 @@
> PPC405_ERR77(0,%2)
> "2: stwcx. %4,0,%2\n\
> bne- 1b\n"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> "3: .section .fixup,\"ax\"\n\
> 4: li %0,%5\n\
> b 3b\n\
> Index: linux-2.6/arch/powerpc/include/asm/spinlock.h
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/include/asm/spinlock.h 2009-02-20 01:50:20.000000000 +1100
> +++ linux-2.6/arch/powerpc/include/asm/spinlock.h 2009-02-20 02:13:22.000000000 +1100
> @@ -65,7 +65,7 @@
> bne- 2f\n\
> stwcx. %1,0,%2\n\
> bne- 1b\n\
> - isync\n\
> + lwsync\n\
> 2:" : "=&r" (tmp)
> : "r" (token), "r" (&lock->slock)
> : "cr0", "memory");
> @@ -193,7 +193,7 @@
> PPC405_ERR77(0,%1)
> " stwcx. %0,0,%1\n\
> bne- 1b\n\
> - isync\n\
> + lwsync\n\
> 2:" : "=&r" (tmp)
> : "r" (&rw->lock)
> : "cr0", "xer", "memory");
> @@ -217,7 +217,7 @@
> PPC405_ERR77(0,%1)
> " stwcx. %1,0,%2\n\
> bne- 1b\n\
> - isync\n\
> + lwsync\n\
> 2:" : "=&r" (tmp)
> : "r" (token), "r" (&rw->lock)
> : "cr0", "memory");
> Index: linux-2.6/arch/powerpc/include/asm/system.h
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/include/asm/system.h 2009-02-20 02:09:41.000000000 +1100
> +++ linux-2.6/arch/powerpc/include/asm/system.h 2009-02-20 02:13:22.000000000 +1100
> @@ -246,7 +246,7 @@
> PPC405_ERR77(0,%2)
> " stwcx. %3,0,%2 \n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (prev), "+m" (*(volatile unsigned int *)p)
> : "r" (p), "r" (val)
> : "cc", "memory");
> @@ -289,7 +289,7 @@
> PPC405_ERR77(0,%2)
> " stdcx. %3,0,%2 \n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (prev), "+m" (*(volatile unsigned long *)p)
> : "r" (p), "r" (val)
> : "cc", "memory");
> @@ -382,7 +382,7 @@
> PPC405_ERR77(0,%2)
> " stwcx. %4,0,%2\n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> "\n\
> 2:"
> : "=&r" (prev), "+m" (*p)
> @@ -427,7 +427,7 @@
> bne- 2f\n\
> stdcx. %4,0,%2\n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> "\n\
> 2:"
> : "=&r" (prev), "+m" (*p)
> Index: linux-2.6/arch/powerpc/include/asm/synch.h
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/include/asm/synch.h 2009-02-20 01:50:20.000000000 +1100
> +++ linux-2.6/arch/powerpc/include/asm/synch.h 2009-02-20 02:13:22.000000000 +1100
> @@ -38,7 +38,7 @@
>
> #ifdef CONFIG_SMP
> #define ISYNC_ON_SMP "\n\tisync\n"
> -#define LWSYNC_ON_SMP stringify_in_c(LWSYNC) "\n"
> +#define LWSYNC_ON_SMP "\n\t" stringify_in_c(LWSYNC) "\n"
> #else
> #define ISYNC_ON_SMP
> #define LWSYNC_ON_SMP
> Index: linux-2.6/arch/powerpc/include/asm/mutex.h
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/include/asm/mutex.h 2009-02-20 01:50:20.000000000 +1100
> +++ linux-2.6/arch/powerpc/include/asm/mutex.h 2009-02-20 02:13:22.000000000 +1100
> @@ -15,7 +15,7 @@
> PPC405_ERR77(0,%1)
> " stwcx. %3,0,%1\n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> "\n\
> 2:"
> : "=&r" (t)
> @@ -35,7 +35,7 @@
> PPC405_ERR77(0,%1)
> " stwcx. %0,0,%1\n\
> bne- 1b"
> - ISYNC_ON_SMP
> + LWSYNC_ON_SMP
> : "=&r" (t)
> : "r" (&v->counter)
> : "cc", "memory");
> Index: linux-2.6/arch/powerpc/mm/hash_low_64.S
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/mm/hash_low_64.S 2009-02-20 01:50:20.000000000 +1100
> +++ linux-2.6/arch/powerpc/mm/hash_low_64.S 2009-02-20 02:13:22.000000000 +1100
> @@ -110,7 +110,7 @@
> /* Write the linux PTE atomically (setting busy) */
> stdcx. r30,0,r6
> bne- 1b
> - isync
> + lwsync
>
> /* Step 2:
> *
> @@ -393,7 +393,7 @@
> /* Write the linux PTE atomically (setting busy) */
> stdcx. r30,0,r6
> bne- 1b
> - isync
> + lwsync
>
> /* Step 2:
> *
> @@ -734,7 +734,7 @@
> /* Write the linux PTE atomically (setting busy) */
> stdcx. r30,0,r6
> bne- 1b
> - isync
> + lwsync
>
> /* Step 2:
> *
^ permalink raw reply
* [PATCH] [POWERPC] cpm_uart: fix non-console port startup bug
From: Danny Feng @ 2009-03-04 2:28 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: linux-kernel
after UART interrupt handler is installed and rx is enabled, if an rx
interrupt comes before hardware init, rx->cur will be updated. Then the
hardware init will reset BD and make rx->cur out of sync, move the hardware
init code before request_irq.
Signed-off-by: Xiaotian Feng <xiaotian.feng@windriver.com>
---
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index bde4b4b..5c6ef51 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -406,6 +406,18 @@ static int cpm_uart_startup(struct uart_port *port)
pr_debug("CPM uart[%d]:startup\n", port->line);
+ /* If the port is not the console, make sure rx is disabled. */
+ if (!(pinfo->flags & FLAG_CONSOLE)) {
+ /* Disable UART rx */
+ if (IS_SMC(pinfo)) {
+ clrbits16(&pinfo->smcp->smc_smcmr, SMCMR_REN);
+ clrbits8(&pinfo->smcp->smc_smcm, SMCM_RX);
+ } else {
+ clrbits32(&pinfo->sccp->scc_gsmrl, SCC_GSMRL_ENR);
+ clrbits16(&pinfo->sccp->scc_sccm, UART_SCCM_RX);
+ }
+ cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
+ }
/* Install interrupt handler. */
retval = request_irq(port->irq, cpm_uart_int, 0, "cpm_uart", port);
if (retval)
@@ -420,8 +432,6 @@ static int cpm_uart_startup(struct uart_port *port)
setbits32(&pinfo->sccp->scc_gsmrl, (SCC_GSMRL_ENR |
SCC_GSMRL_ENT));
}
- if (!(pinfo->flags & FLAG_CONSOLE))
- cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
return 0;
}
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc: oprofile: enable support for ppc750 processors
From: Benjamin Herrenschmidt @ 2009-03-04 4:47 UTC (permalink / raw)
To: Octavian Purdila; +Cc: linuxppc-dev
In-Reply-To: <1231246535-13151-3-git-send-email-opurdila@ixiacom.com>
On Tue, 2009-01-06 at 14:55 +0200, Octavian Purdila wrote:
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
So I'm going to merge 1/2 but this one should really be changed to
advertise ppc/750 in oprofile_cpu_type (ie. to userspace).
Cheers,
Ben.
> arch/powerpc/kernel/cputable.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> index 923f87a..4e20cfb 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -726,6 +726,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .cpu_setup = __setup_cpu_750,
> .machine_check = machine_check_generic,
> .platform = "ppc750",
> + .oprofile_cpu_type = "ppc/7450",
> + .oprofile_type = PPC_OPROFILE_G4,
> },
> { /* 750FX rev 2.0 must disable HID0[DPM] */
> .pvr_mask = 0xffffffff,
> @@ -741,6 +743,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .cpu_setup = __setup_cpu_750,
> .machine_check = machine_check_generic,
> .platform = "ppc750",
> + .oprofile_cpu_type = "ppc/7450",
> + .oprofile_type = PPC_OPROFILE_G4,
> },
> { /* 750FX (All revs except 2.0) */
> .pvr_mask = 0xffff0000,
> @@ -756,6 +760,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .cpu_setup = __setup_cpu_750fx,
> .machine_check = machine_check_generic,
> .platform = "ppc750",
> + .oprofile_cpu_type = "ppc/7450",
> + .oprofile_type = PPC_OPROFILE_G4,
> },
> { /* 750GX */
> .pvr_mask = 0xffff0000,
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: setup archdata for {of_}platform via a single platform_notify
From: Benjamin Herrenschmidt @ 2009-03-04 4:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, arnd
In-Reply-To: <1235076557-24464-2-git-send-email-galak@kernel.crashing.org>
On Thu, 2009-02-19 at 14:49 -0600, Kumar Gala wrote:
> Since a number of powerpc chips are SoCs we end up having dma-able
> devices that are registered as platform or of_platform devices. We need
> to hook the archdata to setup proper dma_ops for these devices.
>
> In the short term the majority of these devices only need the
> direct_dma_ops as the platforms don't have any IOMMUs.
>
> In the future to enable >4G DMA support on ppc32 we can hook swiotlb ops.
I'm trying to figure out why I didn't use platform_notify back when I
did cell blades support and instead added the per-bus type notifier
support. I think I wanted to avoid the compare with bus types thingy
which somewhat suck.
Can't we do something akin to what the Cell IOMMU code does and just
have the platform code register a notifier for those bus types that
fill things up ?
IE. With this patch, if I'm not mistaken, on Cell blades, things will
start with a dma_direct_ops (which is bogus) and then end up being
hopefully "fixed up" by the iommu code. A bit weird.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/mm: Unify PTE_RPN_SHIFT and _PAGE_CHG_MASK definitions
From: Benjamin Herrenschmidt @ 2009-03-04 5:15 UTC (permalink / raw)
To: linuxppc-dev
This updates the 32-bit headers to use the same definitions for the RPN
shift inside the PTE as 64-bit, and thus updates _PAGE_CHG_MASK to
become identical.
This does introduce a runtime visible difference, which is that now,
_PAGE_HASHPTE will be part of _PAGE_CHG_MASK and thus preserved. However
this should have no practical effect as it should have been preserved in
the first place and we got away with not having it there due to our
PTE access functions preserving it anyway.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/pgtable-ppc32.h | 36 ++++++++++++++++++++-----------
arch/powerpc/include/asm/pte-fsl-booke.h | 2 +
2 files changed, 26 insertions(+), 12 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/pgtable-ppc32.h 2009-03-02 13:41:49.000000000 +1100
+++ linux-work/arch/powerpc/include/asm/pgtable-ppc32.h 2009-03-02 13:41:50.000000000 +1100
@@ -146,9 +146,29 @@ extern int icache_44x_need_flush;
#define _PAGE_HPTEFLAGS _PAGE_HASHPTE
-#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY | \
- _PAGE_SPECIAL)
+/* Location of the PFN in the PTE. Most platforms use the same as _PAGE_SHIFT
+ * here (ie, naturally aligned). Platform who don't just pre-define the
+ * value so we don't override it here
+ */
+#ifndef PTE_RPN_SHIFT
+#define PTE_RPN_SHIFT (PAGE_SHIFT)
+#endif
+
+#ifdef CONFIG_PTE_64BIT
+#define PTE_RPN_MAX (1ULL << (64 - PTE_RPN_SHIFT))
+#define PTE_RPN_MASK (~((1ULL<<PTE_RPN_SHIFT)-1))
+#else
+#define PTE_RPN_MAX (1UL << (32 - PTE_RPN_SHIFT))
+#define PTE_RPN_MASK (~((1UL<<PTE_RPN_SHIFT)-1))
+#endif
+/* _PAGE_CHG_MASK masks of bits that are to be preserved accross
+ * pgprot changes
+ */
+#define _PAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | \
+ _PAGE_ACCESSED | _PAGE_SPECIAL)
+
+/* Mask of bits returned by pte_pgprot() */
#define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | _PAGE_NO_CACHE | \
_PAGE_WRITETHRU | _PAGE_ENDIAN | \
_PAGE_USER | _PAGE_ACCESSED | \
@@ -236,18 +256,10 @@ extern unsigned long bad_call_to_PMD_PAG
* Conversions between PTE values and page frame numbers.
*/
-/* in some case we want to additionaly adjust where the pfn is in the pte to
- * allow room for more flags */
-#if defined(CONFIG_FSL_BOOKE) && defined(CONFIG_PTE_64BIT)
-#define PFN_SHIFT_OFFSET (PAGE_SHIFT + 8)
-#else
-#define PFN_SHIFT_OFFSET (PAGE_SHIFT)
-#endif
-
-#define pte_pfn(x) (pte_val(x) >> PFN_SHIFT_OFFSET)
+#define pte_pfn(x) (pte_val(x) >> PTE_RPN_SHIFT)
#define pte_page(x) pfn_to_page(pte_pfn(x))
-#define pfn_pte(pfn, prot) __pte(((pte_basic_t)(pfn) << PFN_SHIFT_OFFSET) |\
+#define pfn_pte(pfn, prot) __pte(((pte_basic_t)(pfn) << PTE_RPN_SHIFT) |\
pgprot_val(prot))
#define mk_pte(page, prot) pfn_pte(page_to_pfn(page), prot)
#endif /* __ASSEMBLY__ */
Index: linux-work/arch/powerpc/include/asm/pte-fsl-booke.h
===================================================================
--- linux-work.orig/arch/powerpc/include/asm/pte-fsl-booke.h 2009-03-02 13:41:49.000000000 +1100
+++ linux-work/arch/powerpc/include/asm/pte-fsl-booke.h 2009-03-02 13:41:50.000000000 +1100
@@ -36,6 +36,8 @@
#ifdef CONFIG_PTE_64BIT
/* ERPN in a PTE never gets cleared, ignore it */
#define _PTE_NONE_MASK 0xffffffffffff0000ULL
+/* We extend the size of the PTE flags area when using 64-bit PTEs */
+#define PTE_RPN_SHIFT (PAGE_SHIFT + 8)
#endif
#define _PMD_PRESENT 0
^ permalink raw reply
* [PATCH] powerpc/spufs: Check file offset before calculating write size in fixed-sized files
From: Jeremy Kerr @ 2009-03-04 5:38 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton, cbe-oss-dev
In-Reply-To: <<49AD7A06.2090401@gmail.com>
Based on an original patch from Roel Kluin <roel.kluin@gmail.com>.
The write size calculated during regs and fpcr writes may currently
go negative. Because size is unsigned, this will wrap, and our
check for EFBIG will fail.
Instead, do the check for EFBIG before subtracting from size.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
Roel - How about this? clear up the logic a little rather than casting
---
arch/powerpc/platforms/cell/spufs/file.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index 0da7f2b..83ef889 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -568,9 +568,10 @@ spufs_regs_write(struct file *file, const char __user *buffer,
struct spu_lscsa *lscsa = ctx->csa.lscsa;
int ret;
- size = min_t(ssize_t, sizeof lscsa->gprs - *pos, size);
- if (size <= 0)
+ if (*pos >= sizeof(lscsa->gprs))
return -EFBIG;
+
+ size = min_t(ssize_t, sizeof(lscsa->gprs) - *pos, size);
*pos += size;
ret = spu_acquire_saved(ctx);
@@ -623,10 +624,11 @@ spufs_fpcr_write(struct file *file, const char __user * buffer,
struct spu_lscsa *lscsa = ctx->csa.lscsa;
int ret;
- size = min_t(ssize_t, sizeof(lscsa->fpcr) - *pos, size);
- if (size <= 0)
+ if (*pos >= sizeof(lscsa->fpcr))
return -EFBIG;
+ size = min_t(ssize_t, sizeof(lscsa->fpcr) - *pos, size);
+
ret = spu_acquire_saved(ctx);
if (ret)
return ret;
^ permalink raw reply related
* [PATCH] powerpc/spufs: Fix incorrect buffer offset in regs write
From: Jeremy Kerr @ 2009-03-04 5:39 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev
We need to offset by *pos bytes, not *pos words.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/platforms/cell/spufs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
index 83ef889..6b10877 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -578,7 +578,7 @@ spufs_regs_write(struct file *file, const char __user *buffer,
if (ret)
return ret;
- ret = copy_from_user(lscsa->gprs + *pos - size,
+ ret = copy_from_user((char *)lscsa->gprs + *pos - size,
buffer, size) ? -EFAULT : size;
spu_release_saved(ctx);
^ permalink raw reply related
* RE: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong
From: Steve DeLaney @ 2009-03-04 5:39 UTC (permalink / raw)
To: linuxppc-dev
Here's an update on this issue.
After verifying the device tree was OK, the OF traces led us to the root
cause.
powerpc irq.c irq_alloc_virt() assigns a virtual IRQ as a function of the
input hardware IRQ hint, AND NUM_ISA_INTERRUPTS. it turns out that
asm-ppc/irq.h defines NUM_ISA_INTERRUPTS 16, so that the allocated virq
is offset by this amount. this accounts for the remap shown below for
i2c and serial device vectors.
I didn't realize before that /proc/interrupts
serviced by irq.c show_interrupts() displays virtual vector numbers.
For the mpc8349e-mitx this must be incorrect since there is no ISA?
Essentially all that is needed is a 1:1 mapping hirq:virq since
each interrupt source in the system appears to have a unique vector
in the SOC IPIC. It seems this scheme is needlessly complex, at least for
mpc8349e.
For now we simply define irq.h NUM_ISA_INTERRUPTS 0
but this isn't a complete solution since our PCI device
interrupt on hirq 20, ends up allocated on virq 1. To force
this to work, the driver does an irq_create_mapping(NULL, 20),
then assigns its own dev->irq=20 before calling request_irq()
I'm sure someone has a more elegant solution but that's what
we've been able to come up with so far.
/steverino2
-----Original Message-----
From: Steve DeLaney [mailto:onramp123@yahoo.com]
Sent: Saturday, February 28, 2009 8:08 AM
To: 'linuxppc-dev@ozlabs.org'
Subject: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong
Hello all,
We completed a 2.6.25 build for MPC8349E-mITX platform, and u-booting using
the device tree under ...boot/dts/mpc8349emitx.dts
But the standard platform device IRQs are assigned wrong under
/proc/interrupts:
16 i2c-mpc
17 i2c-mpc
20 serial
According to the device tree, and the processor data sheet, it should be
like this:
9 serial
14 i2c-mpc
15 i2c-mpc
earlier builds (pre-dating device tree) of 2.6.13 and 2.6.16 are OK.
The IRQs are assigned correctly, with serial on 9.
Oddly enough the serial port works OK even though it is assigned to IRQ 20.
We could probably live with it, but this interferes with our application
that uses PCI.
On MPC8349E-mITX, PIC IRQ 20 is intended for PCI INTA that is input to the
MPC8349E processor on IRQ4* signal.
We turned on debug output in irq.c and prom_parse.c Any idea what might be
going wrong? We would appreciate any suggestions on what to look for.
/steverino2
^ permalink raw reply
* Re: ext2_* in bitops.h
From: Benjamin Herrenschmidt @ 2009-03-04 5:58 UTC (permalink / raw)
To: Andy Grover; +Cc: linuxppc-dev, paulus, david
In-Reply-To: <49AE114C.6070903@oracle.com>
On Tue, 2009-03-03 at 21:27 -0800, Andy Grover wrote:
> Hi,
>
> Can the ext2_* definitions in arch/powerpc/include/asm/bitops.h be
> replaced with:
>
> #include <include/asm-generic/bitops/ext2-non-atomic.h>
> #include <include/asm-generic/bitops/ext2-atomic.h>
>
> ?
>
> Also, can the bitop swizzling (starting at line 351) be removed by
> including include/asm-generic/bitops/le.h? It looks very similar if not
> identical.
>
> I'm afraid I don't have a ppc to test on so I wanted to see what you all
> thought.
I suppose you are right, I'll have a closer look.
Cheers,
Ben.
^ permalink raw reply
* new batch in "test"
From: Benjamin Herrenschmidt @ 2009-03-04 6:21 UTC (permalink / raw)
To: linuxppc-dev list
Holler if something is wrong...
Here's what I just stick in "test", to hit "next" one of these days.
Arnd Bergmann (1):
powerpc/spufs: Initialize ctx->stats.tstamp correctly
Benjamin Herrenschmidt (6):
powerpc: Wire up /proc/vmallocinfo to our ioremap()
powerpc/kconfig: Kill PPC_MULTIPLATFORM
powerpc: Split the various pgtable-* headers based on MMU type
powerpc/mm: Unify PTE_RPN_SHIFT and _PAGE_CHG_MASK definitions
powerpc/mm: Tweak PTE bit combination definitions
powerpc/mm: Merge various PTE bits and accessors definitions
Geoff Levand (2):
powerpc: Add missing DABR flags
powerpc/ps3: Print memory hotplug errors
Michael Ellerman (3):
powerpc: Deindentify identify_cpu()
powerpc: Make sure we copy all cpu_spec features except PMC related ones
powerpc: Remove unused asm-offsets entries for cpu_spec
Nick Piggin (1):
powerpc: Estimate G5 cpufreq transition latency
Octavian Purdila (1):
powerpc/oprofile: G4 oprofile has variable number of counters
Timur Tabi (1):
powerpc: Add defintion for MSR[GS] to list of MSR bits
roel kluin (1):
powerpc/ps3: Make ps3av_set_video_mode mode ID signed
^ permalink raw reply
* ext2_* in bitops.h
From: Andy Grover @ 2009-03-04 5:27 UTC (permalink / raw)
To: david; +Cc: paulus, linuxppc-dev
Hi,
Can the ext2_* definitions in arch/powerpc/include/asm/bitops.h be
replaced with:
#include <include/asm-generic/bitops/ext2-non-atomic.h>
#include <include/asm-generic/bitops/ext2-atomic.h>
?
Also, can the bitop swizzling (starting at line 351) be removed by
including include/asm-generic/bitops/le.h? It looks very similar if not
identical.
I'm afraid I don't have a ppc to test on so I wanted to see what you all
thought.
Regards -- Andy
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-03-04 6:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a fix for a USB related regression on some PowerPC machines.
The following changes since commit fec6c6fec3e20637bee5d276fb61dd8b49a3f9cc:
Linus Torvalds (1):
Linux 2.6.29-rc7
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Tony Breeds (1):
powerpc: Run sbc610 USB fixup code only on the appropriate platform.
arch/powerpc/platforms/86xx/gef_sbc610.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: [PATCH] ppc: detect sbc610 boards and only fixup nec usb on them
From: Benjamin Herrenschmidt @ 2009-03-04 6:42 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Kyle McMartin, linux-kernel
In-Reply-To: <20090304035930.GD24834@bilbo.ozlabs.org>
Thanks, I applied Tony's patch and sent a pull request to Linus.
Cheers,
Ben.
On Wed, 2009-03-04 at 14:59 +1100, Tony Breeds wrote:
> On Tue, Mar 03, 2009 at 08:22:29PM -0500, Kyle McMartin wrote:
> > From: Kyle McMartin <kyle@redhat.com>
> >
> > Bug #486511 in Fedora, this is getting applied to any machine with a NEC
> > USB pci device if this CONFIG_GEF_SBC610 is on (as it was in Fedora.)
> > Obviously this isn't appropriate to do in any more than the SBC610
> > case..., so flag that we're a sbc610 board, and skip the fixup if we're
> > not.
> >
> > (Fedora: Should fix USB on Mac G4/G5...)
> >
> > Signed-off-by: Kyle McMartin <kyle@redhat.com>
> >
> > ---
> > diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c b/arch/powerpc/platforms/86xx/gef_sbc610.c
> > index fb371f5..54afda2 100644
> > --- a/arch/powerpc/platforms/86xx/gef_sbc610.c
> > +++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
> > @@ -51,6 +51,8 @@
> >
> > void __iomem *sbc610_regs;
> >
> > +static int is_sbc610;
>
> I came up with this as well, but used the machine_is() infrasturcture.
>
> Subject: [PATCH] Run fixup code only on the appropriate platform.
>
> commit a969e76a7101bf5f3d369563df1ca1253dd6131b (powerpc: Correct USB
> support for GE Fanuc SBC610) introduced a fixup for NEC usb controllers.
> This fixup should only run on GEF SBC610 boards.
>
> Fixes Fedora bug #486511.
> (https://bugzilla.redhat.com/show_bug.cgi?id=486511)
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
> arch/powerpc/platforms/86xx/gef_sbc610.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c b/arch/powerpc/platforms/86xx/gef_sbc610.c
> index fb371f5..d6b772b 100644
> --- a/arch/powerpc/platforms/86xx/gef_sbc610.c
> +++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
> @@ -142,6 +142,10 @@ static void __init gef_sbc610_nec_fixup(struct pci_dev *pdev)
> {
> unsigned int val;
>
> + /* Do not do the fixup on other platforms! */
> + if (!machine_is(gef_sbc610))
> + return;
> +
> printk(KERN_INFO "Running NEC uPD720101 Fixup\n");
>
> /* Ensure ports 1, 2, 3, 4 & 5 are enabled */
^ permalink raw reply
* Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
From: Geert Uytterhoeven @ 2009-03-04 8:26 UTC (permalink / raw)
To: Paul Mundt
Cc: Linux/m68k, Alessandro Zummo, Richard Zidlicky, rtc-linux,
linux-parisc, Linux Kernel Development, Kyle McMartin,
Linux/PPC Development, David Woodhouse
In-Reply-To: <20090303190609.GB6907@linux-sh.org>
On Wed, 4 Mar 2009, Paul Mundt wrote:
> On Tue, Mar 03, 2009 at 11:41:23AM +0100, Geert Uytterhoeven wrote:
> > So would you accept a patch series that:
> > 1. Adds the missing module aliases to rtc-parisc (which is a bugfix),
> > 2. Moves the platform device creation out of rtc-ppc and into arch-specific
> > code (which is also a bugfix),
> > 3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is a cleanup),
> > 4. Makes rtc-generic dependent on PARISC, PPC, and M68K (the existing
> > [sg]et_rtc_time() users):
> > a. without introducing ARCH_HAS_GENERIC_RTC,
> > b. with a big fat warning in the Kconfig comment not relaxing the
> > dependencies, as it's supposed to go away.
> > 4. Converts the PS3 RTC support into a separate driver, called rtc-ps3
> > (as a bonus ;-)
> >
> > ? If yes, I'll cook it up.
> >
> > Other RTC platform support can be converted into separate drivers later.
> >
> Did you miss the rtc-firmware thread?
>
> http://groups.google.com/group/rtc-linux/browse_thread/thread/53e8d98966048f66/1d730cb4aa2f85f0?lnk=gst&q=rtc-firmware#1d730cb4aa2f85f0
> http://groups.google.com/group/rtc-linux/browse_thread/thread/b3d10115c7e147f2/cb9c1530d9c3a433?lnk=gst&q=rtc-firmware#cb9c1530d9c3a433
Thanks Paul, I wasn't aware of that thread!
Yes, this is almost the same. The only part I don't agree with is the move of
the creation of the platform device from arch-specific code to rtc-firmware.c,
as this makes autoloading the driver more difficult.
Seems like everybody but the RTC maintainer has an interest in having an RTC
class driver on top of [gs]et_rtc_time()... ;-)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] powerpc/spufs: Fix incorrect buffer offset in regs write
From: Geert Uytterhoeven @ 2009-03-04 8:36 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <1236145172.189228.314429009881.1.gpush@pingu>
On Wed, 4 Mar 2009, Jeremy Kerr wrote:
> We need to offset by *pos bytes, not *pos words.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>
> ---
> arch/powerpc/platforms/cell/spufs/file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c
> index 83ef889..6b10877 100644
> --- a/arch/powerpc/platforms/cell/spufs/file.c
> +++ b/arch/powerpc/platforms/cell/spufs/file.c
> @@ -578,7 +578,7 @@ spufs_regs_write(struct file *file, const char __user *buffer,
> if (ret)
> return ret;
>
> - ret = copy_from_user(lscsa->gprs + *pos - size,
> + ret = copy_from_user((char *)lscsa->gprs + *pos - size,
> buffer, size) ? -EFAULT : size;
>
> spu_release_saved(ctx);
Could this be abused by an attacker to write registers or local store he's not
allowed to do?
Should it be backported to stable?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* [PATCH] Add unwind information for SPE registers of E500 core
From: Liming Wang @ 2009-03-04 4:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, Liming Wang, Alan Modra
SPE registers use the high part bit0~bit31 of E500 GPR0~GPR31.
The unwind information in "eh_frame" section is used during exception
handling and describes register information in the signal frame. But
current unwind information doesn't cover SPE registers, which have
been saved in the signal frame. This patch adds this unwind information
to "eh_frame" section.
SPE registers use register number 1200+N to identify register 'N', but
they start from 113 in unwind column, which is computed from gcc
source code, macro DWARF_REG_TO_UNWIND_COLUMN:
#define FIRST_PSEUDO_REGISTER 114
#define DWARF_REG_TO_UNWIND_COLUMN(r) \
((r) > 1200 ? ((r) - 1200 + FIRST_PSEUDO_REGISTER - 1) : (r))
Signed-off-by: Liming Wang <liming.wang@windriver.com>
---
arch/powerpc/kernel/vdso32/sigtramp.S | 34 +++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/vdso32/sigtramp.S b/arch/powerpc/kernel/vdso32/sigtramp.S
index 68d49dd..789a343 100644
--- a/arch/powerpc/kernel/vdso32/sigtramp.S
+++ b/arch/powerpc/kernel/vdso32/sigtramp.S
@@ -251,6 +251,40 @@ V_FUNCTION_END(__kernel_sigtramp_rt32)
vsave_msr1 (31); \
vsave_msr2 (33, 32*16+12); \
vsave (32, 32*16)
+#elif defined(CONFIG_SPE)
+#define EH_FRAME_VMX \
+ rsave (113, VREGS); \
+ rsave (114, VREGS + 1*4); \
+ rsave (115, VREGS + 2*4); \
+ rsave (116, VREGS + 3*4); \
+ rsave (117, VREGS + 4*4); \
+ rsave (118, VREGS + 5*4); \
+ rsave (119, VREGS + 6*4); \
+ rsave (120, VREGS + 7*4); \
+ rsave (121, VREGS + 8*4); \
+ rsave (122, VREGS + 9*4); \
+ rsave (123, VREGS + 10*4); \
+ rsave (124, VREGS + 11*4); \
+ rsave (125, VREGS + 12*4); \
+ rsave (126, VREGS + 13*4); \
+ rsave (127, VREGS + 14*4); \
+ rsave (128, VREGS + 15*4); \
+ rsave (129, VREGS + 16*4); \
+ rsave (130, VREGS + 17*4); \
+ rsave (131, VREGS + 18*4); \
+ rsave (132, VREGS + 19*4); \
+ rsave (133, VREGS + 20*4); \
+ rsave (134, VREGS + 21*4); \
+ rsave (135, VREGS + 22*4); \
+ rsave (136, VREGS + 23*4); \
+ rsave (137, VREGS + 24*4); \
+ rsave (138, VREGS + 25*4); \
+ rsave (139, VREGS + 26*4); \
+ rsave (140, VREGS + 27*4); \
+ rsave (141, VREGS + 28*4); \
+ rsave (142, VREGS + 29*4); \
+ rsave (143, VREGS + 30*4); \
+ rsave (144, VREGS + 31*4);
#else
#define EH_FRAME_VMX
#endif
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: [patch 1/2] powerpc: optimise smp_mb
From: Nick Piggin @ 2009-03-04 9:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1236139395.6696.9.camel@pasglop>
On Wed, Mar 04, 2009 at 03:03:15PM +1100, Benjamin Herrenschmidt wrote:
> Allright, sorry for the delay, I had those stored into my "need more
> than half a brain cell for review" list and only got to them today :-)
No problem :)
> On Thu, 2009-02-19 at 18:12 +0100, Nick Piggin wrote:
> > Using lwsync, isync sequence in a microbenchmark is 5 times faster on my G5 than
> > using sync for smp_mb. Although it takes more instructions.
> >
> > Running tbench with 4 clients on my 4 core G5 (20 times) gives the
> > following:
> >
> > unpatched AVG=920.33 STD=2.36
> > patched AVG=921.27 STD=2.77
> >
> > So not a big improvement here, actually it could even be in the noise.
> > But other workloads or systems might see a bigger win, and the patch
> > maybe is interesting or could be improved, so I'll ask for comments.
>
> So not a huge objection here, however I have some doubts as to whether
> this will be worthwhile on power5,6,7 since those optimized somewhat the
> behaviour of the full sync. Since anything older than power4 doesn't
> have lwsync, that potentially makes it not worth the pain.
I would be interested to know. Avoiding sync when there *is* outstanding
IO operations happening should be a win? (My test of tbench on localhost
obviously wouldn't generate much MMIO).
I mean, even in the most optimised implementation possible, this sequence
is less constraining than sync.
> But I need to measure to be sure... it might be that newer embedded
> processors that support lwsync and SMP (and that are using a different
> pipeline structure) might benefit from this. I'll try to run some tests
> later this week or next week, but ping me in case I forget.
OK I'll ping you next week.
> Now what would be worth doing is to also try using a twi;isync sequence
> like we do to order MMIO reads, see if it's any better than cmp/branch
Probably makes sense to use the same pattern.
^ permalink raw reply
* Re: [patch 2/2] powerpc: replace isync with lwsync
From: Nick Piggin @ 2009-03-04 10:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1236139451.6696.10.camel@pasglop>
On Wed, Mar 04, 2009 at 03:04:11PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 18:21 +0100, Nick Piggin wrote:
> > OK, here is this patch again. You didn't think I'd let a 2% performance
> > improvement be forgotten? :)
> >
> > Anyway, patch won't work well on architecture without lwsync, but I won't
> > bother fixing that kind of thing and making it merge worthy until you
> > guys say something positive about it.
> >
> > 20 runs of tbench on the G5
> >
> > unpatched AVG=920.37 STD=2.36
> > patched AVG=938.89 STD=3.33
> >
> > (throughput in MB/s) This is a 1.9% throughput increase.
>
> Definitely worth it believe. We could use a macro that uses michael new
> improvements on the CPU features code pathing so that the isync gets
> changed to lwsync on some CPUs based on the availability of it.
OK. I guess the interesting part about this is that I can't find any
IBM documentation for lwsync capable CPUs that suggest using this
pattern for acquire locking. It would be interesting to know whether
it helps other CPUs...
^ 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