← Documents Documentation/power/regulator/design.rst GitHub 원문 ↗

Linux 6.18.37 · Power

Regulator API design notes

Hardware safety와 shared supply를 기본으로 하는 regulator API의 보수적 설계 원칙을 설명합니다.

Source pathDocumentation/power/regulator/design.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

design.rst:1-38

Hardware safety와 shared supply를 기본으로 하는 regulator API의 보수적 설계 원칙을 설명합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 ==========================
2 Regulator API design notes
3 ==========================
4
5 This document provides a brief, partially structured, overview of some
6 of the design considerations which impact the regulator API design.
7
8 Safety
9 ------
10
11 - Errors in regulator configuration can have very serious consequences
12 for the system, potentially including lasting hardware damage.
13 - It is not possible to automatically determine the power configuration
14 of the system - software-equivalent variants of the same chip may
15 have different power requirements, and not all components with power
16 requirements are visible to software.
17
18 .. note::
19
20 The API should make no changes to the hardware state unless it has
21 specific knowledge that these changes are safe to perform on this
22 particular system.
23
24 Consumer use cases
25 ------------------
26
27 - The overwhelming majority of devices in a system will have no
28 requirement to do any runtime configuration of their power beyond
29 being able to turn it on or off.
30
31 - Many of the power supplies in the system will be shared between many
32 different consumers.
33
34 .. note::
35
36 The consumer API should be structured so that these use cases are
37 very easy to handle and so that consumers will work with shared
38 supplies without any additional effort.
39

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

설계 고려사항

1-7

이 문서는 regulator API 설계에 영향을 주는 일부 고려사항을 간략하고 부분적으로 구조화해 설명합니다.

==========================
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 원칙

8-23

Regulator configuration 오류는 system에 매우 심각한 결과를 일으킬 수 있고 영구적인 hardware damage까지 초래할 수 있습니다.

System의 power configuration을 자동으로 판별할 수는 없습니다. Software 관점에서 같은 chip variant라도 power requirement가 다를 수 있고, power가 필요한 모든 component가 software에 보이는 것도 아닙니다.

따라서 API는 해당 system에서 변경이 안전하다는 구체적인 지식이 없으면 hardware state를 바꾸지 않아야 합니다.

Regulator safety
위험설계 원칙
잘못된 voltage/current영구 hardware damage 가능
자동 topology 추론 불가Machine-specific 지식 필요
안전성 근거 없음Hardware state 변경 금지

변경 허용의 기본값은 보수적이어야 합니다.

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.

.. note::

     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 사용 사례

24-38

System device의 압도적 다수는 power를 켜고 끄는 것 외에는 runtime power configuration이 필요하지 않습니다.

또한 system의 많은 power supply는 여러 consumer가 공유합니다.

Consumer API는 단순 on/off 사용 사례를 매우 쉽게 처리하고, consumer가 추가 작업 없이 shared supply에서도 동작하도록 구성해야 합니다.

Consumer API 목표
일반 사례API 요구
Runtime 조정 없는 on/off간단한 enable/disable
여러 consumer가 supply 공유Reference count와 자동 합산

흔한 on/off와 shared supply를 기본 경로로 최적화합니다.

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.

.. note::

     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.