Eric Lee / smarc-fsl-linux-kernel

14 Dec, 2020

1 commit

24 Jul, 2020

1 commit

  • 0ceef681e   ASoC: soc-xxx: add asoc_substream_to_rtd() ... Browse Code »

    Current soc-xxx are getting rtd from substream by

    rtd = substream->private_data;

    But, getting data from "private_data" is very unclear.
    This patch adds asoc_substream_to_rtd() macro which is
    easy to understand that rtd from substream.

    Signed-off-by: Kuninori Morimoto
    Link: https://lore.kernel.org/r/87wo2z0yve.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Mark Brown

    Kuninori Morimoto
     

30 Jun, 2020

1 commit

12 Dec, 2019

1 commit

08 Oct, 2019

1 commit

05 Aug, 2019

1 commit

  • 4ff1fef10   ASoC: add soc-component.c ... Browse Code »

    ALSA SoC has many snd_soc_component_xxx(), but these are randomly
    located in many files. Because of it, code is difficult to read.
    This patch creates new soc-component.c, and moves existing
    snd_soc_component_xxx() into it.
    But not yet fully. We need more cleanup it.

    Signed-off-by: Kuninori Morimoto
    Link: https://lore.kernel.org/r/87imrp5roa.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Mark Brown

    Kuninori Morimoto
     

28 Sep, 2018

