headers
Xie Shaohui-B21989 | 1 Aug 2011 04:44
Favicon

RE: [PATCH] powerpc/85xx: fix memory controller compatible for edac

>From: Grant Likely [mailto:glikely <at> secretlab.ca] On Behalf Of Grant Likely
>Sent: Sunday, July 31, 2011 12:03 PM
>To: Xie Shaohui-B21989
>Cc: linuxppc-dev <at> lists.ozlabs.org; Gala Kumar-B11780; mm-
>commits <at> vger.kernel.org; avorontsov <at> mvista.com; davem <at> davemloft.net;
>akpm <at> linux-foundation.org
>Subject: Re: [PATCH] powerpc/85xx: fix memory controller compatible for
>edac
>
>On Tue, Jul 26, 2011 at 01:46:33PM +0800, Shaohui Xie wrote:
>> compatible in dts has been changed, so driver need to update accordingly.
>>
>> Signed-off-by: Shaohui Xie <Shaohui.Xie <at> freescale.com>
>> ---
>> apply for
>> http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
>> 'next' branch.
>>
>>  drivers/edac/mpc85xx_edac.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
>> index 13f6cc5..94c064a 100644
>> --- a/drivers/edac/mpc85xx_edac.c
>> +++ b/drivers/edac/mpc85xx_edac.c
>>  <at>  <at>  -1253,7 +1253,7  <at>  <at>  static struct of_device_id
>mpc85xx_mc_err_of_match[] = {
>>  	{ .compatible = "fsl,p1020-memory-controller", },
>>  	{ .compatible = "fsl,p1021-memory-controller", },
>>  	{ .compatible = "fsl,p2020-memory-controller", },
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gibson | 1 Aug 2011 04:48
Picon

Re: kvm PCI assignment & VFIO ramblings

On Sat, Jul 30, 2011 at 09:58:53AM +1000, Benjamin Herrenschmidt wrote:
[snip]
> That current hack won't work well if two devices share an iommu. Note
> that we have an additional constraint here due to our paravirt
> interfaces (specificed in PAPR) which is that PE domains must have a
> common parent. Basically, pHyp makes them look like a PCIe host bridge
> per domain in the guest. I think that's a pretty good idea and qemu
> might want to do the same.
> 
> - We hack out the currently unconditional mapping of the entire guest
> space in the iommu. Something will have to be done to "decide" whether
> to do that or not ... qemu argument -> ioctl ?

Not quite.  We already require the not-yet-upstream patches which add
guest-side (emulated) IOMMU support to qemu.  The approach we're using
for the passthrough (or at least will when I fix up my patches again)
is that we only map all guest ram into the vfio iommu if and only if
there is no guest visible iommu advertised in the qdev.

This kind of makes sense - if there is no iommu from the guest
perspective, the guest will expect to see all its physical memory 1:1
in DMA.

The hacky bit is that when there *is* a guest visible iommu, it's
assumed that whatever interface the guest iommu uses is somehow wired
up to vfio map/unmap calls.  For us at the moment, this means
passthrough devices for us must be assigned to a special (guest) pci
domain which sets up a suitable wires up the paravirt iommu to the vfio iommu.

In theory under some circumstances, with full emu, you could wire up
(Continue reading)

Permalink | Reply | 0 comments |
headers
Baruch Siach | 1 Aug 2011 06:59
Picon

Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC

Hi Scott,

On Thu, Jul 28, 2011 at 03:20:33PM -0500, Scott Wood wrote:
> On Thu, 28 Jul 2011 19:56:53 +0000
> Tabi Timur-B04825 <B04825 <at> freescale.com> wrote:
> 
> > On Sun, Jun 19, 2011 at 11:56 PM, Baruch Siach <baruch <at> tkos.co.il> wrote:
> > > CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
> > > breaking clear_pages(), probably others too.
> > >
> > > Cc: Kumar Gala <galak <at> kernel.crashing.org>
> > > Signed-off-by: Baruch Siach <baruch <at> tkos.co.il>
> > > ---
> > > Is this the right approach?
> > 
> > It doesn't work for me.
> > 
> > I need something that if an e500v2 platform (e.g. the P1022DS) is
> > selected, then I won't be able to select any e500mc platforms (e.g.
> > P4080DS).  And if I don't select any e500v2 platforms, then I will be
> > able to select an e500mc platform.  This patch doesn't seem to do
> > that.
> > 
> > It might be necessary to split the entire menu into two parts, one for
> > e500v2 parts and one for e500mc parts.
> 
> How about making the "Processor Type" entry be either E500 or E500MC, both
> of which select PPC_85xx?

