1. 20 Dec, 2013 3 commits
  2. 19 Dec, 2013 3 commits
    • Takashi Iwai's avatar
      ALSA: hda - Add warning texts when codec driver Kconfig doesn't match · d8f66c71
      Takashi Iwai authored
      When a Kconfig of a codec driver doesn't match with the controller
      (CONFIG_SND_HDA_INTEL), it'll result in the non-working automatic
      probing.  Unfortunately kbuild can't give such a restriction, but at
      least, it's possible to show a warning if such a condition is found.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d8f66c71
    • Takashi Iwai's avatar
      ALSA: hda - Kill EXPORT_SYMBOL_HDA() · 2698ea98
      Takashi Iwai authored
      Replace all with the standard EXPORT_SYMBOL_GPL().
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2698ea98
    • Takashi Iwai's avatar
      ALSA: hda - Make CONFIG_SND_HDA_CODEC_* tristate · 595fe1b7
      Takashi Iwai authored
      So far, CONFIG_SND_HDA_CODEC_* kconfigs have been booleans due to
      historical reasons.  The major reason was that the automatic codec
      driver probing wouldn't work if user sets a codec driver as a module
      while the controller driver as a built-in.  And, another reason was to
      avoid exporting symbols of the helper codes when all drivers are built
      in.
      
      But, this sort of "kindness" rather confuses people in the end,
      especially makes the config refinement via localmodconfig unhappy.
      Also, a codec module would still work if you re-bind the controller
      driver via sysfs (although it's no automatic loading), so there might
      be a slight use case.
      
      That said, better to let people fallen into a pitfall than being too
      smart and restrict something.  Let's make things straightforward: now
      all CONFIG_SND_HDA_CODEC_* become tristate, and all symbols exported
      unconditionally.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      595fe1b7
  3. 18 Dec, 2013 1 commit
    • David Henningsson's avatar
      ALSA: hda - Explicitly keep codec powered up in hdmi_present_sense · da4a7a39
      David Henningsson authored
      This should help us avoid the following mutex deadlock:
      
      [] mutex_lock+0x2a/0x50
      [] hdmi_present_sense+0x53/0x3a0 [snd_hda_codec_hdmi]
      [] generic_hdmi_resume+0x5a/0x70 [snd_hda_codec_hdmi]
      [] hda_call_codec_resume+0xec/0x1d0 [snd_hda_codec]
      [] snd_hda_power_save+0x1e4/0x280 [snd_hda_codec]
      [] codec_exec_verb+0x5f/0x290 [snd_hda_codec]
      [] snd_hda_codec_read+0x5b/0x90 [snd_hda_codec]
      [] snd_hdmi_get_eld_size+0x1e/0x20 [snd_hda_codec_hdmi]
      [] snd_hdmi_get_eld+0x2c/0xd0 [snd_hda_codec_hdmi]
      [] hdmi_present_sense+0x9a/0x3a0 [snd_hda_codec_hdmi]
      [] hdmi_repoll_eld+0x34/0x50 [snd_hda_codec_hdmi]
      Signed-off-by: default avatarDavid Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      da4a7a39
  4. 16 Dec, 2013 2 commits
  5. 13 Dec, 2013 2 commits
  6. 12 Dec, 2013 4 commits
  7. 11 Dec, 2013 3 commits
    • Takashi Iwai's avatar
      ALSA: hda - Add static DAC/pin mapping for AD1986A codec · 3690739b
      Takashi Iwai authored
      AD1986A codec is a pretty old codec and has really many hidden
      restrictions.  One of such is that each DAC is dedicated to certain
      pin although there are possible connections.  Currently, the generic
      parser tries to assign individual DACs as much as possible, and this
      lead to two bad situations: connections where the sound actually
      doesn't work, and connections conflicting other channels.
      
      We may fix this by trying to find the best connections more harder,
      but as of now, it's easier to give some hints for paired DAC/pin
      connections and honor them if available, since such a hint is needed
      only for specific codecs (right now only AD1986A, and there will be
      unlikely any others in future).
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3690739b
    • Hui Wang's avatar
      ALSA: hda - One more Dell headset detection quirk · 7dca4bc6
      Hui Wang authored
      On the Dell machines with codec whose Subsystem Id is 0x10280624,
      no external microphone can be detected when plugging a 3-ring
      headset. If we add "model=dell-headset-multi" for the
      snd-hda-intel.ko, the problem will disappear.
      
      BugLink: https://bugs.launchpad.net/bugs/1259790
      Cc: David Henningsson <david.henningsson@canonical.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7dca4bc6
    • Anssi Hannula's avatar
      ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devices · c9a6338a
      Anssi Hannula authored
      In case a single HDA card has both HDMI and S/PDIF outputs, the S/PDIF
      outputs will have their IEC958 controls created starting from index 16
      and the HDMI controls will be created starting from index 0.
      
      However, HDMI simple_playback_build_controls() as used by old VIA and
      NVIDIA codecs incorrectly requests the IEC958 controls to be created
      with an S/PDIF type instead of HDMI.
      In case the card has other codecs that have HDMI outputs, the controls
      will be created with wrong index=16, causing them to e.g. be unreachable
      by the ALSA "hdmi" alias.
      
      Fix that by making simple_playback_build_controls() request controls
      with HDMI indexes.
      
      Not many cards have an affected configuration, but e.g. ASUS M3N78-VM
      contains an integrated NVIDIA HDA "card" with:
      - a VIA codec that has, among others, an S/PDIF pin incorrectly
        labelled as an HDMI pin, and
      - an NVIDIA MCP7x HDMI codec.
      
      Reported-by: MysterX on #openelec
      Tested-by: MysterX on #openelec
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@iki.fi>
      Cc: <stable@vger.kernel.org> # 3.8+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c9a6338a
  8. 10 Dec, 2013 7 commits
    • Paul Walmsley's avatar
      ALSA: atmel_abdac: clk_round_rate() can return a zero upon error · 337bb336
      Paul Walmsley authored
      Treat both negative and zero return values from clk_round_rate()
      as errors.  This is needed since subsequent patches will convert
      clk_round_rate()'s return value to be an unsigned type, rather
      than a signed type, since some clock sources can generate rates higher
      than (2^31)-1 Hz.
      
      Eventually, when calling clk_round_rate(), only a return value of
      zero will be considered a error; all other values will be
      considered valid rates.  The comparison against values less than
      0 is kept to preserve the correct behavior in the meantime.
      Signed-off-by: default avatarPaul Walmsley <pwalmsley@nvidia.com>
      Acked-by: default avatarHans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      337bb336
    • Paul Walmsley's avatar
      ALSA: at73c213: clk_round_rate() can return a zero upon error · f62438ac
      Paul Walmsley authored
      Treat both negative and zero return values from clk_round_rate()
      as errors.  This is needed since subsequent patches will convert
      clk_round_rate()'s return value to be an unsigned type, rather
      than a signed type, since some clock sources can generate rates higher
      than (2^31)-1 Hz.
      
      Eventually, when calling clk_round_rate(), only a return value of
      zero will be considered a error.  All other values will be
      considered valid rates.  The comparison against values less than
      0 is kept to preserve the correct behavior in the meantime.
      Signed-off-by: default avatarPaul Walmsley <pwalmsley@nvidia.com>
      Acked-by: default avatarHans-Christian Egtvedt <egtvedt@samfundet.no>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f62438ac
    • Takashi Iwai's avatar
      ALSA: hda - Mute all aamix inputs as default · ebb93c05
      Takashi Iwai authored
      Not all channels have been initialized, so far, especially when aamix
      NID itself doesn't have amps but its leaves have.  This patch fixes
      these holes.  Otherwise you might get unexpected loopback inputs,
      e.g. from surround channels.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ebb93c05
    • Takashi Iwai's avatar
      ALSA: compress: Fix 64bit ABI incompatibility · 6733cf57
      Takashi Iwai authored
      snd_pcm_uframes_t is defined as unsigned long so it would take
      different sizes depending on 32 or 64bit architectures.  As we don't
      want this ABI incompatibility, and there is no real 64bit user yet,
      let's make it the fixed size with __u32.
      
      Also bump the protocol version number to 0.1.2.
      Acked-by: default avatarVinod Koul <vinod.koul@intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6733cf57
    • Stefano Panella's avatar
      ALSA: memalloc.h - fix wrong truncation of dma_addr_t · 932e9dec
      Stefano Panella authored
      When running a 32bit kernel the hda_intel driver is still reporting
      a 64bit dma_mask if the HW supports it.
      
      From sound/pci/hda/hda_intel.c:
      
              /* allow 64bit DMA address if supported by H/W */
              if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64)))
                      pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));
              else {
                      pci_set_dma_mask(pci, DMA_BIT_MASK(32));
                      pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32));
              }
      
      which means when there is a call to dma_alloc_coherent from
      snd_malloc_dev_pages a machine address bigger than 32bit can be returned.
      This can be true in particular if running  the 32bit kernel as a pv dom0
      under the Xen Hypervisor or PAE on bare metal.
      
      The problem is that when calling setup_bdle to program the BLE the
      dma_addr_t returned from the dma_alloc_coherent is wrongly truncated
      from snd_sgbuf_get_addr if running a 32bit kernel:
      
      static inline dma_addr_t snd_sgbuf_get_addr(struct snd_dma_buffer *dmab,
                                                 size_t offset)
      {
              struct snd_sg_buf *sgbuf = dmab->private_data;
              dma_addr_t addr = sgbuf->table[offset >> PAGE_SHIFT].addr;
              addr &= PAGE_MASK;
              return addr + offset % PAGE_SIZE;
      }
      
      where PAGE_MASK in a 32bit kernel is zeroing the upper 32bit af addr.
      
      Without this patch the HW will fetch the 32bit truncated address,
      which is not the one obtained from dma_alloc_coherent and will result
      to a non working audio but can corrupt host memory at a random location.
      
      The current patch apply to v3.13-rc3-74-g6c843f5
      Signed-off-by: default avatarStefano Panella <stefano.panella@citrix.com>
      Reviewed-by: default avatarFrediano Ziglio <frediano.ziglio@citrix.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      932e9dec
    • Hui Wang's avatar
      ALSA: hda - Another Dell headset detection quirk · 0dfb9809
      Hui Wang authored
      On the Dell Inspiron 3045 machine (codec Subsystem Id: 0x10280628),
      no external microphone can be detected when plugging a 3-ring
      headset. If we add "model=dell-headset-multi" for the
      snd-hda-intel.ko, the problem will disappear.
      
      BugLink: https://bugs.launchpad.net/hwe-somerville/+bug/1259437
      CC: David Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0dfb9809
    • Hui Wang's avatar
      ALSA: hda - A Dell headset detection quirk · 6c6eb427
      Hui Wang authored
      On the Dell Optiplex 3030 machine (codec Subsystem Id: 0x10280623),
      no external microphone can be detected when plugging a 3-ring
      headset. If we add "model=dell-headset-multi" for the
      snd-hda-intel.ko, the problem will disappear.
      
      BugLink: https://bugs.launchpad.net/hwe-somerville/+bug/1259435
      CC: David Henningsson <david.henningsson@canonical.com>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6c6eb427
  9. 09 Dec, 2013 5 commits
  10. 06 Dec, 2013 10 commits