Re: perf events ring buffer memory barrier on powerpc

2013-11-03 Thread Paul E. McKenney
On Sat, Nov 02, 2013 at 10:32:39AM -0700, Paul E. McKenney wrote: On Fri, Nov 01, 2013 at 03:56:34PM +0100, Peter Zijlstra wrote: On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote: Now the whole crux of the question is if we need barrier A at all, since the STORES issued

[RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Peter Zijlstra
On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). Well, I'm obviously all for introducing this new barrier, for it will reduce a full mfence on x86 to a compiler barrier. And ppc can use lwsync as opposed

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Linus Torvalds
On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra pet...@infradead.org wrote: On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). Well, I'm obviously all for introducing this new barrier, for it will reduce a

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Peter Zijlstra
On Sun, Nov 03, 2013 at 10:08:14AM -0800, Linus Torvalds wrote: On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra pet...@infradead.org wrote: On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). Well, I'm

Re: perf events ring buffer memory barrier on powerpc

2013-11-03 Thread Benjamin Herrenschmidt
On Fri, 2013-11-01 at 18:30 +0200, Victor Kaplansky wrote: David Laight david.lai...@aculab.com wrote on 11/01/2013 06:25:29 PM: gcc will do unexpected memory accesses for bit fields that are adjacent to volatile data. In particular it may generate 64bit sized (and aligned) RMW cycles

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Benjamin Herrenschmidt
On Sun, 2013-11-03 at 16:17 +0100, Peter Zijlstra wrote: On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). Well, I'm obviously all for introducing this new barrier, for it will reduce a full mfence on

[PATCH v3 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100

2013-11-03 Thread Stephen Chivers
Add support for the Motorola/Emerson MVME5100 Single Board Computer. The MVME5100 is a 6U form factor VME64 computer with: - A single MPC7410 or MPC750 CPU - A HAWK Processor Host Bridge (CPU to PCI) and MultiProcessor Interrupt Controller (MPIC) - Up to 500Mb

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Paul E. McKenney
On Sun, Nov 03, 2013 at 09:01:24PM +0100, Peter Zijlstra wrote: On Sun, Nov 03, 2013 at 10:08:14AM -0800, Linus Torvalds wrote: On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra pet...@infradead.org wrote: On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: If there was an

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Paul E. McKenney
On Mon, Nov 04, 2013 at 07:59:23AM +1100, Benjamin Herrenschmidt wrote: On Sun, 2013-11-03 at 16:17 +0100, Peter Zijlstra wrote: On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote: If there was an smp_tmb(), I would likely use it in rcu_assign_pointer(). Well, I'm

Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()

2013-11-03 Thread Linus Torvalds
On Sun, Nov 3, 2013 at 2:42 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: smp_storebuffer_mb() -- A barrier that enforces those orderings that do not invalidate the hardware store-buffer optimization. Ugh. Maybe. Can you guarantee that those are the correct semantics? And why

Please pull 'next' branch of 5xxx tree

2013-11-03 Thread Anatolij Gustschin
Hi Ben ! Please pull mpc5xxx patches for v3.13: Fixes for build issues when LPB FIFO driver is configured as a module, removal of #ifdefs in mpc512x DIU platform code and a revert of recent changes to mpc52xx PIC driver. Wolfram provided a better fix for PIC driver build issue popping up when

[PATCH] powerpc/scom: Improve debugfs interface

2013-11-03 Thread Benjamin Herrenschmidt
The current debugfs interface to scom is essentially unused and racy. It uses two different files address and data to perform accesses which is at best impractical for anything but manual use by a developer. This replaces it with an access file which represent the entire scom address space which

Re: [V2 PATCH 2/3] powerpc: Fix Unaligned Fixed Point Loads and Stores

2013-11-03 Thread Benjamin Herrenschmidt
On Thu, 2013-10-31 at 13:38 -0500, Tom wrote: From: Tom Musta tommu...@gmail.com This patch modifies the unaligned access routines of the sstep.c module so that it properly reverses the bytes of storage operands in the little endian kernel kernel. Do that patch differ from v1 ? (I already

Re: [V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores

2013-11-03 Thread Benjamin Herrenschmidt
On Thu, 2013-10-31 at 13:38 -0500, Tom wrote: From: Tom Musta tommu...@gmail.com This patch addresses unaligned single precision floating point loads and stores in the single-step code. The old implementation improperly treated an 8 byte structure as an array of two 4 byte words, which is

Re: [V2 PATCH 1/3] powerpc: Enable emulate_step In Little Endian Mode

2013-11-03 Thread Paul Mackerras
On Thu, Oct 31, 2013 at 01:38:56PM -0500, Tom wrote: From: Tom Musta tommu...@gmail.com This patch modifies the endian chicken switch in the single step Chicken switch is IBM jargon, perhaps best avoided where possible in commit messages. emulation code (emulate_step()). The old (big

Re: [V2 PATCH 2/3] powerpc: Fix Unaligned Fixed Point Loads and Stores

2013-11-03 Thread Paul Mackerras
On Thu, Oct 31, 2013 at 01:38:57PM -0500, Tom wrote: From: Tom Musta tommu...@gmail.com This patch modifies the unaligned access routines of the sstep.c module so that it properly reverses the bytes of storage operands in the little endian kernel kernel. This has rather a lot of #ifdefs

RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.

2013-11-03 Thread Li Xiubo
This adds Freescale SAI ASoC Audio support. This implementation is only compatible with device tree definition. Features: o Supports playback/capture o Supports 16/20/24 bit PCM o Supports 8k - 96k sample rates o Supports slave mode only. Just for curiosity, I found there're

RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

2013-11-03 Thread Dongsheng Wang
-Original Message- From: Wang Dongsheng-B40534 Sent: Monday, October 21, 2013 11:11 AM To: Wood Scott-B07421 Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle -Original

Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.

2013-11-03 Thread Nicolin Chen
On Mon, Nov 04, 2013 at 11:45:10AM +0800, Xiubo Li-B47053 wrote: +snd-soc-fsl-sai-objs := fsl-sai.o And I think it should be better to put it along with fsl-ssi.o and fsl- spdif.o But fsl-ssi.o and fsl-spdif.o is based PowrePC platform? Which we can see from the comments. No.

RE: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.

2013-11-03 Thread Li Xiubo
+static int fsl_sai_set_dai_clkdiv(struct snd_soc_dai *cpu_dai, + int div_id, int div) +{ + struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai); + u32 tcr2, rcr2; + + if (div_id == FSL_SAI_TX_DIV) { + tcr2 = readl(sai-base + FSL_SAI_TCR2); +