Hello Grant,
Heiko Schocher wrote:
> Hello Grant,
>
> On Thu, 29 Sep 2011 07:49:07 -0500 Grant wrote:
>> On Sep 29, 2011 4:31 AM, "Anatolij Gustschin" wrote:
Hi Ben,
please pull another two mpc5xxx patches for next. These patches were
queued in Grant's 'powerpc/next' branch a
Hello Grant,
On Thu, 29 Sep 2011 07:49:07 -0500 Grant wrote:
> On Sep 29, 2011 4:31 AM, "Anatolij Gustschin" wrote:
> > >
> > > Hi Ben,
> > >
> > > please pull another two mpc5xxx patches for next. These patches were
> > > queued in Grant's 'powerpc/next' branch a while ago, but a pull request
>
This patch add the Chroma platform to WSP/PowerEN, which is a PCIe
card (a defconfig is included).
The card includes an H8 service processor that is used to manage the
card. The H8 is connected over the second serial UART on the PowerEN
chip so this patch includes a simple 16550 driver to enable
On Sep 29, 2011, at 6:52 PM, Kumar Gala wrote:
>
> On Sep 29, 2011, at 4:55 PM, Jimi Xenidis wrote:
>
>> arch/powerpc/configs/chroma_defconfig | 1817
>> +
>
> Seems kind big, you probably need a 'make savedefconfig' ;)
wow had no idea that evan existed, will
On Thu, Sep 29, 2011 at 08:22:06PM +, Tabi Timur-B04825 wrote:
> Grant Likely wrote:
> > A chained handler has an expedited path through the interrupt code for
> > handling it (basically, it skips handling it at the parent controller
> > and passes through to the child, but it cannot handle mul
On Sep 29, 2011, at 4:55 PM, Jimi Xenidis wrote:
> arch/powerpc/configs/chroma_defconfig | 1817 +
Seems kind big, you probably need a 'make savedefconfig' ;)
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.o
Sorry, there was a typo in the #if
signed-off-by: Jimi Xenidis
---
arch/powerpc/xmon/xmon.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 13f82f8..e88e7f5 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerp
The 'u' command will print the TLB on book3e parts and the SLB on
Book3s parts, but the help system doesn't say that correctly.
Signed-off-by: Jimi Xenidis
---
arch/powerpc/xmon/xmon.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c
This patch adds a fault handler that responds to illegal Coprocessor
types. Currently all CTs are treated and illegal. There are two ways
to report the fault back to the application. If the application used
the record form ("icswx.") then the architected "reject" is emulated.
If the application
ICSWX is also used by the A2 processor to access coprocessors,
although not all "chips" that contain A2s have coprocessors.
Signed-off-by: Jimi Xenidis
---
Re: ga...@kernel.crashing.org
Fix white space *embarrassed*
Re: b...@kernel.crashing.org
rebase
---
arch/powerpc/include/asm/cputab
Some processors, like embedded, that already have a PID register that
is managed by the system. This patch separates the ACOP and PID
processing into separate files so that the ACOP code can be shared.
Signed-off-by: Jimi Xenidis
---
Re: b...@kernel.crashing.org
rebase
--in-reply-to=131727
Hi Grant,
On 09/29/2011 08:27 PM, Grant Likely wrote:
On Wed, Sep 28, 2011 at 08:52:30PM +, Tabi Timur-B04825 wrote:
On Tue, Sep 27, 2011 at 1:29 PM, Grant Likely wrote:
The solution is to make the gpio driver register as a regular
interrupt handler, and not as a chained handler.
I was
Grant Likely wrote:
> A chained handler has an expedited path through the interrupt code for
> handling it (basically, it skips handling it at the parent controller
> and passes through to the child, but it cannot handle multiple chained
> children on a single irq input.
So you can't do a shared c
On Wed, Sep 28, 2011 at 08:52:30PM +, Tabi Timur-B04825 wrote:
> On Tue, Sep 27, 2011 at 1:29 PM, Grant Likely
> wrote:
>
> > The solution is to make the gpio driver register as a regular
> > interrupt handler, and not as a chained handler.
>
> I was wondering about that.
>
> What exactly
From: Mahesh Salgaonkar
This patch introduces a new config option CONFIG_FA_DUMP for firmware
assisted dump feature on Powerpc (ppc64) architecture.
Signed-off-by: Mahesh Salgaonkar
---
arch/powerpc/Kconfig | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/a
From: Mahesh Salgaonkar
If dump is active during system reboot, shutdown or halt then invalidate
the fadump registration as it does not get invalidated automatically.
Signed-off-by: Mahesh Salgaonkar
---
arch/powerpc/kernel/setup-common.c |8
1 files changed, 8 insertions(+), 0 de
From: Mahesh Salgaonkar
This patch introduces an sysfs interface '/sys/kernel/fadump_release_mem' to
invalidate the last fadump registration, invalidate '/proc/vmcore', release
the reserved memory for general use and re-register for future kernel dump.
Once the dump is copied to the disk, the use
From: Mahesh Salgaonkar
With the firmware-assisted dump support we don't require a reboot when we
are in second kernel after crash. The second kernel after crash is a normal
kernel boot and has knowledge about entire system RAM with the page tables
initialized for entire system RAM. Hence once th
From: Mahesh Salgaonkar
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 system
crash.
Signed-off-by: Mahesh Salgaonkar
---
arch/powerpc/kernel/f
From: Mahesh Salgaonkar
When registered for firmware assisted dump on powerpc, firmware preserves
the registers for the active CPUs during a system crash. This patch reads
the cpu register data stored in Firmware-assisted dump format (except for
crashing cpu) and converts it into elf notes and up
From: Mahesh Salgaonkar
Build the crash memory range list by traversing through system memory during
the first kernel before we register for firmware-assisted dump. After the
successful dump registration, initialize the elfcore header and populate
PT_LOAD program headers with crash memory ranges.
From: Mahesh Salgaonkar
This patch registers for firmware-assisted dump using rtas token
ibm,configure-kernel-dump. During registration firmware is informed about
the reserved area where it saves the CPU state data, HPTE table and contents
of RMR region at the time of kernel crash. Apart from thi
From: Mahesh Salgaonkar
Reserve the memory during early boot to preserve CPU state data, HPTE region
and RMR region data in case of kernel crash. At the time of crash, powerpc
firmware will store CPU state data, HPTE region data and move RMR region
data to the reserved memory area.
If the firmwa
From: Mahesh Salgaonkar
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 implementation.
Change in v2:
- Modified the documentation to reflect t
Hi All,
Please find the version 2 of the patchset that implements firmware-assisted
dump mechanism to capture kernel crash dump for Powerpc architecture. The
firmware-assisted dump is a robust mechanism to get reliable kernel crash
dump with assistance from firmware. This approach does not use kex
On Sep 28, 2011, at 9:29 PM, Liu Gang wrote:
> Add two message units and number of ports according to the p4080 reference
> manual.
>
> Signed-off-by: Li Yang
> Signed-off-by: Jin Qing
> Signed-off-by: Liu Gang
> ---
> arch/powerpc/boot/dts/p4080ds.dts |4 +-
> arch/powerpc/boot/dts/p408
On Sep 28, 2011, at 9:29 PM, Liu Gang wrote:
> Add two message units and number of ports according to the p4080 reference
> manual.
Explain why range size increased.
>
> Signed-off-by: Li Yang
> Signed-off-by: Jin Qing
> Signed-off-by: Liu Gang
> ---
> arch/powerpc/boot/dts/p4080ds.dts |
On Sep 28, 2011, at 9:28 PM, Liu Gang wrote:
> The Freescale PowerPC RapidIO controller consists of a RapidIO endpoint and a
> RapidIO
> message unit(RMU). Or use RapidIO message manager(RMan) to replace the RMU in
> DPAA
> architecture. Therefore, we should split the code into two function mod
On Sep 28, 2011, at 9:29 PM, Liu Gang wrote:
> This document is created for powerpc rapidio and rmu nodes in dts file. These
> nodes
> can support two rapidio ports and message units. In addition, It explicates
> the properties
> and gives examples about rapidio and rmu nodes.
>
> Signed-off-b
Hi Grant,
On Thu, 29 Sep 2011 07:49:07 -0500
Grant Likely wrote:
...
> > are available in the git repository at:
> > git://git.denx.de/linux-2.6-agust.git next
> >
> > Grant Likely (1):
> > powerpc/5200: add support for charon board
>
> Hmmm, I didn't actually write this patch. It looks li
On Sep 29, 2011 4:31 AM, "Anatolij Gustschin" wrote:
>
> Hi Ben,
>
> please pull another two mpc5xxx patches for next. These patches were
> queued in Grant's 'powerpc/next' branch a while ago, but a pull request
> have never been submitted for them. Thanks!
>
> Anatolij
>
> The following changes s
From: David Gibson
Based on patch by David Gibson
xmon has a longstanding bug on systems which are SMP-capable but lack
the MSR[RI] bit. In these cases, xmon invoked by IPI on secondary
CPUs will not properly keep quiet, but will print stuff, thereby
garbling the primary xmon's output. This p
On 09/29/11 04:33, Benjamin Herrenschmidt wrote:
On Tue, 2011-09-27 at 17:54 +0530, Suzuki Poulose wrote:
Hi,
I am working on enabling CONFIG_RELOCATABLE for PPC44x Embedded PowerPC
boards as a foundation to enable CONFIG_CRASH_DUMP. After a discussion
on the linux-ppcdev we decided that we wil
Hi Ben,
please pull another two mpc5xxx patches for next. These patches were
queued in Grant's 'powerpc/next' branch a while ago, but a pull request
have never been submitted for them. Thanks!
Anatolij
The following changes since commit 7680057cc4c7d9caada12767831bfd9738dd7b43:
powerpc: Don't
Hi list,
I am currently using a MPC8313 with an MMC slot on SPI bus.
My fsl is the following :
spi@7000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl,spi";
On Wed, 2011-09-28 at 14:23 -0700, Carl E. Love wrote:
> Ben, Paul:
>
> I posted this patch to lkml but did not copy the linuxppc-...@ozlabs.org
> mailing list.
Patch is also completely damaged. I'm fixing it up myself this time
around but by now you should know how to send patches correctly :
On Tue, 2011-09-27 at 20:05 +1000, Anton Blanchard wrote:
> Hi Jimi,
>
> > Some processors, like embedded, that already have a PID register that
> > is managed by the system. This patch separates the ACOP and PID
> > processing into separate files so that the ACOP code can be shared.
> >
> > Sig
37 matches
Mail list logo
