aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorMark Brown <broonie@opensource.wolfsonmicro.com>2009-09-22 11:50:32 -0400
committerLiam Girdwood <lrg@slimlogic.co.uk>2009-09-22 17:16:53 -0400
commit63209a71e8e7727f52208d17bb7180cd392edcfb (patch)
tree66f39826fdde64d0d77555a98c744d171df1e4fc /Documentation
parent55c1d7c60d9b269551cd7cc31e6be8323e1d94ec (diff)
regulator: Add some brief design documentation
Provide some brief documentation of some of the design decisions that are made by the regulator API. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/power/regulator/design.txt33
1 files changed, 33 insertions, 0 deletions
diff --git a/Documentation/power/regulator/design.txt b/Documentation/power/regulator/design.txt
new file mode 100644
index 000000000000..f9b56b72b782
--- /dev/null
+++ b/Documentation/power/regulator/design.txt
@@ -0,0 +1,33 @@
1Regulator API design notes
2==========================
3
4This document provides a brief, partially structured, overview of some
5of the design considerations which impact the regulator API design.
6
7Safety
8------
9
10 - Errors in regulator configuration can have very serious consequences
11 for the system, potentially including lasting hardware damage.
12 - It is not possible to automatically determine the power confugration
13 of the system - software-equivalent variants of the same chip may
14 have different power requirments, and not all components with power
15 requirements are visible to software.
16
17 => The API should make no changes to the hardware state unless it has
18 specific knowledge that these changes are safe to do perform on
19 this particular system.
20
21Consumer use cases
22------------------
23
24 - The overwhelming majority of devices in a system will have no
25 requirement to do any runtime configuration of their power beyond
26 being able to turn it on or off.
27
28 - Many of the power supplies in the system will be shared between many
29 different consumers.
30
31 => The consumer API should be structured so that these use cases are
32 very easy to handle and so that consumers will work with shared
33 supplies without any additional effort.