Skip to content
Snippets Groups Projects
  1. Feb 08, 2019
    • Daniel Vetter's avatar
      i915/snd_hdac: I915 subcomponent for the snd_hdac · 8857c7d0
      Daniel Vetter authored
      
      Since we need multiple components for I915 for different purposes
      (Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
      by the previous patch (mentioned below).
      
      	Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      	Date:   Mon Jan 28 17:08:20 2019 +0530
      
      	    components: multiple components for a device
      
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by-by: Ramalingam C <ramalinagm.c@intel.com> (commit message)
      Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (code)
      cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc: Russell King <rmk+kernel@arm.linux.org.uk>
      cc: Rafael J. Wysocki <rafael@kernel.org>
      cc: Jaroslav Kysela <perex@perex.cz>
      cc: Takashi Iwai <tiwai@suse.com>
      cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      cc: Jani Nikula <jani.nikula@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190207232759.14553-4-daniel.vetter@ffwll.ch
      8857c7d0
  2. Feb 05, 2019
    • Charles Keepax's avatar
      ALSA: compress: Fix stop handling on compressed capture streams · 4f2ab5e1
      Charles Keepax authored
      
      It is normal user behaviour to start, stop, then start a stream
      again without closing it. Currently this works for compressed
      playback streams but not capture ones.
      
      The states on a compressed capture stream go directly from OPEN to
      PREPARED, unlike a playback stream which moves to SETUP and waits
      for a write of data before moving to PREPARED. Currently however,
      when a stop is sent the state is set to SETUP for both types of
      streams. This leaves a capture stream in the situation where a new
      start can't be sent as that requires the state to be PREPARED and
      a new set_params can't be sent as that requires the state to be
      OPEN. The only option being to close the stream, and then reopen.
      
      Correct this issues by allowing snd_compr_drain_notify to set the
      state depending on the stream direction, as we already do in
      set_params.
      
      Fixes: 49bb6402 ("ALSA: compress_core: Add support for capture streams")
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4f2ab5e1
  3. Feb 01, 2019
    • Takashi Iwai's avatar
      ALSA: hda - Serialize codec registrations · 305a0ade
      Takashi Iwai authored
      
      In the current code, the codec registration may happen both at the
      codec bind time and the end of the controller probe time.  In a rare
      occasion, they race with each other, leading to Oops due to the still
      uninitialized card device.
      
      This patch introduces a simple flag to prevent the codec registration
      at the codec bind time as long as the controller probe is going on.
      The controller probe invokes snd_card_register() that does the whole
      registration task, and we don't need to register each piece
      beforehand.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      305a0ade
  4. Jan 14, 2019
    • Curtis Malainey's avatar
      ASoC: soc-core: fix init platform memory handling · 09ac6a81
      Curtis Malainey authored
      
      snd_soc_init_platform initializes pointers to snd_soc_dai_link which is
      statically allocated and it does this by devm_kzalloc. In the event of
      an EPROBE_DEFER the memory will be freed and the pointers are left
      dangling. snd_soc_init_platform sees the dangling pointers and assumes
      they are pointing to initialized memory and does not reallocate them on
      the second probe attempt which results in a use after free bug since
      devm has freed the memory from the first probe attempt.
      
      Since the intention for snd_soc_dai_link->platform is that it can be set
      statically by the machine driver we need to respect the pointer in the
      event we did not set it but still catch dangling pointers. The solution
      is to add a flag to track whether the pointer was dynamically allocated
      or not.
      
      Signed-off-by: default avatarCurtis Malainey <cujomalainey@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Unverified
      09ac6a81
  5. Dec 19, 2018
  6. Dec 14, 2018
  7. Dec 11, 2018
    • Takashi Iwai's avatar
      ALSA: hda: Make snd_hdac_display_power() void function · 4f799e73
      Takashi Iwai authored
      
      After the recent refactoring, snd_hdac_display_power() doesn't return
      any error, hence it can be defined to return void.
      This makes many error checks redundant and allows us to reduce them
      gracefully.
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4f799e73
    • Takashi Iwai's avatar
      ALSA: hda: Refactor display power management · 029d92c2
      Takashi Iwai authored
      The current HD-audio code manages the DRM audio power via too complex
      redirections, and this seems even still unbalanced in a corner case as
      Intel DRM CI has been intermittently reporting.  This patch is a big
      surgery for addressing the complexity and the possible unbalance.
      
      Basically the patch changes the display PM in the following ways:
      
      - Both HD-audio controller and codec drivers call a single helper,
        snd_hdac_display_power().  (Formerly, the display power control from
        a codec was done indirectly via link_power bus ops.)
      
      - snd_hdac_display_power() receives the codec address index.  For
        turning on/off from the controller, pass HDA_CODEC_IDX_CONTROLLER.
      
      - snd_hdac_display_power() doesn't manage refcounts any longer, but
        keeps the power status in bitmap.  If any of controller or codecs is
        turned on, the function updates the DRM power state via get_power()
        or put_power().
      
      Also this refactor allows us more cleanup:
      
      - The link_power bus ops is dropped, so there is no longer indirect
        management, as mentioned in the above.
      
      - hdac_device link_power_control flag is moved to hda_codec
        display_power_control flag, as it's only for HDA legacy.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106525
      
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      029d92c2
  8. Dec 03, 2018
  9. Nov 29, 2018
  10. Nov 26, 2018
  11. Nov 23, 2018
  12. Nov 21, 2018
  13. Nov 20, 2018
  14. Nov 06, 2018
  15. Nov 05, 2018
    • Arnd Bergmann's avatar
      ASoC: wm97xx: fix uninitialized regmap pointer problem · 576ce407
      Arnd Bergmann authored
      
      gcc notices that without either the ac97 bus or the pdata, we never
      initialize the regmap pointer, which leads to an uninitialized variable
      access:
      
      sound/soc/codecs/wm9712.c: In function 'wm9712_soc_probe':
      sound/soc/codecs/wm9712.c:666:2: error: 'regmap' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      Since that configuration is invalid, it's better to return an error
      here. I tried to avoid adding complexity to the conditions, and turned
      the #ifdef into a regular if(IS_ENABLED()) check for readability.
      This in turn requires moving some header file declarations out of
      an #ifdef.
      
      The same code is used in three drivers, all of which I'm changing
      the same way.
      
      Fixes: 2ed1a8e0 ("ASoC: wm9712: add ac97 new bus support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Unverified
      576ce407
  16. Oct 30, 2018
  17. Oct 04, 2018
  18. Sep 21, 2018
  19. Sep 20, 2018
  20. Sep 12, 2018
    • Yu Zhao's avatar
      sound: don't call skl_init_chip() to reset intel skl soc · 75383f8d
      Yu Zhao authored
      
      Internally, skl_init_chip() calls snd_hdac_bus_init_chip() which
      1) sets bus->chip_init to prevent multiple entrances before device
      is stopped; 2) enables interrupt.
      
      We shouldn't use it for the purpose of resetting device only because
      1) when we really want to initialize device, we won't be able to do
      so; 2) we are ready to handle interrupt yet, and kernel crashes when
      interrupt comes in.
      
      Rename azx_reset() to snd_hdac_bus_reset_link(), and use it to reset
      device properly.
      
      Fixes: 60767abc ("ASoC: Intel: Skylake: Reset the controller in probe")
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarYu Zhao <yuzhao@google.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Unverified
      75383f8d
    • Srinivas Kandagatla's avatar
      ASoC: core: add support to card rebind · e894efef
      Srinivas Kandagatla authored
      
      Current behaviour of ASoC core w.r.t to component removal is that it
      unregisters dependent sound card totally. There is no support to
      rebind the card if the component comes back.
      Typical use case is DSP restart or kernel modules itself.
      
      With this patch, core now maintains list of cards that are unbind due to
      any of its depended components are removed and card not unregistered yet.
      This list is cleared when the card is rebind successfully or when the
      card is unregistered from machine driver.
      
      This list of unbind cards are tried to bind once again after every new
      component is successfully added, giving a fair chance for card bind
      to be successful.
      
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Unverified
      e894efef
  21. Sep 11, 2018
  22. Sep 05, 2018
  23. Sep 04, 2018
  24. Aug 31, 2018
    • Kuninori Morimoto's avatar
      ASoC: simple-card-util: support snd_soc_dai_link_component style for platform · 868cdb46
      Kuninori Morimoto authored
      
      Current ASoC is supporting snd_soc_dai_link_component for binding,
      it is more useful than current legacy style.
      Currently only codec is supporting it as multicodec (= codecs).
      CPU will support multi style in the future.
      We want to have it on Platform too in the future.
      
      If all Codec/CPU/Platform are replaced into snd_soc_dai_link_component
      style, we can remove legacy complex style.
      This patch supports snd_soc_dai_link_component style
      for simple-card-util for platform.
      
      [current]
      struct snd_soc_dai_link {
      	...
      	*cpu_name;
      	*cpu_of_node;
      	*cpu_dai_name;
      
      	*codec_name;
      	*codec_of_node;
      	*codec_dai_name;
      	*codecs;
      	num_codecs;
      
      	*platform_name;
      	*platform_of_node;
      	...
      }
      
      [in the future]
      struct snd_soc_dai_link {
      	...
      	*cpus
      	num_cpus;
      
      	*codecs;
      	num_codecs;
      
      	*platform;
      	...
      }
      
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Unverified
      868cdb46
    • Kuninori Morimoto's avatar
      ASoC: soc-core: use snd_soc_dai_link_component for platform · daecf46e
      Kuninori Morimoto authored
      
      Current struct snd_soc_dai_link is supporting multicodec,
      and it is supporting legacy style of
      	codec_name
      	codec_of_node
      	code_dai_name
      This is handled as single entry of multicodec.
      
      We don't have multicpu support yet, but in the future we will.
      In such case, we can use snd_soc_dai_link_component for both
      cpu/codec. Then the code will be more simple and readble.
      
      As next step, we want to use it for platform, too.
      This patch adds snd_soc_dai_link_component style for platform.
      We might have multiplatform support in the future, but we
      don't know yet. To avoid un-known issue / complex code,
      this patch supports just single-platform as 1st step.
      
      If we could use snd_soc_dai_link_component for all CPU/Codec/Platform,
      we will switch to new style, and remove legacy code.
      This is prepare for it.
      
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Unverified
      daecf46e
    • Kuninori Morimoto's avatar
      ASoC: simple_card_utils: support snd_soc_dai_link_component style for codec · e664de68
      Kuninori Morimoto authored
      
      Current ASoC is supporting snd_soc_dai_link_component for binding,
      it is more useful than current legacy style.
      Currently only codec is supporting it as multicodec (= codecs).
      CPU will support multi style in the future.
      We want to have it on Platform too in the future.
      
      If all Codec/CPU/Platform are replaced into snd_soc_dai_link_component
      style, we can remove legacy complex style.
      This patch supports snd_soc_dai_link_component style
      for simple_card_utils for codec.
      
      [current]
      struct snd_soc_dai_link {
      	...
      	*cpu_name;
      	*cpu_of_node;
      	*cpu_dai_name;
      
      	*codec_name;
      	*codec_of_node;
      	*codec_dai_name;
      	*codecs;
      	num_codecs;
      
      	*platform_name;
      	*platform_of_node;
      	...
      }
      
      [in the future]
      struct snd_soc_dai_link {
      	...
      	*cpus
      	num_cpus;
      
      	*codecs;
      	num_codecs;
      
      	*platform;
      	...
      }
      
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Unverified
      e664de68
  25. Aug 30, 2018
Loading