On Wed, Nov 09, 2011 at 09:48:25AM -0600, Scott Wood wrote:
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
How about using clean_dcache_range() to flush the range runtime
address range [ _stext, _end ] ? That would flush the entire
instructions.
Wouldn't that result in more cache flushing than the original
solution?
For example, my kernel is 3.5MB. Assuming a 32 byte cache line
size,
Hi, Mahesh,
Could you please also add ke...@lists.infradead.org and Vivek into your
Cc list when you send your patchset next time?
Thanks!
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
于 2011年11月07日 17:55, Mahesh J Salgaonkar 写道:
From: Mahesh Salgaonkarmah...@linux.vnet.ibm.com
Documentation for firmware-assisted dump. This document is based on the
original documentation written for phyp assisted dump by Linas Vepstas
and Manish Ahuja, with few changes to reflect the current
Hi, Mahesh,
Your patch seems have some style problems... checkpatch.pl complains,
total: 330 errors, 1 warnings, 355 lines checked
NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
scripts/cleanfile
Could use scripts/checkpatch.pl to check your patch?
Thanks.
于 2011年11月07日 17:55, Mahesh J Salgaonkar 写道:
+#ifdef CONFIG_FA_DUMP
+ crash_fadump(regs, str);
+#endif
+
Please make it a nop for !CONFIG_FA_DUMP.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
于 2011年11月07日 17:56, Mahesh J Salgaonkar 写道:
From: Mahesh Salgaonkarmah...@linux.vnet.ibm.com
This patch introduces a new config option CONFIG_FA_DUMP for firmware
assisted dump feature on Powerpc (ppc64) architecture.
I think this patch can be folded into the 02/10, as this config
is
于 2011年11月07日 17:56, Mahesh J Salgaonkar 写道:
From: Mahesh Salgaonkarmah...@linux.vnet.ibm.com
Introduce a PT_NOTE program header that points to physical address of
vmcoreinfo_note buffer declared in kernel/kexec.c. The vmcoreinfo
note buffer is populated during crash_fadump() at the time of
On 2011-11-10 17:46:30 Thu, Cong Wang wrote:
于 2011年11月07日 17:55, Mahesh J Salgaonkar 写道:
From: Mahesh Salgaonkarmah...@linux.vnet.ibm.com
Documentation for firmware-assisted dump. This document is based on the
original documentation written for phyp assisted dump by Linas Vepstas
and
On 2011-11-10 17:57:02 Thu, Cong Wang wrote:
Hi, Mahesh,
Your patch seems have some style problems... checkpatch.pl complains,
total: 330 errors, 1 warnings, 355 lines checked
NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
scripts/cleanfile
Could
Hello people,
I have a little problem with the isr routine. The interrupt handler
is installed and working fine, but I can not clear the interrupt flag in
ICTL-Register.
Is that right way to get interrupt controller register ?
Thanks in advance,
Andreas Friesen
Hier is my ISR-Handler and
On Thu, Nov 10, 2011 at 01:41:44AM -0800, Joe Perches wrote:
arch/mips/include/asm/ptrace.h |2 +-
arch/mips/kernel/traps.c |2 +-
For the MIPS bits:
Acked-by: Ralf Baechle r...@linux-mips.org
Ralf
___
Linuxppc-dev
On Thu, Nov 10, 2011 at 01:41:45AM -0800, Joe Perches wrote:
Use the more commonly used __noreturn instead of ATTRIB_NORETURN.
Subject and here: s/ATTRIB_NORETURN/ATTRIB_NORET/
Signed-off-by: Joe Perches j...@perches.com
---
arch/ia64/kernel/machine_kexec.c |2 +-
On Nov 9, 2011, at 6:06 PM, Kyle Moffett wrote:
The code inside the conditional is only used by 85xx CoreNet fabric
platforms, so add a new config define and use it where necessary.
1. why make the change
2. if you're using FSL_CORENET as a SoC feature CONFIG option than other bits
of this
On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
The CONFIG_PHYS_64BIT option violates the Kconfig best-practices in
various colorful ways. It has explicit dependencies, but it is also
selected by various CPUs and platforms. It is not set on 64-bit
systems, but it is used by a number of
On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
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
On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
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
On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
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
On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:
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
Kyle Moffett wrote:
CONFIG_PHYS_64BIT_SUPPORTED:
This hidden option should be selected by any CPU type which supports
64-bit physical addresses. This will enable the PHYS_64BIT option
to be selected. It is (obviously) always set on PPC64.
CONFIG_PHYS_64BIT_DT_REQUIRED:
If we include the p1020rdb.dts instead of p1020si.dts we greatly reduce
duplication and maintenance. We can just list which devices are
disabled for the given core and mpic protected sources.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020rdb_camp_core0.dts |
Support MPC85xx platforms outside of MPC8572/MPC8536. The
MPC8572/MPC8536 have an erratum that is worked around based on having
fsl,mpc8572-gpio in the compatiable list. All other MPC85xx SoCs
don't require this workaround and thus utilize the 'fsl,pq3-gpio'
compatiable.
Signed-off-by: Kumar
* Move SoC specific details like irq mapping to SoC dtsi
* Update interrupt property to cover both error interrupt and PCIe
runtime interrupts
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020rdb.dts | 26 +-
The SPI node is out of date with regards to the binding for fsl-espi and
driver support.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020rdb.dts | 30 +-
arch/powerpc/boot/dts/p1020si.dtsi |5 ++---
2 files changed, 15
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020si.dtsi |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi
b/arch/powerpc/boot/dts/p1020si.dtsi
index 25e10cf..5514e1d 100644
---
* set interrupt-parent at root so its not duplicate in every node
* Add mpic timers
* Move to 4-prop cells for mpic timer
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020si.dtsi | 117 +---
1 files changed, 56 insertions(+), 61
All eTSEC2 controllers support waking on magic packet so fixup device
tree to report that.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020si.dtsi |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi
Split the P1020 SoC device tree into what we can include as a 'prefix'
to the board device tree and what needs to be included as a 'postfix'.
This allows use more re-use and less duplication between various board
device tree configurations (32-bit address map vs 36-bit address map).
Introduce some common components that we can utilize to build up the
various PQ3/85xx device trees.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/pq3-dma-0.dtsi| 66 ++
arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi | 51
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020rdb_36b.dts | 66
1 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1020rdb_36b.dts
diff --git a/arch/powerpc/boot/dts/p1020rdb_36b.dts
We split out the common bits of the P1020RDB device tree such that we
can reuse those bits between a 32-bit or 36-bit address map device tree.
We also update the P1020RDB device tree to utilize the new p1020 SoC dts
includes (fsl/p1020si-pre.dtsi fsl/p1020si-post.dtsi).
Signed-off-by: Kumar
Posting this to get any feedback and review while I cleanup commit messages
and the such.
The general idea is to split out the SoC and IP blocks into their own files
that can be included to build up a board level device tree. This allows us
to reduce overall duplication and forward looking
If we include the p1020rdb.dts instead of p1020si.dts we greatly reduce
duplication and maintenance. We can just list which devices are
disabled for the given core and mpic protected sources.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020rdb_camp_core0.dts |
* Move SoC specific details like irq mapping to SoC dtsi
* Update interrupt property to cover both error interrupt and PCIe
runtime interrupts
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020rdb.dts | 26 +-
The SPI node is out of date with regards to the binding for fsl-espi and
driver support.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020rdb.dts | 30 +-
arch/powerpc/boot/dts/p1020si.dtsi |5 ++---
2 files changed, 15
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020si.dtsi |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi
b/arch/powerpc/boot/dts/p1020si.dtsi
index 25e10cf..5514e1d 100644
---
All eTSEC2 controllers support waking on magic packet so fixup device
tree to report that.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020si.dtsi |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi
* set interrupt-parent at root so its not duplicate in every node
* Add mpic timers
* Move to 4-prop cells for mpic timer
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020si.dtsi | 117 +---
1 files changed, 56 insertions(+), 61
Split the P1020 SoC device tree into what we can include as a 'prefix'
to the board device tree and what needs to be included as a 'postfix'.
This allows use more re-use and less duplication between various board
device tree configurations (32-bit address map vs 36-bit address map).
Also enable
We split out the common bits of the P1020RDB device tree such that we
can reuse those bits between a 32-bit or 36-bit address map device tree.
We also update the P1020RDB device tree to utilize the new p1020 SoC dts
includes (fsl/p1020si-pre.dtsi fsl/p1020si-post.dtsi).
Signed-off-by: Kumar
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1020rdb_36b.dts | 66
1 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1020rdb_36b.dts
diff --git a/arch/powerpc/boot/dts/p1020rdb_36b.dts
Utilize new split between board SoC, and new SoC device trees split
into pre post utilizing 'template' includes for SoC IP blocks.
Moved to 4 cell interrupt nodes to deal with FSL timer and moved
interrupt-parent to root so we don't duplicate it per IP block.
During rework fixed:
* PCI
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1010rdb.dtsi |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi
b/arch/powerpc/boot/dts/p1010rdb.dtsi
index 149d196..3aa2b82 100644
---
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
index 75eb921..bd9e163 100644
---
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p1010rdb_36b.dts | 89
1 files changed, 89 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1010rdb_36b.dts
diff --git a/arch/powerpc/boot/dts/p1010rdb_36b.dts
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 235 +++
arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 68 +
arch/powerpc/boot/dts/p1022ds.dts | 431 +--
3 files changed, 318 insertions(+),
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p2020si-post.dtsi | 194 +++
arch/powerpc/boot/dts/fsl/p2020si-pre.dtsi | 69 ++
arch/powerpc/boot/dts/p2020ds.dts | 353 ++-
arch/powerpc/boot/dts/p2020ds.dtsi
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p2020rdb.dts| 63 ++---
arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 141 +--
arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 107 +
arch/powerpc/boot/dts/p2020si.dtsi|
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 225 ++
arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi | 68 +
arch/powerpc/boot/dts/p1021mds.dts | 421 ++-
3 files changed, 314 insertions(+),
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 248 ++
arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi | 63
arch/powerpc/boot/dts/mpc8536ds.dts | 456 +
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/mpc8544si-post.dtsi | 191 ++
arch/powerpc/boot/dts/fsl/mpc8544si-pre.dtsi | 63
arch/powerpc/boot/dts/mpc8544ds.dts | 473 ++---
arch/powerpc/boot/dts/mpc8544ds.dtsi
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi | 143 +++
arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi | 62 +++
arch/powerpc/boot/dts/mpc8548cds.dts | 505 ++---
3 files changed, 327 insertions(+), 383
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 342
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 145 +
arch/powerpc/boot/dts/p4080ds.dts | 14 +-
arch/powerpc/boot/dts/p4080si.dtsi | 755
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 335 +
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 96
arch/powerpc/boot/dts/p5020ds.dts | 13 +-
arch/powerpc/boot/dts/p5020si.dtsi | 716
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 332
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 112
arch/powerpc/boot/dts/p3041ds.dts | 12 +-
arch/powerpc/boot/dts/p3041si.dtsi | 729
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 332 +++
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 112 +
arch/powerpc/boot/dts/p2041rdb.dts | 28 ++-
3 files changed, 470 insertions(+), 2
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p3060si-post.dtsi | 296 +++
arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi | 125 +
arch/powerpc/boot/dts/p3060qds.dts | 12 +-
arch/powerpc/boot/dts/p3060si.dtsi | 719
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 248 ++
arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi | 76 ++
arch/powerpc/boot/dts/p1023rds.dts | 372 +--
3 files changed, 330
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi | 265 ++
arch/powerpc/boot/dts/fsl/mpc8568si-pre.dtsi | 65
arch/powerpc/boot/dts/mpc8568mds.dts | 480 -
3 files changed, 393
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/fsl/mpc8569si-post.dtsi | 292 ++
arch/powerpc/boot/dts/fsl/mpc8569si-pre.dtsi | 64
arch/powerpc/boot/dts/mpc8569mds.dts | 409 ++---
3 files changed, 389
oops, sent the wrong set of patches, ignore this group.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:
On Nov 10, 2011, at 08:59, Kumar Gala wrote:
On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:
I saw Baruch Siach's patch:
powerpc: 85xx: separate e500 from e500mc
Unfortunately, that patch breaks the dependencies for the P5020DS
On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
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
On Nov 10, 2011, at 09:04, Timur Tabi wrote:
Kyle Moffett wrote:
CONFIG_PHYS_64BIT_SUPPORTED:
This hidden option should be selected by any CPU type which supports
64-bit physical addresses. This will enable the PHYS_64BIT option
to be selected. It is (obviously) always set on
On Nov 10, 2011, at 08:37, Kumar Gala wrote:
On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
+#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
+#ifdef CONFIG_FSL_E500_V1_V2
doesn't exist yet, so patch is wrong sequence order.
Oops, d'oh.
You are completely correct, thanks for
On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
As FreeScale e500 systems have different cacheline sizes from e500mc, it
is basically impossible for the kernel to support both in a
On Wed, Nov 09, 2011 at 07:07:14PM -0500, Kyle Moffett wrote:
Only build the setup functions when the corresponding entries are
included in the CPU table.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 14 +-
1 files
On Wed, Nov 09, 2011 at 07:07:11PM -0500, Kyle Moffett wrote:
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.
How much code is this? e5500 is basically just a 64-bit version of
e500mc.
Moffett, Kyle D wrote:
Did you look at the existing code? It's already that complicated:
config ARCH_PHYS_ADDR_T_64BIT
def_bool PPC64 || PHYS_64BIT
I never understood why we have PHYS_64BIT and ARCH_PHYS_ADDR_T_64BIT, since
they mean the same thing.
config ARCH_DMA_ADDR_T_64BIT
On Thu, Nov 10, 2011 at 10:30:41AM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:
Furthermore, it looks like there are a couple issues here I missed
before. PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
except when you turn on the P5020DS board
On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
Nak, we can run an e500mc in a mode that is compatible with e500v1/v2. I
see no reason to change the support we have
On 11/08/2011 12:36 AM, Nishanth Aravamudan wrote:
Fix KVM build for older toolchains (found with .powerpc64-unknown-linux-gnu-gcc
(crosstool-NG-1.8.1) 4.3.2):
AS arch/powerpc/kvm/book3s_hv_rmhandlers.o
arch/powerpc/kvm/book3s_hv_rmhandlers.S: Assembler messages:
On 11/08/2011 12:29 AM, Nishanth Aravamudan wrote:
kvm_rma_init() is only called at boot-time, by setup_arch, which is also __init.
Signed-off-by: Nishanth Aravamudann...@us.ibm.com
Thanks, applied to kvm-ppc-next.
Alex
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
On Nov 10, 2011, at 08:59, Kumar Gala wrote:
On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:
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
BOn Wed, Nov 09, 2011 at 07:07:12PM -0500, Kyle Moffett wrote:
The only systems which need the sparse PowerPC register map are the
e500v1/e500v2.
Is this due to SPE?
+/*
+ * On FreeScale e500v1 or e500v2 processors we need to skip some register
+ * sections, so just add up a list of what we
On Thu, Nov 10, 2011 at 10:13 AM, Kumar Gala ga...@kernel.crashing.org wrote:
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 235 +++
arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 68 +
arch/powerpc/boot/dts/p1022ds.dts | 431
+--
3
On Thu, Nov 10, 2011 at 10:13:51AM -0600, Kumar Gala wrote:
Split the P1020 SoC device tree into what we can include as a 'prefix'
to the board device tree and what needs to be included as a 'postfix'.
This allows use more re-use and less duplication between various board
device tree
On Thu, Nov 10, 2011 at 10:14:11AM -0600, Kumar Gala wrote:
- power@e0070{
- compatible = fsl,mpc8536-pmc, fsl,mpc8548-pmc,
- fsl,p1022-pmc;
- reg = 0xe0070 0x20;
- etsec1_clk: soc-clk@B0{
On Nov 10, 2011, at 12:10 PM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:14:11AM -0600, Kumar Gala wrote:
-power@e0070{
-compatible = fsl,mpc8536-pmc, fsl,mpc8548-pmc,
- fsl,p1022-pmc;
-reg = 0xe0070 0x20;
On Nov 10, 2011, at 12:05 PM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:13:51AM -0600, Kumar Gala wrote:
Split the P1020 SoC device tree into what we can include as a 'prefix'
to the board device tree and what needs to be included as a 'postfix'.
This allows use more re-use and less
On Nov 10, 2011, at 11:30 AM, Tabi Timur-B04825 wrote:
On Thu, Nov 10, 2011 at 10:13 AM, Kumar Gala ga...@kernel.crashing.org
wrote:
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 235 +++
arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 68 +
On Nov 10, 2011, at 10:47 AM, Scott Wood wrote:
On Wed, Nov 09, 2011 at 07:07:14PM -0500, Kyle Moffett wrote:
Only build the setup functions when the corresponding entries are
included in the CPU table.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
On Thu, Nov 10, 2011 at 12:42:54PM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 12:10 PM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:14:11AM -0600, Kumar Gala wrote:
- power@e0070{
- compatible = fsl,mpc8536-pmc, fsl,mpc8548-pmc,
-
On Thu, Nov 10, 2011 at 12:46:27PM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 12:05 PM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:13:51AM -0600, Kumar Gala wrote:
Split the P1020 SoC device tree into what we can include as a 'prefix'
to the board device tree and what needs to be
On Nov 10, 2011, at 12:55 PM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 12:42:54PM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 12:10 PM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:14:11AM -0600, Kumar Gala wrote:
- power@e0070{
- compatible =
On Nov 10, 2011, at 12:58 PM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 12:46:27PM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 12:05 PM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:13:51AM -0600, Kumar Gala wrote:
Split the P1020 SoC device tree into what we can include as a 'prefix'
On Nov 10, 2011, at 2:27 PM, Moffett, Kyle D wrote:
On Nov 10, 2011, at 12:03, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
Nak, we can run an
On Nov 10, 2011, at 12:03, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.
I see
On Thu, 2011-11-10 at 08:01 +0530, Suzuki Poulose wrote:
How about using clean_dcache_range() to flush the range runtime
address range [ _stext, _end ] ? That would flush the entire
instructions.
Wouldn't that result in more cache flushing than the original solution?
For example, my
On Nov 10, 2011, at 11:54, Scott Wood wrote:
On Thu, Nov 10, 2011 at 10:30:41AM -0600, Kumar Gala wrote:
On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:
Furthermore, it looks like there are a couple issues here I missed
before. PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
Currently kvmppc_start_thread() tries to wake other SMT threads via
xics_wake_cpu(). Unfortunately xics_wake_cpu only exists when
CONFIG_SMP=Y so when compiling with CONFIG_SMP=N we get:
arch/powerpc/kvm/built-in.o: In function `.kvmppc_start_thread':
book3s_hv.c:(.text+0xa1e0): undefined
On Thu, Nov 10, 2011 at 01:41:45AM -0800, Joe Perches wrote:
Use the more commonly used __noreturn instead of ATTRIB_NORETURN.
Signed-off-by: Joe Perches j...@perches.com
---
arch/ia64/kernel/machine_kexec.c |2 +-
arch/m68k/amiga/config.c |2 +-
The trace_hardirqs_off will use CALLER_ADDR0 and CALLER_ADDR1.
If an exception occurs in user mode, there is only one stack frame
on the stack and accessing the CALLER_ADDR1 will causes the following
call trace. So we create a dummy stack frame to make
trace_hardirqs_off happy.
WARNING: at
On Thu, 2011-11-10 at 08:01 +0530, Suzuki Poulose wrote:
Oops ! You are right. We could go back to the clean_dcache_all() or the
initial approach that you suggested. (dcbst).
I am not sure how do we flush the entire dcache(only). Could you post a
patch which does the same ?
Another
On Thu, 2011-11-10 at 14:18 +0530, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
The Processor Identification Register (PIR) on some powerpc platforms
provides information to decode the processor identification tag.
Decoding this information is
On Tue, 08 Nov 2011 13:44:58 -0800, Miche Baker-Harvey mi...@google.com wrote:
Some modifications of vtermno were not done under the spinlock.
Moved assignment from vtermno and increment of vtermno together,
putting both under the spinlock. Revert vtermno on failure.
Signed-off-by: Miche
On Thu, 2011-11-10 at 18:38 -0600, Moffett, Kyle D wrote:
Ok, so I've been poking around this code a bunch and as far as I can
tell, the cacheline stuff has basically always been subtly wrong in
twelve different ways and it's only largely coincidence that it works
today.
Yay ! Somebody to
On Thu, 2011-11-10 at 14:27 -0600, Moffett, Kyle D wrote:
Does this mean that PPC_BOOK3E_64 needs to be split into two separate
Book 3-III families the same way that 32-bit has been split? Is there
another way around it?
No, I don't want more split, on the contrary.
Cheers,
Ben.
On Thu, 2011-11-10 at 14:34 -0600, Kumar Gala wrote:
No idea, we have to ask Ben how much he cares. I don't see any FSL
customers pushing us to run the same kernel on A2 and P5020 (or future
FSL devices).
I do care. For example, imagine somebody wanting to support an
enterprise distro on
On Fri, Nov 11, 2011 at 03:18:14PM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2011-11-10 at 14:18 +0530, Ananth N Mavinakayanahalli wrote:
From: Ananth N Mavinakayanahalli ana...@in.ibm.com
The Processor Identification Register (PIR) on some powerpc platforms
provides information
1 - 100 of 102 matches
Mail list logo
