1. 27 Sep, 2018 2 commits
    • Arnd Bergmann's avatar
      ASoC: pxa: avoid AC97_BUS build warning · bec5ecdf
      Arnd Bergmann authored
      Selecting AC97_BUS_NEW from SND_PXA2XX_SOC_AC97 leads to a Kconfig
      warning if any other driver selects AC97_BUS:
      
      WARNING: unmet direct dependencies detected for AC97_BUS_COMPAT
        Depends on [n]: SOUND [=y] && !UML && SND [=y] && AC97_BUS_NEW [=y] && !AC97_BUS [=y]
        Selected by [y]:
        - SND_SOC_WM9713 [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && AC97_BUS_NEW [=y]
      
      I don't know if that combination is supposed to work.
      Assuming it is not, this adds a dependency on all users
      for PXA to avoids the combination.
      
      Fixes: 1c8bc7b3 ("ASoC: pxa: switch to new ac97 bus support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      bec5ecdf
    • 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 5 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