|
@@ -0,0 +1,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 confugration
|
|
|
+ of the system - software-equivalent variants of the same chip may
|
|
|
+ have different power requirments, 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.
|
|
|
+
|
|
|
+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.
|