diff options
| author | Takashi Iwai <tiwai@suse.de> | 2014-10-06 14:01:11 +0200 |
|---|---|---|
| committer | Takashi Iwai <tiwai@suse.de> | 2014-10-06 14:01:11 +0200 |
| commit | 8df22a4d6f5b81c9c1703579d4907b57002689ed (patch) | |
| tree | 064e9662d427a82076e1151fcd9aa78a1066f9f4 /Documentation/power/regulator/design.txt | |
| parent | 0cae90a96c15f2fd3bd139ba5505755c9c9ef2eb (diff) | |
| parent | a5448c88b812390a3622e76d774e10c0da1fb970 (diff) | |
Merge tag 'asoc-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v3.18
- More componentisation work from Lars-Peter, this time mainly
cleaning up the suspend and bias level transition callbacks.
- Real system support for the Intel drivers and a bunch of fixes and
enhancements for the associated CODEC drivers, this is going to need
a lot quirks over time due to the lack of any firmware description of
the boards.
- Jack detect support for simple card from Dylan Reid.
- A bunch of small fixes and enhancements for the Freescale drivers.
- New drivers for Analog Devices SSM4567, Cirrus Logic CS35L32, Everest
Semiconductor ES8328 and Freescale cards using the ASRC in newer i.MX
processors.
Diffstat (limited to 'Documentation/power/regulator/design.txt')
| -rw-r--r-- | Documentation/power/regulator/design.txt | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/Documentation/power/regulator/design.txt b/Documentation/power/regulator/design.txt index f9b56b72b78..fdd919b9683 100644 --- a/Documentation/power/regulator/design.txt +++ b/Documentation/power/regulator/design.txt @@ -9,14 +9,14 @@ Safety - Errors in regulator configuration can have very serious consequences for the system, potentially including lasting hardware damage. - - It is not possible to automatically determine the power confugration + - It is not possible to automatically determine the power configuration of the system - software-equivalent variants of the same chip may - have different power requirments, and not all components with power + have different power requirements, and not all components with power requirements are visible to software. => The API should make no changes to the hardware state unless it has - specific knowledge that these changes are safe to do perform on - this particular system. + specific knowledge that these changes are safe to perform on this + particular system. Consumer use cases ------------------ |