CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
breaking clear_pages(), probably others too.
This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems
depend on PPC_E500_V1_V2.
Cc: Kumar Gala
Signed-off-by: Baruch Siach
---
Changes from v3:
The get_phy_id() routine (called via fsl_pq_mdio_find_free()) tries to acquire
the mdio_lock mutex which is only initialized when of_mdiobus_register() gets
called later. This causes the following oops:
Unable to handle kernel paging request for data at address 0x
Faulting instruction addr
On 11/07/11 20:43, Josh Poimboeuf wrote:
On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
On 11/03/11 05:06, Josh Poimboeuf wrote:
On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
@@ -137,6 +137,9 @@ get_type:
lwz r0, 8(r9) /* r_addend */
add r0,
On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> On 11/06/2011 10:47 PM, Ananth N Mavinakayanahalli wrote:
> > The Processor Identification Register (PIR) on powerpc provides
> > information to decode the processor identification tag. Decoding
> > this information platform specfic.
> >
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, November 08, 2011 2:44 AM
> To: Zang Roy-R61911
> Cc: 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 02:32 AM, Roy Zang wrote:
> >
On Tue, 2011-11-08 at 15:21 +1100, Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> Me again :-) So yesterday you pulled my -next branch with the bulk of
> what happened since the last merge window up to when I left for my long
> vacation (5 weeks). Today are a few remaining nits that happened durin
Hi Linus !
Me again :-) So yesterday you pulled my -next branch with the bulk of
what happened since the last merge window up to when I left for my long
vacation (5 weeks). Today are a few remaining nits that happened during
that time.
Essentially small fixes, a defconfig bit, some janitorial stu
Add HV mode KVM to Book3 server 64bit defconfigs as a module.
Doesn't add much to the size:
textdata bss dechex filename
8244109 4686767 994000 13924876 d47a0c vmlinux.vanilla
8256092 4691607 994128 13941827 d4bc43 vmlinux.kvm
This should enable mor
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:
arch/powerpc/kvm/book3s_hv_rmhandlers.S:1388: Error: Unrecognized opcode:
`po
> -Original Message-
> From: Scott Wood [mailto:scottw...@freescale.com]
> Sent: Monday, November 07, 2011 5:14 PM
> To: Robert Sciuk
> Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org
> Subject: Re: fpga driver on custom PPC target platform (P4080) ...
>
...
> If
Recent binutils refuses to assemble AltiVec opcodes when in e500/SPE
mode, as some of those opcodes alias the "SPE" instructions. This
triggers an ancient binutils version check even when building a kernel
with CONFIG_ALTIVEC disabled.
In theory, the check could be conditionalized on CONFIG_ALTIV
kvm_rma_init() is only called at boot-time, by setup_arch, which is also __init.
Signed-off-by: Nishanth Aravamudan
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index d431203..73fdcc1 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/po
...
>
> switched-bank@2,0 {
> // no simple-bus here
> compatible = "something specific to your board's setup";
> ranges = <0 0 2 0 0x8000>;
>
> // reg is here just to make the unit-addres valid
> reg = <2 0 0>;
>
>
On 11/07/2011 02:09 PM, Robert Sciuk wrote:
> In my continuing saga of dev/tree driver development, I have a problem which
> might be obvious to those who have more experience in such matters.
>
> I'm a bit perplexed on the tree nodes for the localbus/simplebus
> nodes for my FPGA. CS0 is reserv
> -Original Message-
> From: Mitch Bradley [mailto:w...@firmworks.com]
>
> I would be tempted to add another level of hierarchy as a container for
> the two FPEs on CS2.
>
Hi, Mitch.
As a long time Forth(er), I'm somewhat honoured to have this exchange with you
8-)
Do you mean someth
On 11/7/2011 10:09 AM, Robert Sciuk wrote:
In my continuing saga of dev/tree driver development, I have a problem which
might be obvious to those who have more experience in such matters.
I'm a bit perplexed on the tree nodes for the localbus/simplebus nodes for my
FPGA. CS0 is reserved for b
On Mon, Nov 07, 2011 at 05:19:42PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Wed, 2 Nov 2011 18:30:12 -0700 Greg KH wrote:
> >
> > On Wed, Nov 02, 2011 at 12:13:09PM +1100, Stephen Rothwell wrote:
> > >
> > > On Thu, 27 Oct 2011 07:48:06 +0200 Greg KH wrote:
> > > >
> > > > On Thu, Oct 2
In my continuing saga of dev/tree driver development, I have a problem which
might be obvious to those who have more experience in such matters.
I'm a bit perplexed on the tree nodes for the localbus/simplebus nodes for my
FPGA. CS0 is reserved for booting (from NOR flash as required by our des
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,
>>> + mpc85xx_freqs,
>>> + target
> > Ah, my compatible attribute was wrong:
> >
> > Compatible = "nxp,pca9539";
> >
> > Should have been:
> >
> > Compatible = "nxp,pca953x";
> >
> > The tree now seems to bind the i2c gpio drivers properly ... on to
> > the localbus mappings!
>
> Ah. In that case the drivers should p
On 11/07/2011 02: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 PCIe.
Some extra commentary on why this works would
On 11/04/2011 07:08 PM, Tabi Timur-B04825 wrote:
> On Fri, Nov 4, 2011 at 7:39 AM, Zhao Chenhui
> wrote:
>> + /* clear to enable clock in low power mode */
>> + if (enable)
>> + clrbits32(&pmc_regs->pmcdr, *pmcdr_mask);
>> + else
>> + setbits32(&pmc_r
On Sat, 2011-11-05 at 11:55 +1100, Paul Mackerras wrote:
> On Thu, Nov 03, 2011 at 09:14:44AM -0400, John Stultz wrote:
> > On Thu, 2011-11-03 at 11:59 +1100, Anton Blanchard wrote:
> > > plain text document attachment (clock3)
> > > Use clocksource_register_hz which calculates the shift/mult
> > >
On 11/06/2011 10:47 PM, Ananth N Mavinakayanahalli wrote:
> The Processor Identification Register (PIR) on powerpc provides
> information to decode the processor identification tag. Decoding
> this information platform specfic.
>
> Export PIR data via sysfs.
>
> (Powerpc manuals state this regist
On 11/07/2011 05:22 AM, Zhao Chenhui wrote:
> On Fri, Nov 04, 2011 at 04:14:25PM -0500, Scott Wood wrote:
>> On 11/04/2011 07:39 AM, Zhao Chenhui wrote:
>>> + if (enable && !device_may_wakeup(&pdev->dev))
>>> + return -EINVAL;
>>> +
>>> + clk_np = of_parse_phandle(pdev->dev.of_node, "
> On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
> > On 11/03/11 05:06, Josh Poimboeuf wrote:
> > > On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
> > > @@ -137,6 +137,9 @@ get_type:
> > > lwz r0, 8(r9) /* r_addend */
> > > add r0, r0, r3
On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
> On 11/03/11 05:06, Josh Poimboeuf wrote:
> > On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
> > @@ -137,6 +137,9 @@ get_type:
> > lwz r0, 8(r9) /* r_addend */
> > add r0, r0, r3 /* final addend */
> >
Add a 5121-custom reject if an input-only pin is requested to be output
(see 18.3.1.1 in the refman). Also, rewrite mach-specific quirk setup to
consume less lines.
Signed-off-by: Wolfram Sang
---
drivers/gpio/gpio-mpc8xxx.c | 17 -
1 files changed, 12 insertions(+), 5 deletion
Hello All,
I am using ppc460ex based custom board.
using linux 2.6.30.2 kernel on this board it has ibm_newemac driver in it.
I am using this board as a iSCSI target which has RAID system behind it.
||
On Fri, Nov 04, 2011 at 04:14:25PM -0500, Scott Wood wrote:
> On 11/04/2011 07:39 AM, Zhao Chenhui wrote:
> > @@ -45,6 +46,72 @@ static int has_lossless;
> > * code can be compatible with both 32-bit & 36-bit */
> > extern void mpc85xx_enter_deep_sleep(u64 ccsrbar, u32 powmgtreq);
> >
> > +#if
On Fri, Nov 04, 2011 at 07:08:24PM -0500, Tabi Timur-B04825 wrote:
> On Fri, Nov 4, 2011 at 7:39 AM, Zhao Chenhui
> wrote:
>
> > + if (!pmc_regs) {
> > + printk(KERN_WARNING "PMC is unavailable\n");
>
> Use pr_warn() and the other pr_xxx functions.
>
> > + pmcdr_mask
Hi All,
Please find the version 4 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 Fri, Nov 04, 2011 at 02:42:54PM -0500, Scott Wood wrote:
> On 11/04/2011 07:36 AM, Zhao Chenhui wrote:
> > From: Li Yang
> >
> > Some 85xx silicons like MPC8536 and P1022 has the JOG PM feature.
> >
> > The patch adds the support to change CPU frequency using the standard
> > cpufreq interfac
Hi Ben,
On Mon, 07 Nov 2011 10:29:10 +1100 Benjamin Herrenschmidt
wrote:
>
> I've moved the powerpc git tree back to kernel.org. The URL should be
> back to normal for users:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
OK, I have switched back to that, now.
--
Cheers,
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
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
Below are codes for accessing usb sysif_regs in driver:
usb_sys_regs = (struct usb_sys_interface *)
((u32)dr_regs + USB_DR_SYS_OFFSET);
these codes work in 32-bit, but in 64-bit, use u32 to type cast the address
of ioremap is not right, and accessing members of 'usb_sys_regs' will cause
c
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 v3:
- Modified the documentation to reflect i
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
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
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
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
45 matches
Mail list logo
