1. 06 Jun, 2011 3 commits
    • Stephen Warren's avatar
      ALSA: hda: HDMI: Support codecs with fewer cvts than pins · 384a48d7
      Stephen Warren authored
      
      
      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: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      384a48d7
    • Stephen Warren's avatar
      ALSA: hda: Virtualize SPDIF out controls · 74b654c9
      Stephen Warren authored
      
      
      The SPDIF output controls apply to converter widgets. A future change
      will create a PCM device per pin widget, and hence a set of SPDIF output
      controls per pin widget, for certain HDMI codecs. To support this, we
      need the ability to virtualize the SPDIF output controls. Specifically:
      
      * Controls can be "unassigned" from real hardware when a converter is
        not used for the PCM the control was created for.
      * Control puts only write to hardware when they are assigned.
      * Controls can be "assigned" to real hardware when a converter is picked
        to support output for a particular PCM.
      * When a converter is assigned, the hardware is updated to the cached
        configuration.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      74b654c9
    • Stephen Warren's avatar
      ALSA: hda: Allow multple SPDIF controls per codec · 7c935976
      Stephen Warren authored
      
      
      Currently, the data that backs the kcontrols created by
      snd_hda_create_spdif_out_ctls is stored directly in struct hda_codec. When
      multiple sets of these controls are stored, they will all manipulate the
      same data, causing confusion. Instead, store an array of this data, one
      copy per converter, to isolate the controls.
      
      This patch would cause a behavioural change in the case where
      snd_hda_create_spdif_out_ctls was called multiple times for a single codec.
      As best I can tell, this is never the case for any codec.
      
      This will be relevant at least for some HDMI audio codecs, such as the
      NVIDIA GeForce 520 and Intel Ibex Peak. A future change will modify the
      driver's handling of those codecs to create multiple PCMs per codec. Note
      that this issue isn't affected by whether one creates a PCM-per-converter
      or PCM-per-pin; there are multiple of both within a single codec in both
      of those codecs.
      
      Note that those codecs don't currently create multiple PCMs for the codec
      due to the default HW mux state of all pins being to point at the same
      converter, hence there is only a single converter routed to any pin, and
      hence only a single PCM.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7c935976
  2. 26 May, 2011 1 commit
  3. 19 May, 2011 1 commit
  4. 02 May, 2011 2 commits
  5. 29 Apr, 2011 1 commit
  6. 20 Apr, 2011 1 commit
  7. 15 Apr, 2011 1 commit
  8. 07 Apr, 2011 1 commit
  9. 31 Mar, 2011 1 commit
  10. 03 Mar, 2011 1 commit
  11. 17 Jan, 2011 1 commit
  12. 10 Jan, 2011 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Fix multi-headphone handling for Realtek codecs · b2d05760
      Takashi Iwai authored
      
      
      When multiple headphone pins are defined without line-out pins, the
      driver takes them as primary outputs.  But it forgot to set line_out_type
      to HP by assuming there is some rest of HP pins.  This results in some
      mis-handling of these pins for Realtek codec parser.  It takes as if
      these are pure line-out jacks.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Cc: <stable@kernel.org>
      b2d05760
  13. 23 Dec, 2010 1 commit
  14. 25 Oct, 2010 1 commit
  15. 22 Oct, 2010 1 commit
  16. 17 Oct, 2010 2 commits
  17. 21 Sep, 2010 1 commit
  18. 17 Sep, 2010 2 commits
  19. 09 Sep, 2010 6 commits
  20. 08 Sep, 2010 2 commits
  21. 30 Aug, 2010 2 commits
  22. 20 Aug, 2010 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Fix stream and channel-ids codec-bus wide · 3f50ac6a
      Takashi Iwai authored
      
      
      The new sticky PCM parameter introduced the delayed clean-ups of
      stream- and channel-id tags.  In the current implementation, this check
      (adding dirty flag) and actual clean-ups are done only for the codec
      chip.  However, with HD-audio architecture, multiple codecs can be
      on a single bus, and the controller assign stream- and channel-ids in
      the bus-wide.
      
      In this patch, the stream-id and channel-id are checked over all codecs
      connected to the corresponding bus.  Together with it, the mutex is
      moved to struct hda_bus, as this becomes also bus-wide.
      Reported-and-tested-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3f50ac6a
  23. 13 Aug, 2010 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Fix dynamic ADC change working again · f0cea797
      Takashi Iwai authored
      The commit eb541337
      
      
          ALSA: hda - Make converter setups sticky
      changes the semantics of snd_hda_codec_cleanup_stream() not to clean up
      the stream at that moment but delay the action.  This broke the codes
      expecting that the clean-up is done immediately, such as dynamic ADC
      changes in some codec drivers.
      
      This patch fixes the issue by introducing a lower helper,
      __snd_hda_codec_cleanup_stream(), to allow the immediate clean up.
      The original snd_hda_codec_cleanup_stream() is kept as is now.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f0cea797
  24. 06 Aug, 2010 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Make converter setups sticky · eb541337
      Takashi Iwai authored
      
      
      So far, we reset the converter setups like the stream-tag, the
      channel-id and format-id in prepare callbacks, and clear them in
      cleanup callbacks.  This often causes a silence of the digital
      receiver for a couple of seconds.
      
      This patch tries to delay the converter setup changes as much as
      possible.  The converter setups are cached and aren't reset as long
      as the same values are used.  At suspend/resume, they are cleared
      to be recovered properly, too.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      eb541337
  25. 03 Aug, 2010 2 commits
  26. 30 Jul, 2010 1 commit
  27. 26 Jul, 2010 1 commit