Skip to content
Snippets Groups Projects
  1. Mar 13, 2019
  2. Feb 14, 2019
  3. Feb 12, 2019
  4. Feb 08, 2019
    • Pierre-Louis Bossart's avatar
      ASoC: core: don't increase component module refcount unconditionally · b450b878
      Pierre-Louis Bossart authored
      
      The ASoC core has for the longest time increased the module reference
      counts, even before the transition to the component model. This is
      probably fine on most platforms, but it introduces a deadlock case on
      Intel devices with the Skylake and SOF drivers which cannot be removed
      due to their reference counts being modified by the core.
      
      In these 2 cases, the PCI or ACPI driver .probe creates a platform
      device to let the machine driver .probe register the audio
      card. Conversely the PCI or ACPI driver .remove will unregister the
      platform device which results in the card being removed by the machine
      driver .remove.
      
      With ascii art, this can be represented as
      
      modprobe
      snd_soc_skl/
      soc-pci-dev/sof-acpci-dev  ----------> pci/acpi probe
             ^                                    |
             |                     ---------------|
             |                    |               |
             |                    V               V
          increase            register        register machine
          refcount            component       platform_device
             ^                                    |
             |                                    |
             |                                    V
          component <----   register card  <---- probe
          probe
      
      The issue is that by playing with the component's module reference
      counts during the card registration, it's no longer possible to remove
      the module which controls the component. This can be shown, e.g. with
      the following error:
      
      root@plb-XPS-13-9350:~# lsmod | grep snd_soc_skl
      snd_soc_skl           110592  1
      
      root@plb-XPS-13-9350:~# rmmod snd_soc_skl
      rmmod: ERROR: Module snd_soc_skl is in use
      
      Increasing the reference count during the component probe is not
      useful. If the PCI/ACPI module is removed, the card will be removed
      anyway.
      
      To avoid breaking existing platforms and allowing Intel platforms to
      safely deal with module load/unload cases, this patch introduces a
      flag which needs to be set during the component initialization. This
      is a strictly opt-in capability that should only be used when the
      handling of the component module does not require a reference count
      increase to prevent removal during use.
      
      Note that this solution is not directly applicable to the legacy
      Atom/SST driver, which uses a different device hierarchy. There are
      however additional refcount issues which prevent the ACPI driver from
      being removed. This is a different issue which would need a different
      patch.
      
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      b450b878
    • 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
    • Takashi Iwai's avatar
      ALSA: pcm: Define snd_pcm_lib_preallocate_*() as returning void · bb580602
      Takashi Iwai authored
      
      Now all callers no longer check the return value from
      snd_pcm_lib_preallocate_pages() and co, let's make them to return
      void, so that any new code won't fall into the same pitfall.
      
      Reviewed-by: default avatarJaroslav Kysela <perex@perex.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      bb580602
    • James Schulman's avatar
      ASoC: cs35l36: Add support for Cirrus CS35L36 Amplifier · 6ba9dd6c
      James Schulman authored
      
      Add driver support for Cirrus Logic CS35L36 boosted
      speaker amplifier
      
      Signed-off-by: default avatarJames Schulman <james.schulman@cirrus.com>
      Reviewed-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Acked-by: default avatarBrian Austin <brian.austin@cirrus.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      6ba9dd6c
  5. Feb 06, 2019
  6. 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
  7. Feb 04, 2019
  8. Feb 02, 2019
    • Charles Keepax's avatar
      ASoC: dapm: Only power up active channels from a DAI · 078a85f2
      Charles Keepax authored
      
      Currently all widgets attached to a DAI link will be powered
      up when the DAI is active, however this may include routes
      that are not actually in use if there are unused channels
      available on the DAI.
      
      The macros for creating AIF widgets already include an entry for
      slot, it is proposed to change that to channel. The effective
      difference here being respresenting the logical channel index
      rather than the physical slot index. The CODECs currently
      using the slot entry on the DAPM_AIF macros are using it in
      a manner consistent with this, the CODECs not using it just
      have the field set to zero.
      
      A variable is added to snd_soc_dapm_widget to represent
      this channel index and then for each AIF widget attached to
      a DAI this is compared against the number of channels on
      the stream. Enabling the links for those which will be in
      use. This has the nice property that the CODECs which haven't
      used the slot/channel entry in the macro will function exactly
      as before due to all the AIF widgets having a channel of zero
      and a stream by definition having at least one channel.
      
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      078a85f2
  9. Feb 01, 2019
    • Takashi Iwai's avatar
      ALSA: isa: Avoid passing NULL to memory allocators · 0b6a2c9c
      Takashi Iwai authored
      
      We used to pass NULL to memory allocators for ISA devices due to
      historical reasons.  But we prefer rather a proper device object to be
      assigned, so let's fix it by replacing snd_dma_isa_data() call with
      card->dev reference, and kill snd_dma_isa_data() definition.
      
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0b6a2c9c
    • 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
  10. Jan 29, 2019
  11. Jan 28, 2019
  12. Jan 24, 2019
  13. Jan 23, 2019
    • Takashi Iwai's avatar
      ALSA: pcm: More fine-grained PCM link locking · f57f3df0
      Takashi Iwai authored
      
      We have currently two global locks, a rwlock and a rwsem, that are
      used for managing linking the PCM streams.  Due to these global locks,
      once when a linked stream is used, the lock granularity suffers a
      lot.
      
      This patch attempts to eliminate the former global lock for atomic
      ops.  The latter rwsem needs remaining because of the loosy way of the
      loop calls in snd_pcm_action_nonatomic(), as well as for avoiding the
      deadlock at linking.  However, these are used far rarely, actually
      only by two actions (prepare and  reset), where both are no timing
      critical ones.  So this can be still seen as a good improvement.
      
      The basic strategy to eliminate the rwlock is to assure group->lock at
      adding or removing a stream to / from the group.  Since we already
      takes the group lock whenever taking the all substream locks under the
      group, this shouldn't be a big problem.  The reference to group
      pointer in snd_pcm_substream object is protected by the stream lock
      itself.
      
      However, there are still pitfalls: a race window at re-locking and the
      lifecycle of group object.  The former is a small race window for
      dereferencing the substream group object opened while snd_pcm_action()
      performs re-locking to avoid ABBA deadlocks.  This includes the unlink
      of group during that window, too.  And the latter is the kfree
      performed after all streams are removed from the group while it's
      still dereferenced.
      
      For addressing these corner cases, two new tricks are introduced:
      - After re-locking, the group assigned to the stream is checked again;
        if the group is changed, we retry the whole procedure.
      - Introduce a refcount to snd_pcm_group object, so that it's freed
        only when it's empty and really no one refers to it.
      
      (Some readers might wonder why not RCU for the latter.  RCU in this
      case would cost more than refcounting, unfortunately.  We take the
      group lock sooner or later, hence the performance improvement by RCU
      would be negligible.  Meanwhile, because we need to deal with
      schedulable context depending on the pcm->nonatomic flag, it'll become
      dynamic RCU/SRCU switch, and the grace period may become too long.)
      
      Along with these changes, there are a significant amount of code
      refactoring.  The complex group re-lock & ref code is factored out to
      snd_pcm_stream_group_ref() function, for example.
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f57f3df0
  14. Jan 21, 2019
  15. Jan 18, 2019
    • Kuninori Morimoto's avatar
      ASoC: soc.h: add explanation of legacy/modern style of dai_link · 62bc79d3
      Kuninori Morimoto authored
      
      Current ALSA SoC is assuming 1 CPU 1 Platform (= DMA) style system.
      Because of this background, it is directly using
      xxx_name / xxx_of_node / xxx_dai_name on dai_link.
      Let's call it as legacy style here.
      
      More complex style system like multi CPU multi Platform (= DMA) will
      coming. To supporting it, we can use snd_soc_dai_link_component on
      dai_link. Let's call it as modern style here.
      But current ALSA SoC can't support it so far. Thus, we need to have
      multi CPU / multi Codec / multi Platform style in the future on ALSA SoC.
      
      Currently we already have multi Codec support. Platform is starting to
      use modern style on dai_link, but still style only. Multi Platform is
      not yet implemented. And we still don't have multi CPU support on ALSA
      SoC, and not have modern style either.
      
      Currently, if driver is using legacy style Codec/Platform, it will be
      converted to modern style on soc-core. This means, we are using glue code
      for legacy vs modern style so far on ALSA SoC.
      We can fully switch to modern style on all drivers if ALSA SoC supported
      modern style for CPU, and then, legacy style code will be removed from
      ALSA SoC.
      Untile then, we need to keep both legacy/modern style and its glue code.
      This patch adds such future plan and background on soc.h
      
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      62bc79d3
  16. Jan 15, 2019
    • Takashi Iwai's avatar
      ALSA: pcm: Make snd_pcm_suspend() local static · ce7f93e2
      Takashi Iwai authored
      
      snd_pcm_suspend() is no longer called from outside, so let's make it
      local static.  Also drop a superfluous NULL check there.
      
      Reviewed-by: default avatarJaroslav Kysela <perex@perex.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ce7f93e2
    • Takashi Iwai's avatar
      ALSA: pcm: Suspend streams globally via device type PM ops · 3d21ef0b
      Takashi Iwai authored
      
      Until now we rely on each driver calling snd_pcm_suspend*() explicitly
      at its own PM handling.  However, this can be done far more easily by
      setting the PM ops to each actual snd_pcm device object.
      
      This patch adds the device_type object for PCM stream and assigns to
      each PCM stream object.  The type contains only the PM ops for system
      suspend; we don't need to deal with the resume in general.
      
      The suspend hook simply calls snd_pcm_suspend_all() for the given PCM
      streams.  This implies that the PM order is correctly put, i.e. PCM is
      suspended before the main (or codec) driver, which should be true in
      general.  If a special ordering is needed, you'd need to adjust the
      device PM order manually later.
      
      This patch introduces a new flag, snd_pcm.no_device_suspend, too.
      With this flag set, the PCM device object won't invoke
      snd_pcm_suspend_all() by itself.  This is needed for ASoC who wants to
      manage the PM call orders in its serialized way, and the flag is set
      in soc_new_pcm() as default.
      
      For the non-ASoC world, we can get rid of the manual snd_pcm_suspend
      calls.  This will be done in the later patches.
      
      Reviewed-by: default avatarJaroslav Kysela <perex@perex.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3d21ef0b
  17. Jan 14, 2019
  18. Dec 19, 2018
  19. Dec 14, 2018
  20. 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
  21. Dec 03, 2018
  22. Nov 29, 2018
Loading