On Wed, Jun 10, 2009 at 12:20:02PM +0530, K.Prasad wrote:
> On Fri, Jun 05, 2009 at 03:13:45PM +1000, David Gibson wrote:
> > On Wed, Jun 03, 2009 at 10:05:24PM +0530, K.Prasad wrote:
> > > Modify the ptrace code to use the hardware breakpoint interfaces for
> > > user-space.
> > >
> > > Signed-o
On Wed, 2009-05-27 at 12:55 -0600, Grant Likely wrote:
> From: Grant Likely
>
> ioremap_early() is useful for things like mapping SoC internally registers
> and early debug output because it allows mappings to devices to be setup
> early in the boot process where they are needed. It also give a
Hi Li/Nathan,
On Thu, 2009-06-11 at 09:07 +0530, Subrata Modak wrote:
> Hi Nathan,
>
> >On Wed, 2009-06-10 at 21:28 -0500, Nathan Lynch wrote:
> >Subrata Modak writes:
> >
> > > On Thu, 2009-06-11 at 11:05 +1000, Stephen Rothwell wrote:
> > >> Hi Subrata,
> > >>
> > >> On Wed, 10 Jun 2009 23:
On Thu, 2009-06-11 at 09:20 +0530, Subrata Modak wrote:
> Hi Benjamin/Paul,
>
> >On Thu, 2009-06-04 at 19:02 +0530, Subrata Modak wrote:
> >CC drivers/net/lance.o
> > drivers/net/lance.c: In function 'lance_probe1':
> > drivers/net/lance.c:575: error: implicit declaration of function
> > '
On Fri, 2009-06-12 at 15:05 +0530, Subrata Modak wrote:
> 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.
On Wed, Jun 10, 2009 at 12:13:49PM +0530, K.Prasad wrote:
> On Fri, Jun 05, 2009 at 03:11:58PM +1000, David Gibson wrote:
> > On Wed, Jun 03, 2009 at 10:05:11PM +0530, K.Prasad wrote:
>
> Hi David,
> Sorry for the delay in response below. In the meanwhile, I
> discovered an issue in detectin
On Wed, 2009-06-10 at 16:38 +0200, Geert Uytterhoeven wrote:
> probe functions should be __devinit
> initialization functions should be __init
Please send to USB maintainers or get an ack from them.
Cheers,
Ben.
> Signed-off-by: Geert Uytterhoeven
> Cc: Geoff Levand
> ---
> drivers/usb/host/e
On Wed, 2009-06-10 at 16:38 +0200, Geert Uytterhoeven wrote:
> probe functions should be __devinit
>
> Signed-off-by: Geert Uytterhoeven
> Cc: Geoff Levand
Please send to netdev or get an ack from davem.
Cheers,
Ben.
> ---
> drivers/net/ps3_gelic_net.c | 22 --
> d
At Mon, 15 Jun 2009 15:51:03 +1000,
Benjamin Herrenschmidt wrote:
>
> On Mon, 2009-06-15 at 07:43 +0200, Takashi Iwai wrote:
> > The alsa part also already reached to the upstream, so we have to give
> > revert patches if needed. But, in the case of sound bits, I think
> > they can remain there a
On Mon, Jun 15 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-06-10 at 16:38 +0200, Geert Uytterhoeven wrote:
> > Introduce bio_list_peek(), to obtain a pointer to the first bio on the
> > bio_list
> > without actually removing it from the list. This is needed when you want to
> > serialize ba
On Mon, 2009-06-15 at 07:43 +0200, Takashi Iwai wrote:
> The alsa part also already reached to the upstream, so we have to give
> revert patches if needed. But, in the case of sound bits, I think
> they can remain there as they are independent changes.
> But, if you think it's better to revert for
At Mon, 15 Jun 2009 12:22:08 +1000,
Benjamin Herrenschmidt wrote:
>
> On Wed, 2009-06-10 at 16:55 +0200, Takashi Iwai wrote:
> > At Wed, 10 Jun 2009 16:39:01 +0200,
> > Geert Uytterhoeven wrote:
> > >
> > > Signed-off-by: Geert Uytterhoeven
> > > Cc: alsa-de...@alsa-project.org
> > > Cc: Takashi
Roland Dreier writes:
> FWIW, Nehalem EX actually goes to 8 cores/16 threads per socket. But
> worrying about 32-bit performance on Nehalem is a little silly -- this
> simplest solution is simply to run a 64-bit kernel.
I'm not worried about ANY x86 processor, 32-bit or 64-bit, in fact,
since x8
> The new Nehalems provide 8 logical threads in a single socket. All
> those threads share a cache, and they have cmpxchg8b anyway, so this
> won't matter.
FWIW, Nehalem EX actually goes to 8 cores/16 threads per socket. But
worrying about 32-bit performance on Nehalem is a little silly -- t
On Fri, Jun 12, 2009 at 07:27:42AM +0200, Heiko Schocher wrote:
> Hello David,
>
> David Gibson wrote:
> > On Thu, Jun 11, 2009 at 08:10:41PM +0200, Heiko Schocher wrote:
> >> The following series implements basic board support for
> >> the kmeter1 board from keymile, based on a MPC8360.
> >
> >
On Wed, 2009-06-10 at 16:55 +0200, Takashi Iwai wrote:
> At Wed, 10 Jun 2009 16:39:01 +0200,
> Geert Uytterhoeven wrote:
> >
> > Signed-off-by: Geert Uytterhoeven
> > Cc: alsa-de...@alsa-project.org
> > Cc: Takashi Iwai
>
> Thanks, applied these three patches (26,27,28) to sound git tree.
Are
Without this clobber, mtspr can be re-ordered by gcc vs. surrounding
memory accesses. While this might be ok for some cases, it's not in
others and I'm not confident that all callers get it right (In fact
I'm sure some of them don't).
So for now, let's make mtspr() itself contain a memory clobber
Hi Linus !
Here's the first half of the powerpc merge for 2.6.31. I'll have the
rest in a couple of days, just dealing with some of my own backlog here
plus some collisions.
The few things outside of arch/powerpc are powerpc-specific drivers (and
an addition to pci_ids.h). There's also a cleanup
On Fri, 2009-06-12 at 14:08 +1000, Michael Ellerman wrote:
> Currently prom_init.c always instantiates RTAS, even if the kernel
> is built without RTAS support - that seems wrong.
Nak :-)
We want to always instantiate it from prom_init.c because we can't do
it any more later. There's the vague po
On Wed, 2009-06-10 at 16:38 +0200, Geert Uytterhoeven wrote:
> Both arch/powerpc/platforms/cell/iommu.c and arch/powerpc/platforms/ps3/mm.c
> contain the same Cell IOMMU page table entry definitions. Extract them and
> move
> them to , while adding a CBE_ prefix.
> This also allows them to be used
On Wed, 2009-06-10 at 16:38 +0200, Geert Uytterhoeven wrote:
> Introduce bio_list_peek(), to obtain a pointer to the first bio on the
> bio_list
> without actually removing it from the list. This is needed when you want to
> serialize based on the list being empty or not.
Leaving that one (and th
Hi Michael,
On Mon, 15 Jun 2009 10:56:36 +1000 Michael Ellerman
wrote:
>
> Rather than "-git7" can you tell us the actual SHA, I don't know what
> git7 is.
$ cat tools/get_gitid
#!/bin/sh
wget -q -O - http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-$1.id
--
Cheers,
Stephen Rothw
On Sun, 2009-06-14 at 17:08 +0530, Sachin Sant wrote:
> Benjamin Herrenschmidt wrote:
> > On Fri, 2009-06-05 at 16:59 +0530, Sachin Sant wrote:
> >
> >> While executing Hugetlbfs tests against 2.6.30-rc8-git1 on a
> >> Power 6 box observed the following OOPS message.
> I was able to recreate thi
commit 5b7c3c918c9c26c50d220b2b50359208cb5a1dbe introduced an invalid
construct in our CPU selection. This caused warnings, though it still
appeared to do the right thing.
This fixes it properly by having separate formal definitions of
PPC_BOOK3S_32 and PPC_BOOK3S_64 and one statement defining
PPC
On Mon, Jun 15, 2009 at 01:46:43AM +0200, Wolfram Sang wrote:
>
> > driver. A user _has_ to setup irq, if there is none, he still has to set
> > irq=UIO_IRQ_NONE. For that matter, 'not specified' and 'not found' is both
> > the same bad thing.
>
> Hmm, what should I do?
>
> A typical interrupts-
> driver. A user _has_ to setup irq, if there is none, he still has to set
> irq=UIO_IRQ_NONE. For that matter, 'not specified' and 'not found' is both
> the same bad thing.
Hmm, what should I do?
A typical interrupts-property in a device-tree is specified as:
interrupts = <&irq_control
On Mon, Jun 15, 2009 at 12:12:07AM +0100, Alan Cox wrote:
> > > + if (!uioinfo->irq)
> > > + uioinfo->irq = UIO_IRQ_NONE;
> >
> > Please don't do this. It's inconsistent if all other UIO drivers require
> > people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was
> > introduced
> > + if (!uioinfo->irq)
> > + uioinfo->irq = UIO_IRQ_NONE;
>
> Please don't do this. It's inconsistent if all other UIO drivers require
> people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was
> introduced because 0 may be a legal interrupt number on some platforms.
Zer
On Mon, Jun 15, 2009 at 12:00:22AM +0200, Wolfram Sang wrote:
> > > For x86 it's not defined at all. But as this code is for the PowerPC,
> >
> > No, it isn't. What makes you say that? The Kconfig entry doesn't depend
> > on PowerPC. I compiled it on x86...
>
> It depends on OF. You could compile
> > For x86 it's not defined at all. But as this code is for the PowerPC,
>
> No, it isn't. What makes you say that? The Kconfig entry doesn't depend
> on PowerPC. I compiled it on x86...
It depends on OF. You could compile on x86? Have to check that...
> > where using NO_IRQ seems still to be O
On Sun, Jun 14, 2009 at 12:27:07PM -0700, Greg KH wrote:
> On Sun, Jun 14, 2009 at 09:05:33PM +0200, Wolfram Sang wrote:
> > Well, I assume that issues regarding checkpatch do not have the highest
> > priority (especially while the merge-window is open), which is
> > understandable.
>
> Hm, the "
On Sun, Jun 14, 2009 at 09:36:53PM +0200, Wolfgang Grandegger wrote:
> if (uioinfo->irq == NO_IRQ)
> uioinfo->irq = UIO_IRQ_NONE;
> >>> Sorry for my ignorance, but what is NO_IRQ? If I do
>
> It's 0 on PowerPC but ARM seems still to use -1.
Using 0 is simply wrong, especially
On Sun, Jun 14, 2009 at 09:05:33PM +0200, Wolfram Sang wrote:
> Well, I assume that issues regarding checkpatch do not have the highest
> priority (especially while the merge-window is open), which is understandable.
Hm, the "merge-window" for new stuff like these patches is pretty much
already cl
Hans J. Koch wrote:
> On Sun, Jun 14, 2009 at 09:05:33PM +0200, Wolfram Sang wrote:
>>> Anyway, 0 is a valid IRQ number, so it cannot be used as "no irq".
>> May I point you to this thread?
>>
>> http://lkml.org/lkml/2005/11/21/221
>
> Linus is just plain wrong in this 4 year old mail.
See also t
On Sun, Jun 14, 2009 at 09:05:33PM +0200, Wolfram Sang wrote:
>
> > Anyway, 0 is a valid IRQ number, so it cannot be used as "no irq".
>
> May I point you to this thread?
>
> http://lkml.org/lkml/2005/11/21/221
Linus is just plain wrong in this 4 year old mail.
>
> (The issue comes up once in
> Anyway, 0 is a valid IRQ number, so it cannot be used as "no irq".
May I point you to this thread?
http://lkml.org/lkml/2005/11/21/221
(The issue comes up once in a while as some archs still use NO_IRQ, some with
0 some with -1)
> > if (uioinfo->irq == NO_IRQ)
> > uioinfo->ir
On Sun, Jun 14, 2009 at 07:14:06PM +0200, Wolfram Sang wrote:
> Hello Hans,
>
> > > + uioinfo->irq = irq_of_parse_and_map(op->node, 0);
> > > + if (!uioinfo->irq)
> > > + uioinfo->irq = UIO_IRQ_NONE;
> >
> > Please don't do this. It's inconsistent if all other UIO drivers require
> > peop
Hello Hans,
> > + uioinfo->irq = irq_of_parse_and_map(op->node, 0);
> > + if (!uioinfo->irq)
> > + uioinfo->irq = UIO_IRQ_NONE;
>
> Please don't do this. It's inconsistent if all other UIO drivers require
> people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was
> intro
On Thu, Jun 11, 2009 at 6:04 PM, Wolfram Sang wrote:
> Picking up the now exported generic probe function from the
> platform-variant of this driver, this patch adds an of-version. Also add
> the binding documentation.
>
> Signed-off-by: Wolfram Sang
> Cc: Magnus Damm
> Cc: Hans J. Koch
> Cc: Gr
Ben Dooks wrote:
is there a new version of this patch available?
I will catch up on it ASAP.
/Esben
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
is there a new version of this patch available?
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Paul Mackerras wrote:
Avi Kivity writes:
An alternative implementation using 64-bit cmpxchg will recover most of
the costs of hashed spinlocks. I assume most serious 32-bit
architectures have them?
Have a 64-bit cmpxchg, you mean? x86 is the only one I know of, and
it already has a
On Fri, Jun 12, 2009 at 02:04:21AM +0200, Wolfram Sang wrote:
> This patch refactors the probe routine, so that an of-version of a similiar
> driver can pick it up later.
Looks good to me.
Signed-off-by: Hans J. Koch
>
> Signed-off-by: Wolfram Sang
> Cc: Magnus Damm
> Cc: Hans J. Koch
> Cc:
On Fri, Jun 12, 2009 at 02:04:22AM +0200, Wolfram Sang wrote:
> Picking up the now exported generic probe function from the
> platform-variant of this driver, this patch adds an of-version. Also add
> the binding documentation.
Some minor problems, see below.
>
> Signed-off-by: Wolfram Sang
> C
Avi Kivity writes:
> An alternative implementation using 64-bit cmpxchg will recover most of
> the costs of hashed spinlocks. I assume most serious 32-bit
> architectures have them?
Have a 64-bit cmpxchg, you mean? x86 is the only one I know of, and
it already has an atomic64_t implementation
Linus Torvalds wrote:
On Sat, 13 Jun 2009, Linus Torvalds wrote:
On Sat, 13 Jun 2009, Paul Mackerras wrote:
Linus, Andrew: OK if this goes in via the powerpc tree?
Ok by me.
Btw, do 32-bit architectures really necessarily want 64-bit performance
counters?
I realize tha
Benjamin Herrenschmidt wrote:
On Fri, 2009-06-05 at 16:59 +0530, Sachin Sant wrote:
While executing Hugetlbfs tests against 2.6.30-rc8-git1 on a
Power 6 box observed the following OOPS message.
I was able to recreate this with 2.6.30-git7.
Here is the supporting data.
cpu 0x1: Vector: 300 (
47 matches
Mail list logo
