1. 22 8月, 2012 1 次提交
  2. 06 8月, 2012 1 次提交
  3. 28 7月, 2012 1 次提交
  4. 27 7月, 2012 1 次提交
  5. 20 7月, 2012 1 次提交
  6. 17 7月, 2012 1 次提交
  7. 16 7月, 2012 1 次提交
  8. 21 6月, 2012 3 次提交
  9. 20 6月, 2012 3 次提交
  10. 15 6月, 2012 5 次提交
  11. 11 6月, 2012 1 次提交
  12. 10 5月, 2012 1 次提交
  13. 10 4月, 2012 1 次提交
  14. 23 2月, 2012 1 次提交
  15. 20 12月, 2011 1 次提交
  16. 02 12月, 2011 1 次提交
    • T
      ALSA: hda - Integrate input-jack stuff into kctl-jack · 31ef2257
      Takashi Iwai 提交于
      Instead of managing input-jack stuff separately, call all stuff inside
      the kctl-jack creation, deletion and report.  The caller no longer needs
      to care about input-jack.
      
      The better integration between input-jack and kctl-jack should be done
      in the upper layer in near future, but for now, it's implemented locally
      for more tests.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      31ef2257
  17. 26 11月, 2011 1 次提交
  18. 22 11月, 2011 1 次提交
  19. 16 11月, 2011 7 次提交
    • T
      ALSA: hda - Merge input-jack helpers to hda_jack.c · aad37dbd
      Takashi Iwai 提交于
      We can use the very same table in hda_jack.c for managing the list for
      input-jack elements, too.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      aad37dbd
    • T
      ALSA: hda - Manage unsol tags in hda_jack.c · 3a93897e
      Takashi Iwai 提交于
      Manage the tags assigned for unsolicited events dynamically together
      with the jack-detection routines.  Basically this is almost same as what
      we've done in patch_sigmatel.c.  Assign the new tag number for each new
      unsol event, associate with the given NID and the action type, etc.
      
      With this change, now all pins looked over in snd_hda_jack_add_kctls()
      are actually enabled for detection now even if the pins aren't used for
      jack-retasking by the driver.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3a93897e
    • T
      ALSA: hda - Create jack-detection kcontrols · 01a61e12
      Takashi Iwai 提交于
      Create kcontrols for pin jack-detections, which work similarly like
      jack-input layer.  Each control will notify when the jack is plugged or
      unplugged, and also user can read the value at any time via the normal
      control API.
      
      The control elements are created with iface=CARD, so that they won't
      appear in the mixer apps.
      
      So far, only the pins that enabled the jack-detection are registered.
      For covering all pins, the transition of the common unsol-tag handling
      would be needed.  Stay tuned.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      01a61e12
    • T
      ALSA: hda - Cache the jack-detection value · 1835a0f9
      Takashi Iwai 提交于
      Introduce a table containing the pins and their jack-detection states
      for avoiding the unnecessary verbs to check the pin status at each time.
      
      When the unsol event is enabled via snd_hda_jack_detect_enable(), it
      automatically adds the given NID to the table.  Then the driver supposes
      that the codec driver will set the dirty flag appropariately when an
      unsolicited event is invoked for that pin.
      
      The behavior for reading other pins that aren't registered in the table
      doesn't change.  Only the pins assigned to the table are cached, so far.
      
      In near futre, this table can be extended to use the central place for
      the unsolicited events of all pins, etc, and eventually include the
      jack-detect kcontrols that replace the current input-jack stuff.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      1835a0f9
    • W
      ALSA: hda - move eld->spk_alloc fixup to hdmi_update_eld() · 2d1b439b
      Wu Fengguang 提交于
      It looks more natural and saves two lines of code.
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2d1b439b
    • W
      ALSA: hda - delayed ELD repoll · 744626da
      Wu Fengguang 提交于
      The Intel HDMI chips (ironlake at least) are found to have ~250ms delay
      between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes
      actually readable. During the time the ELD buffer is mysteriously all 0.
      
      Fix it by scheduling a delayed work to re-read ELD buffer after 300ms.
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      744626da
    • W
      ALSA: hda - fix ELD memory leak · b95d68b8
      Wu Fengguang 提交于
      memset(eld) clears eld->proc_entry which will leak the struct
      snd_info_entry when unloading module.
      
      Fix it by
      - memset only the fields before eld->eld_buffer
      - set eld->eld_valid to true _after_ all eld fields have been filled
      
      Cc: <stable@kernel.org>
      Cc: Pierre-louis Bossart <pierre-louis.bossart@intel.com>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b95d68b8
  20. 03 11月, 2011 1 次提交
  21. 01 11月, 2011 1 次提交
  22. 03 10月, 2011 1 次提交
    • P
      ALSA: hda/hdmi: expose ELD control · 14bc52b8
      Pierre-Louis Bossart 提交于
      Applications may want to read ELD information to
      understand what codecs are supported on the HDMI
      receiver and handle the a-v delay for better lip-sync.
      
      ELD information is exposed in a device-specific
      IFACE_PCM kcontrol. Tested both with amixer and
      PulseAudio; with a corresponding patch passthrough modes
      are enabled automagically.
      
      ELD control size is set to zero in case of errors or
      wrong configurations. No notifications are implemented
      for now, it is expected that jack detection is used to
      reconfigure the audio outputs.
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      14bc52b8
  23. 21 9月, 2011 1 次提交
  24. 06 6月, 2011 3 次提交
    • S
      ALSA: hda: HDMI: Support codecs with fewer cvts than pins · 384a48d7
      Stephen Warren 提交于
      The general concept of this change is to create a PCM device for each
      pin widget instead of each converter widget. Whenever a PCM is opened,
      a converter is dynamically selected to drive that pin based on those
      available for muxing into the pin.
      
      The one thing this model doesn't support is a single PCM/converter
      sending audio to multiple pin widgets at once.
      
      Note that this means that a struct hda_pcm_stream's nid variable is
      set to 0 except between a stream's open and cleanup calls. The dynamic
      de-assignment of converters to PCMs occurs within cleanup, not close,
      in order for it to co-incide with when controller stream IDs are
      cleaned up from converters.
      
      While the PCM for a pin is not open, the pin is disabled (its widget
      control's PIN_OUT bit is cleared) so that if the currently routed
      converter is used to drive a different PCM/pin, that audio does not
      leak out over a disabled pin.
      
      We use the recently added SPDIF virtualization feature in order to
      create SPDIF controls for each pin widget instead of each converter
      widget, so that state is specific to a PCM.
      
      In order to support this, a number of more mechanical changes are made:
      
      * s/nid/pin_nid/ or s/nid/cvt_nid/ in many places in order to make it
        clear exactly what the code is dealing with.
      
      * We now have per_pin and per_cvt arrays in hdmi_spec to store relevant
        data. In particular, we store a converter's capabilities in the per_cvt
        entry, rather than relying on a combination of codec_pcm_pars and
        the struct hda_pcm_stream.
      
      * ELD-related workarounds were removed from hdmi_channel_allocation
        into hdmi_instrinsic in order to simplifiy infoframe calculations and
        remove HW dependencies.
      
      * Various functions only apply to a single pin, since there is now
        only 1 pin per PCM. For example, hdmi_setup_infoframe,
        hdmi_setup_stream.
      
      * hdmi_add_pin and hdmi_add_cvt are more oriented at pure codec parsing
        and data retrieval, rather than determining which pins/converters
        are to be used for creating PCMs.
      
      This is quite a large change; it may be appropriate to simply read the
      result of the patch rather than the diffs. Some small parts of the change
      might be separable into different patches, but I think the bulk of the
      change will probably always be one large patch. Hopefully the change
      isn't too opaque!
      
      This has been tested on:
      
      * NVIDIA GeForce 400 series discrete graphics card. This model has the
        classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM
        audio to a PC monitor that supports audio.
      
      * NVIDIA GeForce 520 discrete graphics card. This model is the new
        1 codec n converters m pins m>n model. Tested stereo PCM audio to a
        PC monitor that supports audio.
      
      * NVIDIA GeForce 400 series laptop graphics chip. This model has the
        classical 1:1:1 codec:converter:pcm widget model. Tested stereo PCM,
        multi-channel PCM, and AC3 pass-through to an AV receiver.
      
      * Intel Ibex Peak laptop. This model is the new 1 codec n converters m
        pins m>n model. Tested stereo PCM, multi-channel PCM, and AC3 pass-
        through to an AV receiver.
      
      Note that I'm not familiar at all with AC3 pass-through. Hence, I may
      not have covered all possible mechanisms that are applicable here. I do
      know that my receiver definitely received AC3, not decoded PCM. I tested
      with mplayer's "-afm hwac3" and/or "-af lavcac3enc" options, and alsa a
      WAV file that I believe has AC3 content rather than PCM.
      
      I also tested:
      * Play a stream
      * Mute while playing
      * Stop stream
      * Play some other streams to re-assign the converter to a different
        pin, PCM, set of SPDIF controls, ... hence hopefully triggering
        cleanup for the original PCM.
      * Unmute original stream while not playing
      * Play a stream on the original pin/PCM.
      
      This was to test SPDIF control virtualization.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      384a48d7
    • S
      ALSA: hda: hdmi_eld_update_pcm_info: update a stream in place · 2def8172
      Stephen Warren 提交于
      A future change won't store an entire hda_pcm_stream just to represent
      the capabilities of a codec; a custom data-structure will be used. To
      ease that transition, modify hdmi_eld_update_pcm_info to expect the
      hda_pcm_stream to be pre-initialized with the codec's capabilities, and
      to update those capabilities in-place based on the ELD.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2def8172
    • S
      ALSA: hda: Separate generic and non-generic implementations · 3aaf8980
      Stephen Warren 提交于
      A future change will significantly rework the generic implementation
      in order to support codecs with a different number of pins and
      converters. Isolate the more custom codec variants from this change by
      duplicating the small portions of generic code they share. This
      simplifies the later rework of that previously shared code, since we
      don't have to consider the more custom codecs, and also prevents
      support for those codecs from regressing.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3aaf8980