Thanks for the tip. A patch along these lines follows.
(Continue reading)

Permalink | Reply | 140 comments |
headers
Baruch Siach | 1 Aug 2011 07:02
Picon

Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC

Hi Timur,

On Thu, Jul 28, 2011 at 03:02:21PM -0500, Timur Tabi wrote:
>  wrote:
> > On Sun, Jun 19, 2011 at 11:56 PM, Baruch Siach <baruch <at> tkos.co.il> wrote:
> >> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
> >> breaking clear_pages(), probably others too.
> >>
> >> Cc: Kumar Gala <galak <at> kernel.crashing.org>
> >> Signed-off-by: Baruch Siach <baruch <at> tkos.co.il>
> >> ---
> >> Is this the right approach?
> > 
> > It doesn't work for me.
> 
> I also get this error if I try to build corenet32_smp_defconfig:
> 
> arch/powerpc/platforms/Kconfig.cputype:136:error: recursive dependency detected!
> arch/powerpc/platforms/Kconfig.cputype:136:	symbol PPC_E500MC is selected by
> P2040_RDB
> arch/powerpc/platforms/85xx/Kconfig:176:	symbol P2040_RDB depends on PPC_E500MC

Thanks for reporting. Where can I get this corenet32_smp_defconfig for 
testing?

baruch

--

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
(Continue reading)

Permalink | Reply | 0 comments |
headers
Baruch Siach | 1 Aug 2011 07:12
Picon

[PATCH] powerpc: 85xx: separate e500 from e500mc

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.

Cc: Kumar Gala <galak <at> kernel.crashing.org>
Signed-off-by: Baruch Siach <baruch <at> tkos.co.il>
---

Sending again with the correct list address. Sorry for the noise.

 arch/powerpc/platforms/85xx/Kconfig    |   12 +++++++++---
 arch/powerpc/platforms/Kconfig.cputype |   27 +++++++++++++++------------
 2 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index b6976e1..9530fca 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
 <at>  <at>  -13,6 +13,8  <at>  <at>  if FSL_SOC_BOOKE

 if PPC32

+if PPC_E500
+
 config MPC8540_ADS
 	bool "Freescale MPC8540 ADS"
 	select DEFAULT_UIMAGE
 <at>  <at>  -155,10 +157,13  <at>  <at>  config SBC8560
(Continue reading)

Permalink | Reply | 138 comments |
headers
Anton Blanchard | 1 Aug 2011 07:27
Picon
Favicon

[PATCH] powerpc: Move kdump default base address to half RMO size on 64bit


We are seeing boot failures on some very large boxes even with
commit b5416ca9f824 (powerpc: Move kdump default base address to
64MB on 64bit).

This patch halves the RMO so both kernels get about the same
amount of RMO memory. On large machines this region will be
at least 256MB, so each kernel will get 128MB.

We cap it at 256MB (small SLB size) since some early allocations need
to be in the bolted SLB region. We could relax this on machines with
1TB SLBs in a future patch.

Signed-off-by: Anton Blanchard <anton <at> samba.org>
---

Index: linux-powerpc/arch/powerpc/include/asm/kdump.h
===================================================================
--- linux-powerpc.orig/arch/powerpc/include/asm/kdump.h	2011-07-26 11:11:35.583436932 +1000
+++ linux-powerpc/arch/powerpc/include/asm/kdump.h	2011-07-26 11:17:13.159317079 +1000
 <at>  <at>  -3,17 +3,7  <at>  <at> 

 #include <asm/page.h>

-/*
- * If CONFIG_RELOCATABLE is enabled we can place the kdump kernel anywhere.
- * To keep enough space in the RMO for the first stage kernel on 64bit, we
- * place it at 64MB. If CONFIG_RELOCATABLE is not enabled we must place
- * the second stage at 32MB.
- */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anton Blanchard | 1 Aug 2011 07:30
Picon
Favicon

[PATCH] powerpc: Lack! of! ibm,io-events! not! that! important!


The ibm,io-events code is a bit verbose with its error messages.
Reverse the reporting so we only print when we successfully enable
I/O event interrupts.

Signed-off-by: Anton Blanchard <anton <at> samba.org>
---

Index: linux-powerpc/arch/powerpc/platforms/pseries/io_event_irq.c
===================================================================
--- linux-powerpc.orig/arch/powerpc/platforms/pseries/io_event_irq.c	2011-07-26
08:50:11.291231586 +1000
+++ linux-powerpc/arch/powerpc/platforms/pseries/io_event_irq.c	2011-07-26
08:51:39.992772071 +1000
 <at>  <at>  -212,17 +212,15  <at>  <at>  static int __init ioei_init(void)
 	struct device_node *np;

 	ioei_check_exception_token = rtas_token("check-exception");
-	if (ioei_check_exception_token == RTAS_UNKNOWN_SERVICE) {
-		pr_warning("IO Event IRQ not supported on this system !\n");
+	if (ioei_check_exception_token == RTAS_UNKNOWN_SERVICE)
 		return -ENODEV;
-	}
+
 	np = of_find_node_by_path("/event-sources/ibm,io-events");
 	if (np) {
 		request_event_sources_irqs(np, ioei_interrupt, "IO_EVENT");
+		pr_info("IBM I/O event interrupts enabled\n");
 		of_node_put(np);
 	} else {
(Continue reading)

Permalink | Reply | 2 comments |
headers
Heiko Schocher | 1 Aug 2011 07:30
Picon
Picon
Favicon

Re: [PATCH v2 2/4] powerpc, mpc52xx: add a4m072 board support

Hello Grant,

Grant Likely wrote:
> On Wed, Jun 22, 2011 at 12:39:10PM +0200, Heiko Schocher wrote:
>> Signed-off-by: Heiko Schocher <hs <at> denx.de>
>> cc: Grant Likely <grant.likely <at> secretlab.ca>
>> cc: devicetree-discuss <at> ozlabs.org
>> cc: Wolfgang Denk <wd <at> denx.de>
>> cc: Wolfram Sang <w.sang <at> pengutronix.de>
>> ---
>> For this patchseries following patch is needed:
>>
>> http://patchwork.ozlabs.org/patch/91919/
>>
>> Grant? Do you have some comments on that patch?
>>
>> changes for v2:
>>   add comment from Wolfram Sang:
>>   use mpc5200.dtsi
>>
>>  arch/powerpc/boot/dts/a4m072.dts             |  172 ++++++++++++++++++++++++++
>>  arch/powerpc/platforms/52xx/mpc5200_simple.c |    1 +
>>  2 files changed, 173 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/powerpc/boot/dts/a4m072.dts
>>
>> diff --git a/arch/powerpc/boot/dts/a4m072.dts b/arch/powerpc/boot/dts/a4m072.dts
>> new file mode 100644
>> index 0000000..adb6746
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/a4m072.dts
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wizard | 1 Aug 2011 09:25
Picon

For Power Arch, the Exception Vector always locate at 0x0100-0x0FFF physical address?

Hi

I am not sure whether this is the right place for this question.

From the PEM, it says the physical area is reserved for the exception
vector, this is always true?
And how many vectors could it hold?

--

-- 
Wizard
Permalink | Reply | 0 comments |
headers
Peter Zijlstra | 1 Aug 2011 11:59
Favicon

Re: [PATCH] perf: powerpc: Disable pagefaults during callchain stack read

On Sat, 2011-07-30 at 14:53 -0600, David Ahern wrote:
> A page fault occurred walking the callchain while creating a perf
> sample for the context-switch event. To handle the page fault the
> mmap_sem is needed, but it is currently held by setup_arg_pages.
> (setup_arg_pages calls shift_arg_pages with the mmap_sem held.
> shift_arg_pages then calls move_page_tables which has a cond_resched
> at the top of its for loop - hitting that cond_resched is what caused
> the context switch.)
> 
> This is an extension of Anton's proposed patch:
> https://lkml.org/lkml/2011/7/24/151
> adding case for 32-bit ppc.
> 
> Tested on the system that first generated the panic and then again
> with latest kernel using a PPC VM. I am not able to test the 64-bit
> path - I do not have H/W for it and 64-bit PPC VMs (qemu on Intel)
> is horribly slow.
> 
> Signed-off-by: David Ahern <dsahern <at> gmail.com>
> CC: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
> CC: Anton Blanchard <anton <at> samba.org> 

Hmm, Paul, didn't you fix something like this early on? Anyway, I've no
objections since I'm really not familiar enough with the PPC side of
things.
Permalink | Reply | 0 comments |

Gmane