1. 27 Sep, 2018 1 commit
    • Matthias Kaehlcke's avatar
      ASoC: soc-utils: Rename dummy_dma_ops to snd_dummy_dma_ops · 42cfb412
      Matthias Kaehlcke authored
      The symbols 'dummy_dma_ops' is declared with different data types by
      sound/soc/soc-utils.c and arch/arm64/include/asm/dma-mapping.h. This
      leads to conflicts when soc-utils.c (indirectly) includes dma-mapping.h:
      
      sound/soc/soc-utils.c:282:33: error: conflicting types for 'dummy_dma_ops'
        static const struct snd_pcm_ops dummy_dma_ops = {
                                        ^
      ...
      arch/arm64/include/asm/dma-mapping.h:27:33: note: previous declaration of 'dummy_dma_ops' was here
        extern const struct dma_map_ops dummy_dma_ops;
                                        ^
      
      Rename the symbol in soc-utils.c to 'snd_dummy_dma_ops' to avoid the
      conflict.
      Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      42cfb412
  2. 25 Sep, 2018 3 commits
  3. 21 Sep, 2018 5 commits
  4. 20 Sep, 2018 10 commits
  5. 19 Sep, 2018 1 commit
  6. 18 Sep, 2018 8 commits
  7. 17 Sep, 2018 6 commits
  8. 12 Sep, 2018 6 commits
    • Mark Brown's avatar
      ALSA: hda: Fix implicit definition of pci_iomap() on SH · d9b84a15
      Mark Brown authored
      Include asm/io.h directly so we've got a definition of pci_iomap(), the
      current set of includes do this implicitly on most architectures but not
      on SH.
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      d9b84a15
    • 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>
      75383f8d
    • Yu Zhao's avatar
      sound: enable interrupt after dma buffer initialization · b61749a8
      Yu Zhao authored
      In snd_hdac_bus_init_chip(), we enable interrupt before
      snd_hdac_bus_init_cmd_io() initializing dma buffers. If irq has
      been acquired and irq handler uses the dma buffer, kernel may crash
      when interrupt comes in.
      
      Fix the problem by postponing enabling irq after dma buffer
      initialization. And warn once on null dma buffer pointer during the
      initialization.
      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>
      b61749a8
    • Yu Zhao's avatar
      Revert "ASoC: Intel: Skylake: Acquire irq after RIRB allocation" · 542cedec
      Yu Zhao authored
      This reverts commit 12eeeb4f.
      
      The patch doesn't fix accessing memory with null pointer in
      skl_interrupt().
      
      There are two problems: 1) skl_init_chip() is called twice, before
      and after dma buffer is allocate. The first call sets bus->chip_init
      which prevents the second from initializing bus->corb.buf and
      rirb.buf from bus->rb.area. 2) snd_hdac_bus_init_chip() enables
      interrupt before snd_hdac_bus_init_cmd_io() initializing dma buffers.
      There is a small window which skl_interrupt() can be called if irq
      has been acquired. If so, it crashes when using null dma buffer
      pointers.
      
      Will fix the problems in the following patches. Also attaching the
      crash for future reference.
      
      [   16.949148] general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
      <snipped>
      [   16.950903] Call Trace:
      [   16.950906]  <IRQ>
      [   16.950918]  skl_interrupt+0x19e/0x2d6 [snd_soc_skl]
      [   16.950926]  ? dma_supported+0xb5/0xb5 [snd_soc_skl]
      [   16.950933]  __handle_irq_event_percpu+0x27a/0x6c8
      [   16.950937]  ? __irq_wake_thread+0x1d1/0x1d1
      [   16.950942]  ? __do_softirq+0x57a/0x69e
      [   16.950944]  handle_irq_event_percpu+0x95/0x1ba
      [   16.950948]  ? _raw_spin_unlock+0x65/0xdc
      [   16.950951]  ? __handle_irq_event_percpu+0x6c8/0x6c8
      [   16.950953]  ? _raw_spin_unlock+0x65/0xdc
      [   16.950957]  ? time_cpufreq_notifier+0x483/0x483
      [   16.950959]  handle_irq_event+0x89/0x123
      [   16.950962]  handle_fasteoi_irq+0x16f/0x425
      [   16.950965]  handle_irq+0x1fe/0x28e
      [   16.950969]  do_IRQ+0x6e/0x12e
      [   16.950972]  common_interrupt+0x7a/0x7a
      [   16.950974]  </IRQ>
      <snipped>
      [   16.951031] RIP: snd_hdac_bus_update_rirb+0x19b/0x4cf [snd_hda_core] RSP: ffff88015c807c08
      [   16.951036] ---[ end trace 58bf9ece1775bc92 ]---
      
      Fixes: 2eeeb4f4733b ("ASoC: Intel: Skylake: Acquire irq after RIRB allocation")
      Signed-off-by: default avatarYu Zhao <yuzhao@google.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      542cedec
    • Kuninori Morimoto's avatar
      ASoC: soc-core: remove dai->driver NULL check · a7c439d6
      Kuninori Morimoto authored
      It is strange if it has "dai" but doesn't have "dai->driver".
      And more over "dai->driver->xxx" is used everywhere without
      "dai->driver" pointer NULL checking.
      It got Oops already if "dai->driver" was NULL.
      Let's remove un-needed "dai->driver" NULL check.
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      a7c439d6
    • 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>
      e894efef