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>
This commit is contained in:
parent
55c1d7c60d
commit
63209a71e8
|
@ -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.
|
Loading…
Reference in New Issue