diff options
author | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2009-09-22 11:50:32 -0400 |
---|---|---|
committer | Liam Girdwood <lrg@slimlogic.co.uk> | 2009-09-22 17:16:53 -0400 |
commit | 63209a71e8e7727f52208d17bb7180cd392edcfb (patch) | |
tree | 66f39826fdde64d0d77555a98c744d171df1e4fc /Documentation | |
parent | 55c1d7c60d9b269551cd7cc31e6be8323e1d94ec (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.txt | 33 |
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 @@ | |||
1 | Regulator API design notes | ||
2 | ========================== | ||
3 | |||
4 | This document provides a brief, partially structured, overview of some | ||
5 | of the design considerations which impact the regulator API design. | ||
6 | |||
7 | Safety | ||
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 | |||
21 | Consumer 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. | ||