> > +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
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 comm
> -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
> > 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 f
On Thu, Oct 31, 2013 at 01:38:57PM -0500, Tom wrote:
> From: Tom Musta
>
> 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 inside function d
On Thu, Oct 31, 2013 at 01:38:56PM -0500, Tom wrote:
> From: Tom Musta
>
> 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 endian) code baile
On Thu, 2013-10-31 at 13:38 -0500, Tom wrote:
> From: Tom Musta
>
> 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 a classic lit
On Thu, 2013-10-31 at 13:38 -0500, Tom wrote:
> From: Tom Musta
>
> 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 merged v1)
Che
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 w
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 old
On Sun, Nov 3, 2013 at 2:42 PM, Paul E. McKenney
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 talk about the hardware
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
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 wrote:
> > > On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote:
> > >> If there was an smp_tmb(), I wo
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 of
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 mfenc
On Fri, 2013-11-01 at 18:30 +0200, Victor Kaplansky wrote:
> "David Laight" 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
> > when accessing b
On Sun, Nov 03, 2013 at 10:08:14AM -0800, Linus Torvalds wrote:
> On Sun, Nov 3, 2013 at 7:17 AM, 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 a
On Sun, Nov 3, 2013 at 7:17 AM, 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
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 t
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 STOR
20 matches
Mail list logo
