1. 24 Jul, 2019 1 commit
  2. 23 Jul, 2019 2 commits
  3. 22 Jul, 2019 5 commits
    • Wenwen Wang's avatar
      ASoC: dapm: fix a memory leak bug · 45004d66
      Wenwen Wang authored
      In snd_soc_dapm_new_control_unlocked(), a kernel buffer is allocated in
      dapm_cnew_widget() to hold the new dapm widget. Then, different actions are
      taken according to the id of the widget, i.e., 'w->id'. If any failure
      occurs during this process, snd_soc_dapm_new_control_unlocked() should be
      terminated by going to the 'request_failed' label. However, the allocated
      kernel buffer is not freed on this code path, leading to a memory leak bug.
      
      To fix the above issue, free the buffer before returning from
      snd_soc_dapm_new_control_unlocked() through the 'request_failed' label.
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Link: https://lore.kernel.org/r/1563803864-2809-1-git-send-email-wang6495@umn.eduSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      45004d66
    • Masahiro Yamada's avatar
      ASoC: SOF: use __u32 instead of uint32_t in uapi headers · 62ec3d13
      Masahiro Yamada authored
      When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
      make sure they can be included from user-space.
      
      Currently, header.h and fw.h are excluded from the test coverage.
      To make them join the compile-test, we need to fix the build errors
      attached below.
      
      For a case like this, we decided to use __u{8,16,32,64} variable types
      in this discussion:
      
        https://lkml.org/lkml/2019/6/5/18
      
      Build log:
      
        CC      usr/include/sound/sof/header.h.s
        CC      usr/include/sound/sof/fw.h.s
      In file included from <command-line>:32:0:
      ./usr/include/sound/sof/header.h:19:2: error: unknown type name ‘uint32_t’
        uint32_t magic;  /**< 'S', 'O', 'F', '\0' */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:20:2: error: unknown type name ‘uint32_t’
        uint32_t type;  /**< component specific type */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:21:2: error: unknown type name ‘uint32_t’
        uint32_t size;  /**< size in bytes of data excl. this struct */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:22:2: error: unknown type name ‘uint32_t’
        uint32_t abi;  /**< SOF ABI version */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:23:2: error: unknown type name ‘uint32_t’
        uint32_t reserved[4]; /**< reserved for future use */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:24:2: error: unknown type name ‘uint32_t’
        uint32_t data[0]; /**< Component data - opaque to core */
        ^~~~~~~~
      In file included from <command-line>:32:0:
      ./usr/include/sound/sof/fw.h:49:2: error: unknown type name ‘uint32_t’
        uint32_t size;  /* bytes minus this header */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:50:2: error: unknown type name ‘uint32_t’
        uint32_t offset; /* offset from base */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:64:2: error: unknown type name ‘uint32_t’
        uint32_t size;  /* bytes minus this header */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:65:2: error: unknown type name ‘uint32_t’
        uint32_t num_blocks; /* number of blocks */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:73:2: error: unknown type name ‘uint32_t’
        uint32_t file_size; /* size of file minus this header */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:74:2: error: unknown type name ‘uint32_t’
        uint32_t num_modules; /* number of modules */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:75:2: error: unknown type name ‘uint32_t’
        uint32_t abi;  /* version of header format */
        ^~~~~~~~
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Link: https://lore.kernel.org/r/20190721142308.30306-1-yamada.masahiro@socionext.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      62ec3d13
    • Enric Balletbo i Serra's avatar
      SoC: rockchip: rockchip_max98090: Enable MICBIAS for headset keypress detection · f86621cd
      Enric Balletbo i Serra authored
      The TS3A227E says that the headset keypress detection needs the MICBIAS
      power in order to report the key events to ensure proper operation
      The headset keypress detection needs the MICBIAS power in order to report
      the key events all the time as long as MIC is present. So MICBIAS pin
      is forced on when a MICROPHONE is detected.
      
      On Veyron Minnie I observed that if the MICBIAS power is not present and
      the key press detection is activated (just because it is enabled when you
      insert a headset), it randomly reports a keypress on insert.
      E.g. (KEY_PLAYPAUSE)
      
       Event: (SW_HEADPHONE_INSERT), value 1
       Event: (SW_MICROPHONE_INSERT), value 1
       Event: -------------- SYN_REPORT ------------
       Event: (KEY_PLAYPAUSE), value 1
      
      Userspace thinks that KEY_PLAYPAUSE is pressed and produces the annoying
      effect that the media player starts a play/pause loop.
      
      Note that, although most of the time the key reported is the one
      associated with BTN_0, not always this is true. On my tests I also saw
      different keys reported
      Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Link: https://lore.kernel.org/r/20190719173929.24065-1-enric.balletbo@collabora.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      f86621cd
    • Shengjiu Wang's avatar
      ASoC: cs42xx8: Fix MFREQ selection issue for async mode · 48dfd37a
      Shengjiu Wang authored
      When sample rate of TX is different with sample rate of RX in
      async mode, the MFreq selection will be wrong.
      
      For example, sysclk = 24.576MHz, TX rate = 96000Hz, RX rate = 48000Hz.
      Then ratio of TX = 256, ratio of RX = 512, For MFreq is shared by TX
      and RX instance, the correct value of MFreq is 2 for both TX and RX.
      
      But original method will cause MFreq = 0 for TX, MFreq = 2 for RX.
      If TX is started after RX, RX will be impacted, RX work abnormal with
      MFreq = 0.
      
      This patch is to select proper MFreq value according to TX rate and
      RX rate.
      
      Fixes: 0c516b4f ("ASoC: cs42xx8: Add codec driver support for CS42448/CS42888")
      Signed-off-by: default avatarShengjiu Wang <shengjiu.wang@nxp.com>
      Link: https://lore.kernel.org/r/20190716094547.46787-1-shengjiu.wang@nxp.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      48dfd37a
    • Charles Keepax's avatar
      ASoC: dapm: Fix handling of custom_stop_condition on DAPM graph walks · 8dd26dff
      Charles Keepax authored
      DPCM uses snd_soc_dapm_dai_get_connected_widgets to build a
      list of the widgets connected to a specific front end DAI so it
      can search through this list for available back end DAIs. The
      custom_stop_condition was added to is_connected_ep to facilitate this
      list not containing more widgets than is necessary. Doing so both
      speeds up the DPCM handling as less widgets need to be searched and
      avoids issues with CODEC to CODEC links as these would be confused
      with back end DAIs if they appeared in the list of available widgets.
      
      custom_stop_condition was implemented by aborting the graph walk
      when the condition is triggered, however there is an issue with this
      approach. Whilst walking the graph is_connected_ep should update the
      endpoints cache on each widget, if the walk is aborted the number
      of attached end points is unknown for that sub-graph. When the stop
      condition triggered, the original patch ignored the triggering widget
      and returned zero connected end points; a later patch updated this
      to set the triggering widget's cache to 1 and return that. Both of
      these approaches result in inaccurate values being stored in various
      end point caches as the values propagate back through the graph,
      which can result in later issues with widgets powering/not powering
      unexpectedly.
      
      As the original goal was to reduce the size of the widget list passed
      to the DPCM code, the simplest solution is to limit the functionality
      of the custom_stop_condition to the widget list. This means the rest
      of the graph will still be processed resulting in correct end point
      caches, but only widgets up to the stop condition will be added to the
      returned widget list.
      
      Fixes: 6742064a ("ASoC: dapm: support user-defined stop condition in dai_get_connected_widgets")
      Fixes: 5fdd022c ("ASoC: dpcm: play nice with CODEC<->CODEC links")
      Fixes: 09464974 ("ASoC: dapm: Fix to return correct path list in is_connected_ep.")
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20190718084333.15598-1-ckeepax@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      8dd26dff
  4. 16 Jul, 2019 3 commits
  5. 11 Jul, 2019 2 commits
  6. 10 Jul, 2019 9 commits
  7. 06 Jul, 2019 3 commits
  8. 05 Jul, 2019 4 commits
  9. 03 Jul, 2019 4 commits
  10. 02 Jul, 2019 7 commits