15 Dec, 2012

2 commits

  • Mark Brown
     
  • pop_wait is used to determine if a deferred playback close
    needs to be cancelled when the a PCM is open or if after
    the power-down delay expires it needs to run. pop_wait is
    associated with the CODEC DAI, so the CODEC DAI must be
    unique. This holds true for most CODECs, except for the
    dummy CODEC and its DAI.

    In DAI links with non-unique dummy CODECs (e.g. front-ends),
    pop_wait can be overwritten by another DAI link using also a
    dummy CODEC. Failure to cancel a deferred close can cause
    mute due to the DAPM STOP event sent in the deferred work.

    One scenario where pop_wait is overwritten and causing mute
    is below (where hw:0,0 and hw:0,1 are two front-ends with
    default pmdown_time = 5 secs):

    aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE -d 1
    sleep 1
    aplay /dev/urandom -D hw:0,1 -c 2 -r 48000 -f S16_LE -d 3 &
    aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE

    Since CODECs may not be unique, pop_wait is moved to the PCM
    runtime structure. Creating separate dummy CODECs for each
    DAI link can also solve the problem, but at this point it's
    only pop_wait variable in the CODEC DAI that has negative
    effects by not being unique.

    Signed-off-by: Misael Lopez Cruz
    Signed-off-by: Mark Brown

    Misael Lopez Cruz
     

28 Nov, 2012

1 commit


21 Nov, 2012

1 commit

  • Currently ASoC has a mixture of message prefixes e.g. "ASoC", "asoc"
    or none and message types e.g. pr_debug or dev_dbg.

    Make sure all ASoC core messages use the same "ASoC" prefix and
    convert any component device specific messages to use dev_dbg
    instead of pr_debug.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood
     

07 Jul, 2012

2 commits


08 Jun, 2012

1 commit


10 May, 2012

1 commit


08 May, 2012

1 commit

  • When we instantiate an aux_dev we use a fake rtd as part of the process
    which doesn't have a dai_link associated with it. Fix the dpcm startup
    code to cope with this.

    Signed-off-by: Mark Brown
    Acked-by: Liam Girdwood

    Mark Brown
     

28 Apr, 2012

1 commit


27 Apr, 2012

5 commits

  • Provide an ioctl marshaller for ASoC platform drivers.
    This will use the default ALSA handler if no platform
    handler exists.

    This is also required for DPCM BE PCMs as snd_pcm_info()
    will call the ioctl as part of stream startup.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood
     
  • Some on SoC DSP HW is very tightly coupled with DMA and DAI drivers. It's
    necessary to allow some flexability wrt to PCM operations here so that we
    can define a bespoke DPCM trigger() PCM operation for such HW.

    A bespoke DPCM trigger() allows exact ordering and timing of component
    triggering by allowing a component driver to manage the final enable
    and disable configurations without adding extra complexity to other
    component drivers. e.g. The McPDM DAI and ABE are tightly coupled on
    OMAP4 so we have a bespoke trigger to manage the trigger to improve
    performance and reduce complexity when triggering new McPDM BEs.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood
     
  • This patch allows DPCM to dynamically alter the FE to BE PCM links
    at runtime based on mixer setting updates. DAPM is looked up after
    every mixer update and we perform a DPCM runtime update if the
    mixer has a change of value.

    This patchs adds/changes the following :-

    o Adds DPCM runtime update core.
    o Changes soc_dapm_mixer_update_power() and soc_dapm_mux_update_power()
    to return if a change has occured rather than 0. No other users check
    atm.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood
     
  • Add debugFS files for DPCM link management information.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood
     
  • The Dynamic PCM core allows digital audio data to be dynamically
    routed between different ALSA PCMs and DAI links on SoC CPUs with
    on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
    routed to any (or all) SoC DAI links.

    Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
    End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
    they can dynamically route digital audio data to any supported BE
    PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
    substream and audio HW parameters.

    e.g. pcm:0,0 routing digital data to 2 external codecs.

    FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
    +--> BE (McPDM.0) ----> CODEC 1

    e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.

    FE pcm:0,0 ---
    +--> BE (McBSP.0) ----> CODEC
    FE pcm:0,1 ---

    The digital audio routing is controlled by the usual ALSA method
    of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
    routing based upon the mixer settings and configures the BE PCMs
    based on routing and the FE HW params.

    DPCM is designed so that most ASoC component drivers will need no
    modification at all. It's intended that existing CODEC, DAI and
    platform drivers can be used in DPCM based audio devices without
    any changes. However, there will be some cases where minor changes
    are required (e.g. for very tightly coupled HW) and there are
    helpers to support this too.

    Somethimes the HW params of a FE and BE do not match or are
    incompatible, so in these cases the machine driver can reconfigure
    any hw_params and make any DSP perform sample rate / format conversion.

    This patch adds the core DPCM code and contains :-

    o The FE and BE PCM operations.
    o FE and BE DAI link support.
    o FE and BE PCM creation.
    o BE support API.
    o BE and FE link management.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood
     

01 Apr, 2012

1 commit

  • Currently stream events are only perfomed on codec stream widgets only.
    There is now a need to be able to perform stream events on platform
    widgets too.

    e.g. we have the ABE platform driver with several DAI links
    to dummy codecs. We need to be able to perform stream events on any
    of the dummy codec DAI links.

    This patch also removes the snd_soc_dai * parameter since it's already
    contained within the rtd * parameter.

    Finally makle stream event return void since no one checks it anyway.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood
     

18 Feb, 2012

1 commit

  • In order to allow us to do something smarter than iterate through widgets
    doing strcmp() to work out what to power up for stream events change the
    interface used to generate them to be based on the combination of a DAI
    and a stream direction rather than just a simple string identifying the
    stream.

    At some point we'll probably want a set of channels too.

    Signed-off-by: Mark Brown
    Acked-by: Liam Girdwood

    Mark Brown
     

09 Feb, 2012

1 commit


02 Feb, 2012

1 commit

  • Use the standard logging macros and use dev_ variants where we can, also
    reporting error codes whenever we report an error. These changes (the
    error codes in particular) make it noticeably easier to figure out what
    went wrong just from the basic dmesg output.

    Signed-off-by: Mark Brown
    Acked-by: Liam Girdwood

    Mark Brown
     

25 Jan, 2012

1 commit


22 Jan, 2012

1 commit


20 Jan, 2012

1 commit

  • Most devices accept data in formats that don't correspond directly to
    their internal format. ALSA allows us to set a msbits constraint which
    tells userspace about this in case it finds it useful (for example, in
    order to avoid wasting effort dithering bits that will be ignored when
    raising the sample size of data) so provide a mechanism for drivers to
    specify the number of bits that are actually significant on a DAI and
    add the appropriate constraints along with all the others.

    This is done slightly awkwardly as the constraint is specified per sample
    size - we loop over every possible sample size, including ones that the
    device doesn't support and including ones that have fewer bits than are
    actually used, but this is harmless as the upper layers do the right thing
    in these cases.

    Signed-off-by: Mark Brown
    Acked-by: Liam Girdwood

    Mark Brown
     

04 Jan, 2012

1 commit

  • The original code does not cover the case that two DAIs(CPU) have different
    ASoC core PCM operations(like mmap, pointer...). Currently we have only one
    global soc_pcm_ops for ASoC core PCM operation. When two DAIs have different
    pointer functions, second DAI's pointer function is set for both first DAI
    and second DAI in case of original code.

    This patch uses runtime's pcm_ops instead of global pcm_ops for each DAIs. So
    each DAIs can have different ASoC core PCM operations. This is needed to
    support multiple DAIs.

    Signed-off-by: Sangsu Park
    Signed-off-by: Mark Brown

    Sangsu Park
     

08 Dec, 2011

1 commit

  • Every device that implements runtime power management for DAIs is doing
    it in pretty much the same way: in the startup callback they take a
    runtime PM reference and then in the shutdown callback they release that
    reference, keeping the device active while the DAI is active. Given the
    frequency with which this is done and the obviousness of the need to keep
    the device active in this period factor the code out into the core, taking
    references on the device for each CPU DAI, CODEC DAI and DMA device in the
    core.

    As runtime PM is reference counted this shouldn't interfere with any
    other reference holding by the drivers, and since (in common with the
    existing implementations) we don't check for errors on enabling it
    shouldn't matter if the device actually has runtime PM enabled or not.

    Signed-off-by: Mark Brown
    Tested-by: Peter Ujfalusi

    Mark Brown
     

05 Nov, 2011

1 commit

  • There's no point in adding unlikely() annotations outside of hot paths
    and on systems using these features the annotation will always be wrong
    (as opposed to being something that only comes up once in a while) so
    the annotation may even be harmful.

    Signed-off-by: Mark Brown

    Mark Brown
     

27 Oct, 2011

1 commit


15 Oct, 2011

1 commit


21 Sep, 2011

1 commit

  • The orginal code does not cover the case that one DAI such as codec
    may be shared between other two DAIs(CPU).
    When do symmetry checking, altough the codec DAI requires symmetry,
    the two CPU DAIs may still be configured to run on different rates.

    We change to check each DAI's state separately instead of only checking
    the dai link to prevent this issue.

    Signed-off-by: Dong Aisheng
    Tested-by: Wolfram Sang
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Dong Aisheng
     

17 Aug, 2011

2 commits

  • Mark Brown
     
  • The ASoC core tries to not enforce symmetric rates when
    two streams open simultaneously. It does so by checking
    rtd->rate being zero. This works exactly once after booting
    because it is not set to zero again when the streams close.
    Fix this by setting rtd->rate when no active stream is left.

    [This leads to lots of warnings about not enforcing the symmetry in some
    situations as there's a race in the userspace API where we know we've
    got two applications but don't know what rates they want to set.
    -- broonie ]

    Signed-off-by: Sascha Hauer
    Signed-off-by: Mark Brown

    Sascha Hauer
     

15 Aug, 2011

1 commit


10 Jun, 2011

2 commits

  • Make sure we follow naming convention for all PCM ops.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood
     
  • In preparation for the new ASoC Dynamic PCM support (AKA DSP support).

    The new ASoC Dynamic PCM core allows DAIs to be dynamically re-routed
    at runtime between the PCM device end (or Frontend - FE) and the physical DAI
    (Backend - BE) using regular kcontrols (just like a hardware CODEC routes
    audio in the analog domain). The Dynamic PCM core therefore must be
    able to call PCM operations for both the Frontend and Backend(s) DAIs at
    the same time.

    Currently we have a global pcm_mutex that is used to serialise
    the ASoC PCM operations. This patch removes the global mutex
    and adds a mutex per RTD allowing the PCM operations to be reentrant and
    allow control of more than one DAI at at time. e.g. a frontend PCM hw_params()
    could configure multiple backend DAI hw_params() with similar or different
    hw parameters at the same time.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood
     

09 Jun, 2011

1 commit

  • In preparation for Dynamic PCM support (AKA DSP support).

    There will be future patches that add support to allow PCMs to be dynamically
    routed to multiple DAIs at startup and also during stream runtime. This patch
    moves the ASoC core PCM operaitions into a new file called soc-pcm.c. This will
    in simplify the ASoC core features into distinct files.

    Signed-off-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Liam Girdwood