1. 15 Apr, 2020 2 commits
    • Stephan Gerhold's avatar
      ASoC: soc-pcm: dpcm: Only allow playback/capture if supported · 9b5db059
      Stephan Gerhold authored
      At the moment, PCM devices for DPCM are only created based on the
      dpcm_playback/capture parameters of the DAI link, without considering
      if the CPU/FE DAI is actually capable of playback/capture.
      
      Normally the dpcm_playback/capture parameter should match the
      capabilities of the CPU DAI. However, there is no way to set that
      parameter from the device tree (e.g. with simple-audio-card or
      qcom sound cards). dpcm_playback/capture are always both set to 1.
      
      This causes problems when the CPU DAI does only support playback
      or capture. Attemting to open that PCM device with an unsupported
      stream type then results in a null pointer dereference:
      
          Unable to handle kernel NULL pointer dereference at virtual address 0000000000000128
          Internal error: Oops: 96000044 [#1] PREEMPT SMP
          CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1
          pc : invalidate_paths_ep+0x30/0xe0
          lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8
          Call trace:
           invalidate_paths_ep+0x30/0xe0
           snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8
           dpcm_path_get+0x38/0xd0
           dpcm_fe_dai_open+0x70/0x920
           snd_pcm_open_substream+0x564/0x840
           snd_pcm_open+0xfc/0x228
           snd_pcm_capture_open+0x4c/0x78
           snd_open+0xac/0x1a8
           ...
      
      ... because the DAI playback/capture_widget is not set in that case.
      
      We could add checks there to fix the problem (maybe we should
      anyway), but much easier is to not expose the device as
      playback/capture in the first place. Attemting to use that
      device would always fail later anyway.
      
      Add checks for snd_soc_dai_stream_valid() to the DPCM case
      to avoid exposing playback/capture if it is not supported.
      Signed-off-by: default avatarStephan Gerhold <stephan@gerhold.net>
      Link: https://lore.kernel.org/r/20200415104928.86091-1-stephan@gerhold.netSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      9b5db059
    • Sebastian Reichel's avatar
      ASoC: sgtl5000: Fix VAG power-on handling · aa781273
      Sebastian Reichel authored
      As mentioned slightly out of patch context in the code, there
      is no reset routine for the chip. On boards where the chip is
      supplied by a fixed regulator, it might not even be resetted
      during (e.g. watchdog) reboot and can be in any state.
      
      If the device is probed with VAG enabled, the driver's probe
      routine will generate a loud pop sound when ANA_POWER is
      being programmed. Avoid this by properly disabling just the
      VAG bit and waiting the required power down time.
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.com>
      Reviewed-by: default avatarFabio Estevam <festivem@gmail.com>
      Link: https://lore.kernel.org/r/20200414181140.145825-1-sebastian.reichel@collabora.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      aa781273
  2. 14 Apr, 2020 16 commits
  3. 09 Apr, 2020 6 commits
  4. 07 Apr, 2020 1 commit
  5. 06 Apr, 2020 3 commits
  6. 03 Apr, 2020 4 commits
  7. 01 Apr, 2020 3 commits
  8. 31 Mar, 2020 2 commits
  9. 30 Mar, 2020 3 commits