From: Mark Brown <broonie(a)linaro.org>
Allow DMA data to be set at probe time for devices that can do that,
avoiding the need to do it every time we start a stream and supporting
non-DT dmaengine users using the helpers.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
include/sound/soc-dai.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 1ce3685..800c101 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -286,6 +286,13 @@ static inline void snd_soc_dai_set_dma_data(struct snd_soc_dai *dai,
dai->capture_dma_data = data;
}
+static inline void snd_soc_dai_init_dma_data(struct snd_soc_dai *dai,
+ void *playback, void *capture)
+{
+ dai->playback_dma_data = playback;
+ dai->capture_dma_data = capture;
+}
+
static inline void snd_soc_dai_set_drvdata(struct snd_soc_dai *dai,
void *data)
{
--
1.8.4.rc3
On Wed, Oct 16, 2013 at 10:17:14PM +0100, Måns Rullgård wrote:
> Taras Kondratiuk <taras.kondratiuk(a)linaro.org> writes:
>
> > On 10/16/2013 10:25 PM, Dave Martin wrote:
> >> Unfortunately, objdump can and does get confused about data/instruction
> >> boundaries, so the output you see above may be misleading.
> >>
> >> Displaying the symbol table with --special-syms will list the magic
> >> symbols that mark the instruction and data boundaries, to help debug
> >> this kind of situation.
> >>
> >>
> >> However, in this case, I think you've found a bug in the assembler,
> >> as shown below.
> >>
> >> Before linking, the final $a symbol (indicating the start of ARM
> >> instructions) is at address 8, so in this case objdump is correct
> >> to show 0x12345678 as an instruction.
> >>
> >> After linking, the mapping symbols ($[atd]) remain as before, and
> >> the linker has byteswapped this "instruction" (as it should).
> >>
> >> This is likely related to the magic for inserting the extensible
> >> NOP-padding fragment which implements the .align in code sections.
> >> That is code, and requires a $a mapping symbol, but that somehow
> >> goes AWOL or gets displaced after the alignment padding ...
> >>
> >> I can't quite get my head around what is going on in
> >> binutils/gas/config/tc-arm.c. We would need to understand that
> >> before we can identify a reliable workaround.
> >
> > Thanks for confirming the issue.
> > Does it makes sense to file a GCC bug?
>
> It seems like a binutils (gas) bug to me.
It is indeed a gas bug (actually a few interrelated bugs).
I've raised this with my local friendly binutils hackers, but I'll
propagate it to the upstream bugzilla if it's slow to turn around a
fix.
In any case, we can't rely on this working for Linux for some time
to come, because the fix would still need to make it into a binutils
release, and then everyone would need to upgrade to that release.
If we can work around it, we should just do that instead.
Cheers
---Dave