1. 29 8月, 2012 1 次提交
  2. 23 8月, 2012 1 次提交
    • M
      ALSA: hda - add runtime PM support · b8dfc462
      Mengdong Lin 提交于
      Runtime PM can bring more power saving:
      - When the controller is suspended, its parent device will also have a chance
        to suspend.
      - PCI subsystem can choose the lowest power state the controller can signal
        wake up from. This state can be D3cold on platforms with ACPI PM support.
      And runtime PM can provide a gerneral sysfs interface for a system policy
      manager.
      
      Runtime PM support is based on current HDA power saving implementation. The user
      can enable runtime PM on platfroms that provide acceptable latency on transition
      from D3 to D0.
      
      Details:
      - When both power saving and runtime PM are enabled:
        -- If a codec supports 'stop-clock' in D3, it will request suspending the
           controller after it enters D3 and request resuming the controller before
           back to D0. Thus the controller will be suspended only when all codecs are
           suspended and support stop-clock in D3.
        -- User IO operations and HW wakeup signal can resume the controller back to
           D0.
      - If runtime PM is disabled, power saving just works as before.
      - If power saving is disabled, the controller won't be suspended because the
        power usage counter can never be 0.
      
      More about 'stop-clock' feature:
      If a codec can support targeted pass-through operations in D3 state when there
      is no BCLK present on the link, it will set CLKSTOP flag in the supported power
      states and report PS-ClkStopOk when entering D3 state. Please refer to HDA spec
      section 7.3.3.10 Power state and 7.3.4.12 Supported Power State.
      
      [Fixed CONFIG_PM_RUNTIME dependency in hda_intel.c by tiwai]
      Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b8dfc462
  3. 20 8月, 2012 1 次提交
  4. 13 8月, 2012 1 次提交
  5. 09 8月, 2012 1 次提交
  6. 08 8月, 2012 1 次提交
  7. 03 7月, 2012 1 次提交
  8. 18 6月, 2012 1 次提交
    • D
      ALSA: hda - Handle open while transitioning to D3. · b4a91cf0
      Dylan Reid 提交于
      This addresses an issue encountered when a pcm is opened while
      transitioning to low power state (codec->power_on == 1 &&
      codec->power_transition == -1).  Add snd_pcm_power_up_d3wait to
      hda_codec.  This function is used to power up from azx_open as opposed
      to snd_hda_power_up used from codec_exec_verb. When powering up from
      azx_open, wait for pending power downs to complete, avoiding the power
      up continuing in parallel with the power down on the work queue.
      
      The specific issue seen was with the CS4210 codec, it powers off the ADC
      and DAC nid in its suspend handler.  If it is re-opened before the
      ~100ms power down process completes, the ADC and DAC nid are initialized
      while powered down and audio is lost until another suspend/resume cycle.
      Signed-off-by: NDylan Reid <dgreid@chromium.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      b4a91cf0
  9. 06 6月, 2012 1 次提交
  10. 19 5月, 2012 1 次提交
  11. 14 5月, 2012 1 次提交
  12. 10 5月, 2012 1 次提交
    • T
      ALSA: hda - Fix concurrent hash accesses · c3b6bcc2
      Takashi Iwai 提交于
      The amp and caps hashes aren't protected properly for concurrent
      accesses.  Protect them via a new mutex now.
      
      But it can't be so simple as originally thought: since the update of a
      hash table entry itself might trigger the power-up sequence which
      again accesses the hash table, we can't cover the whole function
      simply via mutex.  Thus the update part has to be split from the mutex
      and revalidated.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      c3b6bcc2
  13. 09 5月, 2012 4 次提交
    • T
      ALSA: hda - More robustify the power-up/down sequence · a2d96e77
      Takashi Iwai 提交于
      Check the power_transition up/down state instead of boolean bit, so
      that the power-up sequence can cancel the pending power-down work
      properly.  Also, by moving cancel_delayed_work_sync() before the
      actual power-up sequence, make sure that the delayed power-down is
      completed.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a2d96e77
    • T
      ALSA: hda - Remove pre_resume and post_suspend ops · 607d4f7f
      Takashi Iwai 提交于
      Since the recent commit, the resume procedure is always performed at
      the resume time.  This makes the pre_resume hack for VREF mute LED on
      some HP laptops superfluous.  As this is the only user of pre_resume
      (and there is no user of post_suspend) ops, let's kill them again.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      607d4f7f
    • T
      ALSA: hda - Protect the power-saving count with spinlock · 5536c6d6
      Takashi Iwai 提交于
      To avoid some races.  Still not perfect, but now a bit safer.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      5536c6d6
    • T
      ALSA: hda - Always resume the codec immediately · 7f30830b
      Takashi Iwai 提交于
      This is a fix for the problem in commit 785f857d, the pop noise
      issue on some machines with ALC269.  The problem was the uninitialized
      state after the resume due to the delayed resume of the codec chips.
      In that commit, we tried to fix by forcibly putting the codec to D3 at
      suspend.  But, this still also leaves the uninitialized state after
      resume, and it _might_ be still problematic with some BIOS.  Since the
      commit turned out to regress another issues, we reverted it in the
      end.
      
      Now, in this fix, try to fix by turning on the codec immediately at
      the resume path.  We need to take care of the power-saving in this
      case.  When the device is woken up at the power-saved state, it should
      go power-saving again after the resume.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7f30830b
  14. 07 4月, 2012 1 次提交
  15. 01 3月, 2012 1 次提交
    • T
      ALSA: hda - Add a fake mute feature · 3868137e
      Takashi Iwai 提交于
      Some codecs don't supply the mute amp-capabilities although the lowest
      volume gives the mute.  It'd be handy if the parser provides the mute
      mixers in such a case.
      
      This patch adds an extension amp-cap bit (which is used only in the
      driver) to represent the min volume = mute state.  Also modified the
      amp cache code to support the fake mute feature when this bit is set
      but the real mute bit is unset.
      
      In addition, conexant cx5051 parser uses this new feature to implement
      the missing mute controls.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42825
      
      Cc: <stable@kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3868137e
  16. 13 2月, 2012 1 次提交
  17. 26 11月, 2011 1 次提交
    • T
      ALSA: hda - Supports more audio streams · 01b65bfb
      Takashi Iwai 提交于
      So far, the driver supports up to 10 streams.  This is a restriction in
      hda_intel.c and hda_codec.c: in the former, the fixed array size limits
      the amount, and in the latter, the fixed device-number assignment table
      (in get_empty_pcm_device()) limits the possibility.
      
      This patch reduces the restriction by
      - using linked list for managing PCM instances in hda_intel.c, and
      - assigning non-fixed device numbers for the extra devices
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      01b65bfb
  18. 16 11月, 2011 1 次提交
    • 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
  19. 10 11月, 2011 1 次提交
    • T
      ALSA: hda - Re-enable the check NO_PRESENCE misc bit · 2f451d2a
      Takashi Iwai 提交于
      We disabled the check of NO_PRESENCE bit of the default pin-config
      in commit f4419172 temporarily.  One problem was that the first
      implementation was wrong -- the bit after the shift must be checked.
      However, this would still give many regressions on machines with broken
      BIOS.  They set this bit wrongly even on active pins.
      
      A workaround is to check whether all pins contain this bit.  As far as
      I've checked, broken BIOSen set this bit on all pins, no matter whether
      active or not.  In such a case, the driver should ignore this bit check.
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2f451d2a
  20. 26 7月, 2011 4 次提交
  21. 12 7月, 2011 2 次提交
  22. 29 6月, 2011 1 次提交
  23. 28 6月, 2011 1 次提交
    • T
      ALSA: hda - Fix warnings with CONFIG_SND_POWER_SAVE=n · ff2b7e2a
      Takashi Iwai 提交于
      Use static inline for dummy function to fix the warnings like below
        sound/pci/hda/patch_sigmatel.c: In function ‘stac92xx_init’:
        sound/pci/hda/patch_sigmatel.c:4387:3: warning: statement with no effect
        sound/pci/hda/patch_sigmatel.c: In function ‘stac92xx_resume’:
        sound/pci/hda/patch_sigmatel.c:4927:3: warning: statement with no effect
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ff2b7e2a
  24. 25 6月, 2011 1 次提交
  25. 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: Virtualize SPDIF out controls · 74b654c9
      Stephen Warren 提交于
      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: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      74b654c9
    • S
      ALSA: hda: Allow multple SPDIF controls per codec · 7c935976
      Stephen Warren 提交于
      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: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      7c935976
  26. 02 5月, 2011 1 次提交
  27. 07 4月, 2011 1 次提交
  28. 03 3月, 2011 1 次提交
  29. 25 10月, 2010 1 次提交
  30. 21 9月, 2010 1 次提交
  31. 20 8月, 2010 1 次提交
    • T
      ALSA: hda - Fix stream and channel-ids codec-bus wide · 3f50ac6a
      Takashi Iwai 提交于
      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: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      3f50ac6a