Hi Wolfram,
On Wed, 10 Feb 2010 00:24:06 +0100
Wolfram Sang wrote:
> Two comments:
...
> > +void mpc512x_restart(char *cmd)
> > +{
> > + struct mpc512x_reset_module *rm = reset_module_base;
>
> Why not using reset_module_base directly?
I will fix it in v4 patch.
> > @@ -62,4 +95,5 @@ void _
Add reset module registers representation and
machine restart callback for mpc5121 platform.
Signed-off-by: Piotr Ziecik
Signed-off-by: Wolfgang Denk
Signed-off-by: Anatolij Gustschin
Cc: Grant Likely
Cc: John Rigby
---
Changes since v3:
- move reset module struct definition to
arch/power
Adds NAND Flash Controller driver for MPC5121 Revision 2.
All device features, except hardware ECC and power management,
are supported.
Signed-off-by: Piotr Ziecik
Signed-off-by: Wolfgang Denk
Signed-off-by: Anatolij Gustschin
Acked-by: Grant Likely
Cc:
Cc: Grant Likely
Cc: John Rigby
---
C
Ben D.,
These 4 patches are totally fine. Do you want to pick them up, or
should I take them through the PowerPC tree?
Cheers,
g.
On Wed, Feb 10, 2010 at 7:55 AM, Wolfgang Grandegger
wrote:
> From: Wolfgang Grandegger
>
> This patch series adds support for the MPC512x from Freescale to the
>
On Fri, Feb 5, 2010 at 1:54 PM, Anton Vorontsov
wrote:
> The driver wrongly sets default state for LEDs that don't specify
> default-state property.
>
> Currently the driver handles default state this way:
>
> memset(&led, 0, sizeof(led));
> for_each_child_of_node(np, child) {
> state = of_
On Tue, Feb 9, 2010 at 12:14 PM, Anton Vorontsov
wrote:
> On Tue, Feb 09, 2010 at 10:28:15AM -0700, Grant Likely wrote:
> [...]
>> Rather than having a lock at the device tree data pointer level which
>> mixes usage with potentially many other drivers; wouldn't it make more
>> sense to use a mutex
On Mon, 2010-02-15 at 08:34 +0100, Pavel Machek wrote:
> > On Tue, 2010-02-09 at 16:24 +0100, Pavel Machek wrote:
> > > ...according to gcc docs, sp should be global, or placement in
> > > register is not guaranteed (except at asm boundaries, but there
> are
> > > none).
> >
> > Sorry I'm not sure
On Tue 2010-02-16 06:59:52, Benjamin Herrenschmidt wrote:
> On Mon, 2010-02-15 at 08:34 +0100, Pavel Machek wrote:
> > > On Tue, 2010-02-09 at 16:24 +0100, Pavel Machek wrote:
> > > > ...according to gcc docs, sp should be global, or placement in
> > > > register is not guaranteed (except at asm bo
On Mon, Feb 15, 2010 at 05:51:33PM +0100, Anatolij Gustschin wrote:
> Add reset module registers representation and
> machine restart callback for mpc5121 platform.
>
> Signed-off-by: Piotr Ziecik
> Signed-off-by: Wolfgang Denk
> Signed-off-by: Anatolij Gustschin
> Cc: Grant Likely
> Cc: John
On Mon, Feb 15, 2010 at 12:49:56PM -0700, Grant Likely wrote:
[...]
> Okay, I'm convinced now. The model is wrong. struct of_gc does need
> to be a member of struct gpio_chip and conditionally compiled against
> CONFIG_OF_GPIO. This locking requirement is just too plain ugly,
And how would you
On Mon, 2010-02-15 at 21:28 +0100, Pavel Machek wrote:
> On Tue 2010-02-16 06:59:52, Benjamin Herrenschmidt wrote:
> > On Mon, 2010-02-15 at 08:34 +0100, Pavel Machek wrote:
> > > > On Tue, 2010-02-09 at 16:24 +0100, Pavel Machek wrote:
> > > > > ...according to gcc docs, sp should be global, or pl
On 02/15/2010 01:04 PM, Benjamin Herrenschmidt wrote:
>
> It's true that most other use of it we have are global scope (local_paca
> in r13, glibc use of r2/r13, etc...) afaik, but since r1 itself is the
> stack pointer always, I think they pretty much guarantee it works.
>
It should work, becau
Ben,
I cannot find those two patches from Jean [0] in your tree, I take it
they'll be included and pushed to Linus in 2.6.34 then?
(Although I had hoped to see them in 2.6.33, I'm "testing"[1] them since
-rc2 on my PowerBook)
Thanks,
Christian.
[0] http://lists.ozlabs.org/pipermail/linuxppc-
On Wed, Feb 10, 2010 at 10:10:25PM +1100, Anton Blanchard wrote:
>
> Nick Piggin discovered that lwsync barriers around locks were faster than
> isync
> on 970. That was a long time ago and I completely dropped the ball in testing
> his patches across other ppc64 processors.
>
> Turns out the id
On Wed, Feb 10, 2010 at 09:57:28PM +1100, Anton Blanchard wrote:
> v2: We do this only for 64bit until we can verify all 32bit CPUs.
>
> Tested so far: 970 (thanks Ben), POWER5, POWER6, POWER7
> Still to test: RS64, POWER3, POWER4
Tested on PA6T as well, no performance impact (as expected).
-O
On Mon, 2010-02-15 at 22:22 -0600, Olof Johansson wrote:
>
> Turns out this one hurts PA6T performance quite a bit, lwsync seems to be
> significantly more expensive there. I see a 25% drop in the microbenchmark
> doing pthread_lock/unlock loops on two cpus.
>
> Taking out the CPU_FTR_LWSYNC will
From: Grant Likely
Date: Thu, 11 Feb 2010 15:40:24 -0700
> On Thu, Feb 11, 2010 at 3:12 PM, John Linn wrote:
>> These changes add MDIO and phy lib support to the driver as the
>> IP core now supports the MDIO bus.
>>
>> The MDIO bus and phy are added as a child to the emaclite in the device
>> t
On Tue, Feb 16, 2010 at 03:19:03PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-02-15 at 22:22 -0600, Olof Johansson wrote:
> >
> > Turns out this one hurts PA6T performance quite a bit, lwsync seems to be
> > significantly more expensive there. I see a 25% drop in the microbenchmark
> > do
18 matches
Mail list logo
