* 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
* Re: [PATCH 02/13] powerpc/e500: SPE register saving: take arbitrary struct offset
From: Kumar Gala @ 2011-05-19 6:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, agraf, kvm-ppc
In-Reply-To: <20110517233628.GA3542@schlenkerla.am.freescale.net>
On May 17, 2011, at 6:36 PM, Scott Wood wrote:
> Previously, these macros hardcoded THREAD_EVR0 as the base of the save
> area, relative to the base register passed. This base offset is now
> passed as a separate macro parameter, allowing reuse with other SPE
> save areas, such as used by KVM.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> This is a resending of =
http://www.spinics.net/lists/kvm-ppc/msg02672.html
>=20
> Kumar, please ack to go via kvm.
>=20
> arch/powerpc/include/asm/ppc_asm.h | 28 =
++++++++++++++++------------
> arch/powerpc/kernel/head_fsl_booke.S | 6 +++---
> 2 files changed, 19 insertions(+), 15 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 ]
- k
^ permalink raw reply
* Re: [PATCH 01/13] powerpc/e500: Save SPEFCSR in flush_spe_to_thread()
From: Kumar Gala @ 2011-05-19 6:04 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, agraf, kvm-ppc
In-Reply-To: <20110517233551.GA3511@schlenkerla.am.freescale.net>
On May 17, 2011, at 6:35 PM, Scott Wood wrote:
> From: yu liu <yu.liu@freescale.com>
>=20
> giveup_spe() saves the SPE state which is protected by MSR[SPE].
> However, modifying SPEFSCR does not trap when MSR[SPE]=3D0.
> 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().
>=20
> This patch moves SPEFSCR saving to flush_spe_to_thread(),
> and cleans up the caller that needs to save SPEFSCR accordingly.
>=20
> 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/
>=20
> 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.
>=20
> 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 ]
- k=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl: enable verbose bug output
From: Kumar Gala @ 2011-05-19 6:02 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110510180206.GB18443@schlenkerla.am.freescale.net>
On May 10, 2011, at 1:02 PM, Scott Wood wrote:
> This debug option has no overhead other than a slight increase in
> kernel size, and makes bug reports more useful. While some end users
> may prefer to save the space, as a default on a kernel config aimed
> primarily at development on reference boards, it should be enabled.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 1 -
> arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 1 -
> arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 1 -
> arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 1 -
> arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 1 -
> arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 1 -
> arch/powerpc/configs/e55xx_smp_defconfig | 1 -
> arch/powerpc/configs/mpc85xx_defconfig | 1 -
> arch/powerpc/configs/mpc85xx_smp_defconfig | 1 -
> arch/powerpc/configs/mpc86xx_defconfig | 1 -
> 10 files changed, 0 insertions(+), 10 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/mpic: add the mpic global timer support
From: Kumar Gala @ 2011-05-19 6:01 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20110324214355.GC9524@schlenkerla.am.freescale.net>
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> Add support for MPIC timers as requestable interrupt sources.
>=20
> Based on http://patchwork.ozlabs.org/patch/20941/ by Dave Liu.
>=20
> Signed-off-by: Dave Liu <daveliu@freescale.com>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/include/asm/mpic.h | 3 +-
> arch/powerpc/sysdev/mpic.c | 92 =
++++++++++++++++++++++++++++++++++++---
> 2 files changed, 88 insertions(+), 7 deletions(-)
applied to next, fixed for upstream changes.
- k=
^ permalink raw reply
* Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7
From: Alexander Graf @ 2011-05-19 6:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: kvm-ppc, Linuxppc-dev, Avi Kivity, KVM list
In-Reply-To: <20110519052246.GA8165@drongo>
On 19.05.2011, at 07:22, Paul Mackerras wrote:
> On Tue, May 17, 2011 at 02:42:08PM +0300, Avi Kivity wrote:
>> On 05/17/2011 02:38 PM, Alexander Graf wrote:
>>>>=20
>>>> What would be the path for these patches to get upstream? Would =
this
>>>> stuff normally go through Avi's tree? There is a bit of a
>>>> complication in that they are based on Ben's next branch. Would =
Avi
>>>> pull Ben's next branch, or would they go in via Ben's tree?
>>>=20
>>> Usually the ppc tree gets merged into Avi's tree and goes on from
>>> there. When we have interdependencies, we can certainly do it
>>> differently though. We can also shove them through Ben's tree this
>>> time around, as there are more dependencies on ppc code than KVM
>>> code.
>>>=20
>>=20
>> Yes, both options are fine. If it goes through kvm.git I can merge
>> Ben's tree (provided it is append-only) and apply the kvm-ppc
>> patches on top.
>=20
> OK, the easiest thing is for them to go via Ben's tree, I think, since
> they depend so much on other stuff in Ben's tree.
>=20
> Alex, could you give Ben an acked-by for patches 1-8 of the series?
> There haven't been any changes requested for them.
Let me give them a spin on a G5, so I can at least verify nothing breaks =
;). I'll hopefully get to this before next week.
Alex
^ permalink raw reply
* Re: [PATCH 3/4] powerpc/mpic: parse 4-cell intspec types other than zero
From: Kumar Gala @ 2011-05-19 6:01 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20110324214354.GB9524@schlenkerla.am.freescale.net>
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/include/asm/mpic.h | 2 ++
> arch/powerpc/sysdev/mpic.c | 37 =
++++++++++++++++++++++++++++++++++++-
> 2 files changed, 38 insertions(+), 1 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/p1022ds: fix broken mpic timer node
From: Kumar Gala @ 2011-05-19 6:01 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20110324214352.GA9524@schlenkerla.am.freescale.net>
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> There is no hardware interrupt 0xf7. But now we can express the timer
> interrupt using 4-cell interrupts. This requires converting all of =
the
> other interrupt specifiers in the tree as well.
>=20
> Also add the second timer group, and fix the reg property to only
> describe the timer registers.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/boot/dts/p1022ds.dts | 106 =
++++++++++++++++++++----------------
> 1 files changed, 59 insertions(+), 47 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc,e5500: add networking to defconfig
From: Kumar Gala @ 2011-05-19 6:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110510180147.GA18443@schlenkerla.am.freescale.net>
On May 10, 2011, at 1:01 PM, Scott Wood wrote:
> Even though support for the p5020's on-chip ethernet is not yet =
upstream,
> it is not appropriate to disable all networking support (including
> loopback, unix domain sockets, external ethernet devices, etc) in the
> defconfig. The networking settings are taken from =
mpc85xx_smp_defconfig,
> minus the drivers for ethernet devices not found on any current e5500
> chip.
>=20
> The other changes are the result of running "make savedefconfig".
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/configs/e55xx_smp_defconfig | 38 =
++++++++++++++++++++++-------
> 1 files changed, 29 insertions(+), 9 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: Add fsl mpic timer binding
From: Kumar Gala @ 2011-05-19 6:01 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <20110324214315.GA9502@schlenkerla.am.freescale.net>
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> Update the existing example in the general mpic binding to have a
> separate TCRx region. Currently the example doesn't describe TCRx at
> all. The one upstream device tree with an mpic timer node (p1022ds)
> uses one large reg region to describe both, even though there are =
other
> unrelated registers in between. That device tree also contains a =
bogus
> interrupt specifier, and there's no upstream software that uses this =
yet,
> so changing this shouldn't be a problem.
>=20
> Add a full binding for the MPIC timer node, not just an example of
> 4-cell interrupts in the MPIC binding.
>=20
> Add fsl,available-ranges, similar to msi-available-ranges.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/mpic-timer.txt | 38 =
++++++++++++++++++++
> .../devicetree/bindings/powerpc/fsl/mpic.txt | 2 +-
> 2 files changed, 39 insertions(+), 1 deletions(-)
> create mode 100644 =
Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 3/7] [RFC] add support for BlueGene/P FPU
From: Michael Neuling @ 2011-05-19 5:58 UTC (permalink / raw)
To: Eric Van Hensbergen; +Cc: linuxppc-dev, linux-kernel, bg-linux
In-Reply-To: <1305753895-24845-3-git-send-email-ericvh@gmail.com>
Eric,
> This patch adds save/restore register support for the BlueGene/P
> double hummer FPU.
What does this mean? Needs more details here.
> Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
> ---
> arch/powerpc/include/asm/ppc_asm.h | 39 ++++++++++++++++++++++++----------
-
> arch/powerpc/kernel/fpu.S | 8 +++---
> arch/powerpc/platforms/44x/Kconfig | 9 ++++++++
> 3 files changed, 40 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/pp
c_asm.h
> index 9821006..daa22bb 100644
> --- a/arch/powerpc/include/asm/ppc_asm.h
> +++ b/arch/powerpc/include/asm/ppc_asm.h
> @@ -88,6 +88,13 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
> REST_10GPRS(22, base)
> #endif
>
> +#ifdef CONFIG_BGP
> +#define LFPDX(frt, ra, rb) .long (31<<26)|((frt)<<21)|((ra)<<16)| \
> + ((rb)<<11)|(462<<1)
> +#define STFPDX(frt, ra, rb) .long (31<<26)|((frt)<<21)|((ra)<<16)| \
> + ((rb)<<11)|(974<<1)
> +#endif /* CONFIG_BGP */
Put these in arch/powerpc/include/asm/ppc-opcode.h and reformat to fit
whats there already.
Also, don't need to put these defines inside a #ifdef.
> +
> #define SAVE_2GPRS(n, base) SAVE_GPR(n, base); SAVE_GPR(n+1, base)
> #define SAVE_4GPRS(n, base) SAVE_2GPRS(n, base); SAVE_2GPRS(n+2, base)
> #define SAVE_8GPRS(n, base) SAVE_4GPRS(n, base); SAVE_4GPRS(n+4, base)
> @@ -97,18 +104,26 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
> #define REST_8GPRS(n, base) REST_4GPRS(n, base); REST_4GPRS(n+4, base)
> #define REST_10GPRS(n, base) REST_8GPRS(n, base); REST_2GPRS(n+8, base)
>
> -#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> -#define SAVE_2FPRS(n, base) SAVE_FPR(n, base); SAVE_FPR(n+1, base)
> -#define SAVE_4FPRS(n, base) SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base)
> -#define SAVE_8FPRS(n, base) SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base)
> -#define SAVE_16FPRS(n, base) SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base)
> -#define SAVE_32FPRS(n, base) SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base)
> -#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
> -#define REST_2FPRS(n, base) REST_FPR(n, base); REST_FPR(n+1, base)
> -#define REST_4FPRS(n, base) REST_2FPRS(n, base); REST_2FPRS(n+2, base)
> -#define REST_8FPRS(n, base) REST_4FPRS(n, base); REST_4FPRS(n+4, base)
> -#define REST_16FPRS(n, base) REST_8FPRS(n, base); REST_8FPRS(n+8, base)
> -#define REST_32FPRS(n, base) REST_16FPRS(n, base); REST_16FPRS(n+16, base)
> +#ifdef CONFIG_BGP
> +#define SAVE_FPR(n, b, base) li b, THREAD_FPR0+(16*(n)); STFPDX(n, base, b)
> +#define REST_FPR(n, b, base) li b, THREAD_FPR0+(16*(n)); LFPDX(n, base, b)
16*? Are these FP regs 64 or 128 bits wide? If 128 you are doing to
have to play with TS_WIDTH to get the size of the FPs correct in the
thread_struct.
I think there's a bug here.
> +#else /* CONFIG_BGP */
> +#define SAVE_FPR(n, b, base) (stfd n, THREAD_FPR0+8*TS_FPRWIDTH*(n)(base))
> +#define REST_FPR(n, b, base) (lfd n, THREAD_FPR0+8*TS_FPRWIDTH*(n)(base))
> +#endif /* CONFIG_BGP */
> +
> +#define SAVE_2FPRS(n, b, base) SAVE_FPR(n, b, base); SAVE_FPR(n+1, b,
base)
> +#define SAVE_4FPRS(n, b, base) SAVE_2FPRS(n, b, base); SAVE_2FPRS(n+2,
b, base)
> +#define SAVE_8FPRS(n, b, base) SAVE_4FPRS(n, b, base); SAVE_4FPRS(n+4,
b, base)
> +#define SAVE_16FPRS(n, b, base) SAVE_8FPRS(n, b, base); SAVE_8FPRS(n+8,
b, base)
> +#define SAVE_32FPRS(n, b, base) SAVE_16FPRS(n, b, base); \
> + SAVE_16FPRS(n+16, b, base)
> +#define REST_2FPRS(n, b, base) REST_FPR(n, b, base); REST_FPR(n+1, b,
base)
> +#define REST_4FPRS(n, b, base) REST_2FPRS(n, b, base); REST_2FPRS(n+2,
b, base)
> +#define REST_8FPRS(n, b, base) REST_4FPRS(n, b, base); REST_4FPRS(n+4,
b, base)
> +#define REST_16FPRS(n, b, base) REST_8FPRS(n, b, base); REST_8FPRS(n+8,
b, base)
> +#define REST_32FPRS(n, b, base) REST_16FPRS(n, b, base); \
> + REST_16FPRS(n+16, b, base)
>
> #define SAVE_VR(n,b,base) li b,THREAD_VR0+(16*(n)); stvx n,base,b
> #define SAVE_2VRS(n,b,base) SAVE_VR(n,b,base); SAVE_VR(n+1,b,base)
> diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
> index de36955..9f11c66 100644
> --- a/arch/powerpc/kernel/fpu.S
> +++ b/arch/powerpc/kernel/fpu.S
> @@ -30,7 +30,7 @@
> BEGIN_FTR_SECTION \
> b 2f; \
> END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
> - REST_32FPRS(n,base); \
> + REST_32FPRS(n,c,base); \
> b 3f; \
> 2: REST_32VSRS(n,c,base); \
> 3:
> @@ -39,13 +39,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX);
\
> BEGIN_FTR_SECTION \
> b 2f; \
> END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
> - SAVE_32FPRS(n,base); \
> + SAVE_32FPRS(n,c,base); \
> b 3f; \
> 2: SAVE_32VSRS(n,c,base); \
> 3:
> #else
> -#define REST_32FPVSRS(n,b,base) REST_32FPRS(n, base)
> -#define SAVE_32FPVSRS(n,b,base) SAVE_32FPRS(n, base)
> +#define REST_32FPVSRS(n,b,base) REST_32FPRS(n,b,base)
> +#define SAVE_32FPVSRS(n,b,base) SAVE_32FPRS(n,b,base)
> #endif
>
> /*
> diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/
Kconfig
> index f485fc5f..24a515e 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -169,6 +169,15 @@ config YOSEMITE
> help
> This option enables support for the AMCC PPC440EP evaluation board.
>
> +config BGP
Does this FPU feature have a specific name like double hammer? I'd
rather have the BGP defconfig depend on PPC_FPU_DOUBLE_HUMMER, or
something like that...
> + bool "Blue Gene/P"
> + depends on 44x
> + default n
> + select PPC_FPU
> + select PPC_DOUBLE_FPU
... in fact, it seem you are doing something like these here but you
don't use PPC_DOUBLE_FPU anywhere?
Mikey
> + help
> + This option enables support for the IBM BlueGene/P supercomputer.
> +
> config ISS4xx
> bool "ISS 4xx Simulator"
> depends on (44x || 40x)
> --
> 1.7.4.1
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: don't pretend that we support 8-bit pixels on the MPC8610 HPCD
From: Kumar Gala @ 2011-05-19 5:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1304969380-24897-1-git-send-email-timur@freescale.com>
On May 9, 2011, at 2:29 PM, Timur Tabi wrote:
> If the video mode is set to 16-, 24-, or 32-bit pixels, then the pixel =
data
> contains actual levels of red, blue, and green. However, if the video =
mode is
> set to 8-bit pixels, then the 8-bit value represents an index into =
color table.
> This is called "palette mode" on the Freescale DIU video controller.
>=20
> The DIU driver does not currently support palette mode, but the =
MPC8610 HPCD
> board file returned a non-zero (although incorrect) pixel format value =
for
> 8-bit mode.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 97 =
++++++++++++++++++----------
> 1 files changed, 64 insertions(+), 33 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/mpc8610_hpcd: Do not use "/" in interrupt names
From: Kumar Gala @ 2011-05-19 5:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Anton Vorontsov, Linux/PPC Development, Linux Kernel Development
In-Reply-To: <alpine.DEB.2.00.1105041627560.2601@ayla.of.borg>
On May 4, 2011, at 9:29 AM, Geert Uytterhoeven wrote:
> It may trigger a warning in fs/proc/generic.c:__xlate_proc_name() when
> trying to add an entry for the interrupt handler to sysfs.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to next, will CC for stable (2.6.39.1)
- k
^ permalink raw reply
* Re: [PATCH] powerpc/e5500: set non-base IVORs
From: Kumar Gala @ 2011-05-19 5:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110509212600.GA29190@schlenkerla.am.freescale.net>
On May 9, 2011, at 4:26 PM, Scott Wood wrote:
> Without this, we attempt to use doorbells for IPIs, and end up
> branching to some bad address. Plus, even for the exceptions
> we don't implement, it's good to handle it and get a message out.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/include/asm/reg_booke.h | 4 ++
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 3 ++
> arch/powerpc/kernel/exceptions-64e.S | 47 =
+++++++++++++++++++++++++++++
> 3 files changed, 54 insertions(+), 0 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
From: Benjamin Herrenschmidt @ 2011-05-19 5:36 UTC (permalink / raw)
To: James Bottomley
Cc: linux-arch, Prakash, Sathya, Roland Dreier, Desai, Kashyap,
Hitoshi Mitake, Matthew Wilcox, Moore, Eric, linux pci,
linux powerpc dev, Milton Miller, linux kernel, Ingo Molnar,
paulus@samba.org, linux scsi dev, Ingo Molnar, Sam Ravnborg
In-Reply-To: <1305780360.2576.20.camel@mulgrave.site>
On Thu, 2011-05-19 at 08:46 +0400, James Bottomley wrote:
> This can't really be done generically. There are several considerations
> to do with hardware requirements. I can see some hw requiring a
> specific write order (I think this applies more to read order, though).
Right. Or there can be a need for a completely different access pattern
to do 32-bit, or maybe write only one half because both might have a
side effect etc etc etc ...
Also a global lock would be suboptimal vs. a per device lock burried in
the driver.
> 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.
>
> > How do you think about them? If you cannot agree with the above two
> > solutions, I'll agree with reverting them.
>
> Having x86 roll its own never made any sense, so I think they need
> reverting anyway.
Agreed.
> This is a driver/platform bus problem not an
> architecture problem. The assumption we can make is that the platform
> CPU can write atomically at its chip width. We *may* be able to make
> the assumption that the bus controller can translate an atomic chip
> width transaction to a single atomic bus transaction; I think that
> assumption holds true for at least PCI and on the parisc legacy busses,
> so if we can agree on semantics, this should be a global define
> somewhere. If there are problems with the bus assumption, we'll likely
> need some type of opt-in (or just not bother).
And we want a well defined #ifdef drivers test to know whether there's a
writeq/readq (just #define writeq/readq itself is fine even if it's an
inline function, we do that elsewhere) so they can have a fallback
scenario.
This is important as these can be used in very performance critical code
path.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
From: Benjamin Herrenschmidt @ 2011-05-19 5:34 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-arch, Prakash, Sathya, Desai, Kashyap, linux scsi dev,
Matthew Wilcox, Hitoshi Mitake, linux powerpc dev, Milton Miller,
linux kernel, James Bottomley, Ingo Molnar, paulus@samba.org,
linux pci, Ingo Molnar, Sam Ravnborg
In-Reply-To: <BANLkTimDktq8SxOU3HZkPpj=J9pdkzVX-w@mail.gmail.com>
On Wed, 2011-05-18 at 21:16 -0700, Roland Dreier wrote:
> On Wed, May 18, 2011 at 11:31 AM, Milton Miller <miltonm@bga.com> wrote:
> > So the real question should be why is x86-32 supplying a broken writeq
> > instead of letting drivers work out what to do it when needed?
>
> Sounds a lot like what I was asking a couple of years ago :)
> http://lkml.org/lkml/2009/4/19/164
>
> But Ingo insisted that non-atomic writeq would be fine:
> http://lkml.org/lkml/2009/4/19/167
Yuck... Ingo, I think that was very wrong.
Those are for MMIO, which must almost ALWAYS know precisely what the
resulting access size is going to be. It's not even about atomicity
between multiple CPUs. I have seen plenty of HW for which a 64-bit
access to a register is -not- equivalent to two 32-bit ones. In fact, in
some case, you can get the side effects twice ... or none at all.
The only case where you can be lax is when you explicitely know that
there is no side effects -and- the HW cope with different access sizes.
This is not the general case and drivers need at the very least a way to
know what the behaviour will be.
Cheers,
Ben.
^ permalink raw reply
* Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame
From: Kumar Gala @ 2011-05-19 5:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Richard Cochran, linuxppc-dev, linux-kernel
In-Reply-To: <1305668416.2781.23.camel@pasglop>
On May 17, 2011, at 4:40 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2011-05-17 at 18:28 +0200, Richard Cochran wrote:
>> Ben,
>>
>> Recent 2.6.39-rc kernels behave strangely on the Freescale dual core
>> mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot
>> sequence after "mpic: requesting IPIs..."
>>
>> When the system comes up, only one core shows in /proc/cpuinfo. Later
>> on, lots of messages appear like the following:
>>
>> INFO: task ksoftirqd/1:9 blocked for more than 120 seconds.
>>
>> I bisected [1] the problem to:
>>
>> commit c56e58537d504706954a06570b4034c04e5b7500
>> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Date: Tue Mar 8 14:40:04 2011 +1100
>>
>> powerpc/smp: Create idle threads on demand and properly reset them
>>
>> I don't see from that commit what had gone wrong. Perhaps you can
>> help resolve this?
>
> Hrm, odd. Kumar, care to have a look ? That's what happens when you
> don't get me HW to test with :-)
I'm trying to work on it ;)
- k
^ permalink raw reply
* Re: powerpc: mpc85xx regression since 2.6.39-rc2, one cpu core lame
From: Kumar Gala @ 2011-05-19 5:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Richard Cochran, linuxppc-dev, linux-kernel
In-Reply-To: <1305755338.7481.8.camel@pasglop>
On May 18, 2011, at 4:48 PM, Benjamin Herrenschmidt wrote:
>=20
>> (I get the feeling that I am the only one testing recent kernels with
>> the mpc85xx.)
>>=20
>> Anyhow, I see that this commit was one of a series. For my own use,
>> can I simply revert this one commit independently?
>=20
> For your own use sure :-) But I'd still like to get to the bottom of
> this !
>=20
> Cheers,
> Ben.
Tested the 'merge' branch and it appears to fix the issues with =
secondary cores coming up.
- k=
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Kumar Gala @ 2011-05-19 5:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev list
In-Reply-To: <1305777978.7481.37.camel@pasglop>
On May 18, 2011, at 11:06 PM, Benjamin Herrenschmidt wrote:
> Hi Linus
>=20
> Dunno if it's too late or not yet but here's 3 fixes for powerpc that
> would be welcome to have in before the release. If not I'll send them
> first thing next (one of them is already in -next in fact).
>=20
> Those are regression fixes and a build breakage.
>=20
> Cheers,
> Ben.
>=20
> The following changes since commit =
fce519588acfac249e8fdc1f5016c73d617de315:
>=20
> Merge branch 'devicetree/merge' of =
git://git.secretlab.ca/git/linux-2.6 (2011-05-18 13:25:57 -0700)
>=20
> are available in the git repository at:
>=20
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>=20
> Ben Hutchings (1):
> powerpc/kexec: Fix build failure on 32-bit SMP
>=20
> Benjamin Herrenschmidt (1):
> powerpc/smp: Make start_secondary_resume available to all CPU =
variants
>=20
> kerstin jonsson (1):
> powerpc/4xx: Fix regression in SMP on 476
>=20
> arch/powerpc/kernel/crash.c | 59 =
+++++++++++++++++++++--------------------
> arch/powerpc/kernel/head_32.S | 9 ------
> arch/powerpc/kernel/misc_32.S | 11 +++++++
> arch/powerpc/kernel/smp.c | 4 +-
> 4 files changed, 43 insertions(+), 40 deletions(-)
>=20
Can you pull this into next.
- k=
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-05-19 5:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
In-Reply-To: <BANLkTikRjqpxRKKhawcD1WjyhmH1PUgz5A@mail.gmail.com>
On Wed, 2011-05-18 at 21:11 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2011 at 9:06 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > Dunno if it's too late or not yet but here's 3 fixes for powerpc that
> > would be welcome to have in before the release. If not I'll send them
> > first thing next (one of them is already in -next in fact).
>
> Gah. I just cut 2.6.39.
Bah, no biggie. I'll stick some CC: stable and put them in -next :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7
From: Paul Mackerras @ 2011-05-19 5:22 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev@ozlabs.org, Alexander Graf, kvm@vger.kernel.org
In-Reply-To: <4DD25F10.4030707@redhat.com>
On Tue, May 17, 2011 at 02:42:08PM +0300, Avi Kivity wrote:
> On 05/17/2011 02:38 PM, Alexander Graf wrote:
> >>
> >> What would be the path for these patches to get upstream? Would this
> >> stuff normally go through Avi's tree? There is a bit of a
> >> complication in that they are based on Ben's next branch. Would Avi
> >> pull Ben's next branch, or would they go in via Ben's tree?
> >
> >Usually the ppc tree gets merged into Avi's tree and goes on from
> >there. When we have interdependencies, we can certainly do it
> >differently though. We can also shove them through Ben's tree this
> >time around, as there are more dependencies on ppc code than KVM
> >code.
> >
>
> Yes, both options are fine. If it goes through kvm.git I can merge
> Ben's tree (provided it is append-only) and apply the kvm-ppc
> patches on top.
OK, the easiest thing is for them to go via Ben's tree, I think, since
they depend so much on other stuff in Ben's tree.
Alex, could you give Ben an acked-by for patches 1-8 of the series?
There haven't been any changes requested for them.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
From: James Bottomley @ 2011-05-19 4:46 UTC (permalink / raw)
To: Hitoshi Mitake
Cc: linux-arch, Prakash, Sathya, Roland Dreier, Desai, Kashyap,
linux scsi dev, Matthew Wilcox, Moore, Eric, linux pci,
linux powerpc dev, Milton Miller, linux kernel, Ingo Molnar,
paulus@samba.org, Ingo Molnar, Sam Ravnborg
In-Reply-To: <BANLkTin4w1QyL1NyTyrZARPWASai45W_4Q@mail.gmail.com>
On Thu, 2011-05-19 at 13:08 +0900, Hitoshi Mitake wrote:
> On Thu, May 19, 2011 at 04:11, Moore, Eric <Eric.Moore@lsi.com> wrote:
> > On Wednesday, May 18, 2011 12:31 PM Milton Miller wrote:
> >> Ingo I would propose the following commits added in 2.6.29 be reverted.
> >> I think the current concensus is drivers must know if the writeq is
> >> not atomic so they can provide their own locking or other workaround.
> >>
> >
> >
> > Exactly.
> >
>
> The original motivation of preparing common readq/writeq is that
> letting each driver
> have their own readq/writeq is bad for maintenance of source code.
>
> But if you really dislike them, there might be two solutions:
>
> 1. changing the name of readq/writeq to readq_nonatomic/writeq_nonatomic
This is fine, but not really very useful
> 2. adding new C file to somewhere and defining spinlock for them.
> With spin_lock_irqsave() and spin_unlock_irqrestore() on the spinlock,
> readq/writeq can be atomic.
This can't really be done generically. There are several considerations
to do with hardware requirements. I can see some hw requiring a
specific write order (I think this applies more to read order, though).
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.
> How do you think about them? If you cannot agree with the above two
> solutions, I'll agree with reverting them.
Having x86 roll its own never made any sense, so I think they need
reverting anyway. This is a driver/platform bus problem not an
architecture problem. The assumption we can make is that the platform
CPU can write atomically at its chip width. We *may* be able to make
the assumption that the bus controller can translate an atomic chip
width transaction to a single atomic bus transaction; I think that
assumption holds true for at least PCI and on the parisc legacy busses,
so if we can agree on semantics, this should be a global define
somewhere. If there are problems with the bus assumption, we'll likely
need some type of opt-in (or just not bother).
James
^ permalink raw reply
* Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
From: Roland Dreier @ 2011-05-19 4:16 UTC (permalink / raw)
To: Milton Miller
Cc: linux-arch, Prakash, Sathya, Desai, Kashyap, linux scsi dev,
Matthew Wilcox, Hitoshi Mitake, linux pci, linux powerpc dev,
linux kernel, James Bottomley, Ingo Molnar, paulus@samba.org,
Ingo Molnar, Sam Ravnborg
In-Reply-To: <x86-32-writeq-is-broken@mdm.bga.com>
On Wed, May 18, 2011 at 11:31 AM, Milton Miller <miltonm@bga.com> wrote:
> So the real question should be why is x86-32 supplying a broken writeq
> instead of letting drivers work out what to do it when needed?
Sounds a lot like what I was asking a couple of years ago :)
http://lkml.org/lkml/2009/4/19/164
But Ingo insisted that non-atomic writeq would be fine:
http://lkml.org/lkml/2009/4/19/167
- R.
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: David Miller @ 2011-05-19 4:16 UTC (permalink / raw)
To: torvalds; +Cc: akpm, linux-kernel, linuxppc-dev
In-Reply-To: <BANLkTikRjqpxRKKhawcD1WjyhmH1PUgz5A@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 18 May 2011 21:11:47 -0700
> On Wed, May 18, 2011 at 9:06 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>>
>> Dunno if it's too late or not yet but here's 3 fixes for powerpc that
>> would be welcome to have in before the release. If not I'll send them
>> first thing next (one of them is already in -next in fact).
>
> Gah. I just cut 2.6.39.
I know we can't let these things go forever, but in my opinion
we should have given this one or two more -rc's.
^ permalink raw reply
* Re: [PATCH RFCv7 0/2] CARMA Board Support
From: Benjamin Herrenschmidt @ 2011-05-19 4:13 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: dmitry.torokhov, linuxppc-dev, linux-kernel
In-Reply-To: <1297467270-29576-1-git-send-email-iws@ovro.caltech.edu>
On Fri, 2011-02-11 at 15:34 -0800, Ira W. Snyder wrote:
> Hello everyone,
>
> This is the seventh posting of these drivers, taking into account comments
> from earlier postings. I've made sure that the drivers both pass checkpatch
> without any errors or warnings. I would appreciate as much review as you
> can offer, so that these can get into the next merge cycle. They've been
> sitting outside mainline for far too long.
This has been bitrotting for way too long indeed. I'm sticking this into
powerpc -next today.
Cheers,
Ben.
> RFCv6 -> RFCv7:
> - reference count private data structure (to support unbind)
> - use #defines instead of hex values for registers
> - keep lines <=80 characters
>
> RFCv5 -> RFCv6:
> - change locking in several functions
> - use list_move_tail() to simplify code
> - remove unused helper functions
>
> RFCv4 -> RFCv5:
> - remove unecessary locking per review comments
> - do not clobber return values from *_interruptible()
> - explicitly track buffer DMA mapping
> - use #defines instead of raw hex addresses
> - change enable sysfs attribute to root-writeable only
>
> RFCv3 -> RFCv4:
> - updates for DATA-FPGA version 2
>
> RFCv2 -> RFCv3:
> - use miscdevice framework (removing the carma class)
> - add bitfile readback capability to the programmer
>
> RFCv1 -> RFCv2:
> - change comments to kerneldoc format
> - Kconfig improvements
> - use the videobuf_dma_sg API in the programmer
> - updates for Freescale DMAEngine DMA_SLAVE API changes
>
> KNOWN ISSUES:
> - untested with a setup that can generate interrupts (will get access soon)
> - does not handle runtime "unbind"
>
> Information about the CARMA board:
>
> The CARMA board is essentially an MPC8349EA MDS reference design with a
> 1GHz ADC and 4 high powered data processing FPGAs connected to the local
> bus. It is all packed into a compact PCI form factor. It is used at the
> Owens Valley Radio Observatory as the main component in the correlator
> system.
>
> For board information, see:
> http://www.mmarray.org/~dwh/carma_board/index.html
>
> For DATA-FPGA register layout, see:
> http://www.mmarray.org/memos/carma_memo46.pdf
>
> These drivers are the necessary pieces to get the data processing FPGAs
> working and producing data. Despite the fact that the hardware is custom
> and we are the only users, I'd still like to get the drivers upstream.
> Several people have suggested that this is possible.
>
> Some further patches will be forthcoming. I have a driver for the LED
> subsystem and the PPS subsystem. The LED register layout is expected to
> change soon, so I won't post the driver until that is finished. The PPS
> driver will be posted seperately from this patch series; it is very
> generic.
>
> Thanks to everyone who has provided comments on earlier versions!
>
> Ira W. Snyder (2):
> misc: add CARMA DATA-FPGA Access Driver
> misc: add CARMA DATA-FPGA Programmer support
>
> drivers/misc/Kconfig | 1 +
> drivers/misc/Makefile | 1 +
> drivers/misc/carma/Kconfig | 18 +
> drivers/misc/carma/Makefile | 2 +
> drivers/misc/carma/carma-fpga-program.c | 1141 ++++++++++++++++++++++++
> drivers/misc/carma/carma-fpga.c | 1433 +++++++++++++++++++++++++++++++
> 6 files changed, 2596 insertions(+), 0 deletions(-)
> create mode 100644 drivers/misc/carma/Kconfig
> create mode 100644 drivers/misc/carma/Makefile
> create mode 100644 drivers/misc/carma/carma-fpga-program.c
> create mode 100644 drivers/misc/carma/carma-fpga.c
>
^ 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