* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Steven Rostedt @ 2011-05-19 12:22 UTC (permalink / raw)
To: Will Drewry
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Ralf Baechle, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, James Morris, Linus Torvalds, Ingo Molnar,
linux-arm-kernel, Ingo Molnar, Serge E. Hallyn,
Martin Schwidefsky, Thomas Gleixner, kees.cook, Roland McGrath,
Michal Marek, Michal Simek, linuxppc-dev, linux-kernel,
Eric Paris, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <BANLkTikBK3-KZ10eErQ6Eex_L6Qe2aZang@mail.gmail.com>
On Wed, 2011-05-18 at 21:07 -0700, Will Drewry wrote:
> Do event_* that return non-void exist in the tree at all now? I've
> looked at the various tracepoint macros as well as some of the other
> handlers (trace_function, perf_tp_event, etc) and I'm not seeing any
> places where a return value is honored nor could be. At best, the
> perf_tp_event can be short-circuited it in the hlist_for_each, but
> it'd still need a way to bubble up a failure and result in not calling
> the trace/event that the hook precedes.
No, none of the current trace hooks have return values. That was what I
was talking about how to implement in my previous emails.
-- Steve
^ permalink raw reply
* RE: [PATCH] powerpc/85xx: add host-pci(e) bridge only for RC
From: Kushwaha Prabhakar-B32579 @ 2011-05-19 11:25 UTC (permalink / raw)
To: Kumar Gala
Cc: meet2prabhu@gmail.com, linuxppc-dev@lists.ozlabs.org,
Vivek Mahajan
In-Reply-To: <7E57A9FF-9BB3-4C5A-9965-E56A4E35B1B8@kernel.crashing.org>
Hello Kumar,
Please find my answer in-lined
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, May 19, 2011 11:55 AM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; meet2prabhu@gmail.com; Vivek Mahajan
> Subject: Re: [PATCH] powerpc/85xx: add host-pci(e) bridge only for RC
>=20
>=20
> On Apr 27, 2011, at 12:35 AM, Prabhakar Kushwaha wrote:
>=20
> > FSL PCIe controller can act as agent(EP) or host(RC).
> > Under Agent(EP) mode they are configured via Host. So it is not
> > required to add with the PCI(e) sub-system.
> >
> > Add and configure PCIe controller only for RC mode.
> >
> > Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
> > Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> > ---
> > Based upon
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(b
> > ranch master)
> >
> > arch/powerpc/sysdev/fsl_pci.c | 14 ++++++++++++++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > b/arch/powerpc/sysdev/fsl_pci.c index 68ca929..87ac11b 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > @@ -323,6 +323,7 @@ int __init fsl_add_bridge(struct device_node *dev,
> int is_primary)
> > struct pci_controller *hose;
> > struct resource rsrc;
> > const int *bus_range;
> > + u8 is_agent;
> >
> > if (!of_device_is_available(dev)) {
> > pr_warning("%s: disabled\n", dev->full_name); @@ -353,6
> +354,19 @@
> > int __init fsl_add_bridge(struct device_node *dev, int is_primary)
> >
> > setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
> > PPC_INDIRECT_TYPE_BIG_ENDIAN);
> > +
> > + early_read_config_byte(hose, 0, 0, PCI_HEADER_TYPE, &is_agent);
>=20
> Why are we looking at PCI_HEADER_TYPE? We should look at PCI_CLASS_PROG.
I think both are OK. We can check for any one.=20
Is there any problem with PCI_HEADER_TYPE?
> > + if ((is_agent & 0x7f) =3D=3D PCI_HEADER_TYPE_NORMAL) {
> > + u32 temp;
> > +
> > + temp =3D (u32)hose->cfg_data & ~PAGE_MASK;
> > + if (((u32)hose->cfg_data & PAGE_MASK) !=3D (u32)hose->cfg_addr)
> > + iounmap(hose->cfg_data - temp);
> > + iounmap(hose->cfg_addr);
> > + pcibios_free_controller(hose);
> > + return 0;
> > + }
> > +
> > setup_pci_cmd(hose);
> >
> > /* check PCI express link status */
> > --
> > 1.7.3
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* RE: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows for PM
From: Kushwaha Prabhakar-B32579 @ 2011-05-19 11:22 UTC (permalink / raw)
To: Kumar Gala
Cc: meet2prabhu@gmail.com, linuxppc-dev@lists.ozlabs.org,
Jiang Yutang-B14898
In-Reply-To: <3A8FAEED-7BD9-4776-85A9-560D07417BA8@kernel.crashing.org>
Hi Kumar,
Please find my answer in-lined
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, May 19, 2011 12:00 PM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-dev@lists.ozlabs.org; meet2prabhu@gmail.com; Jiang Yutang-
> B14898
> Subject: Re: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows for
> PM
>=20
>=20
> On Apr 28, 2011, at 1:38 AM, Prabhakar Kushwaha wrote:
>=20
> > D3-cold state indicates removal of the clock and power. however
> > auxiliary (AUX) Power may remain available even after the main power
> rails are powered down.
> >
> > wakeup from D3-cold state requires full context restore. Other things
> > are taken care in pci-driver except ATMUs.
> > ATMU windows needs to be saved and restored during suspend and resume.
> >
> > Signed-off-by: Jiang Yutang <b14898@freescale.com>
> > Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> > ---
> > Based upon
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(b
> > ranch master)
> >
> > arch/powerpc/sysdev/fsl_pci.c | 116
> +++++++++++++++++++++++++++++++++++++++++
> > arch/powerpc/sysdev/fsl_pci.h | 7 ++-
> > 2 files changed, 121 insertions(+), 2 deletions(-)
>=20
> Is this patch for when we are a host or agent?
This patch is independent of host or agent. It is for supporting D3 cold st=
ate for P1022.
These functions are called during System level suspend and resume.=20
--Prabhakar
^ permalink raw reply
* Re: [PATCH] [klibc] ppc64: Fix build failure with stricter as
From: maximilian attems @ 2011-05-19 11:20 UTC (permalink / raw)
To: Matthias Klose; +Cc: klibc, linuxppc-dev, Paul Mackerras
In-Reply-To: <1305726080-27589-1-git-send-email-max@stro.at>
On Wed, 18 May 2011, maximilian attems wrote:
> From: Matthias Klose <doko@ubuntu.com>
>
> Landed in Ubuntu klibc version 1.5.20-1ubuntu3.
>
>
> Signed-off-by: maximilian attems <max@stro.at>
> ---
> usr/klibc/arch/ppc64/crt0.S | 17 +++++++++--------
> 1 files changed, 9 insertions(+), 8 deletions(-)
>
thank you, merged in klibc git, will be in next 1.5.23.
--
maks
^ permalink raw reply
* [PATCH] Powerpc/fsl_lbc: Add workaround for ELBC-A001 erratum
From: Shengzhou Liu @ 2011-05-19 10:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, kumar.gala, Shengzhou Liu
Simultaneous FCM and GPCM or UPM operation may erroneously trigger
bus monitor timeout.
Set the local bus monitor timeout value to the maximum by setting
LBCR[BMT] = 0 and LBCR[BMTPS] = 0xF.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Gala Kumar <kumar.gala@freescale.com>
---
arch/powerpc/include/asm/fsl_lbc.h | 2 ++
arch/powerpc/sysdev/fsl_lbc.c | 9 +++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_lbc.h b/arch/powerpc/include/asm/fsl_lbc.h
index 5c1bf34..8a0b5ec 100644
--- a/arch/powerpc/include/asm/fsl_lbc.h
+++ b/arch/powerpc/include/asm/fsl_lbc.h
@@ -157,6 +157,8 @@ struct fsl_lbc_regs {
#define LBCR_EPAR_SHIFT 16
#define LBCR_BMT 0x0000FF00
#define LBCR_BMT_SHIFT 8
+#define LBCR_BMTPS 0x0000000F
+#define LBCR_BMTPS_SHIFT 0
#define LBCR_INIT 0x00040000
__be32 lcrr; /**< Clock Ratio Register */
#define LCRR_DBYP 0x80000000
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index 4fcb5a4..19a4ecd 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -184,7 +184,8 @@ int fsl_upm_run_pattern(struct fsl_upm *upm, void __iomem *io_base, u32 mar)
}
EXPORT_SYMBOL(fsl_upm_run_pattern);
-static int __devinit fsl_lbc_ctrl_init(struct fsl_lbc_ctrl *ctrl)
+static int __devinit fsl_lbc_ctrl_init(struct fsl_lbc_ctrl *ctrl,
+ struct device_node *node)
{
struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
@@ -198,6 +199,10 @@ static int __devinit fsl_lbc_ctrl_init(struct fsl_lbc_ctrl *ctrl)
/* Enable interrupts for any detected events */
out_be32(&lbc->lteir, LTEIR_ENABLE);
+ /* Set the monitor timeout value to the maximum for erratum A001 */
+ if (of_device_is_compatible(node, "fsl,elbc"))
+ clrsetbits_be32(&lbc->lbcr, LBCR_BMT, LBCR_BMTPS);
+
return 0;
}
@@ -304,7 +309,7 @@ static int __devinit fsl_lbc_ctrl_probe(struct platform_device *dev)
fsl_lbc_ctrl_dev->dev = &dev->dev;
- ret = fsl_lbc_ctrl_init(fsl_lbc_ctrl_dev);
+ ret = fsl_lbc_ctrl_init(fsl_lbc_ctrl_dev, ofdev->node);
if (ret < 0)
goto err;
--
1.6.4
^ permalink raw reply related
* Re: [PATCH 1/7] [RFC] Mainline BG/P platform support
From: Josh Boyer @ 2011-05-19 11:01 UTC (permalink / raw)
To: Eric Van Hensbergen; +Cc: linuxppc-dev, linux-kernel, bg-linux
In-Reply-To: <1305753895-24845-1-git-send-email-ericvh@gmail.com>
On Wed, May 18, 2011 at 04:24:49PM -0500, Eric Van Hensbergen wrote:
>The Linux kernel patches for the IBM BlueGene/P have been open-sourced
>for quite some time, but haven't been integrated into the mainline Linux
>kernel source tree. This is the first patch series of several where I
>will attempt to cleanup and mainline the already public patches. I
>welcome feedback as well as any help I can get. I'm drawing on
>the patches available for the IBM Compute Node kernel, the ZeptoOS project
>and the Kittyhawk project.
>(all available from http://wiki.bg.anl-external.org)
>
>I'll be prioritizing core patches which are harder to keep current with
>mainline due to merge conflicts and then slowly incorporating the drivers
>and other extensions (if acceptable after community review).
>
>I'll be maintaining the patchset in my kernel.org repository
>(/pub/scm/linux/kernel/git/ericvh/bluegene.git) under the bluegene
>branch with the source repos (zepto, kittyhawk, ibmcn) available in
>respective branches. Ben - if you would prefer me to send pull requests
>once we get rolling, I can switch to that -- otherwise I'll stick to
>just submitting patches to the list assuming you'll pull them when they
>become acceptable. Thanks for your attention reviewing these patches.
This is going to get slightly messy if there are lots of changes in
platforms/44x and/or head_44x.S. Most 4xx changes go through my tree,
and I'm happy to pull from your tree once things get off the ground. We
just need to make sure and coordinate as we go.
My tree is fairly low-churn (as is all of 4xx) so hopefully I'm worried
for nothing.
>Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
>---
> MAINTAINERS | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 69f19f1..3ffca88 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -3863,6 +3863,14 @@ S: Maintained
> F: arch/powerpc/platforms/40x/
> F: arch/powerpc/platforms/44x/
>
>+LINUX FOR POWERPC BLUEGENE/P
>+M: Eric Van Hensbergen <ericvh@gmail.com>
>+W: http://bg-linux.anl-external.org/wiki/index.php/Main_Page
>+L: bg-linux@lists.anl-external.org
>+T: git git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/bluegene.git
>+S: Maintained
>+F: arch/powerpc/platforms/44x/bgp*
This should probably be the last patch in the series. You have a file
pattern listed for files that don't exist at all in any of the other
patches you submitted :).
josh
^ permalink raw reply
* Re: [PATCH 4/7] [RFC] enable L1_WRITETHROUGH mode for BG/P
From: Josh Boyer @ 2011-05-19 10:43 UTC (permalink / raw)
To: Eric Van Hensbergen; +Cc: linuxppc-dev, linux-kernel, bg-linux
In-Reply-To: <1305753895-24845-4-git-send-email-ericvh@gmail.com>
On Wed, May 18, 2011 at 04:24:52PM -0500, Eric Van Hensbergen wrote:
>BG/P nodes need to be configured for writethrough to work in SMP
>configurations. This patch adds the right hooks in the MMU code
>to make sure L1_WRITETHROUGH configurations are setup for BG/P.
>
>Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
>---
> arch/powerpc/include/asm/mmu-44x.h | 2 ++
> arch/powerpc/kernel/head_44x.S | 24 ++++++++++++++++++++++--
> arch/powerpc/kernel/misc_32.S | 15 +++++++++++++++
> arch/powerpc/lib/copy_32.S | 10 ++++++++++
> arch/powerpc/mm/44x_mmu.c | 7 +++++--
> arch/powerpc/platforms/Kconfig | 5 +++++
> arch/powerpc/platforms/Kconfig.cputype | 4 ++++
> 7 files changed, 63 insertions(+), 4 deletions(-)
>
>diff --git a/arch/powerpc/include/asm/mmu-44x.h b/arch/powerpc/include/asm/mmu-44x.h
>index bf52d70..ca1b90c 100644
>--- a/arch/powerpc/include/asm/mmu-44x.h
>+++ b/arch/powerpc/include/asm/mmu-44x.h
>@@ -8,6 +8,7 @@
>
> #define PPC44x_MMUCR_TID 0x000000ff
> #define PPC44x_MMUCR_STS 0x00010000
>+#define PPC44x_MMUCR_U2 0x00200000
>
> #define PPC44x_TLB_PAGEID 0
> #define PPC44x_TLB_XLAT 1
>@@ -32,6 +33,7 @@
>
> /* Storage attribute and access control fields */
> #define PPC44x_TLB_ATTR_MASK 0x0000ff80
>+#define PPC44x_TLB_WL1 0x00100000 /* Write-through L1 */
> #define PPC44x_TLB_U0 0x00008000 /* User 0 */
> #define PPC44x_TLB_U1 0x00004000 /* User 1 */
> #define PPC44x_TLB_U2 0x00002000 /* User 2 */
>diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
>index 5e12b74..1f7ae60 100644
>--- a/arch/powerpc/kernel/head_44x.S
>+++ b/arch/powerpc/kernel/head_44x.S
>@@ -429,7 +429,16 @@ finish_tlb_load_44x:
> andi. r10,r12,_PAGE_USER /* User page ? */
> beq 1f /* nope, leave U bits empty */
> rlwimi r11,r11,3,26,28 /* yes, copy S bits to U */
>-1: tlbwe r11,r13,PPC44x_TLB_ATTRIB /* Write ATTRIB */
>+1:
>+#ifdef CONFIG_L1_WRITETHROUGH
>+ andi. r10, r11, PPC44x_TLB_I
>+ bne 2f
>+ oris r11,r11,PPC44x_TLB_WL1@h /* Add coherency for */
>+ /* non-inhibited */
>+ ori r11,r11,PPC44x_TLB_U2|PPC44x_TLB_M
>+2:
>+#endif /* CONFIG_L1_WRITETHROUGH */
>+ tlbwe r11,r13,PPC44x_TLB_ATTRIB /* Write ATTRIB */
>
> /* Done...restore registers and get out of here.
> */
>@@ -799,7 +808,11 @@ skpinv: addi r4,r4,1 /* Increment */
> sync
>
> /* Initialize MMUCR */
>+#ifdef CONFIG_L1_WRITETHROUGH
>+ lis r5, PPC44x_MMUCR_U2@h
>+#else
> li r5,0
>+#endif /* CONFIG_L1_WRITETHROUGH */
> mtspr SPRN_MMUCR,r5
> sync
>
>@@ -814,7 +827,14 @@ skpinv: addi r4,r4,1 /* Increment */
> /* attrib fields */
> /* Added guarded bit to protect against speculative loads/stores */
> li r5,0
>- ori r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G)
>+#ifdef CONFIG_L1_WRITETHROUGH
>+ ori r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | \
>+ PPC44x_TLB_G | PPC44x_TLB_U2)
>+ oris r5,r5,PPC44x_TLB_WL1@h
>+#else
>+ ori r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | \
>+ PPC44x_TLB_G)
>+#endif /* CONFIG_L1_WRITETHROUGH
>
> li r0,63 /* TLB slot 63 */
>
>diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
>index 094bd98..d88369b 100644
>--- a/arch/powerpc/kernel/misc_32.S
>+++ b/arch/powerpc/kernel/misc_32.S
>@@ -506,7 +506,20 @@ _GLOBAL(clear_pages)
> li r0,PAGE_SIZE/L1_CACHE_BYTES
> slw r0,r0,r4
> mtctr r0
>+#ifdef CONFIG_L1_WRITETHROUGH
>+ /* assuming 32 byte cacheline */
>+ li r4, 0
>+1: stw r4, 0(r3)
>+ stw r4, 4(r3)
>+ stw r4, 8(r3)
>+ stw r4, 12(r3)
>+ stw r4, 16(r3)
>+ stw r4, 20(r3)
>+ stw r4, 24(r3)
>+ stw r4, 28(r3)
>+#else
> 1: dcbz 0,r3
>+#endif /* CONFIG_L1_WRITETHROUGH */
> addi r3,r3,L1_CACHE_BYTES
> bdnz 1b
> blr
>@@ -550,7 +563,9 @@ _GLOBAL(copy_page)
> mtctr r0
> 1:
> dcbt r11,r4
>+#ifndef CONFIG_L1_WRITETHROUGH
> dcbz r5,r3
>+#endif
> COPY_16_BYTES
> #if L1_CACHE_BYTES >= 32
> COPY_16_BYTES
>diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
>index 55f19f9..98a07e3 100644
>--- a/arch/powerpc/lib/copy_32.S
>+++ b/arch/powerpc/lib/copy_32.S
>@@ -98,7 +98,11 @@ _GLOBAL(cacheable_memzero)
> bdnz 4b
> 3: mtctr r9
> li r7,4
>+#ifdef CONFIG_L1_WRITETHROUGH
>+10:
>+#else
> 10: dcbz r7,r6
>+#endif /* CONFIG_L1_WRITETHROUGH */
> addi r6,r6,CACHELINE_BYTES
> bdnz 10b
> clrlwi r5,r8,32-LG_CACHELINE_BYTES
>@@ -187,7 +191,9 @@ _GLOBAL(cacheable_memcpy)
> mtctr r0
> beq 63f
> 53:
>+#ifndef CONFIG_L1_WRITETHROUGH
> dcbz r11,r6
>+#endif /* CONFIG_L1_WRITETHROUGH */
> COPY_16_BYTES
> #if L1_CACHE_BYTES >= 32
> COPY_16_BYTES
>@@ -368,7 +374,11 @@ _GLOBAL(__copy_tofrom_user)
> mtctr r8
>
> 53: dcbt r3,r4
>+#ifdef CONFIG_L1_WRITETHROUGH
>+54:
>+#else
> 54: dcbz r11,r6
>+#endif
> .section __ex_table,"a"
> .align 2
> .long 54b,105f
>diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
>index 024acab..b684c8a 100644
>--- a/arch/powerpc/mm/44x_mmu.c
>+++ b/arch/powerpc/mm/44x_mmu.c
>@@ -80,9 +80,12 @@ static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys)
> :
> #ifdef CONFIG_PPC47x
> : "r" (PPC47x_TLB2_S_RWX),
>-#else
>+#elseif CONFIG_L1_WRITETHROUGH
>+ : "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_WL1 \
>+ | PPC44x_TLB_U2 | PPC44x_TLB_M),
>+#else /* neither CONFIG_PPC47x or CONFIG_L1_WRITETHROUGH */
> : "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
>-#endif
>+#endif /* CONFIG_PPC47x */
> "r" (phys),
> "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
> "r" (entry),
>diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
>index f7b0772..684a281 100644
>--- a/arch/powerpc/platforms/Kconfig
>+++ b/arch/powerpc/platforms/Kconfig
>@@ -348,4 +348,9 @@ config XILINX_PCI
> bool "Xilinx PCI host bridge support"
> depends on PCI && XILINX_VIRTEX
>
>+config L1_WRITETHROUGH
>+ bool "Blue Gene/P enabled writethrough mode"
>+ depends on BGP
>+ default y
You add this config option here, named generically, but then make it
depend on BGP. It sees it should be named BGP_L1_WRITETHROUGH, and then
just selected by the BGP platform. But then....
> endmenu
>diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
>index 111138c..3a3c711 100644
>--- a/arch/powerpc/platforms/Kconfig.cputype
>+++ b/arch/powerpc/platforms/Kconfig.cputype
>@@ -329,9 +329,13 @@ config NOT_COHERENT_CACHE
> bool
> depends on 4xx || 8xx || E200 || PPC_MPC512x || GAMECUBE_COMMON
> default n if PPC_47x
>+ default n if BGP
> default y
>
> config CHECK_CACHE_COHERENCY
> bool
>
>+config L1_WRITETHROUGH
>+ bool
You add an identical option down here. Confused.
josh
^ permalink raw reply
* Re: [PATCH v2 5/7] mmc: sdhci: consolidate sdhci-of-esdhc and sdhci-esdhc-imx
From: Wolfram Sang @ 2011-05-19 9:48 UTC (permalink / raw)
To: Shawn Guo
Cc: Chris Ball, sameo, Arnd Bergmann, patches, devicetree-discuss,
linux-mmc, Saeed Bishara, Xiaobo Xie, kernel, Mike Rapoport,
Olof Johansson, Anton Vorontsov, linuxppc-dev, Albert Herranz,
linux-arm-kernel
In-Reply-To: <1304601778-13837-6-git-send-email-shawn.guo@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
> +config MMC_SDHCI_ESDHC
> + bool
> + depends on MMC_SDHCI
> + select MMC_SDHCI_PLTFM
> + help
> + This selects SDHCI driver for Freescale eSDHC controller.
bool is not a good choice here, because if ESDHC_IMX is selected as a
module (-m), it will get converted here to built-in (-y). Same goes for
MMC_SDHCI_PLTFM. If I change both into tristate and then compile, I get
a build error:
ERROR: "sdhci_pltfm_suspend" [drivers/mmc/host/sdhci-esdhc.ko] undefined!
ERROR: "sdhci_get_of_property" [drivers/mmc/host/sdhci-esdhc.ko] undefined!
ERROR: "sdhci_pltfm_init" [drivers/mmc/host/sdhci-esdhc.ko] undefined!
ERROR: "sdhci_pltfm_free" [drivers/mmc/host/sdhci-esdhc.ko] undefined!
So, the module-support seems to be missing for the library.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/7] Consolidate sdhci pltfm & OF drivers and get them self registered
From: Wolfram Sang @ 2011-05-19 9:40 UTC (permalink / raw)
To: Shawn Guo
Cc: Chris Ball, sameo, Arnd Bergmann, patches, devicetree-discuss,
linux-mmc, Saeed Bishara, Xiaobo Xie, kernel, Mike Rapoport,
Olof Johansson, Anton Vorontsov, linuxppc-dev, Albert Herranz,
linux-arm-kernel
In-Reply-To: <1304601778-13837-1-git-send-email-shawn.guo@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
Hi Shawn,
> Changes since v1:
> * Rebase on cjb's mmc-next tree
Is it maybe possible that you get access to
http://opensource.freescale.com/git or another machine? A branch to pull
from would be more convenient, because the series does not apply to
mmc-next anymore, so an extra step to go "back in time" is needed.
(minor) When applying I got:
Applying: mmc: sdhci: make sdhci-pltfm device drivers self registered
/home/wsa/Kernel/linux-2.6/.git/rebase-apply/patch:384: trailing whitespace.
/home/wsa/Kernel/linux-2.6/.git/rebase-apply/patch:817: space before tab in indent.
struct tegra_sdhci_platform_data *plat;
/home/wsa/Kernel/linux-2.6/.git/rebase-apply/patch:867: trailing whitespace.
Applying: sdhci: rename sdhci-esdhc-imx.c to sdhci-esdhc.c
/home/wsa/Kernel/linux-2.6/.git/rebase-apply/patch:780: trailing whitespace.
See later comments for further issues.
Thanks,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 01/13] powerpc/e500: Save SPEFCSR in flush_spe_to_thread()
From: Alexander Graf @ 2011-05-19 9:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, kvm-ppc
In-Reply-To: <DC207279-54AC-41CC-BF21-25181D16A6AB@kernel.crashing.org>
On 05/19/2011 08:04 AM, Kumar Gala wrote:
> On May 17, 2011, at 6:35 PM, Scott Wood wrote:
>
>> From: yu liu<yu.liu@freescale.com>
>>
>> giveup_spe() saves the SPE state which is protected by MSR[SPE].
>> However, modifying SPEFSCR does not trap when MSR[SPE]=0.
>> And since SPEFSCR is already saved/restored in _switch(),
>> not all the callers want to save SPEFSCR again.
>> Thus, saving SPEFSCR should not belong to giveup_spe().
>>
>> This patch moves SPEFSCR saving to flush_spe_to_thread(),
>> and cleans up the caller that needs to save SPEFSCR accordingly.
>>
>> Signed-off-by: Liu Yu<yu.liu@freescale.com>
>> Signed-off-by: Scott Wood<scottwood@freescale.com>
>> ---
>> This is a resending of http://patchwork.ozlabs.org/patch/88677/
>>
>> Kumar, please ack to go via kvm. This is holding up the rest of the SPE
>> patches, which in turn are holding up the MMU patches due to both
>> touching the MSR update code.
>>
>> arch/powerpc/kernel/head_fsl_booke.S | 2 --
>> arch/powerpc/kernel/process.c | 1 +
>> arch/powerpc/kernel/traps.c | 5 +----
>> 3 files changed, 2 insertions(+), 6 deletions(-)
> Acked-by: Kumar Gala<galak@kernel.crashing.org>
>
> [ Alex, let me know if you want this via my powerpc.git tree or your kvm tree ]
I'll take them :). Thanks!
Alex
^ permalink raw reply
* RE: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic
From: David Laight @ 2011-05-19 8:35 UTC (permalink / raw)
To: James Bottomley, Hitoshi Mitake
Cc: linux-arch, Prakash, Sathya, Roland Dreier, Desai, Kashyap,
linux scsi dev, Matthew Wilcox, linux pci, linux powerpc dev,
Milton Miller, linux kernel, Sam Ravnborg, Ingo Molnar, paulus,
Ingo Molnar, Moore, Eric
In-Reply-To: <1305780360.2576.20.camel@mulgrave.site>
=20
> The specific mpt2sas problem is that if we write a 64 bit register non
> atomically, we can't allow any interleaving writes for any other
region
> on the chip, otherwise the HW will take the write as complete in the
64
> bit register and latch the wrong value. The only way to achieve that
> given the semantics of writeq is a global static spinlock.
That sounds like very specific and slightly dodgy hardware.
You don't say what the scope of 'region on the chip' is, but
it looks like you need to disable ALL writes to the memory
area between the first and second writes of the 64bit value
and not just those coming from writeq().
I don't see how this can possibly be done by normal mutexing
around the writeq() sequence, surely you need to lock the bus
between the two transfers.
Even dma writes would be a problem.
The only way I can think to stop other cpus doing writes
is to use IPIs for force them into a busy wait loop.
All rather reminds me of a PCI slave that got things
horribly wrong when a read was done while a write was
still 'posted', or a 2nd master did a cycle did a read
while a read rerun sequence was still in progress.
(required a mutex and dummy cycles).
At least than one wqs confined to one driver.
David
^ permalink raw reply
* Re: [PATCH 5/8] powerpc: override dma_get_required_mask by platform hook and ops
From: Benjamin Herrenschmidt @ 2011-05-19 7:43 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: cbe-oss-dev, FUJITA Tomonori, Arnd Bergmann, Sonny Rao,
devicetree-discuss, linux-kernel, Milton Miller, Paul Mackerras,
Anton Blanchard, Will Schmidt, Andrew Morton, linuxppc-dev
In-Reply-To: <1305152704-4864-6-git-send-email-nacc@us.ibm.com>
On Wed, 2011-05-11 at 15:25 -0700, Nishanth Aravamudan wrote:
> From: Milton Miller <miltonm@bga.com>
>
> The hook dma_get_required_mask is supposed to return the mask required
> by the platform to operate efficently. The generic version of
> dma_get_required_mask in driver/base/platform.c returns a mask based
> only on max_pfn. However, this is likely too big for iommu systems
> and could be too small for platforms that require a dma offset or have
> a secondary window at a high offset.
The result of those 3 patches doesn't build on top of my current tree,
the generic dma_ops lacks the dma_get_required_mask hook. I'll have a
look again after the merge window.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 19/37] powerpc: consolidate ipi message mux and demux
From: Benjamin Herrenschmidt @ 2011-05-19 6:58 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <1305788222.7481.46.camel@pasglop>
On Thu, 2011-05-19 at 16:57 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2011-05-11 at 00:29 -0500, Milton Miller wrote:
> > Consolidate the mux and demux of ipi messages into smp.c and call
> > a new smp_ops callback to actually trigger the ipi.
>
> .../...
>
> I'm merging the whole series. I had to do some fixups to this one and
> the one adding the CONFIG option, missing cell & wsp bits among others,
> but mostly trivial.
I forgot to mention... I dropped the change to include/linux/smp.h to
remove the unused MSG_ flags for now. It will not have been in -next
long enough to hit Linus via my tree, just in case somebody started
using the flags while we were not looking :-)
I suggest you send it to Linus directly after he pulls my tree during
the merge window.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 19/37] powerpc: consolidate ipi message mux and demux
From: Benjamin Herrenschmidt @ 2011-05-19 6:57 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <b9e2ff2d16e4647af0047ddbf6146b6c7433ce6c.1305092637.git.miltonm@bga.com>
On Wed, 2011-05-11 at 00:29 -0500, Milton Miller wrote:
> Consolidate the mux and demux of ipi messages into smp.c and call
> a new smp_ops callback to actually trigger the ipi.
.../...
I'm merging the whole series. I had to do some fixups to this one and
the one adding the CONFIG option, missing cell & wsp bits among others,
but mostly trivial.
Cheers,
Ben.
^ permalink raw reply
* Re: [linuxppc-dev] [PATCH][upstream] powerpc:Integrated Flash controller device tree bindings
From: Kumar Gala @ 2011-05-19 6:41 UTC (permalink / raw)
To: Dipen Dudhat; +Cc: linuxppc-dev, devicetree-discuss, linuxppc-dev
In-Reply-To: <1305787103-25105-1-git-send-email-Dipen.Dudhat@freescale.com>
On May 19, 2011, at 1:38 AM, Dipen Dudhat wrote:
> Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
> Acked-By: Scott Wood <scottwood@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =
(branch -> master)
> .../devicetree/bindings/powerpc/fsl/ifc.txt | 76 =
++++++++++++++++++++
> 1 files changed, 76 insertions(+), 0 deletions(-)
> create mode 100644 =
Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
applied to next
- k=
^ permalink raw reply
* [PATCH][upstream] powerpc:Integrated Flash controller device tree bindings
From: Dipen Dudhat @ 2011-05-19 6:38 UTC (permalink / raw)
To: devicetree-discuss, linuxppc-dev; +Cc: linuxppc-dev
Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
Acked-By: Scott Wood <scottwood@freescale.com>
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch -> master)
.../devicetree/bindings/powerpc/fsl/ifc.txt | 76 ++++++++++++++++++++
1 files changed, 76 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
new file mode 100644
index 0000000..939a26d
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
@@ -0,0 +1,76 @@
+Integrated Flash Controller
+
+Properties:
+- name : Should be ifc
+- compatible : should contain "fsl,ifc". The version of the integrated
+ flash controller can be found in the IFC_REV register at
+ offset zero.
+
+- #address-cells : Should be either two or three. The first cell is the
+ chipselect number, and the remaining cells are the
+ offset into the chipselect.
+- #size-cells : Either one or two, depending on how large each chipselect
+ can be.
+- reg : Offset and length of the register set for the device
+- interrupts : IFC has two interrupts. The first one is the "common"
+ interrupt(CM_EVTER_STAT), and second is the NAND interrupt
+ (NAND_EVTER_STAT).
+
+- ranges : Each range corresponds to a single chipselect, and covers
+ the entire access window as configured.
+
+Child device nodes describe the devices connected to IFC such as NOR (e.g.
+cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices
+like FPGAs, CPLDs, etc.
+
+Example:
+
+ ifc@ffe1e000 {
+ compatible = "fsl,ifc", "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x0 0xffe1e000 0 0x2000>;
+ interrupts = <16 2 19 2>;
+
+ /* NOR, NAND Flashes and CPLD on board */
+ ranges = <0x0 0x0 0x0 0xee000000 0x02000000
+ 0x1 0x0 0x0 0xffa00000 0x00010000
+ 0x3 0x0 0x0 0xffb00000 0x00020000>;
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x2000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ /* 32MB for user data */
+ reg = <0x0 0x02000000>;
+ label = "NOR Data";
+ };
+ };
+
+ flash@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x1 0x0 0x10000>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg = <0x0 0x00100000>;
+ label = "NAND U-Boot Image";
+ read-only;
+ };
+ };
+
+ cpld@3,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,p1010rdb-cpld";
+ reg = <0x3 0x0 0x000001f>;
+ };
+ };
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] powerpc/qoriq: Add default mode for P1020RDB USB
From: Kumar Gala @ 2011-05-19 6:37 UTC (permalink / raw)
To: Ramneek Mehresh; +Cc: paulus, linuxppc-dev
In-Reply-To: <1304515616-3413-1-git-send-email-ramneek.mehresh@freescale.com>
On May 4, 2011, at 8:26 AM, Ramneek Mehresh wrote:
> Add P1020 USB controller default value for "dr_mode" property
>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> ---
> Applies on git://git.am.freescale.net/mirrors/linux-2.6.git
> (branch master)
> arch/powerpc/boot/dts/p1020rdb.dts | 10 ++++------
> 1 files changed, 4 insertions(+), 6 deletions(-)
Can you update the patch. Also make sure to update the p1020rdb_camp* .dts
Against git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next
thanks
- k
^ permalink raw reply
* Re: [PATCH] powerpc/85xx:Create dts of each core in CAMP mode for P1020RDB
From: Kumar Gala @ 2011-05-19 6:33 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: meet2prabhu, devicetree-discuss, linuxppc-dev
In-Reply-To: <1303974000-2943-1-git-send-email-prabhakar@freescale.com>
On Apr 28, 2011, at 2:00 AM, Prabhakar Kushwaha wrote:
> Create the dts files for each core and splits the devices between the =
two cores
> for P1020RDB.
>=20
> Core0 has core0 to have memory, l2, i2c, spi, gpio, tdm, dma, usb, =
eth1, eth2,
> sdhc, crypto, global-util, message, pci0, pci1, msi.
> Core1 has l2, eth0, crypto.
>=20
> MPIC is shared between two cores but each core will protect its =
interrupts from
> other core by using "protected-sources" of mpic.
>=20
> Fix compatible property for global-util node of P1020si.dtsi.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branc=
h master)
>=20
> This patch depends on following patch
> "powerpc/85xx: P1020 DTS : re-organize dts files"
>=20
> arch/powerpc/boot/dts/p1020rdb_camp_core0.dts | 213 =
+++++++++++++++++++++++++
> arch/powerpc/boot/dts/p1020rdb_camp_core1.dts | 148 +++++++++++++++++
> arch/powerpc/boot/dts/p1020si.dtsi | 2 +-
> 3 files changed, 362 insertions(+), 1 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
> create mode 100644 arch/powerpc/boot/dts/p1020rdb_camp_core1.dts
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Save and restore pcie ATMU windows for PM
From: Kumar Gala @ 2011-05-19 6:30 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: meet2prabhu, linuxppc-dev, Jiang Yutang
In-Reply-To: <1303972729-32242-1-git-send-email-prabhakar@freescale.com>
On Apr 28, 2011, at 1:38 AM, Prabhakar Kushwaha wrote:
> D3-cold state indicates removal of the clock and power. however =
auxiliary (AUX)
> Power may remain available even after the main power rails are powered =
down.
>=20
> wakeup from D3-cold state requires full context restore. Other things =
are taken
> care in pci-driver except ATMUs.
> ATMU windows needs to be saved and restored during suspend and resume.
>=20
> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branc=
h master)
>=20
> arch/powerpc/sysdev/fsl_pci.c | 116 =
+++++++++++++++++++++++++++++++++++++++++
> arch/powerpc/sysdev/fsl_pci.h | 7 ++-
> 2 files changed, 121 insertions(+), 2 deletions(-)
Is this patch for when we are a host or agent?
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: add host-pci(e) bridge only for RC
From: Kumar Gala @ 2011-05-19 6:25 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: meet2prabhu, linuxppc-dev, Vivek Mahajan
In-Reply-To: <1303882532-25615-1-git-send-email-prabhakar@freescale.com>
On Apr 27, 2011, at 12:35 AM, Prabhakar Kushwaha wrote:
> FSL PCIe controller can act as agent(EP) or host(RC).
> Under Agent(EP) mode they are configured via Host. So it is not =
required to add
> with the PCI(e) sub-system.
>=20
> Add and configure PCIe controller only for RC mode.
>=20
> Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branc=
h master)
>=20
> arch/powerpc/sysdev/fsl_pci.c | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/sysdev/fsl_pci.c =
b/arch/powerpc/sysdev/fsl_pci.c
> index 68ca929..87ac11b 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -323,6 +323,7 @@ int __init fsl_add_bridge(struct device_node *dev, =
int is_primary)
> struct pci_controller *hose;
> struct resource rsrc;
> const int *bus_range;
> + u8 is_agent;
>=20
> if (!of_device_is_available(dev)) {
> pr_warning("%s: disabled\n", dev->full_name);
> @@ -353,6 +354,19 @@ int __init fsl_add_bridge(struct device_node =
*dev, int is_primary)
>=20
> setup_indirect_pci(hose, rsrc.start, rsrc.start + 0x4,
> PPC_INDIRECT_TYPE_BIG_ENDIAN);
> +
> + early_read_config_byte(hose, 0, 0, PCI_HEADER_TYPE, &is_agent);
Why are we looking at PCI_HEADER_TYPE? We should look at =
PCI_CLASS_PROG.
> + if ((is_agent & 0x7f) =3D=3D PCI_HEADER_TYPE_NORMAL) {
> + u32 temp;
> +
> + temp =3D (u32)hose->cfg_data & ~PAGE_MASK;
> + if (((u32)hose->cfg_data & PAGE_MASK) !=3D =
(u32)hose->cfg_addr)
> + iounmap(hose->cfg_data - temp);
> + iounmap(hose->cfg_addr);
> + pcibios_free_controller(hose);
> + return 0;
> + }
> +
> setup_pci_cmd(hose);
>=20
> /* check PCI express link status */
> --=20
> 1.7.3
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc/85xx:DTS: Fix PCIe IDSEL for Px020RDB
From: Kumar Gala @ 2011-05-19 6:16 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: meet2prabhu, devicetree-discuss, linuxppc-dev
In-Reply-To: <1303272764-15333-1-git-send-email-prabhakar@freescale.com>
On Apr 19, 2011, at 11:12 PM, Prabhakar Kushwaha wrote:
> PCIe device in legacy mode can trigger interrupts using the wires =
#INTA, #INTB
> ,#INTC and #INTD. PCI devices are obligated to use #INTx for =
interrupts under
> legacy mode. Each PCI slot or device is typically wired to different =
inputs on
> the interrupt controller.=20
>=20
> So, Define interrupt-map and interrupt-map-mask properties for device =
tree to
> of map each PCI interrupt signal to the inputs of the interrupt =
controller.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branc=
h master)
>=20
> This patch has depedency on following 2 patches
> -- powerpc/85xx: P2020 DTS: re-organize dts files
> -- powerpc/85xx: P1020 DTS : re-organize dts files
>=20
> arch/powerpc/boot/dts/p1020rdb.dts | 16 ++++++++++++++++
> arch/powerpc/boot/dts/p2020rdb.dts | 16 ++++++++++++++++
> arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 8 ++++++++
> arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 8 ++++++++
> 4 files changed, 48 insertions(+), 0 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: P2020 DTS: re-organize dts files
From: Kumar Gala @ 2011-05-19 6:16 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: meet2prabhu, devicetree-discuss, linuxppc-dev
In-Reply-To: <1302265625-10131-1-git-send-email-prabhakar@freescale.com>
On Apr 8, 2011, at 7:27 AM, Prabhakar Kushwaha wrote:
> Creates P2020si.dtsi, containing information for P2020 SoC. Modifies =
dts files
> for P2020 based systems to use dtsi file.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branc=
h master)
>=20
> Please see mpc5200b.dtsi for reference.
>=20
> Tested on P2020RDB and P2020DS
>=20
> arch/powerpc/boot/dts/p2020ds.dts | 374 =
++----------------------
> arch/powerpc/boot/dts/p2020rdb.dts | 362 =
++---------------------
> arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 237 +++-------------
> arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 142 ++++++----
> arch/powerpc/boot/dts/p2020si.dtsi | 382 =
+++++++++++++++++++++++++
> 5 files changed, 564 insertions(+), 933 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p2020si.dtsi
applied to next
- k=
^ permalink raw reply
* Re: [PATCH][v2] powerpc/85xx: P1020 DTS : re-organize dts files
From: Kumar Gala @ 2011-05-19 6:16 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: meet2prabhu, devicetree-discuss, linuxppc-dev
In-Reply-To: <1302167455-21538-1-git-send-email-prabhakar@freescale.com>
On Apr 7, 2011, at 4:10 AM, Prabhakar Kushwaha wrote:
> Creates P1020si.dtsi, containing information for the P1020 SoC. =
Modifies dts
> files for P1020 based systems to use dtsi file
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> Acked-by: Kumar Gala <kumar.gala@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branc=
h master)
>=20
> Please see mpc5200b.dtsi for reference.
>=20
> Tested on P1020RDB
>=20
> Changes for v2: Incorporated Grant Likely's comment
> -updated model name
>=20
> arch/powerpc/boot/dts/p1020rdb.dts | 316 =
+------------------------------
> arch/powerpc/boot/dts/p1020si.dtsi | 377 =
++++++++++++++++++++++++++++++++++++
> 2 files changed, 380 insertions(+), 313 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p1020si.dtsi
applied to next
- k=
^ permalink raw reply
* Re: [PATCH][upstream] powerpc: Adding bindings for flexcan controller
From: Kumar Gala @ 2011-05-19 6:06 UTC (permalink / raw)
To: Bhaskar Upadhaya; +Cc: devicetree-discuss, linuxppc-dev, inuxppc-dev
In-Reply-To: <1303221511-12903-1-git-send-email-Bhaskar.Upadhaya@freescale.com>
On Apr 19, 2011, at 8:58 AM, Bhaskar Upadhaya wrote:
> From: Bhaskar Upadhaya <bhaskar.upadhaya@freescale.com>
>=20
> Signed-off-by: Bhaskar Upadhaya <bhaskar.upadhaya@freescale.com>
> Acked-By: Scott Wood <scottwood@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =
(branch -> master)
>=20
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 =
++++++++++++++++++++
> 1 files changed, 61 insertions(+), 0 deletions(-)
> create mode 100755 =
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 13/13] kvm/powerpc: Allow book3s_hv guests to use SMT processor modes
From: Paul Mackerras @ 2011-05-19 6:06 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev@ozlabs.org, kvm@vger.kernel.org
In-Reply-To: <9A23FF37-0369-4DF7-89F7-62E6EA54C97F@suse.de>
On Tue, May 17, 2011 at 01:36:26PM +0200, Alexander Graf wrote:
>
> Just so I understand the scheme: One vcpu needs to go to MMU mode in
> KVM, it then sends IPIs to stop the other threads and finally we
> return from this wait here?
Actually, if one thread needs to get the other threads out of the
guest, it sets the HDEC to 0. Since it's a shared register and
interrupts all threads on a 0 to -1 transition, setting it to 0 makes
all threads come out of the guest.
The IPI is for when we're going into the guest. When we're in the
host, all the secondary threads are in nap and only the primary thread
is running. (Offlining a cpu in the host results in the cpu/thread
going to nap mode.) Sending an IPI to a napping thread wakes it up
and it resumes at the system reset vector with some bits set in SRR1
to say that it was previously in nap mode.
> Oh, I'm certainly fine with the scheme :). I would just like to
> understand it and see it documented somewhere, as it's slightly
> unintuitive.
It took some thought to work it out, so you're right, I should
definitely document it.
> Also, this scheme might confuse the host scheduler for a bit, as it
> might migrate threads to other host CPUs while it would prove
> beneficial for cache usage to keep them local. But since the
> scheduler doesn't know about the correlation between the threads, it
> can't be clever about it.
Well, it's not going to migrate a sleeping thread. The accounting
gets slightly strange in that all the CPU time for running the 4 vcpus
in the vcore gets accounted to one of the vcpu threads (which one can
change over time). However, the total across all qemu threads should
be correct.
Paul.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox