On Fri, 2013-11-01 at 17:24 -0500, Rob Herring wrote:
> On 11/01/2013 12:20 AM, Stephen Rothwell wrote:
> > Hi Rob,
> >
> > Today's linux-next merge of the dt-rh tree got a conflict in
> > arch/powerpc/include/asm/prom.h between commit a3e31b458844 ("of:
> > Move definition of of_find_next_cache_
Hi Rob,
On Fri, 01 Nov 2013 17:24:42 -0500 Rob Herring wrote:
>
> On 11/01/2013 12:20 AM, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the dt-rh tree got a conflict in
> > arch/powerpc/include/asm/prom.h between commit a3e31b458844 ("of:
> > Move definition of of_find_next_cache_
On 11/01/2013 12:20 AM, Stephen Rothwell wrote:
> Hi Rob,
>
> Today's linux-next merge of the dt-rh tree got a conflict in
> arch/powerpc/include/asm/prom.h between commit a3e31b458844 ("of:
> Move definition of of_find_next_cache_node into common code") from
> the powerpc tree and commit 0c3f061
On Fri, Nov 01, 2013 at 03:04:52PM +0800, Xiubo Li wrote:
> On VF610 series there are no regulators used, and now whether the
> CONFIG_REGULATOR mirco is enabled or not, for the VF610 audio
> patch series, the board cannot be probe successfully.
> And this patch will solve this issue.
I don't unde
On Fri, Nov 01, 2013 at 03:04:53PM +0800, Xiubo Li wrote:
> Conflicts:
> sound/soc/fsl/Makefile
Ahem.
> + /* TODO: The SAI driver should figure this out for us */
> + switch (channels) {
> + case 2:
> + snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffc, 0xfffc, 2, 0)
On Fri, Nov 01, 2013 at 03:04:48PM +0800, Xiubo Li wrote:
> +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) {
"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 bit fields.
> And yes, this has caused real problems.
Thanks, I am aw
> But "broken" compiler is much wider issue to be deeply discussed in this
> thread. I'm pretty sure that kernel have tons of very subtle
> code that actually creates locks and memory ordering. Such code
> usually just use the "barrier()" approach to tell gcc not to combine
> or move memory access
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> The dependency you are talking about is via the "if" statement?
> Even C/C++11 is not required to respect control dependencies.
>
> This one is a bit annoying. The x86 TSO means that you really only
> need barrier(), ARM (recent
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> > void kbuf_write(int sz, void *buf)
> > {
> > u64 tail = ACCESS_ONCE(ubuf->tail); /* last location userspace read */
> > u64 offset = kbuf->head; /* we already know where we last wrote */
> > u64 head = offset + sz;
>
"Paul E. McKenney" wrote on 10/31/2013
05:25:43 PM:
> I really don't care about "fair" -- I care instead about the kernel
> working reliably.
Though I don't see how putting a memory barrier without deep understanding
why it is needed helps kernel reliability, I do agree that reliability
is more
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 by the @buf writes are dependent on the ubuf->tail
> > read.
>
> The dependency you are talking about is via the "if" statement?
> Ev
"Paul E. McKenney" wrote on 10/31/2013
08:40:15 AM:
> > void ubuf_read(void)
> > {
> >u64 head, tail;
> >
> >tail = ACCESS_ONCE(ubuf->tail);
> >head = ACCESS_ONCE(ubuf->head);
> >
> >/*
> > * Ensure we read the buffer boundaries before the actual buffer
> > * data...
> >
"Paul E. McKenney" wrote on 10/31/2013
08:16:02 AM:
> > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only
> > around
> > @head read.
Just to be sure, that we are talking about the same code - I was
considering
ACCESS_ONCE() around @tail in point AAA in the following example
On Fri, Nov 01, 2013 at 06:28:05PM +0800, Nicolin Chen wrote:
> > sound/soc/fsl/fsl-sgtl5000-vf610.c | 208
> > +
>
> I just doubt if this file naming is appropriate. Even if we might not have
> rigor rule for the file names, according to existing ones, they ar
Hi Thomas,
On 10/31/2013 1:51 PM, Thomas Hühn wrote:
Hi Claudiu,
Please try the following patch:
http://patchwork.ozlabs.org/patch/283235/
It should help with your issue.
Several OpenWrt users including myself have tested your patch on
TPLink-4900 routers.
We do have positive feedback, as
Not that it would improve functionality, but:
On Fri, Nov 01, 2013 at 15:04:53 +0800, Xiubo Li wrote:
[...]
> diff --git a/sound/soc/fsl/fsl-sgtl5000-vf610.c
> b/sound/soc/fsl/fsl-sgtl5000-vf610.c
> new file mode 100644
> index 000..f535b42
> --- /dev/null
> +++ b/sound/soc/fsl/fsl-sgtl5000-v
On Wed, Oct 30, 2013 at 04:52:05PM +0200, Victor Kaplansky wrote:
> Peter Zijlstra wrote on 10/30/2013 01:25:26 PM:
>
> > Also, I'm not entirely sure on C, that too seems like a dependency, we
> > simply cannot read the buffer @tail before we've read the tail itself,
> > now can we? Similarly we
On Wed, Oct 30, 2013 at 12:25:26PM +0100, Peter Zijlstra wrote:
> On Wed, Oct 30, 2013 at 02:27:25AM -0700, Paul E. McKenney wrote:
> > On Mon, Oct 28, 2013 at 10:58:58PM +0200, Victor Kaplansky wrote:
> > > Oleg Nesterov wrote on 10/28/2013 10:17:35 PM:
> > >
> > > > mb(); // : d
On Thu, Oct 31, 2013 at 11:59:21AM +0200, Victor Kaplansky wrote:
> "Paul E. McKenney" wrote on 10/31/2013
> 06:32:58 AM:
>
> > If you want to play the "omit memory barriers" game, then proving a
> > negative is in fact the task before you.
>
> Generally it is not fair. Otherwise, anyone could p
Hi Xiubo,
On Fri, Nov 01, 2013 at 03:04:53PM +0800, Xiubo Li wrote:
> This is the SGTL5000 codec based audio driver supported with both
> playback and capture dai link implemention.
>
> This implementation is only compatible with device tree definition.
>
> Signed-off-by: Alison Wang Signed-off
On Fri, Nov 01, 2013 at 02:28:14AM -0700, Paul E. McKenney wrote:
> > This is a completely untenable position.
>
> Indeed it is!
>
> C/C++ never was intended to be used for parallel programming,
And yet pretty much all kernels ever written for SMP systems are written
in it; what drugs are those
On Fri, Nov 01, 2013 at 03:04:52PM +0800, Xiubo Li wrote:
> On VF610 series there are no regulators used, and now whether the
> CONFIG_REGULATOR mirco is enabled or not, for the VF610 audio
micro? or macro?
> patch series, the board cannot be probe successfully.
> And this patch will solve this i
On Fri, 1 Nov 2013 11:19:30 +0400
Alexander Popov wrote:
> Concentrate the specific code for MPC8308 in the 'if' branch
> and handle MPC512x in the 'else' branch.
> This modification only reorders instructions but doesn't change behaviour.
>
> Signed-off-by: Alexander Popov
> ---
> drivers/dm
On Fri, Nov 01, 2013 at 05:11:58PM +0800, Shawn Guo wrote:
> Nicolin,
>
> The dmaengine maintainer Vinod Koul should be copied on the series.
> (Just added).
>
Ah, I was careless last night when I sent these patches. My VPN connection
was pretty laggy :( Please forgive me, Vinod.
Thank Shawn for
On Thu, Oct 31, 2013 at 04:19:55PM +0100, Peter Zijlstra wrote:
> On Thu, Oct 31, 2013 at 08:07:56AM -0700, Paul E. McKenney wrote:
> > On Thu, Oct 31, 2013 at 10:04:57AM +0100, Peter Zijlstra wrote:
> > > On Wed, Oct 30, 2013 at 09:32:58PM -0700, Paul E. McKenney wrote:
> > > > Before C/C++11, the
Nicolin,
The dmaengine maintainer Vinod Koul should be copied on the series.
(Just added).
On Thu, Oct 31, 2013 at 09:44:12PM +0800, Nicolin Chen wrote:
> Nicolin Chen (4):
> dma: imx-sdma: Add sdma firmware version 2 support
> dma: imx-sdma: Add new dma type for ssi dual fifo script
> ASoC
Hi Xiubo,
On Fri, Nov 01, 2013 at 03:04:48PM +0800, Xiubo Li wrote:
> 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 Sup
On Thu, 2013-10-31 at 10:32 +, Sudeep KarkadaNagesha wrote:
> Thanks for the follow up. Grant wanted to see usage of this outside PPC and I
> pointed him[0] to the RFC[1] I had posted to support cacheinfo on ARM.
>
> These patches are based on v3.12-rc1, let me know if you want me to
> rebase
On Friday 01 November 2013, Alexander Popov wrote:
> + * of_dma_xlate_by_chan_id - Translate dt property to DMA channel by channel
> id
> + * @dma_spec:pointer to DMA specifier as found in the device tree
> + * @of_dma: pointer to DMA controller data
> + *
> + * This function can be used
Sorry, forgot the Subject!
Sent again.
>
> Hello,
>
> This patch series is mostly Freescale's SAI SoC Digital Audio Interface
> driver implementation. And the implementation is only compatible with
> device tree definition.
>
> This patch series is based on linux-next and has been tested on V
This adds the Document for Freescale VF610 sound driver under
Documentation/devicetree/bindings/sound/.
Signed-off-by: Xiubo Li
---
.../bindings/sound/fsl_audio_sgt15000_vf610.txt| 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindi
This patch add and enable SGTL5000 codec support, and also specified
the corresponding SAI node.
Signed-off-by: Xiubo Li
Signed-off-by: Alison Wang ;
+ audio-codec = <&codec>;
+ audio-routing =
+ "MIC_IN", "Mic Jack",
+ "Mic
This is the SGTL5000 codec based audio driver supported with both
playback and capture dai link implemention.
This implementation is only compatible with device tree definition.
Signed-off-by: Alison Wang
Conflicts:
sound/soc/fsl/Makefile
---
sound/soc/fsl/Kconfig | 10 ++
This adds the Document for Freescale SAI driver under
Documentation/devicetree/bindings/sound/.
Signed-off-by: Xiubo Li
---
.../devicetree/bindings/sound/fsl-sai.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound
On VF610 series there are no regulators used, and now whether the
CONFIG_REGULATOR mirco is enabled or not, for the VF610 audio
patch series, the board cannot be probe successfully.
And this patch will solve this issue.
Signed-off-by: Xiubo Li
---
sound/soc/codecs/sgtl5000.c | 12
1
This patch add and enable SAI device.
Signed-off-by: Xiubo Li
---
arch/arm/boot/dts/vf610-twr.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 1a58678..e4106dd 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/
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.
Signed-off-by: Alison Wang
---
sound/soc/fsl/Kconfig |
This patch add the SAI's edma mux Tx and Rx support.
Signed-off-by: Jingchang Lu
Signed-off-by: Xiubo Li
---
arch/arm/boot/dts/vf610.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 18e3a4c..391f180 100
Hello,
This patch series is mostly Freescale's SAI SoC Digital Audio Interface driver
implementation. And the implementation is only compatible with device tree
definition.
This patch series is based on linux-next and has been tested on Vybrid VF610
Tower board using device tree.
Changed in
From: Gerhard Sittig
Q&D HACK to enable SD card support without correct COMMON_CLK support,
best viewed with 'git diff -w -b', NOT acceptable for mainline (NAKed)
Signed-off-by: Gerhard Sittig
---
drivers/mmc/host/mxcmmc.c | 41 +++--
1 file changed, 27 inse
From: Lars-Peter Clausen
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use
to
lookup the channel by the id.
Unlike of_dma_simple_xlate this function is able to handle a system with
multip
From: Gerhard Sittig
register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees), provide
the '#dma-cells' property in the shared mpc5121.dtsi file, and introduce
a bindings document for the MPC512x DMA controller
Signed-of
Introduce support for slave s/g transfer preparation and the associated
device control callback in the MPC512x DMA controller driver, which adds
support for data transfers between memory and peripheral I/O to the
previously supported mem-to-mem transfers.
Signed-off-by: Alexander Popov
---
drive
Concentrate the specific code for MPC8308 in the 'if' branch
and handle MPC512x in the 'else' branch.
This modification only reorders instructions but doesn't change behaviour.
Signed-off-by: Alexander Popov
---
drivers/dma/mpc512x_dma.c | 42 +-
1 file ch
03.10.2013 18:00, Alexander Popov :
> v2013/7/14 Gerhard Sittig :
>> this series
>> - introduces slave s/g support (that's support for DMA transfers which
>>involve peripherals in contrast to mem-to-mem transfers)
>> - adds device tree based lookup support for DMA channels
>> - combines floatin
46 matches
Mail list logo