1 commit

  • 42cfb412e   ASoC: soc-utils: Rename dummy_dma_ops to snd_dummy_dma_ops ... Browse Code »

    The symbols 'dummy_dma_ops' is declared with different data types by
    sound/soc/soc-utils.c and arch/arm64/include/asm/dma-mapping.h. This
    leads to conflicts when soc-utils.c (indirectly) includes dma-mapping.h:

    sound/soc/soc-utils.c:282:33: error: conflicting types for 'dummy_dma_ops'
    static const struct snd_pcm_ops dummy_dma_ops = {
    ^
    ...
    arch/arm64/include/asm/dma-mapping.h:27:33: note: previous declaration of 'dummy_dma_ops' was here
    extern const struct dma_map_ops dummy_dma_ops;
    ^

    Rename the symbol in soc-utils.c to 'snd_dummy_dma_ops' to avoid the
    conflict.

    Signed-off-by: Matthias Kaehlcke
    Signed-off-by: Mark Brown

    Matthias Kaehlcke
     

09 Aug, 2018

1 commit

02 Jul, 2018

1 commit

26 Jun, 2018

1 commit

  • b66c9b911   ASoC: soc-utils: Fix unregistration order ... Browse Code »

    The unregistration should happen in the opposite order of
    the registration, so change it accordingly.

    No real issue has been noticed, but it is good practice to
    keep the correct unregistration order.

    Signed-off-by: Fabio Estevam
    Signed-off-by: Mark Brown

    Fabio Estevam
     

12 Feb, 2018

2 commits

29 Nov, 2017

1 commit

15 Aug, 2017

1 commit

01 Dec, 2016

1 commit

  • 1b4d9c221   ASoC: core: Add component pin control functions ... Browse Code »

    It's often the case that a codec driver will need to control its
    own pins. However, if a name_prefix has been applied to this codec it
    must be included in the name passed to any of the snd_soc_dapm_x_pin()
    functions.

    The behaviour of the existing pin control functions is reasonable, since
    you may want to search for a fully-specified name within the scope of an
    entire card. This means that we can't apply the prefix in these functions
    because it will break card-scope searches.

    Constructing a prefixed string "manually" in codec drivers leads to a lot
    of repetition of the same code.

    To make this tidier in codec drivers this patch adds a new set of
    equivalent functions that take a struct snd_soc_component instead of a
    dapm context and automatically add the component's name_prefix to the
    given name. This makes it a simple change in codec drivers to be
    prefix-safe.

    The new functions are not quite trivial enough to be inlines and the
    compiler won't be able to compile-away any part of them.

    Although it looks somewhat inefficient to have to allocate a temporary
    buffer and combine strings, the current design of the widget list
    doesn't lend itself to a more optimized implementation - it's a single
    list of all widgets on a card and is searched linearly for a matching
    string. As pin state changes are generally low-frequency events it's
    unlikely to be a significant issue - at least not enough to rewrite the
    widget list handling just for this.

    Signed-off-by: Richard Fitzgerald
    Signed-off-by: Mark Brown

    Richard Fitzgerald
     

13 Sep, 2016

1 commit

  • 115c72548   ASoC: constify snd_pcm_ops structures ... Browse Code »

    Check for snd_pcm_ops structures that are only stored in the ops field of a
    snd_soc_platform_driver structure or passed as the third argument to
    snd_pcm_set_ops. The corresponding field or parameter is declared const,
    so snd_pcm_ops structures that have this property can be declared as const
    also.

    The semantic patch that makes this change is as follows:
    (http://coccinelle.lip6.fr/)

    //
    @r disable optional_qualifier@
    identifier i;
    position p;
    @@
    static struct snd_pcm_ops i@p = { ... };

    @ok1@
    identifier r.i;
    struct snd_soc_platform_driver e;
    position p;
    @@
    e.ops = &i@p;

    @ok2@
    identifier r.i;
    expression e1, e2;
    position p;
    @@
    snd_pcm_set_ops(e1, e2, &i@p)

    @bad@
    position p != {r.p,ok1.p,ok2.p};
    identifier r.i;
    struct snd_pcm_ops e;
    @@
    e@i@p

    @depends on !bad disable optional_qualifier@
    identifier r.i;
    @@
    static
    +const
    struct snd_pcm_ops i = { ... };
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Mark Brown

    Julia Lawall
     

31 Aug, 2015

1 commit

20 Oct, 2014

1 commit

16 Jan, 2014

1 commit

08 Jan, 2014

1 commit

30 Dec, 2013

1 commit

  • 95ab1297e   ASoC: soc-utils: Don't set unused struct snd_pcm_hardware fields ... Browse Code »

    The ASoC core assumes that the PCM component of the ASoC card transparently
    moves data around and does not impose any restrictions on the memory layout or
    the transfer speed. It ignores all fields from the snd_pcm_hardware struct for
    the PCM driver that are related to this. Setting these fields in the PCM driver
    might suggest otherwise though, so rather not set them.

    Signed-off-by: Lars-Peter Clausen
    Signed-off-by: Mark Brown

    Lars-Peter Clausen
     

17 Sep, 2013

1 commit

17 May, 2013

1 commit

17 Apr, 2013

1 commit

  • 60b6f1a1e   ASoC: define playback and capture streams in dummy codec ... Browse Code »

    This patch adds a playback and capture streams to the dummy codec DAI
    configuration. Most permissive set of sampling rates and formats is used.

    This patch is needed for playback and capturing on a codec-less systems,
    as otherwise the PCM device nodes are not even created.

    Signed-off-by: Stas Sergeev
    Signed-off-by: Mark Brown

    Stas Sergeev
     

09 Dec, 2012

1 commit

20 Jan, 2012

1 commit

  • 7aca69f9f   ASoC: utils - Add support for a dummy codec driver. ... Browse Code »

    This is useful to create dummy codec devices where we need to have some
    DAI links without a real Codec. e.g. could be used to represent dumb FM,
    MODEM, etc

    This is also used by dynamic PCM for DAI links that have no codec.

    Signed-off-by: Liam Girdwood
    [Fixed the indentation -- broonie]
    Signed-off-by: Mark Brown

    Liam Girdwood
     

06 Dec, 2011

1 commit

  • cefcc03ff   ASoC: Provide a more complete DMA driver stub ... Browse Code »
    1

    Allow userspace applications to do more parameter setting by providing a
    more complete stub DMA driver specifying a wildcard set of formats and
    channels and essentially random values for the DMA parameters. This is
    required for useful runtime operation of the dummy DMA driver until we
    are able to figure out how to power up links and do hw_params() from DAPM.

    Sending to stable as without this the dummy driver is not terribly
    useful.

    Reported-by: Kyung-Kwee Ryu
    Tested-by: Kyung-Kwee Ryu
    Signed-off-by: Mark Brown
    Cc: stable@kernel.org

    Mark Brown
     

01 Nov, 2011

1 commit

28 Apr, 2011

2 commits

01 Feb, 2011

1 commit

26 Nov, 2009

1 commit

13 Nov, 2009

1 commit