Hi Scott,
On 4 December 2014 at 21:16, Scott Wood wrote:
> On Thu, 2014-12-04 at 10:23 +0100, Alessio Igor Bogani wrote:
>> +/include/ "fsl/pq3-mpic-message-B.dtsi"
>
> The MPIC message include should be done in the SoC file -- it's not
> board-specific.
>
> For some reason I don't see this dtsi
Signed-off-by: Alessio Igor Bogani
---
arch/powerpc/configs/mpc85xx_defconfig | 57 +++---
1 file changed, 12 insertions(+), 45 deletions(-)
diff --git a/arch/powerpc/configs/mpc85xx_defconfig
b/arch/powerpc/configs/mpc85xx_defconfig
index d2c4154..cfae862 100644
---
Add support for the Artesyn MVME2500 Single Board Computer.
The MVME2500 is a 6U form factor VME64 computer with:
- A single Freescale QorIQ P2010 CPU
- 1 GB of DDR3 onboard memory
- Three Gigabit Ethernets
- Five 16550 compatible UARTS
- One USB 2.0 port,
On Fri, 2014-05-12 at 04:26:17 UTC, Benjamin Herrenschmidt wrote:
> Newer versions of OPAL will provide this, so let's expose it to user
> space so tools like perf can use it to properly decode samples in
> firmware space.
>
> diff --git a/arch/powerpc/platforms/powernv/opal.c
> b/arch/powerpc/pl
On Fri, 2014-05-12 at 08:17:42 UTC, Alessio Igor Bogani wrote:
> Signed-off-by: Alessio Igor Bogani
> ---
> arch/powerpc/configs/mpc85xx_defconfig | 57
> +++---
> 1 file changed, 12 insertions(+), 45 deletions(-)
Actually I was planning on doing this in bulk for all
Currently when we back trace something that is in a syscall we see
something like this:
[c000] [c000] SyS_read+0x6c/0x110
[c000] [c000] syscall_exit+0x0/0x98
Although it's entirely correct, seeing syscall_exit at the bottom can be
confusing - we wer
From: Michael Ellerman
> Currently when we back trace something that is in a syscall we see
> something like this:
>
> [c000] [c000] SyS_read+0x6c/0x110
> [c000] [c000] syscall_exit+0x0/0x98
>
> Although it's entirely correct, seeing syscall_exit at
include/linux/mm.h: In function 'is_vmalloc_addr':
include/linux/mm.h:367:14: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
return addr >= VMALLOC_START && addr < VMALLOC_END;
^
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/
When size is equal to 1, the test is always true so lets eliminate both 0 and 1
at first.
include/asm-generic/termios-base.h: In function 'user_termio_to_kernel_termios':
include/asm-generic/termios-base.h:35:2: warning: comparison of unsigned
expression >= 0 is always true [-Wtype-limits]
if (
Commit 5d1638acb9f62fa7 added a hrtimer based broadcast mode for those
platforms in which local timers stop when CPUs enter deep idle states. The
commit expected the platforms to register for this mode explicitly when they
lacked a better external device to wake up CPUs in deep idle. Given that
mor
Hi Preeti,
Moving this out of the architecture code looks good to me!
I have a couple of minor comments below.
On Fri, Dec 05, 2014 at 12:47:57PM +, Preeti U Murthy wrote:
> Commit 5d1638acb9f62fa7 added a hrtimer based broadcast mode for those
> platforms in which local timers stop when CPU
As requested by mpe, this series now covers both the smt-enabled
kernel parameter and the ibm,smt-enabled property. The cleanup was
split into 3 separate patches to ease review, but I guess they
could be folded into a single patch as well.
---
Greg Kurz (4):
powerpc: drop the ability to twe
The smt-enabled kernel parameter basically leaves unwanted cpus executing
in firmware or wherever they happen to be. The very same applies to the
ibm,smt-enabled DT property which is no more used by anything known. These
are hacks that shoudn't be used in a production environment.
Quoting mpe, "th
The paths using the smt_enabled_at_boot variable reveal the following
lifecycle:
initial value: int smt_enabled_at_boot = 1
|
|
check_smt_enabled():smt_enabled_at_boot = threads_per_core
The following assertions are always true:
- threads_per_core > 0
- cpu & (threads_per_core - 1) < threads_per_core
It means smp_generic_cpu_bootable() always returns true.
Signed-off-by: Greg Kurz
---
arch/powerpc/kernel/smp.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/ar
All powerpc platforms share the same cpu_bootable hook, which does nothing
but { return 1 }. It is not needed anymore. Let's drop it at last.
Signed-off-by: Greg Kurz
---
arch/powerpc/include/asm/smp.h |1 -
arch/powerpc/kernel/smp.c|3 +--
arch/powerpc/platforms/85xx/s
Subject should read "powerpc: drop useless code in smp_generic_cpu_bootable()"
actually...
On Fri, 05 Dec 2014 16:15:12 +0100
Greg Kurz wrote:
> The following assertions are always true:
> - threads_per_core > 0
> - cpu & (threads_per_core - 1) < threads_per_core
>
> It means smp_generic_cpu_boo
All powerpc platforms share the same cpu_bootable hook, which does nothing
but { return 1 }. It is not needed anymore. Let's drop it at last.
Signed-off-by: Greg Kurz
---
v3: drop smp_generic_cpu_bootable() as well
I knew that posting a few minutes before leaving is bad idea on fridays... ;)
On Fri, Oct 17, 2014 at 03:28:20PM +0800, xuelin@freescale.com wrote:
> +/*
> + * drivers/dma/fsl_raid.c
> + *
> + * Freescale RAID Engine device driver
> + *
> + * Author:
> + * Harninder Rai
> + * Naveen Burmi
> + *
> + * Rewrite:
> + * Xuelin Shi
> + *
> + * Copyright (c) 2010-2014
On Thu, 4 Dec 2014 13:27:29 -0800
Ashutosh Dixit wrote:
> mic/mpssd along with MIC drivers are currently only usable on
> x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on
> big-endian systems.
I can certainly apply this. But it seems to me that this kind of code
doesn't belo
On Thu, Dec 04 2014 at 07:27:06 PM, Dan Streetman wrote:
> On Thu, Dec 4, 2014 at 4:27 PM, Ashutosh Dixit
> wrote:
>> mic/mpssd along with MIC drivers are currently only usable on
>> x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on
>> big-endian systems.
>
> Only building for
On Fri, Dec 05 2014 at 08:18:18 AM, Jonathan Corbet wrote:
> On Thu, 4 Dec 2014 13:27:29 -0800
> Ashutosh Dixit wrote:
>
>> mic/mpssd along with MIC drivers are currently only usable on
>> x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on
>> big-endian systems.
>
> I can certai
On Fri, Dec 05 2014 at 08:18:18 AM, Jonathan Corbet wrote:
> On Thu, 4 Dec 2014 13:27:29 -0800
> Ashutosh Dixit wrote:
>
>> mic/mpssd along with MIC drivers are currently only usable on
>> x86_64. So build mic/mpssd only for x86_64 to avoid build breaks on
>> big-endian systems.
>
> I can certai
On Fri, 2014-12-05 at 21:58 +0530, Vinod Koul wrote:
> On Fri, Oct 17, 2014 at 03:28:20PM +0800, xuelin@freescale.com wrote:
> > +/*
> > + * drivers/dma/fsl_raid.c
> > + *
> > + * Freescale RAID Engine device driver
> > + *
> > + * Author:
> > + * Harninder Rai
> > + * Naveen Burmi
> > + *
>
On Fri, 2014-12-05 at 16:14 +0100, Greg Kurz wrote:
> The smt-enabled kernel parameter basically leaves unwanted cpus executing
> in firmware or wherever they happen to be. The very same applies to the
> ibm,smt-enabled DT property which is no more used by anything known. These
> are hacks that sho
On Fri, Dec 5, 2014 at 1:18 PM, Ashutosh Dixit wrote:
> On Thu, Dec 04 2014 at 07:27:06 PM, Dan Streetman wrote:
>> On Thu, Dec 4, 2014 at 4:27 PM, Ashutosh Dixit
>> wrote:
>>> mic/mpssd along with MIC drivers are currently only usable on
>>> x86_64. So build mic/mpssd only for x86_64 to avoid
On Thu, Dec 4, 2014 at 7:44 AM, Jiri Olsa wrote:
> On Tue, Dec 02, 2014 at 06:09:35PM -0800, Sukadev Bhattiprolu wrote:
>> From: Cody P Schafer
>>
>> Enable event specification like:
>>
>> pmu/event_name,param1=0x1,param2=0x4/
>>
>> Assuming that
>>
>> /sys/bus/event_source/devices/pm
27 matches
Mail list logo
