* Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
From: Kumar Gala @ 2009-06-12 13:58 UTC (permalink / raw)
To: Li Yang; +Cc: Zhang Wei, netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <2a27d3730906120627l112030b3wa11ea5aa3fcb1087@mail.gmail.com>
On Jun 12, 2009, at 8:27 AM, Li Yang wrote:
> On Thu, Jun 11, 2009 at 9:32 PM, Kumar
> Gala<galak@kernel.crashing.org> wrote:
>>
>> On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote:
>>
>>>> On May 12, 2009, at 3:35 AM, Li Yang wrote:
>>>>
>>>>> Add the mapping functions used to support direct IO memory
>>>>> access of
>>>>> rapidIO.
>>>>>
>>>>> Signed-off-by: Zhang Wei <zw@zh-kernel.org>
>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>
>>>> Use inbnd/outbnd instead of inb/outb which make one think of
>>>> byte level io accessors.
>>>>
>>>> As I look at this I don't think this is the correct API. I
>>>> think we should be using the DMA mapping API to hide these
>>>> details. The concept of mapping like this seems to be more a
>>>> function of FSL's Address translation/mapping unit (ATMU) than
>>>> anything specific to the RIO bus standard.
>>>
>>> This is a separate RIO block level ATMU. Although it looks like the
>>> system level ATMU, system ATMU doesn't have the knowledge of rapidIO
>>> target device ID. The mapping need to be dynamic, as it's easy to
>>> have
>>> more RIO devices than the outbound windows.
>>
>> I understand that. What I'm saying is the RIO block level ATMU is a
>> Freescale specific detail and not part of any standard RIO bus
>> programming
>> model. We have mapping APIs that we can connect to for this via
>> the DMA API
>> layer.
>
> Ok, I see your point now. Do you mean dma_map_*() for DMA API layer?
> But in my understanding the current dma_map_*() APIs are preparing
> local memory for device to access which is similar to the inbound
> case. Is it suitable to also use them for mapping device's space for
> CPU access? Can you give an example of using this API for Address
> Translation and Mapping purpose?
Yes, I meant the dma_map_*() API. Any system with a true IOMMU uses
the dma_map_ layer as the way to do address translation.
- k
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 13:56 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612134428.GC32105@elte.hu>
On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
> This is certainly doable for agreeable features - which is the bulk
> - and it is being done.
>
> But this is a catch-22 for _controversial_ new features - which
> perfcounters clearly was, in case you turned off your lkml
> subscription ;-)
I didn't :-) My point here is that Linus can make a decision with an
email -before- merging so that -next gets a chance, at least for a
couple of days, to do the integration testing once the controversy has
been sorted by his highness.
> And if you hit that build breakage during bisection you can do:
>
> git cherry-pick e14112d
Right, I can, you can, but can random tester who wants to track down
what his problem is ? I'm not sure...
> Also, you seem to brush off the notion that far more bugs slip
> through linux-next than get caught by it.
Less than without linux-next. We aren't perfect and no process will
solve everything. But this could have been easily avoided.
> So if you think linux-next matters in terms of _regression_ testing,
> the numbers dont seem to support that notion. This particular
> incident does support that notion though, granted - but it's taken
> out of context IMHO:
>
> In terms of test coverage, at least for our trees, less than 1% of
> the bugs we handle get reported in a linux-next context - and most
> of the bugs that get reported (against say the scheduler tree) are
> related to rare architectures.
But most obvious bugs will have been caught way before that, which
leaves the hard to catch ones or the configuration-specific ones. Those
will pass linux-next, I agree. But that isn't my point and that isn't
what linux-next will catch. What is will catch is that kind of really
simple mechanical problems, such as build breakage for other archs.
If perfcounters had been 1 or 2 days in -next before being merged, we
would have avoided that problem and made everybody's bisecting life
easier.
> In fact, i checked, there were _zero_ x86 bugs reported against
> linux-next and solved against it between v2.6.30-rc1 and v2.6.30:
No but Stephen caught a bunch of mechanical compile fails due to
integration problems.
> git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/
>
> Doing it over the full cycle shows one commit altogether - a Xen
> build failure. In fact, i just checked the whole stabilization cycle
> for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were
> only 5 linux-next originated patches, most of them build failures.
>
> I did this by looking at all occurances of 'next', in all commit
> logs:
>
> git log --grep=next -i v2.6.30-rc1..v2.6.30
>
> and then manually checking the context of all 'next' matches and
> counting the linux-next related commits.
>
> So lets be generous and say that because some people dont put the
> bug report originator into the changelog it was four times as many,
> 20 - but that's still dwarved by the sheer amount of post-rc1
> changes: thousands of changes and hundreds of regressions.
>
> linux-next is mostly useful (to me at least) not for the
> cross-builds it does, but in terms of mapping out upcoming conflicts
> - which also drives early detection of problematic patches and
> problematic conflicts.
Yes, it does. The problem is that it helps -you- that way, but won't
help -us- vs. that kind of mechanical problems unless -you- also play
the game and get your stuff in there for a little while before merging
it :-)
Cheers,
Ben.
^ permalink raw reply
* Re: "next" branch update
From: Timur Tabi @ 2009-06-12 13:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1244791784.7172.69.camel@pasglop>
On Fri, Jun 12, 2009 at 2:29 AM, Benjamin
Herrenschmidt<benh@kernel.crashing.org> wrote:
> I pushed the following commits, along with merging Linus tree in today.
Is there a reason you keep ignoring my patch?
[PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout()
There is PowerPC code in the ALSA tree that depends on my patch, so
that code will break if you don't push my patch upstream.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 13:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244813397.7172.156.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
>
> > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > Linus ! still listening ?) to maybe be more proactive at giving an ack
> > or nack so that we can get a chance to do that final pass of ironing out
> > the mechanical bugs before we hit the main tree.
>
> Let me add a little bit more background to my reasoning here and why I
> think having this integration testing step is so valuable...
>
> It all boils down to bisection and having a bisectable tree.
I think you are way too concentrated on this particular incident,
and you are generalizing it into something that is not so in
practice.
Even in this particular case, there's just 3 other commit points in
the Git tree between commit 8a1ca8c (the breakage on PowerPC) and
e14112d (the fix). We'll have up to 10,000 commits.
I bisect on an almost daily basis, and i'm not seeing unreasonable
problems.
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 13:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244812224.7172.146.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > linux-next should not be second-guessing maintainers and should
> > not act as an "approval forum" for controversial features,
> > increasing the (already quite substantial) pressure on
> > maintainers to apply more crap.
>
> I agree here. That's not the point. The idea is that for things
> that -are- approved by their respective maintainers, to get some
> integration testing and ironing of those mechanical bugs so that
> by the time they hit mainstream, they don't break bisection among
> others.
This is certainly doable for agreeable features - which is the bulk
- and it is being done.
But this is a catch-22 for _controversial_ new features - which
perfcounters clearly was, in case you turned off your lkml
subscription ;-)
And if you hit that build breakage during bisection you can do:
git cherry-pick e14112d
Also, you seem to brush off the notion that far more bugs slip
through linux-next than get caught by it.
So if you think linux-next matters in terms of _regression_ testing,
the numbers dont seem to support that notion. This particular
incident does support that notion though, granted - but it's taken
out of context IMHO:
In terms of test coverage, at least for our trees, less than 1% of
the bugs we handle get reported in a linux-next context - and most
of the bugs that get reported (against say the scheduler tree) are
related to rare architectures.
In fact, i checked, there were _zero_ x86 bugs reported against
linux-next and solved against it between v2.6.30-rc1 and v2.6.30:
git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/
Doing it over the full cycle shows one commit altogether - a Xen
build failure. In fact, i just checked the whole stabilization cycle
for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were
only 5 linux-next originated patches, most of them build failures.
I did this by looking at all occurances of 'next', in all commit
logs:
git log --grep=next -i v2.6.30-rc1..v2.6.30
and then manually checking the context of all 'next' matches and
counting the linux-next related commits.
So lets be generous and say that because some people dont put the
bug report originator into the changelog it was four times as many,
20 - but that's still dwarved by the sheer amount of post-rc1
changes: thousands of changes and hundreds of regressions.
linux-next is mostly useful (to me at least) not for the
cross-builds it does, but in terms of mapping out upcoming conflicts
- which also drives early detection of problematic patches and
problematic conflicts.
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 13:29 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244812224.7172.146.camel@pasglop>
On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> To some extent, here, the issue is on Linus side and it's up to him (Hey
> Linus ! still listening ?) to maybe be more proactive at giving an ack
> or nack so that we can get a chance to do that final pass of ironing out
> the mechanical bugs before we hit the main tree.
Let me add a little bit more background to my reasoning here and why I
think having this integration testing step is so valuable...
It all boils down to bisection and having a bisectable tree.
Yes, I hate bisecting and I'm sure you are the same. It's a major PITA
and in most cases, I'm better off tracking down the actual bug and then
finding how it came into being.
However, what the ability to have a reasonably bisectable tree buys us
is all those users, testers, good wills, etc... people who do not have
the knowledge, skill, familiarity with the code etc... to track the bug
down, to be able to still find out what precise patch brought that pesky
regression that doesn't happen on anybody else machine, and thus brings
us some useful material to work with when we cannot reproduce the exact
same setup on our own machines.
Yes, I and I'm sure you can deal with a bisection breakage caused by a
minor screweup like the one we are talking about. But our testers often
can't and will just give up.
It has -nothing- to do with whether the patches are controversial or
not, it is purely about trying to make sure that things going into linus
tree had at least a few days of churning by the various involved parties
to try to get closer to the graal of a fully bisectable tree.
At least that's how I see it.
Now, we may disagree and I'm happy to discuss that more around a beer at
next KS, and to some extent, what is done is done, and if we screwed up
with -next vs. perfmon, then so be it and let's learn from our mistakes,
but I believe it makes a lot of sense to have that staging area that
helps us making sure that within a merge window with gazillion things
being merged pretty much at once, we keep this ability for our users and
testers to track down which individual patch broke something.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
From: Li Yang @ 2009-06-12 13:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: Zhang Wei, netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <5D8775BD-9973-4DE8-B442-91FB15F86ACC@kernel.crashing.org>
On Thu, Jun 11, 2009 at 9:32 PM, Kumar Gala<galak@kernel.crashing.org> wrot=
e:
>
> On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote:
>
>>> On May 12, 2009, at 3:35 AM, Li Yang wrote:
>>>
>>>> Add the mapping functions used to support direct IO memory access of
>>>> rapidIO.
>>>>
>>>> Signed-off-by: Zhang Wei <zw@zh-kernel.org>
>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>
>>> Use inbnd/outbnd instead of inb/outb which make one think of
>>> byte level io accessors.
>>>
>>> As I look at this I don't think this is the correct API. =C2=A0I
>>> think we should be using the DMA mapping API to hide these
>>> details. =C2=A0The concept of mapping like this seems to be more a
>>> function of FSL's Address translation/mapping unit (ATMU) than
>>> anything specific to the RIO bus standard.
>>
>> This is a separate RIO block level ATMU. =C2=A0Although it looks like th=
e
>> system level ATMU, system ATMU doesn't have the knowledge of rapidIO
>> target device ID. =C2=A0The mapping need to be dynamic, as it's easy to =
have
>> more RIO devices than the outbound windows.
>
> I understand that. =C2=A0What I'm saying is the RIO block level ATMU is a
> Freescale specific detail and not part of any standard RIO bus programmin=
g
> model. =C2=A0We have mapping APIs that we can connect to for this via the=
DMA API
> layer.
Ok, I see your point now. Do you mean dma_map_*() for DMA API layer?
But in my understanding the current dma_map_*() APIs are preparing
local memory for device to access which is similar to the inbound
case. Is it suitable to also use them for mapping device's space for
CPU access? Can you give an example of using this API for Address
Translation and Mapping purpose?
- Leo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 13:10 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612125335.GH31845@elte.hu>
On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> linux-next has integration testing so that interactions between
> maintainer trees are mapped and that architectures that otherwise
> few people use get build-tested too (well beyond their practical
> relevance, i have to add) - but there's little critical review done
> in linux-next. Nor should it be the forum for that, it simply
> contains way too much stuff and has a weird history format with
> daily rebases that makes review hard and expensive in that form.
I think you are mixing several issues. One is integration testing, one
is the problem of remote architecture of subsystems testing...
> linux-next should not be second-guessing maintainers and should not
> act as an "approval forum" for controversial features, increasing
> the (already quite substantial) pressure on maintainers to apply
> more crap.
I agree here. That's not the point. The idea is that for things that
-are- approved by their respective maintainers, to get some integration
testing and ironing of those mechanical bugs so that by the time they
hit mainstream, they don't break bisection among others.
Yes, next is -not- the place to debate controversial features. That's
not, I believe, why it was initiated (I may be wrong, Stephen will
correct me if I am), but the way I see things is that stuff that is
meant to be merged gets a chance to get some of that integration testing
against all the other stuff that is also meant to be merged to limit the
amount of clash and problems once we hit Linus tree.
> And that is true even if it's a new feature that i happen to support
> - as in this case - it sure would have been handy to have more
> perfcounters test coverage, every little bit of extra testing helps.
That doesn't invalidate my point. We are not talking about whether
perfcounters is worth merging or not, testing more or not, but strictly,
imho, about getting a chance (a couple of days at least) to do that
integration testing and catch the simple issues like the one that
triggered my initial rant -before- they hit mainline.
To some extent, here, the issue is on Linus side and it's up to him (Hey
Linus ! still listening ?) to maybe be more proactive at giving an ack
or nack so that we can get a chance to do that final pass of ironing out
the mechanical bugs before we hit the main tree.
Cheers,
Ben.
> If linux-next wants to do that then it should be renamed to
> something else and not called linux-next.
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 12:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244799197.7172.106.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > Ah - thanks. The bug was caused by me being a bit too optimistic
> > in applying the shiny-new Power7 support patches on the last
> > day. (nice CPU btw.)
>
> In that case paulus tells me it's actually Peter screwing up
> moving something from the powerpc code to generic :-)
Yes, but i committed it and it's my task to make sure that the thing
works as a whole so it's my fault still :)
> .../...
>
> > Such bugs happen, and they are easy enough to fix. What matters
> > arent the 1-2 short-lived bugs that do happen when a new
> > combination of trees is created, but the long-lived combination
> > bugs and conflicts.
>
> I'm not saying -next would fix world hunger ... but in this case
> we have two sets of issues, perfctr and the init ordering change
> which both got merged totally bypassing -next... We should at
> least -try- to follow the process we've defined, don't you think ?
You are trying to define a process that does not exist in that form
and which never existed in that form.
It was never true that new code _MUST_ go via linux-next - and i
hope it will never be true.
linux-next has integration testing so that interactions between
maintainer trees are mapped and that architectures that otherwise
few people use get build-tested too (well beyond their practical
relevance, i have to add) - but there's little critical review done
in linux-next. Nor should it be the forum for that, it simply
contains way too much stuff and has a weird history format with
daily rebases that makes review hard and expensive in that form.
linux-next should not be second-guessing maintainers and should not
act as an "approval forum" for controversial features, increasing
the (already quite substantial) pressure on maintainers to apply
more crap.
And that is true even if it's a new feature that i happen to support
- as in this case - it sure would have been handy to have more
perfcounters test coverage, every little bit of extra testing helps.
If linux-next wants to do that then it should be renamed to
something else and not called linux-next.
Ingo
^ permalink raw reply
* [PATCH RFC] powerpc: Implement atomic64_t for 32-bit processors
From: Paul Mackerras @ 2009-06-12 12:02 UTC (permalink / raw)
To: benh, linuxppc-dev
32-bit powerpc processors have no 64-bit atomic instructions, but we wi=
ll
need atomic64_t in order to support the perf_counter subsystem on 32-bi=
t
processors.
This adds an implementation of 64-bit atomic operations using hashed
spinlocks to provide atomicity. For each atomic operation, the address=
of the atomic64_t variable is hashed to an index into an array of 16
spinlocks. That spinlock is taken (with interrupts disabled) around th=
e
operation, which can then be coded non-atomically within the lock.
On UP, all the spinlock manipulation goes away and we simply disable
interrupts around each operation. In fact gcc eliminates the whole
atomic64_lock variable as well.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Compile-tested only at this stage, which is why it's [RFC].
arch/powerpc/include/asm/atomic.h | 29 ++++++
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/atomic64_32.c | 173 +++++++++++++++++++++++++++++=
++++++++
3 files changed, 203 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/lib/atomic64_32.c
diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/a=
sm/atomic.h
index b401950..45356d6 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -470,6 +470,35 @@ static __inline__ int atomic64_add_unless(atomic64=
_t *v, long a, long u)
=20
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
=20
+#else /* not __powerpc64__ */
+
+typedef struct {
+=09long long counter;
+} atomic64_t;
+
+#define ATOMIC64_INIT(i)=09{ (i) }
+
+extern long long atomic64_read(const atomic64_t *v);
+extern void atomic64_set(atomic64_t *v, long long i);
+extern void atomic64_add(long long a, atomic64_t *v);
+extern long long atomic64_add_return(long long a, atomic64_t *v);
+extern void atomic64_sub(long long a, atomic64_t *v);
+extern long long atomic64_sub_return(long long a, atomic64_t *v);
+extern long long atomic64_dec_if_positive(atomic64_t *v);
+extern long long atomic64_cmpxchg(atomic64_t *v, long long o, long lon=
g n);
+extern long long atomic64_xchg(atomic64_t *v, long long new);
+extern int atomic64_add_unless(atomic64_t *v, long long a, long long u=
);
+
+#define atomic64_add_negative(a, v)=09(atomic64_add_return((a), (v)) <=
0)
+#define atomic64_inc(v)=09=09=09(atomic64_add(1LL, (v))
+#define atomic64_inc_return(v)=09=09(atomic64_add_return(1LL, (v))
+#define atomic64_inc_and_test(v) =09(atomic64_inc_return(v) =3D=3D 0)
+#define atomic64_sub_and_test(a, v)=09(atomic64_sub_return((a), (v)) =3D=
=3D 0)
+#define atomic64_dec(v)=09=09=09(atomic64_sub(1LL, (v))
+#define atomic64_dec_return(v)=09=09(atomic64_sub_return(1LL, (v))
+#define atomic64_dec_and_test(v)=09(atomic64_dec_return((v)) =3D=3D 0)=
+#define atomic64_inc_not_zero(v) =09atomic64_add_unless((v), 1, 0)
+
#endif /* __powerpc64__ */
=20
#include <asm-generic/atomic.h>
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 29b742b..1537f13 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -11,7 +11,7 @@ CFLAGS_REMOVE_feature-fixups.o =3D -pg
=20
obj-y=09=09=09:=3D string.o alloc.o \
=09=09=09 checksum_$(CONFIG_WORD_SIZE).o
-obj-$(CONFIG_PPC32)=09+=3D div64.o copy_32.o crtsavres.o
+obj-$(CONFIG_PPC32)=09+=3D div64.o copy_32.o crtsavres.o atomic64_32.o=
obj-$(CONFIG_HAS_IOMEM)=09+=3D devres.o
=20
obj-$(CONFIG_PPC64)=09+=3D copypage_64.o copyuser_64.o \
diff --git a/arch/powerpc/lib/atomic64_32.c b/arch/powerpc/lib/atomic64=
_32.c
new file mode 100644
index 0000000..4c24b8a
--- /dev/null
+++ b/arch/powerpc/lib/atomic64_32.c
@@ -0,0 +1,173 @@
+/*
+ * Implementation of 64-bit atomics on 32-bit PowerPC processors.
+ *
+ * Copyright =A9 2009 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <linux/types.h>
+#include <linux/cache.h>
+#include <linux/spinlock.h>
+#include <linux/init.h>
+#include <asm/atomic.h>
+
+/*
+ * We use a hashed array of spinlocks to provide exclusive access
+ * to each atomic64_t variable. Since this is expected to used on
+ * systems with at most 4 processors, we use a relatively small
+ * array of 16 spinlocks.
+ */
+#define NR_LOCKS=0916
+
+/*
+ * Ensure each lock is in a separate cacheline on SMP.
+ */
+static union {
+=09spinlock_t lock;
+=09char pad[L1_CACHE_BYTES];
+} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
+
+static inline spinlock_t *lock_addr(const atomic64_t *v)
+{
+=09unsigned long addr =3D (unsigned long) v;
+
+=09addr >>=3D L1_CACHE_SHIFT;
+=09addr ^=3D (addr >> 8) ^ (addr >> 16);
+=09return &atomic64_lock[addr & (NR_LOCKS - 1)].lock;
+}
+
+long long atomic64_read(const atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+void atomic64_set(atomic64_t *v, long long i)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+
+=09spin_lock_irqsave(lock, flags);
+=09v->counter =3D i;
+=09spin_unlock_irqrestore(lock, flags);
+}
+
+void atomic64_add(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+
+=09spin_lock_irqsave(lock, flags);
+=09v->counter +=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+}
+
+long long atomic64_add_return(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter +=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+void atomic64_sub(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+
+=09spin_lock_irqsave(lock, flags);
+=09v->counter -=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+}
+
+long long atomic64_sub_return(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter -=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+long long atomic64_dec_if_positive(atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter - 1;
+=09if (val >=3D 0)
+=09=09v->counter =3D val;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+long long atomic64_cmpxchg(atomic64_t *v, long long o, long long n)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter;
+=09if (val =3D=3D o)
+=09=09v->counter =3D n;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+long long atomic64_xchg(atomic64_t *v, long long new)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter;
+=09v->counter =3D new;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+int atomic64_add_unless(atomic64_t *v, long long a, long long u)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09int ret =3D 1;
+
+=09spin_lock_irqsave(lock, flags);
+=09if (v->counter !=3D u) {
+=09=09v->counter +=3D a;
+=09=09ret =3D 0;
+=09}
+=09spin_unlock_irqrestore(lock, flags);
+=09return ret;
+}
+
+static int init_atomic64_lock(void)
+{
+=09int i;
+
+=09for (i =3D 0; i < NR_LOCKS; ++i)
+=09=09spin_lock_init(&atomic64_lock[i].lock);
+=09return 0;
+}
+
+pure_initcall(init_atomic64_lock);
--=20
1.6.0.4
^ permalink raw reply related
* [PATCH] powerpc: Add compiler memory barrier to mtmsr macro
From: Paul Mackerras @ 2009-06-12 12:00 UTC (permalink / raw)
To: benh, linuxppc-dev
On 32-bit non-Book E, local_irq_restore() turns into just mtmsr(),
which doesn't currently have a compiler memory barrier. This means
that accesses to memory inside a local_irq_save/restore section,
or a spin_lock_irqsave/spin_unlock_irqrestore section on UP, can
be reordered by the compiler to occur outside that section.
To fix this, this adds a compiler memory barrier to mtmsr for both
32-bit and 64-bit. Having a compiler memory barrier in mtmsr makes
sense because it will almost always be changing something about the
context in which memory accesses are done, so in general we don't want
memory accesses getting moved from one side of an mtmsr to the other.
With the barrier in mtmsr(), some of the explicit barriers in
hw_irq.h are now redundant, so this removes them.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/hw_irq.h | 5 ++---
arch/powerpc/include/asm/reg.h | 4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
index 20a44d0..7eada1a 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -80,7 +80,7 @@ static inline void local_irq_disable(void)
__asm__ __volatile__("wrteei 0": : :"memory");
#else
unsigned long msr;
- __asm__ __volatile__("": : :"memory");
+
msr = mfmsr();
SET_MSR_EE(msr & ~MSR_EE);
#endif
@@ -92,7 +92,7 @@ static inline void local_irq_enable(void)
__asm__ __volatile__("wrteei 1": : :"memory");
#else
unsigned long msr;
- __asm__ __volatile__("": : :"memory");
+
msr = mfmsr();
SET_MSR_EE(msr | MSR_EE);
#endif
@@ -108,7 +108,6 @@ static inline void local_irq_save_ptr(unsigned long *flags)
#else
SET_MSR_EE(msr & ~MSR_EE);
#endif
- __asm__ __volatile__("": : :"memory");
}
#define local_save_flags(flags) ((flags) = mfmsr())
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index fb359b0..a3c28e4 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -745,11 +745,11 @@
asm volatile("mfmsr %0" : "=r" (rval)); rval;})
#ifdef CONFIG_PPC64
#define __mtmsrd(v, l) asm volatile("mtmsrd %0," __stringify(l) \
- : : "r" (v))
+ : : "r" (v) : "memory")
#define mtmsrd(v) __mtmsrd((v), 0)
#define mtmsr(v) mtmsrd(v)
#else
-#define mtmsr(v) asm volatile("mtmsr %0" : : "r" (v))
+#define mtmsr(v) asm volatile("mtmsr %0" : : "r" (v) : "memory")
#endif
#define mfspr(rn) ({unsigned long rval; \
--
1.6.0.4
^ permalink raw reply related
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 9:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244768406.7172.1.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2009-06-12 at 10:24 +1000, Stephen Rothwell wrote:
>
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 12 Jun 2009 10:14:22 +1000
> > Subject: [PATCH] perfcounters: remove powerpc definitions of perf_counter_do_pending
> >
> > Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
> > unify and fix delayed counter wakeup") added global definitions.
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Ah - thanks. The bug was caused by me being a bit too optimistic in
applying the shiny-new Power7 support patches on the last day. (nice
CPU btw.)
> Linus, please apply. BTW, This is _EXACTLY_ why this should have
> been in -next for a few days before being merged :-(
Not really: for example current upstream is build-broken on x86 due
to an integration artifact via the kmemleak tree - despite it having
been in linux-next for months.
Paulus was building and booting powerpc on a daily basis and i ran
cross-builds as well.
Such bugs happen, and they are easy enough to fix. What matters
arent the 1-2 short-lived bugs that do happen when a new combination
of trees is created, but the long-lived combination bugs and
conflicts.
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 9:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, ppc-dev, linux-kernel, linux-next, paulus,
Ingo Molnar, Linus
In-Reply-To: <1244799786.6691.1133.camel@laptop>
On Fri, 2009-06-12 at 11:43 +0200, Peter Zijlstra wrote:
> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
>
> So you're saying -next should include whole new subsystems even though
> its not clear they will be merged?
Maybe yes. And if there's some debate as to whether it should be merged
or not, maybe Linus should make the decision, let -next carry it for a
few days to iron out those problems, and -then- merge it.
> That'll invariably create the opposite case where a tree doesn't get
> pulled and breaks bits due to its absence.
>
> -next does a great job of sorting the existing subsystem trees, but I
> don't think its Stephens job to decide if things will get merged.
No, it's not, but then, maybe Linus could play the game and -tell- us
whether he intend to merge or not at least a few days in advance :-)
> Therefore when things are in limbo (there was no definite ACK from Linus
> on perf counters) both inclusion and exclusion from -next can lead to
> trouble.
Well, Linus did ACK by merging :-) So he should have been able to give
that ack a few days in advance too..
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 9:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, ppc-dev, linux-kernel, linux-next, paulus,
Linus
In-Reply-To: <1244799786.6691.1133.camel@laptop>
* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
>
> So you're saying -next should include whole new subsystems even
> though its not clear they will be merged?
>
> That'll invariably create the opposite case where a tree doesn't
> get pulled and breaks bits due to its absence.
>
> -next does a great job of sorting the existing subsystem trees,
> but I don't think its Stephens job to decide if things will get
> merged.
>
> Therefore when things are in limbo (there was no definite ACK from
> Linus on perf counters) both inclusion and exclusion from -next
> can lead to trouble.
Precisely. linux-next is for the uncontroversial stuff from existing
subsystems. Sometimes for features pushed by or approved by existing
subsystem maintainers. But it is not for controversial stuff - Linus
is the upstream maintainer, not Stephen.
We had a real mess with perfmon3 which was included into linux-next
in a rouge way without Cc:-ing the affected maintainers and against
the maintainers. There was a repeat incident recently as well, where
a tree was included into linux-next without the approval (and
without the Cc:) of affected maintainers. linux-next needs to be
more careful about adding trees.
All in one, we did the same with perfcounters that we expected of
perfmonv3. No double standard.
Nor is there any real issue here. The bug was my fault, it was
trivial to fix, it affects a small subset of testers and it is
already upstream, applied on the same day perfcounters were pulled.
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Peter Zijlstra @ 2009-06-12 9:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, ppc-dev, linux-kernel, linux-next, paulus,
Ingo Molnar, Linus
In-Reply-To: <1244799197.7172.106.camel@pasglop>
On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> We should at least -try- to follow the
> process we've defined, don't you think ?
So you're saying -next should include whole new subsystems even though
its not clear they will be merged?
That'll invariably create the opposite case where a tree doesn't get
pulled and breaks bits due to its absence.
-next does a great job of sorting the existing subsystem trees, but I
don't think its Stephens job to decide if things will get merged.
Therefore when things are in limbo (there was no definite ACK from Linus
on perf counters) both inclusion and exclusion from -next can lead to
trouble.
^ permalink raw reply
* Re: [BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
From: Subrata Modak @ 2009-06-12 9:35 UTC (permalink / raw)
To: David Brownell
Cc: Sachin P Sant, Randy Dunlap, Arnd Bergmann, Stephen Rothwell,
linux-usb, Linux-Kernel, Linuxppc-dev, Linux-Next, kernel
In-Reply-To: <200906091738.58154.david-b@pacbell.net>
On Tue, 2009-06-09 at 17:38 -0700, David Brownell wrote:
> On Friday 05 June 2009, Subrata Modak wrote:
> > Correct, it fixes the issue. However, since few changes might have gone
> > to the Kconfig, the patch does not apply cleanly. Below is the patch, just
> > a retake of the earlier one, but on the latest code.
>
> And it got mangled a bit along the way. Plus, the original one
> goofed up Kconfig dependency displays ... both issues fixed in
> this version, against current mainline GIT.
>
> If someone can verify all four PPC/OF/OHCI configs build on
> on PPC64, I'm OK with it.
>
> - Dave
Dave,
Sorry for being late. The patch fixes the issue on the latest git for
PPC64. Infact, the whole drivers/usb/host/ builds just fine:
linux-2.6 # make drivers/usb/host/
CHK include/linux/version.h
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-powerpc
CALL scripts/checksyscalls.sh
CC drivers/usb/host/ohci-hcd.o
CC drivers/usb/host/pci-quirks.o
CC drivers/usb/host/uhci-hcd.o
LD drivers/usb/host/built-in.o
CC [M] drivers/usb/host/isp116x-hcd.o
CC [M] drivers/usb/host/u132-hcd.o
You can check in the patch now.
Regards--
Subrata
>
>
> ========== CUT HERE
> From: Arnd Bergmann <arnd@arndb.de>
> Subject: fix build failure for PPC64 randconfig [usb/ohci]
>
> We could just make the USB_OHCI_HCD_PPC_OF option implicit
> and selected only if at least one of USB_OHCI_HCD_PPC_OF_BE
> and USB_OHCI_HCD_PPC_OF_LE are set.
>
> [ dbrownell@users.sourceforge.net: fix patch manglation and dependencies ]
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Resent-by: Subrata Modak <subrata@linux.vnet.ibm.com>
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> ---
> drivers/usb/host/Kconfig | 29 +++++++++++++++--------------
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -180,26 +180,27 @@ config USB_OHCI_HCD_PPC_SOC
> Enables support for the USB controller on the MPC52xx or
> STB03xxx processor chip. If unsure, say Y.
>
> -config USB_OHCI_HCD_PPC_OF
> - bool "OHCI support for PPC USB controller on OF platform bus"
> - depends on USB_OHCI_HCD && PPC_OF
> - default y
> - ---help---
> - Enables support for the USB controller PowerPC present on the
> - OpenFirmware platform bus.
> -
> config USB_OHCI_HCD_PPC_OF_BE
> - bool "Support big endian HC"
> - depends on USB_OHCI_HCD_PPC_OF
> - default y
> + bool "OHCI support for OF platform bus (big endian)"
> + depends on USB_OHCI_HCD && PPC_OF
> select USB_OHCI_BIG_ENDIAN_DESC
> select USB_OHCI_BIG_ENDIAN_MMIO
> + ---help---
> + Enables support for big-endian USB controllers present on the
> + OpenFirmware platform bus.
>
> config USB_OHCI_HCD_PPC_OF_LE
> - bool "Support little endian HC"
> - depends on USB_OHCI_HCD_PPC_OF
> - default n
> + bool "OHCI support for OF platform bus (little endian)"
> + depends on USB_OHCI_HCD && PPC_OF
> select USB_OHCI_LITTLE_ENDIAN
> + ---help---
> + Enables support for little-endian USB controllers present on the
> + OpenFirmware platform bus.
> +
> +config USB_OHCI_HCD_PPC_OF
> + bool
> + depends on USB_OHCI_HCD && PPC_OF
> + default USB_OHCI_HCD_PPC_OF_BE || USB_OHCI_HCD_PPC_OF_LE
>
> config USB_OHCI_HCD_PCI
> bool "OHCI support for PCI-bus USB controllers"
>
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 9:33 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612092054.GB32052@elte.hu>
> Ah - thanks. The bug was caused by me being a bit too optimistic in
> applying the shiny-new Power7 support patches on the last day. (nice
> CPU btw.)
In that case paulus tells me it's actually Peter screwing up moving
something from the powerpc code to generic :-)
.../...
> Such bugs happen, and they are easy enough to fix. What matters
> arent the 1-2 short-lived bugs that do happen when a new combination
> of trees is created, but the long-lived combination bugs and
> conflicts.
I'm not saying -next would fix world hunger ... but in this case we have
two sets of issues, perfctr and the init ordering change which both got
merged totally bypassing -next... We should at least -try- to follow the
process we've defined, don't you think ?
Cheers,
Ben.
^ permalink raw reply
* Re: 2.6.30-git3 boot failure on PowerPC
From: Benjamin Herrenschmidt @ 2009-06-12 9:28 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev
In-Reply-To: <4A3219B0.3040308@in.ibm.com>
On Fri, 2009-06-12 at 14:32 +0530, Sachin Sant wrote:
> 2.6.30-git3 fails to boot on Power6 box with following messages
.../...
> git2 boots fine with the same config.
>
> I came across the following mail from Ben so this could be a know issue.
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073102.html
Thanks. Yes it's a known issue, I'm working with Pekka to find the right
solution.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Li Yang @ 2009-06-12 9:23 UTC (permalink / raw)
To: Ira Snyder
Cc: David Hawkins, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams, Timur Tabi
In-Reply-To: <20090611151750.GB9323@ovro.caltech.edu>
On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder<iws@ovro.caltech.edu> wrote:
> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
>>
>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
>>
>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com>
>>> wrote:
>>>> Adding Kumar to the CC: list, since he might pick up the patch.
>>>>
>>>
>>> Acked-by: Dan Williams <dan.j.williams@intel.com>
>>>
>>> I agree with taking this through Kumar's tree.
>>
>> I'm going through patches for .31.. Should I still pick this up? =C2=A0G=
oing
>> forward should I pick up fsldma patches?
>>
>
> I'm fine with that, but you should probably talk to Li Yang (added to
> CC). He's gotten in contact with me a few times recently.
I am fine with both ways for this patch as it is only related to
Freescale register details. But in general I think patches should go
through functional subsystem, as they usually would need insight of
the subsystem architecture. I prefer the way that the patch acked or
signed-off by Freescale guys and push upstream through Dan's tree as
most other subsystems did. Unless Dan prefers to ack the subsystem
architectural part of each patch and have them pushed other way.
- Leo
^ permalink raw reply
* 2.6.30-git3 boot failure on PowerPC
From: Sachin Sant @ 2009-06-12 9:02 UTC (permalink / raw)
To: linuxppc-dev
2.6.30-git3 fails to boot on Power6 box with following messages
[boot]0020 XICS Init
Unable to handle kernel paging request for data at address 0x00000020
Faulting instruction address: 0xc0000000000cb7d8
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in:
NIP: c0000000000cb7d8 LR: c0000000000cb780 CTR: 0000000000000002
REGS: c000000000ef3020 TRAP: 0300 Not tainted (2.6.30-git3)
MSR: 8000000000001032 <ME,IR,DR> CR: 28000024 XER: 00000001
DAR: 0000000000000020, DSISR: 0000000040000000
TASK = c000000000e32b40[0] 'swapper' THREAD: c000000000ef0000 CPU: 0
GPR00: 0000000000000000 c000000000ef32a0 c000000000ef21b0 0000000000000000
GPR04: 0000000000000000 0000000000000390 0000000000000370 c000000001453ce8
GPR08: c0000000014435b0 0000000000000000 0000000000000000 c0000000008931f0
GPR12: 8000000000009032 c000000000ff2400 00000000029698f5 0000000002a75be8
GPR16: 0000000000000000 0000000002a75be8 0000000001b5fc90 0000000000000000
GPR20: 0000000000000000 00000000000080d0 ffffffffffffffff c000000000ef3a70
GPR24: c000000041fff8a8 c000000000fa35f0 c000000000f71300 c000000000ef3450
GPR28: 0000000000000000 c00000000113a100 c000000000e6ab68 c000000000ef32a0
NIP [c0000000000cb7d8] .getnstimeofday+0x8c/0x148
LR [c0000000000cb780] .getnstimeofday+0x34/0x148
Call Trace:
[c000000000ef3340] [c0000000000c3ba0] .ktime_get_ts+0x5c/0xbc
[c000000000ef33e0] [c0000000000c3c34] .ktime_get+0x34/0x88
[c000000000ef3480] [c0000000000d02fc] .tick_nohz_stop_sched_tick+0x90/0x43c
[c000000000ef3570] [c0000000000a3dac] .irq_exit+0xac/0xc8
[c000000000ef35f0] [c00000000002ce78] .timer_interrupt+0xe0/0x110
[c000000000ef3680] [c000000000003718] decrementer_common+0x118/0x180
--- Exception: 901 at .raw_local_irq_restore+0x74/0x8c
LR = .__slab_alloc+0x2e0/0x5bc
[c000000000ef3970] [c000000000ef3a10] init_thread_union+0x3a10/0x4000 (unreliable)
[c000000000ef3a00] [c0000000001845f0] .__slab_alloc+0x2e0/0x5bc
[c000000000ef3ae0] [c000000000186410] .__kmalloc+0x160/0x238
[c000000000ef3ba0] [c00000000004a608] .zalloc_maybe_bootmem+0x4c/0xa8
[c000000000ef3c30] [c00000000000d810] .irq_alloc_host+0x74/0x250
[c000000000ef3cf0] [c00000000084906c] .xics_init_IRQ+0x344/0x3e0
[c000000000ef3de0] [c000000000848394] .pseries_xics_init_IRQ+0x18/0x34
[c000000000ef3e60] [c00000000083387c] .init_IRQ+0x44/0x64
[c000000000ef3ee0] [c000000000830a78] .start_kernel+0x238/0x460
[c000000000ef3f90] [c0000000000083ec] .start_here_common+0x1c/0x30
Instruction dump:
7c2004ac 7b8007e1 41820010 7c210b78 7c421378 4bffffe8 ebbe8000 e93d0010
e95d0018 f93b0000 f95b0008 e87d0020 <e9230020> e8090000 f8410028 7c0903a6
---[ end trace 31fd0ba7d8756001 ]---
git2 boots fine with the same config.
I came across the following mail from Ben so this could be a know issue.
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073102.html
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
From: Rini van Zetten @ 2009-06-12 8:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: spi-devel-general, Andrew Morton, linuxppc-dev list
In-Reply-To: <7071E2AF-65ED-41C2-AFE7-06E9336619CB@kernel.crashing.org>
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = <&pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
&pio2 2 0>; /* cs2 */
Signed-off-by: Rini van Zetten <rini@arvoo.nl>
---
Changes :
patch against 2.6.30-rc8-mm1
--- drivers/spi/spi_mpc8xxx.c.org 2009-06-12 10:45:21.000000000 +0200
+++ drivers/spi/spi_mpc8xxx.c 2009-06-12 10:54:48.000000000 +0200
@@ -666,9 +666,10 @@ static void mpc8xxx_spi_cs_control(struc
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev->platform_data);
u16 cs = spi->chip_select;
int gpio = pinfo->gpios[cs];
- bool alow = pinfo->alow_flags[cs];
-
- gpio_set_value(gpio, on ^ alow);
+ if (gpio != -EEXIST) {
+ bool alow = pinfo->alow_flags[cs];
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
@@ -707,27 +708,29 @@ static int of_mpc8xxx_spi_get_chipselect
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, &flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
+ goto err_loop;
+ }
+
+ pinfo->gpios[i] = gpio;
+ pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo->gpios[i],
+ pinfo->alow_flags[i]);
+ if (ret) {
+ dev_err(dev, "can't set output direction for gpio "
+ "#%d: %d\n", i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo->gpios[i] = -EEXIST;
+ } else {
dev_err(dev, "invalid gpio #%d: %d\n", i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
- goto err_loop;
- }
-
- pinfo->gpios[i] = gpio;
- pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
- if (ret) {
- dev_err(dev, "can't set output direction for gpio "
- "#%d: %d\n", i, ret);
- goto err_loop;
- }
}
pdata->max_chipselect = ngpios;
--
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Pekka Enberg @ 2009-06-12 8:38 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Nick Piggin, linuxppc-dev, linux-next
In-Reply-To: <20090612183559.33018f0c.sfr@canb.auug.org.au>
On Fri, 2009-06-12 at 18:35 +1000, Stephen Rothwell wrote:
> Hi Pekka,
>
> On Fri, 12 Jun 2009 11:25:39 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> >
> > Hmm, SLQB in my for-next branch. Stephen, is slab.git dropped from
> > linux-next or something?
>
> Yesterday (next-20090611) the slab tree for linux-next had only one
> commit in it ("SLUB: Out-of-memory diagnostics"). Today (next-20090612)
> it has quite a lot in it again - including SLQB.
Ah, ok. I did mess it up for few hours and I guess you picked up then.
Thanks, Stephen!
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Stephen Rothwell @ 2009-06-12 8:35 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Nick Piggin, linuxppc-dev, linux-next
In-Reply-To: <1244795139.30512.23.camel@penberg-laptop>
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
Hi Pekka,
On Fri, 12 Jun 2009 11:25:39 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
> Hmm, SLQB in my for-next branch. Stephen, is slab.git dropped from
> linux-next or something?
Yesterday (next-20090611) the slab tree for linux-next had only one
commit in it ("SLUB: Out-of-memory diagnostics"). Today (next-20090612)
it has quite a lot in it again - including SLQB.
--
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: [PowerPC] 2.6.30-git3 build break : perf counters
From: Stephen Rothwell @ 2009-06-12 8:25 UTC (permalink / raw)
To: Jaswinder Singh Rajput
Cc: linuxppc-dev, Ingo Molnar, Paul Mackerras, linux-kernel
In-Reply-To: <1244788494.5554.1.camel@ht.satnam>
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
Hi Jaswinder,
On Fri, 12 Jun 2009 12:04:54 +0530 Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
>
> Please check this patch :
>
> [PATCH] powerpc: perf_counter fix performance counter event types
>
> Fix compilation warnings :
> CC arch/powerpc/kernel/power7-pmu.o
> arch/powerpc/kernel/power7-pmu.c:297: error: PERF_COUNT_CPU_CYCLES undeclared here (not in a function)
> arch/powerpc/kernel/power7-pmu.c:297: error: array index in initializer not of integer type
> arch/powerpc/kernel/power7-pmu.c:297: error: (near initialization for power7_generic_events)
> arch/powerpc/kernel/power7-pmu.c:298: error: PERF_COUNT_INSTRUCTIONS undeclared here (not in a function)
> arch/powerpc/kernel/power7-pmu.c:298: error: array index in initializer not of integer type
> ......<SNIP>......
>
> Reported-by: Sachin Sant <sachinp@in.ibm.com>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
I have applied this to linux-next for today. Thanks.
--
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: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Pekka Enberg @ 2009-06-12 8:25 UTC (permalink / raw)
To: Nick Piggin; +Cc: Stephen Rothwell, linux-next, linuxppc-dev
In-Reply-To: <20090612082145.GD24044@wotan.suse.de>
On Fri, 2009-06-12 at 10:21 +0200, Nick Piggin wrote:
> On Fri, Jun 12, 2009 at 01:38:50PM +0530, Sachin Sant wrote:
> > Nick Piggin wrote:
> > >>I was able to boot yesterday's next (20090611) on this machine. Not sure
> > >>
> > >
> > >Still with SLQB? With debug options turned on?
> > >
> > Ah .. spoke too soon. The kernel was not compiled with SLQB. Sorry
> > about the confusion. I can't seem to select SLQB as the slab
> > allocator.
>
> It must have been dropped out of -next. You could just try
> a known-bad kernel with my patch applied?
Hmm, SLQB in my for-next branch. Stephen, is slab.git dropped from
linux-next or something?
Pekka
^ 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