If you build with KVM and UP it fails with the following due to a
missing include.
/arch/powerpc/kvm/book3s_hv.c: In function 'do_h_register_vpa':
arch/powerpc/kvm/book3s_hv.c:156:10: error: 'H_PARAMETER' undeclared (first use
in this function)
arch/powerpc/kvm/book3s_hv.c:156:10: note: each unde
On 11/09/11 20:23, Josh Poimboeuf wrote:
On Wed, 2011-11-09 at 12:03 +0530, Suzuki Poulose wrote:
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf wrote:
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
What I was suggesting is, instead of flushing the cache in
relocate(), lets do i
This ambiguous config option is now only present as a Kconfig stub.
Remove it and fix up the users.
Signed-off-by: Kyle Moffett
---
arch/powerpc/platforms/Kconfig.cputype | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/a
Only build the setup functions when the corresponding entries are
included in the CPU table.
Signed-off-by: Kyle Moffett
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
The CONFIG_E500 config option is ambiguous and used incorrectly in many
places to refer to some combination of e500v1/v2, e500mc, and e5500.
Fix up each reference to use the correct combinations of the following
config options:
CONFIG_FSL_E500_V1_V2
CONFIG_FSL_E500MC
CONFIG_FSL_E5500
Signed
The only systems which need the sparse PowerPC register map are the
e500v1/e500v2.
NOTE: The kgdb code does not otherwise use CONFIG_E500, so this support
is probably still buggy on e500v1/e500v2, but I don't know kgdb enough
to fix it.
Signed-off-by: Kyle Moffett
---
arch/powerpc/include/asm/k
As part of splitting CONFIG_E500 into separate options for e500v1/v2 and
e500mc/e5500, some code only needs to be built when e5500 support is
required.
This adds a new internal-use config option for both 32-bit and 64-bit
builds that enables only the e5500 support code.
Signed-off-by: Kyle Moffet
The e500mc CPUs have a classic FPU and are not compatible with e500v1 or
e500v2. This patch fixes the 32-bit CPU feature tables so that e500mc
entries are not present on e500v1/e500v2 systems and vice versa.
Signed-off-by: Kyle Moffett
---
arch/powerpc/include/asm/cputable.h | 16 ++--
This moves the "select PPC_FPU" from PPC_E500MC to the new FSL_E500MC
processor selection, where it belongs.
The only actual difference that this patch introduces is the P5020DS
board (FreeScale e5500 CPU) will not set FSL_E500MC when building in
64-bit mode.
This is OK as all of the existing cod
These are totally different (more so in fact than 6xx vs. e500v1/v2), so
there isn't really a good reason to keep them in the same file.
Signed-off-by: Kyle Moffett
---
arch/powerpc/include/asm/machdep.h |1 +
arch/powerpc/kernel/Makefile|3 +-
arch/powerpc/kernel/idle_e
The "-me500" assembler option is intended only for use on e500v1 or
e500v2 systems. On modern binutils it will refuse to assemble standard
floating point opcodes, and it will translate "lwsync" into "sync".
This fixes the e500mc/e5500 kernel build on recent binutils.
For e500mc/e5500 with standa
As FreeScale e500 systems have different cacheline sizes from e500mc, it
is basically impossible for the kernel to support both in a single
system image at present.
Given that one is SPE-float and the other is classic-float, they are not
generally userspace-compatible either.
This patch updates t
Match the config symbols for FreeScale e500/e5500 chips by using "FSL"
in the name of the config symbol.
Signed-off-by: Kyle Moffett
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/Makefile |2 +-
arch/powerpc/include/asm/cputable.h|2 +-
arch/powe
Kernels built for e500 and e500mc are fundamentally incompatible with
each other due to different cacheline sizes, support for SPE
instructions, etc.
Unfortuantely, there is a lot of support code with a morass of config
options which mostly mean the same things (E500/E500MC/PPC_85xx/etc).
As prep
As the 3 "e500" variants are generally incompatible with each other,
(32bit-spe, 32bit-classic-fpu, 64bit-classic-fpu), there is no such
thing as a "default e500" processor.
Signed-off-by: Kyle Moffett
---
arch/powerpc/kernel/cputable.c | 16
1 files changed, 0 insertions(+),
Certain processor types are co-supportable, and their machine-check
handlers will be referenced if the entries in cputable.c are actually
generated, so allow more than one machine-check handler to be built in.
This fixes a bug where configuring FreeScale E5500 support (P5020DS)
into the kernel wou
The "CONFIG_E500" conditional should be unnecessary. The fsl_rio
hardware is only present on MPC85xx (e500/e500mc) anyways, although it
should build everywhere for better compile-test coverage.
The conditionally-defined fsl_rio_mcheck_exception() function lost its
two e500-specific constants in c
The "CONFIG_PHYS_64BIT" option violates the Kconfig best-practices in
various colorful ways. It has explicit dependencies, but it is also
"select"ed by various CPUs and platforms. It is not set on 64-bit
systems, but it is used by a number of pieces of powerpc code to enable
or disable 64-bit phy
The code inside the conditional is only used by 85xx CoreNet fabric
platforms, so add a new config define and use it where necessary.
Signed-off-by: Kyle Moffett
---
arch/powerpc/platforms/85xx/Kconfig|5 +
arch/powerpc/platforms/85xx/Makefile | 11 ++-
arch/powerpc/platf
(Sorry for the repost, I accidentally omitted Baruch's email).
Hello,
I saw Baruch Siach's patch:
powerpc: 85xx: separate e500 from e500mc
Unfortunately, that patch breaks the dependencies for the P5020DS
platform and does not fix the underlying code which does not
understand what the ambiguou
From: Alexander Graf
powerpc/kvm: Fix build failure with HV KVM and CBE
When running with HV KVM and CBE config options enabled, I get
build failures like the following:
arch/powerpc/kernel/head_64.o: In function `cbe_system_error_hv':
(.text+0x1228): undefined reference to `do_kvm_0x1202'
From: Paul Mackerras
KVM: PPC: Assemble book3s{,_hv}_rmhandlers.S separately
This makes arch/powerpc/kvm/book3s_rmhandlers.S and
arch/powerpc/kvm/book3s_hv_rmhandlers.S be assembled as
separate compilation units rather than having them #included in
arch/powerpc/kernel/exceptions-64s.S. We no lo
Hello,
I saw Baruch Siach's patch:
powerpc: 85xx: separate e500 from e500mc
Unfortunately, that patch breaks the dependencies for the P5020DS
platform and does not fix the underlying code which does not
understand what the ambiguous "CONFIG_E500" means.
In order to fix the issue at the fundame
> Fix this by moving the of_mdiobus_register() call earlier.
>
> Cc: Andy Fleming
> Signed-off-by: Baruch Siach
> ---
> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fsl_pq_md
>-Original Message-
>From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On Behalf
>Of Pratyush Anand
>Sent: Thursday, October 20, 2011 2:12 AM
>To: tma...@apm.com
>Cc: Mark Miesfeld; g...@kroah.com; linux-...@vger.kern
On Wed, Nov 09, 2011 at 04:59:16AM -0600, Li Yang-R58472 wrote:
> >>> Do we have any chips that have ethernet controller support for wake
> >>> on user-defined packet, but a sleep mode that doesn't let it be used?
> >>
> >> I think it is more a PMC feature cause Ethernet controller on many
> >> SoC
On Wed, Nov 09, 2011 at 07:38:13PM +0800, Zhao Chenhui wrote:
> On Mon, Nov 07, 2011 at 12:50:24PM -0600, Scott Wood wrote:
> > On 11/07/2011 04:27 AM, Zhao Chenhui wrote:
> > > There is only one ppc_proc_freq. no lock.
> >
> > I realize there's only one.
> >
> > I'm asking whether CPUs can have
On Wed, Nov 09, 2011 at 02:31:23AM -0600, Li Yang-R58472 wrote:
> >-Original Message-
> >From: Wood Scott-B07421
> >Sent: Wednesday, November 09, 2011 4:58 AM
> >To: Li Yang-R58472
> >Cc: Wood Scott-B07421; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
> >Subject: Re: [PATCH 2/7] power
How did you come by this information?
- k
On Nov 7, 2011, at 2:32 AM, Roy Zang wrote:
> P1023 external IRQ[4:6, 11] do not pin out, but the interrupts are
> shared with PCIe controller.
> The silicon internally ties the interrupts to L, so change the
> IRQ[4:6,11] to high level sensitive for PCI
On Wed, Nov 09, 2011 at 10:11:24AM +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Nov 08, 2011 at 10:59:46AM -0600, Scott Wood wrote:
> > On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > > On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> > >> What use does userspace ha
On Wed, Nov 09, 2011 at 09:27:02AM -0600, Zang Roy-R61911 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, November 09, 2011 0:54 AM
> > To: Zang Roy-R61911
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] powerpc/p1023: set IRQ
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, November 09, 2011 0:54 AM
> To: Zang Roy-R61911
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/p1023: set IRQ[4:6, 11] to high level sensitive
> for
> PCIe
>
> On 11/07/2011 11:51 PM
On Wed, 2011-11-09 at 12:03 +0530, Suzuki Poulose wrote:
> On Tue, 08 Nov 2011 10:19:05 -0600
> Josh Poimboeuf wrote:
>
> > On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
> > > What I was suggesting is, instead of flushing the cache in
> > > relocate(), lets do it like:
> > >
> > > for
On Mon, Nov 07, 2011 at 12:50:24PM -0600, Scott Wood wrote:
> On 11/07/2011 04:27 AM, Zhao Chenhui wrote:
> > On Fri, Nov 04, 2011 at 02:42:54PM -0500, Scott Wood wrote:
> >> On 11/04/2011 07:36 AM, Zhao Chenhui wrote:
> >>> + cpufreq_frequency_table_target(policy,
> >>> +
>-Original Message-
>From: Wood Scott-B07421
>Sent: Wednesday, November 09, 2011 4:40 AM
>To: Li Yang-R58472
>Cc: Wood Scott-B07421; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 5/7] fsl_pmc: update device bindings
>
>On 11/08/2011 04:56 AM, Li Yang-R58472 wrote:
于 2011/9/15 4:26, Anton Blanchard 写道:
The sysfs memory probe interface allows unaligned regions
to be added:
# echo 0xff> /sys/devices/system/memory/probe
# cat /proc/iomem
00ff-01fe : System RAM
01ff-02fe : System RAM
02ff-03fe : System RAM
03ff-04fe : Sys
On Tue, 2011-11-08 at 14:37 -0800, Geoff Levand wrote:
> Fixes the PS3 bootup hang introduced in 3.0-rc1 by:
>
> commit 317f394160e9beb97d19a84c39b7e5eb3d7815a
> sched: Move the second half of ttwu() to the remote cpu
>
> Move the PS3's LV1 EOI call lv1_end_of_interrupt_ext() from ps3_chip_eo
On 11/09/11 12:03, Suzuki Poulose wrote:
On Tue, 08 Nov 2011 10:19:05 -0600
Josh Poimboeuf wrote:
On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
What I was suggesting is, instead of flushing the cache in
relocate(), lets do it like:
for e.g, on 440x, (in head_44x.S :)
#ifdef CONFI
>-Original Message-
>From: Wood Scott-B07421
>Sent: Wednesday, November 09, 2011 4:58 AM
>To: Li Yang-R58472
>Cc: Wood Scott-B07421; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
>
>On 11/08/2011 04:05 AM, Li Yang-R58472
On Tue, 2011-11-08 at 13:45 -0800, Miche Baker-Harvey wrote:
> It is possible to make any virtio_console port be a console
> by sending VIRITO_CONSOLE_CONSOLE_PORT. But hvc_alloc was
> using a single struct console hvc_console, which contains
> both an index and flags which are per-port.
>
> This
40 matches
Mail list logo
