Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa: (299 commits)
  [ALSA] version 1.0.16rc2
  [ALSA] hda: fix Mic in as output
  [ALSA] emu10k1 - Another EMU0404 Board ID
  [ALSA] emu10k1 - Fix kthread handling at resume
  [ALSA] emu10k1: General cleanup, add new locks, fix alsa bug#3501, kernel bug#9304.
  [ALSA] emu10k1 - Use enum for emu_model types
  [ALSA] emu10k1 - Don't create emu1010 controls for non-emu boards
  [ALSA] emu10k1 - 1616(M) cardbus improvements
  [ALSA] snd:emu10k1: E-Mu updates. Fixes to firmware loading and support for 0404.
  [ALSA] emu10k1: Add comments regarding E-Mu ins and outs.
  [ALSA] oxygen: revert SPI clock frequency change for AK4396/WM8785
  [ALSA] es1938 - improve capture hw pointer reads
  [ALSA] HDA-Intel - Add support for Intel SCH
  [ALSA] hda: Add GPIO mute support to STAC9205
  [ALSA] hda-codec - Add Dell T3400 support
  [ALSA] hda-codec - Add model for HP DV9553EG laptop
  [ALSA] hda-codec - Control SPDIF as slave
  [ALSA] hda_intel: ALSA HD Audio patch for Intel ICH10 DeviceID's
  [ALSA] Fix Oops with PCM OSS sync
  [ALSA] hda-codec - Add speaker automute to ALC262 HP models
  ...

1 files changed, 26 insertions, 25 deletions

diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt
index ab0766f..c784a18 100644
--- a/Documentation/sound/alsa/soc/dapm.txt
+++ b/Documentation/sound/alsa/soc/dapm.txt
@@ -4,20 +4,20 @@ Dynamic Audio Power Management for Portable Devices
 1. Description
 ==============
 
-Dynamic Audio Power Management (DAPM) is designed to allow portable Linux devices
-to use the minimum amount of power within the audio subsystem at all times. It
-is independent of other kernel PM and as such, can easily co-exist with the
-other PM systems.
+Dynamic Audio Power Management (DAPM) is designed to allow portable
+Linux devices to use the minimum amount of power within the audio
+subsystem at all times. It is independent of other kernel PM and as
+such, can easily co-exist with the other PM systems.
 
-DAPM is also completely transparent to all user space applications as all power
-switching is done within the ASoC core. No code changes or recompiling are
-required for user space applications. DAPM makes power switching decisions based
-upon any audio stream (capture/playback) activity and audio mixer settings
-within the device.
+DAPM is also completely transparent to all user space applications as
+all power switching is done within the ASoC core. No code changes or
+recompiling are required for user space applications. DAPM makes power
+switching decisions based upon any audio stream (capture/playback)
+activity and audio mixer settings within the device.
 
-DAPM spans the whole machine. It covers power control within the entire audio
-subsystem, this includes internal codec power blocks and machine level power
-systems.
+DAPM spans the whole machine. It covers power control within the entire
+audio subsystem, this includes internal codec power blocks and machine
+level power systems.
 
 There are 4 power domains within DAPM
 
@@ -34,7 +34,7 @@ There are 4 power domains within DAPM
       Automatically set when mixer and mux settings are changed by the user.
       e.g. alsamixer, amixer.
 
-   4. Stream domain - DAC's and ADC's.
+   4. Stream domain - DACs and ADCs.
       Enabled and disabled when stream playback/capture is started and
       stopped respectively. e.g. aplay, arecord.
 
@@ -51,7 +51,7 @@ widgets hereafter.
 Audio DAPM widgets fall into a number of types:-
 
  o Mixer      - Mixes several analog signals into a single analog signal.
- o Mux        - An analog switch that outputs only 1 of it's inputs.
+ o Mux        - An analog switch that outputs only one of many inputs.
  o PGA        - A programmable gain amplifier or attenuation widget.
  o ADC        - Analog to Digital Converter
  o DAC        - Digital to Analog Converter
@@ -78,14 +78,14 @@ parameters for stream name and kcontrols.
 2.1 Stream Domain Widgets
 -------------------------
 
-Stream Widgets relate to the stream power domain and only consist of ADC's
-(analog to digital converters) and DAC's (digital to analog converters).
+Stream Widgets relate to the stream power domain and only consist of ADCs
+(analog to digital converters) and DACs (digital to analog converters).
 
 Stream widgets have the following format:-
 
 SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert),
 
-NOTE: the stream name must match the corresponding stream name in your codecs
+NOTE: the stream name must match the corresponding stream name in your codec
 snd_soc_codec_dai.
 
 e.g. stream widgets for HiFi playback and capture
@@ -97,7 +97,7 @@ SND_SOC_DAPM_ADC("HiFi ADC", "HiFi Capture", REG, 2, 1),
 2.2 Path Domain Widgets
 -----------------------
 
-Path domain widgets have a ability to control or effect the audio signal or
+Path domain widgets have a ability to control or affect the audio signal or
 audio paths within the audio subsystem. They have the following form:-
 
 SND_SOC_DAPM_PGA(name, reg, shift, invert, controls, num_controls)
@@ -149,7 +149,7 @@ SND_SOC_DAPM_MIC("Mic Jack", spitz_mic_bias),
 2.4 Codec Domain
 ----------------
 
-The Codec power domain has no widgets and is handled by the codecs DAPM event
+The codec power domain has no widgets and is handled by the codecs DAPM event
 handler. This handler is called when the codec powerstate is changed wrt to any
 stream event or by kernel PM events.
 
@@ -158,8 +158,8 @@ stream event or by kernel PM events.
 -------------------
 
 Sometimes widgets exist in the codec or machine audio map that don't have any
-corresponding register bit for power control. In this case it's necessary to
-create a virtual widget - a widget with no control bits e.g.
+corresponding soft power control. In this case it is necessary to create
+a virtual widget - a widget with no control bits e.g.
 
 SND_SOC_DAPM_MIXER("AC97 Mixer", SND_SOC_DAPM_NOPM, 0, 0, NULL, 0),
 
@@ -172,13 +172,14 @@ subsystem individually with a call to snd_soc_dapm_new_control().
 3. Codec Widget Interconnections
 ================================
 
-Widgets are connected to each other within the codec and machine by audio
-paths (called interconnections). Each interconnection must be defined in order
-to create a map of all audio paths between widgets.
+Widgets are connected to each other within the codec and machine by audio paths
+(called interconnections). Each interconnection must be defined in order to
+create a map of all audio paths between widgets.
+
 This is easiest with a diagram of the codec (and schematic of the machine audio
 system), as it requires joining widgets together via their audio signal paths.
 
-i.e. from the WM8731 codec's output mixer (wm8731.c)
+e.g., from the WM8731 output mixer (wm8731.c)
 
 The WM8731 output mixer has 3 inputs (sources)