summaryrefslogtreecommitdiff
path: root/Documentation/power/regulator/design.txt
blob: fdd919b96830b882e54c31d4c7b1f5f468624a5e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Regulator API design notes
==========================

This document provides a brief, partially structured, overview of some
of the design considerations which impact the regulator API design.

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 configuration
   of the system - software-equivalent variants of the same chip may
   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 perform on this
     particular system.

Consumer use cases
------------------

 - The overwhelming majority of devices in a system will have no
   requirement to do any runtime configuration of their power beyond
   being able to turn it on or off.

 - Many of the power supplies in the system will be shared between many
   different consumers.

  => The consumer API should be structured so that these use cases are
     very easy to handle and so that consumers will work with shared
     supplies without any additional effort.