- 이 글의 대부분의 내용은 `Power Control System Architecture 2.1` 를 번역했다. 그러나, 내가 이해한 방식으로 번역해서 실제 문서와는 꾀 다를 수 있음을 주의하자.
글의 내용
- System Control Processor
" 아래 보이는 것처럼 SoC에서 `power control function` 기능을 담당하는 영역은 `sleep state` 에서도 active를 유지하고 있다. `arm`의 PSSA 구조에서 해당 영역을 `Always-On` 이라고 부른다.
Power Control System Architecture
" 여태까지 `power control function` 들은 대개 하드웨어에서 지원하는 기능들을 소프트웨어에서 직접 구현하는 방식으로 이루어졌다. 이와 같이, AP가 하드웨어에 리소스를 직접적으로 사용하게 되면, 중요한 작업을 하는 상황이 아니어도 계속 active 상태를 유지하거나, 빈번히 `sleep-state`에서 `wake-up` 하게 된다.
" 그래서 `arm` 은 `power control function` 들을 별도의 MCU 에게 책임을 전가하는 방안을 채택하게 된다. 이렇게 되면, AP 와 하드웨어와 의존성이 사라지게 되고 AP 와 Hardware 사이에 `Firmware` 라는 새로운 레이어가 형성된다. MCU 는 소프트웨어에 의해서 동작하기 때문에 이제부터는 `Software <-> Hardware`가 아닌, `Software <-> Software` 가 되어 이전보다 훨씬 유연한 구조를 가질 수 있게 되었다.
Power Control System Architecture
" arm 의 `PCSA` 구조에서 위와 같은 MCU를 `System Control Processor(SCP)` 라고 부른다. `SCP`는 직접 하드웨어와 통신하면서 AP 에게 파워 매니지먼트 기능 및 서비스를 제공한다. 모바일쪽에서 `SCP` 는 주로 `Cortex-M` 으로 구현된다. 위에서 `AP Software` 에서 `AP FW` 가 `SCP` 와 통신하면서 하드웨어 기능 및 서비스를 요청하는 것을 볼 수 있다. 그리고, `Agent` 들은 다른 IP`s or subsystems 들을 의미한다. 대표적인 예로 `모뎀`이 될 수 있다. 퀄컴 같은 경우에는 `APSS`, `MDSS` 등(별도의 processor 를 탑재하고 있는 hardware 를 의미) 이 `Agent` 에 해당하고, `AOSS` 가 `SCP` 에 해당한다고 볼 수 있다.
" 결국 `SCP`의 핵심적인 기능은 하드웨어 리소스를 컨트롤하는 것이라 볼 수 있다. 비록 위 그림에서는 보이지는 않지만, SCP 안에는 `local private memory`, `timers`, `interrupt control`, `register` 등과 같은 최소한의 리소스들을 가지고 있다. 그외에 `SCP`가 제공하는 주요 서비스들은 다음과 같다.
1. Response to system events - Timer events : 아래에서 보겠지만, SCP 또한 로컬 타이머를 가지고 있다. 이 타이머는 시스템을 wake-up 시키거나, 주기적인 상태 모니터링을 위해서 사용된다. - Wake events : GIC 웨이크-업 인터럽트 뿐만 아니라, IPI 관련 인터럽트를 포함해서 모든 `wake-up request`를 처리하는 업무를 맡고 있다. - Watchdog events : 아래에서 보겠지만, SCP는 `Local watchdog` 모듈을 가지고 있다. 왓치-독 타임아웃이 발생할 경우, 시스템을 리셋한다.
2. System aware function - SCP 펌웨어는 하드웨어 리소스에 대한 모든 `agents` 들에 요청을 모아서 컨트롤한다. 이 말은 프로세서들끼리 통신하기 위해서는 반드시 SCP 펌웨어를 거쳐야 한다는 뜻이 된다. 이런 구조를 통해 AP는 좀 더 오래 `sleep` 상태를 유지할 수 가 있다. - OS에서 OPP를 설정하는 것은 조금 위험할 수 있다. 왜냐하면, OPP는 현재 시스템 하드웨어에 가장 최적화된 값으로 설정이 되어야 하기 때문에, 하드웨어 디펜던시가 강한 부분이다. 그러므로, 이 값을 범용적인 OS에서 바꾸는 것은 조금 위험한 행위다. 그래서, SCP 펌웨어는 OS가 특정 시나리오에서 임의의 OPP를 선택했을 때, 하드웨어를 보호한다는 목적으로는 해당 OPP를 사용하지 않을 수 있다.
" SCP 펌웨어를 통해 OS에서 하드웨어 종속적인 부분들이 사라지면서, 디바이스 드라이버 및 BSP 제작이 상당히 심플해진다. 그리고, SCP 펌웨어를 통해 AP가 `low-power-state`에 더 오래 유지할 수 있도록 해주는 방패 역할을 해준다. 왜냐면, AP가 `low-power-state`에 있을 때, 굉장히 사소한 일들에도 `wake-up`이 되어야 하는 상황들이 있다. 그런데, SCP 펌웨어를 도입함으로써, AP가 `low-power-state`에 들어가면, AP 대신 SCP 펌웨어가 AP가 수행하던 기본적인 작업들을 처리하기 때문이다.
- Power Management Software
" 아래 block diagram 은 일반적인 arm architecture 에서 사용하는 power management software stack 을 보여준다. 아래 block diagram 에서 크게 2 가지 components 들로 나눌 수 있다.
1. OS power management framework(OSPM) 2. SCP 에게 직접 service 를 요청할 수 있는 component(Self-Managed Devices)
" 가장 핵심은 모든 `hardware power management actions` 들은 SCP 에 의해서 실행된다는 것이다.
Power Control System Architecture
" OS power management(OSPM) 은 크게 2 가지 파트로 나눠볼 수 있다.
1. Core power management : 말 그대로 `CPU 코어` 파워 매니지먼트를 의미한다. 대게, CPU 파워 매니지먼트는 OS의 스케줄링과 깊은 연관성을 뛰고있다. 코어 파워 매니지먼트는 크게 2가지 관점에서 나눠볼 수 있다.
1. Idle management : 일반적인 `CPU idle PM` 은 해당 AP 코어에 스케줄링할 스레드가 없을 경우, OSPM이 해당 코어를 idle 상태로 진입시킨다. 그런데, 재미있는 건 `power-off core`라도 OS 스케줄링 대상으로 남아있고, 시스템이 `power-off`가 아닌 이상, 코어가 `power-off`가 된 것은 런타임에 `power-on`이 가능하다. `CPU idle`이 아닌 더 강력한 방식도 존재한다.
" `CPU idle PM` 방식을 대체할 수 있는 더 강력한 방식이 존재한다. 바로 `CPU hotplug` 방식이다. 소프트웨어적으로 hotplug된 코어는 OS 의 스케줄링 대상에서 제외된다. 그리고, 하드웨어적으로는 코어가 power-off 되고, 해당 코어에서 담당했던 인터럽트 및 스레드들은 다른 코어로 migrated 된다.
2. DVFS management : DVFS 는 상황에 따라 변할 수 있는 소비 전력 효율성을 맞추기 위해 동적으로 동적으로 다양한 { 전압, 주파수 } 레벨 테이블을 만들어서, 상황에 맞게 적절한 퍼포먼스 레벨을 적용하는 방법을 말한다. 대개, `온도 제어` 관련해서 `thermal mitigation` 알고리즘들도 DVFS 와 연관되어 있다. 왜냐면, 온도가 높아지면, 열을 낮추기 위해 CPU 주파수를 낮춰야 하기 때문이다.
2. Device power management : 시스템에 존재하는 대부분의 디바이스들은 시스템 `OS-managed` 다. 그래서 디바이스들은 해당 OS 에 크게 의존하고, 하드웨어 리소스 액세스 요청 권한이 모두 OS 에게 있다. 그러나, SoC 에는 여러 프로세서가 들어가고, 각 프로세서마다 동작하는 OS 가 다를 수 있다. 심지어, 펌웨어로 동작하는 프로세서 또한 있다. 이러한 관점에서 디바이스 파워 매니지먼트는 크게 2가지 측면으로 나눠볼 수 있다.
1. OS managed : 이 영역에 속하는 디바이스는 파워 매니지먼트 권한을 모두 OS 에게 위임하게 된다. 예를 들어, 리눅스 커널에서 특정 디바이스가 `System PM` 및 `Runtime PM` 을 구현하는 경우, 디바이스의 파워 매니지먼트 플로우가 리눅스 커널에서 제공하는 흐름에 맞춰서 발동이 된다. 이 때, 디바이스가 아닌 OSPM 이 SCP 에게 하드웨어 리소스 사용 요청을 한다. 2. Self managed(Not OS managed) : 몇몇 self-managed devices 들은 agent(퀄컴의 MPSS 등) 처럼 직접 SCP 에게 power management 기능을 요청한다. 대개 self-managed devices 은 2 개로 나눠볼 수 있다. 먼저, `fully self-managed` devices 들은 SCP 에게 요청하는 모든 서비스들이 power management 일 때이다. fully self-managed devices 들은 OSPM 과는 완전히 독립적으로 동작한다. `partially self-managed` devices 들은 SCP 에게 직접 서비스를 요청하는 경우도 있고, OSPM 을 통해서 서비스를 요청하는 경우도 있는 device 를 의미한다.
" 위 그림에서 `self-managed` devices 들은 아마도 독립적인 자체 software interface path 를 가지고 있을 것이다. 여기서 software interface path 는 self-managed device 가 자체 software 를 통해서 SCP 에게 직접 서비스를 요청하는 메커니즘이 있다는 것을 의미한다. 어떻게 이게 가능할까?
" SCP 에 하드웨어적으로 연결되려면, on-chip device 여야 한다. 그러나, 아래에서 보겠지만, SCP 와 통신하기 위해서 별도의 하드웨어 라인이 필요하지 않다. SCP 에게 service 를 요청하려면, mailbox & door bell register 를 이용한다. 즉, 특별한 하드웨어 인터페이스 없이 system memory 의 특정 영역에 데이터를 writing 함으로써 SCP 에게 서비스를 요청할 수 있다.
" `arm`에서 제시하는 Linux 기반의 mobile software stack 은 아래와 같다. 기본적으로 EAS 방식을 통해 `core scheduling` 을 진행하고 있으며, EAS 는 `thermal management solution` 인 `IPA(Intelligent Power Allocation)` 와도 상호 작용을 하며, 전반적인 `mobile arm` 생태계의 파워 매니지먼트를 관리한다. 그리고, EAS & IPA 는 각 use case 에 opimization 이 될 수 있도록 하기 위해 user space 에서 컨트롤이 가능하다.
Figure 3.4 Linux mobile : example power management software stack
" `OS agnostic standard FW` 는 OS 에 의존하지 않는 독립적인 소프트웨어 계층을 의미한다. PCSA 구조에서는 `SCMI` 레이어가 SCP 펌웨어와 통신할 수 있는 인터페이스를 제공해준다. `PSCI` 는 `Core power management - Idle management` 기능을 제공하는 인터페이스라고 보면 된다. 이런 PSCI 기능을 사용하려면 결국 SCP 를 통해서 수행되어야 하며, PSCI 가 SCP 와 통신하려면, 결국 SCMI 를 거쳐야 한다.정리하면, SCMI 는 hardware 에 의존적이지 않은 계층으로 ARM PCSA 구조를 따르는 여러 OS 들은 hardware 가 변경되더라도, 수정할 필요가 없게된다. 왜냐면, hardware 에 직접적으로 의존적인 소프트웨어는 SCP 이기 때문에, SCP 만 수정딘 hardware 에 맞게 소스 코드가 변경될 뿐이다.
" 아래 구조는 mobile이 아닌 server 시장에서의 `arm PCSA` 구조를 보여준다. 이전과 가장 큰 차이점은 `ACPI` 를 사용하는 레이어가 추가되었다는 점이다. 서버 시장이다 보니, `x86` 기반의 PC 코어들이 여전히 압도적인 점유율을 보이고 있다. 그래서인지, `arm` 또한 ACPI 를 따르고 있다. 그런데, `arm`의 SCP 펌웨어와 비슷한 역할을 하는 ACPI 펌웨어가 존재한다. 바로 `BIOS 및 UEFI` 다. `Standard OS` 계층을 Linux 로 본다면, `Industry standard FW` 는 ACPI 스펙을 따르는 `BIOS 및 UEFI 펌웨어` 라고 볼 수 있다.
Figure 3.5 : Infrastructure system : example power management software stack
- Voltage domains and Power domains
" power management 관련해서 domain 은 크게 2 개로 나눠볼 수 있다.
1. voltage domain - a single voltage source 를 통해서 전원이 공급되는 domain 을 의미한다. 대개는 DVFS 를 적용하기 위해 하나의 voltage domain 에는 다양한 voltage supplies 들이 존재한다. 요즘에도(2023.12) 단일 voltage domain 을 동작하는 SoC 가 있을까? 있긴 있다. 하드웨어 구조가 굉장히 단순한 시스템에서는 여전히 single voltage domain 을 사용한다. 그러나, SoC 라고 부르는 반도체에는 single voltage domain 을 사용하지 않는다. 그렇다면, 현재 대부분의 SoC 는 multiple voltage domains 을 사용한다는 것인데, 그 이유는 2 가지가 있다.
1. SoC level 에서 DVFS 를 적용하기 위해서다. 하나의 voltage domain 에 여러 개의 voltage supplies 를 두어서 상황에 맞게 voltage 와 frequency 를 바꾸겠다는 소리다. 참고로, 우리가 흔히아는 DVFS 는 CPU 만 적용되는 것처럼 알고 있지만, DVFS 는 GPU 및 성능이 높은 devices 들에도 적용되는 기술이다. DVFS 는 energy 와 performance 를 최적화하는데 있어서, 가장 기본적인 기술이다.
2. power gating 에 대체체 역할을 할 수 있다. 즉, voltage domains 을 더 추가함으로써 idle 상태의 devices 들은 powered-off 시키면서 동시에 특정 기능을 수행해야 하는 devices 들에게 지속적으로 전원을 공급할 수 있도록 해준다.
" 비용적인 측면에서 voltage supplies 를 추가하는 것은 굉장히 주의가 필요하다. voltage supplies 를 추가한다는 것은 새로운 voltage regulator 를 추가한다는 것인데, SoC physical implementation 측면에서 구조가 복잡해질 가능성이 높으며, 복잡해지는 만큼 추가하는데 상당한 노력이 필요하다.
2. power domain - 하나의 voltage domain 은 여러 개의 power domain 으로 나눌수 있다. 좀 더 정확하게 표현하면, 하나의 voltage domain 은 다수의 power-gated domain 및 always-on(not-gated) power domain 으로 나눠서 볼 수 있다. 그렇다면, voltage domain 을 여러 개의 power domains 들로 분리한 이유가 뭘까? 즉, power domain 을 도입한 배경이 뭘까? static leakae power 를 완화시켜주기 때문이다.
" 쉽게 정리해보자. voltage domains 은 동적으로 DVFS 를 적용하기 위해 등장했고, power domains 은 동적으로 On / Off 를 적용하기 위해 등장했다고 생각하면 쉽다.
- power modes of power(-gated) domain
" hardware level 에서 power-gated domain 은 3 가지 power modes 를 가질 수 있다(주의해야 할 점이 있다. 이건 power domain 의 power mode 를 의미한다. PPU 의 power mode 를 의미하는 것이 아니다).
1. ON " power domain 은 항시 ON 모드를 지원해야 한다. 이 모드는 가장 normally working(functional) mode 를 의미한다. 즉, 특별한 일이 없으면 power domain 은 ON 상태에 놓인다. ON mode 에서 system 은 power 와 관련된 어떠한 간섭없이 정상적인 동작들을 수행할 수 있다. 일반적으로, DVFS 는 power domain 이 ON mode 일 때만 적용되는 메커니즘이다. 즉, ON mode 에서는 dynamic power consumption 를 줄이기 위해 DVFS 및 clock gating 등의 메커니즘들이 적용될 수 있다.
2. OFF " OFF power mode 는 power supply 를 제거하기 때문에, 현재 software 및 hardware context 가 소멸해버린다. OFF mode 를 지원하기 위해서는 반드시 OFF mode 로 진입하기전에 중요한 context 를 저장하고, 다시 ON mode 로 돌아갈 때, context 를 복구하는 메커니즘이 구현되어 있어야 한다. context 를 저장 및 복구하는 메커니즘은 software or hardware 으로 구현될 수 있다.
" 한 가지 주의할 점이 있다. OFF mode 를 사용하면 resume latency 에서 상당한 overhead 가 발생한다. 즉, 깊게 잠들 수 록, 깨는데 오래 걸린다는 것이다. 이것 또한 devices 마다 다르다. 일반적으로, device 가 기능이 많을 수 록, wake-up 하는데 시간이 오래걸린다. 그러나, 일반적으로 resume 시에 restore 및 reconfigration 에 소요되는 시간이 많이 걸린느 deivces 는 많지 않다.
3. RETENTION [참고1] " Retention mode 는 powered-off 상태에서도 현재 cell 의 state 를 유지하는 mode 를 의미한다. 이게 무슨말일까? OFF mode 와 비교해보면 이해할 수 있을 것이다.
- OFF : Loss current contexts and states + Powered-off - RETENTION : Retain current contexts and states + Powered-off
" 위에서 볼 수 있다시피, 현재 상태 정보를 유지한채로 powered-off 가 되는 것을 의미한다. RETENTION mode 는 주로 fast recovery 용으로 사용된다. 예를 들어, linux 에서 `echo mem > /sys/power/state` 를 생각하면 쉽다.
" RET mode 는 구현하는 방법은 여러 가지가 있는데, 이 때, 2 가지 카테고리를 기준으로 RET mode 를 구분한다.
- Entry to and exit from the mode : This can be either hardware autonomous or software visible - Physical implementation : Full or partial state retention within the mode
" 먼저 `Entry to and exit from the mode` 를 기준으로 RET mode 를 구분해보자.
1. hardware autonomous RET mode - system 이 이미 RET mode 라고 가정하자. 이 때, wake event 가 발생했고 RET mode 에서 restore process 의 모든 과정이 hardware 에 의해서 이루어지는 RET mode 를 말한다. 즉, software 가 전혀 개입하지 않는 것을 말한다. 일반적으로, hardware autonomous RET mode 는 physical implemention 측면에서 보면 full retention 으로 정의한다.
2. software visible RET mode - system 이 이미 RET mode 라고 가정하자. 이 때, wake event 가 발생했고 RET mode 에서 일부 restore process 과정이 software hardware 에 의해서 이루어지는 RET mode 를 말한다. software visible RET mode 는 restore process 에서만 software 가 개입하는 것이 아닌, RET mode 를 진입하는 과정에서도 context saving 과정도 software 가 개입한다. software visible RET mode 는 linux kenrel 에서 system suspend 를 생각하면 쉽다. system suspend 는 일반적으로, RAM contents 만 retained 하고 나머지 하드웨어들의 state 는 모두 폐기한다. physical implemention 측면에서 보면, partial RET mode 라고 보면된다(RAM 만 RET mode 고, 다른 하드웨어들은 OFF).
" RET mode 는 OFF mode 보다 exit latency 가 적다. 그러나, OFF mode 보다 power consumption 은 상대적으로 더 높다. 여기서, trade-off 가 발생한다. 이제부터는 사용 시나리오에 따라 달라진다. exit latency & residency time & power consumption 등을 잘 고려해서 특정 케이스에 맞는 power mode 를 선택할 필요가 있다.
- Power States and Power Modes
" PCSA 에서 정의하는 power state 와 power mode 는 명확히 다르다. 그리고, 명확히 구분되어야 한다고 한다. 간결하게 정의하면, power state 는 software state 를 의미하고, power mode 는 hardware mode 를 나타낸다. 여기서 중요한 점은 일반적으로, power mode 와 power state 는 1:1 mapping 이 성립하지 않는다는 것이다. 왜냐면, power modes 는 hardware 에서 어떤 power techniques 를 지원하는지에 따라 달라지기 때문이다. 예를 들어, ADC 의 power modes 가 ON / OFF 만 지원한다고 하자. 그런데, software 적으로 SLEEP power state & OFF power state 가 ADC 의 OFF power mode 에 대응할 수 도 있다. 즉, 2 개의 software power states 가 한 개의 hardware power mode 에 대응된다는 것이다. 그렇다면, power mode 는 하드웨어에 의존적이기 때문에 개발자들이 정할 수 없다는 것은 이해했다. 그렇다면, software power states 를 정의하는 기준은 뭘까? PCSA 에서는 software power states 를 정의할 때, 일반적으로 3 가지를 고려한다고 한다.
1. wake capability - 해당 power state 에서 wake-up 이 될 수 있는지 여부
2. loss of context - 해당 software power state 로 진입할 경우, 현재 software 및 hardware 정보(context)들이 모두 소멸되는지 여부
3. power consumption - 해당 power states 를 진입할 경우, 얼마나 전류를 소모하는지 혹은 얼마나 power saving 이 되는지
- Power Domain Hierarchy Requirements
" SBSA(`Server Base System Architecture`) 에서는 `power domain hierarchy` 관련해서 몇 가지 요구 사항있다.
1. always-on power domain 에서 동작하는 system global timer(arm 같은 경우 `Generic Timer` 를 의미)
2. 2가지 wake-up 방법
1. Interrupts from the `Generic Interrupt Controller(GIC)` 2. Always-n domain wake events
3. system memory 사용 여부
Power Control System Architecture
" 위 block diagram 에는 다양하 power domains 들이 존재한다. 요약하면 다음과 같다.
1. Always-On power domain(AON) 에는 SCP, generic timer subsystem 과 wake detection logic 이 포함되어 있다.
2. System Logic domain(SYSTOP) 에는 GIC 와 다른 components 들이 system memory 에 접근할 수 있게 해주는 system logic 들이 포함되어 있다.
3. per-core power-gated domain 과 cluster power-gated domain 이 있다.
4. device 는 2 개로 나눠서 관리된다.
1. OS managed - DMA device 는 `OS managed` 다. DMA 는 GIC 와 system memory 를 사용할 수 있어야 정상 동작이 보장된다. 즉, GIC 와 system memory 에 의존한다.
2. Selff managed - `self-managed` I/O devices 들은 power-gated domain 과 always-on domain 를 모두 가지고 있다. I/O device 의 always-on domain 에서는 SCP 에게 resource 요청을 하기 위해 wake events 를 생성할 수 있다.
" 아래의 항목들은 SBSA 에서 따라야 하는 `power domain partitioning` 관련한 요구 사항들이다.
1. Timer Subsystem
" SoC 는 반드시 always-on power domain 에 `a generic timer subsystem` 을 가지고 있어야 한다.
1. AP core 가 powered-off 되더라도, system 은 powered-off 되지 않는다. system counter 는 AP core 의 시간을 기록하는 device 가 아니다. system counter 는 말 그대로 system 의 시간을 기록하는 device 다. 즉, system 이 powered-on 상태라면, system 의 time 을 계속 기록해줄 수 있도록 always-on domain 에서 system 의 시간을 기록해줘야 한다.
2. system counter 의 count value 는 모든 AP core 의 private timers 들에게 제공되어야 한다.
ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile
" 만약, SoC 가 GIC 까지 powerrd-off 되는 sleep state 를 지원한다면, 해당 sleep state 에서 wake-up 할 수 있도록, always-on wake-up timer event 가 만료되면 always-on wake-up event 를 생성할 수 있어야 한다. 이 때, SCP firmware 는 always-on wake-up timer event 를 받으면, 반드시 AP core 를 wake-up 시킬 수 있어야 한다. 이 인터럽트는 GIC 한테도 전달된다.
" GIC SPI interrupt 로 등록된 Always-on power domain events 들은 반드시 level sensitive 여야 한다. 만약, wake-up event 가 edge trigger 라면, GIC 가 interrupt 를 받는 시점에 powered-off 되어있으면, 인지할 수 가 없다. 그러므로, wake-up event 는 level sensitive 로 해서 GIC 가 powered-on 된 이후에 어떤 인터럽트가 발생했는지를 알 수 있도록 해야 한다.
2. Generic Interrupt Controller(GIC)
" GICv2 에서는 모든 GIC hardware logic 은 single power domain 으로 구성되어 있다. 즉, GICv2 에 공급되는 power supply 가 gated 될 경우, 모든 GICv2 logic 들 또한 power-off 된다. 그러나 GICv3 에서는 power domain 이 좀 더 세분화 되었다.
1. GIC CPU interface 는 반드시 AP core power domain 과 통합되어야 한다.
2. 반면에, redistributor, distributor, interrupt translation service(ITS) 들은 AP core power domain 과 다른 power domain 이여도 된다.
1. redistributor - 이 친구는 AP core power domain 와 같은 power domain 을 사용한다. 혹은, AP core power domain 에 `relatively always-on relationship` 의 power domain 을 사용할 수 도 있다.
2. distributor - GIC distributor 는 반드시 모든 AP cores 들 보다 먼저 power-on 되어야 한다. 그러나, 반드시 always-on domain 일 필요는 없다. 즉, SoC sleep state 에서 powered-off 될 수 있다는 소리다. 예를 들어, GIC distributor 가 powered-off 라면, AP core 는 always-on domain wake events 를 통해서만 wake-up 될 수 있다.
" 참고로, GIC-600 은 GICv3 를 지원한다.
3. Core Timers
" 일반적으로, local AP core timers 들은 AP core 가 powered-off 되는 시점에 함께 powered-off 된다. 만약, AP core timers 들은 powered-off 되면, core 를 power-on 시키기 위해서 GIC 는 반드시 wake-up timer 를 interrupt source 로 등록해야 한다. wake-up timer 는 SCP 에게 wake-up signal 을 날려 SCP 가 core 를 power-on 시킬 수 있도록 한다. 만약, 모든 local AP core timers 들이 always-on domain 이 아니라면, SBSA 에서는 SoC sleep 에서 모든 local AP core timers 들이 powered-off 가 되므로, always-on domain 을 갖는 memory mapped generic timer(system global timer) 를 하나 준비해야 한다고 얘기한다. 더 정확히 얘기하면 SBSA 는 level 0 과 1 을 언급하고 있는데, SBSA 는 이 글을 벗어나는 주제이므로, 이 글에서는 자세한 내용은 생략한다. SBSA level 1 에 대해서만 간략히 설명하자면, system global timer 로 non-secure address space 에 mapping 되는 `memory mapped generic timer` 를 준비해야 한다고 언급하고 있다.
4. Always-On Domain Wake Events
" always-on doamin wake events 이 없다면, `SoC sleep` 기능은 지원되지 않을 것이다. 즉, SoC sleep 에서 system 을 wake-up 시켜줄 always-on power domain resources 들이 있기 때문에, SoC sleep 과 같은 강력한 power state 를 지원할 수 있다는 뜻이다. 위에서 언급했다싶이, SBSA 에서는 always-on wake-up timer 가 expired 될 경우, 반드시 always-on power domain wake event 를 지원해야 한다(ACPI 스펙에 명시되어 있는 부분으로 추측된다). 이외에는 필수는 아니지만, 일반적으로 사용되는 always-on domain wake events 들은 다음과 같다.
1. SoC external events - Off chip events 들을 의미한다. 예를 들어, cable detection(USB, Ethernet 등), power buttons, 무선 패킷 수신(wireless subsystems) 등
2. On-chip events from devices with self-managed capability - high speed I/O(PCIe or USB 3.1 같은 경우, 일부분은 always-on domain 이 존재한다. 이 영역을 통해 AP 에 wake events 를 날릴 수 있음. 예를 들어, USB PHY 는 USB cable detection 을 위해서 특정 부분은 always-on domain 이어야 한다) devices or integrated modes(퀄컴 같은 경우는 AP + MODEM 을 원칩(SoC)으로 통합함. 그래서, AP 가 suspend 에 들어가도 modem 이 QMI 를 통해 AP 를 wake-up 시킬 수 있다)
5. system memory
" memory 는 system 에 존재하는 모든 devices 들에게 dependency 가 있다. 예를 들어, memory 를 사용해야 하는 device 가 powered-on 될 때 마다, memory 를 반드시 사용 가능 상태에 있어야 한다. AP Core 와 system memory 는 동일한 power domain(SYSTOP) 에 있기 때문에, AP core 가 powered-on 되는 시점에 system memory 를 사용할 수 있다.
" 여기서 주의할 점이 있다. system memory 가 powered-off 상태일때도, always-on domain 에서 동작하는 components 들(I/O devices 등) 은 여전히 powered-on 상태다. 이 때, always-on domain 에 있는 components 들이 system memory 를 사용하고 싶을 경우, 어떻게 해야 할까? 이 때는 always-on domain 에 있는 components 들은 wake event 을 생성해서 SCP 에게 던진다. 그리고, system memory 가 사용 가능해질 때 까지 `stall` 한다. 자세한 내용은 `Power Control System Architecture - 7.2.8 Access Control` 파트를 참고하자.
6. power ordering requirements
" power domain hierarchy 는 결국 의존적인 관계에 의해서 형성된 domains 들이다. 각 domains 들간에 관계는 다음과 같다.
1. always-on domain 은 SoC 가 power-on 되어있다면, 항시 accessible 한 영역이다. power-off 시에만 access 하지 못한다. 즉, sleep 에서도 accessible 하다.
2. SYSTOP domain 은 processor cluster 보다 항상 먼저 power-on 되어야 한다.
3. SYSTOP domain 은 OS managed devices 들 보다 항상 먼저 power-on 되어야 한다. 위 그림으로 표현하면 `DMA device` 가 OS managed devices 들에 속한다.
4. 위 그림에서 I/O devices 들은 모두 self-managed devices 들이다. self-managed devices 의 power-gated domain 은 항상 always-on domain 에 의존한다.
5. 각 processor cluster 들은 자신의 cores 들 보다 항상 먼저 power-on 되어야 한다.
" PCSA 문서에서 `relatively always-on relationship` 라는 문장이 나온다. 이 문장의 의미는 parent 와 child 의 관계를 생각하면 된다. 예를 들어, SYSTOP 은 반드시 모든 processor cluster 보다 먼저 powered-on 되어야 한다. powered-off 는 그 반대다.
- SoC Partitioning Exmaple with each voltage and power domain
" 아래 그림은 ARM mobile SoC 를 2가지 domain 으로 분류해놓았다. 여기서 눈 여겨볼 점은 동일한 voltage domain 이더라도, power gate domain 은 다르다는 것을 알 수 있다.
1. voltage domain - 동일한 전압을 사용하는 components 들끼리 group 한다. 2. power gate domain - power gate 가 가능한 components 들과 아닌 components 들로 나눈다.
Voltage Domain
Power-gated Domain
" 위에서 왼쪽 block diagram 은 big.LITTLE 시스템을 voltage domain 을 기준으로 나눴을 때의 모습이다. 그리고, 오른쪽은 voltage domain 에 power domain 이 적용된 모습이다.
- Power State Hierarchy
" system level power control 관점에서 볼 때, 모든 디바이스들을(CPU, I/O devices) 을 어떠한 순서 및 방법으로 power management 를 해야할 지 고민이 많이 된다. 이러한 관점에서 아래 power state hierarchy 를 사용하면 최소한 중복으로 가장 합리적인 system power state or mode 를 select 할 수 있다. 아래 그림은 단순함을 위해서 device power management 가 제외되었다(I/O devices 같은 경우는 모든 I/O deivces 가 OS-managed 가 아니기 때문에, 주의가 필요하다(self-managed 도 존재)). 즉, CPU, Cluster, SoC 만 power management 대상으로 간주한다.
Power Control System Architecture
" 위에 hierarchy 구조는 아래로 내려가기 위해서는 위에가 먼저 조건을 충족해야 하는 구조다. 예를 들어, Cluster 0 이 OFF state 가 되려면, Cluster 0 안에 모든 Cores 들이 OFF 상태여야 한다. SoC 는 모든 Clusters 들과 Devices 들이 OFF 여야, 자신도 OFF 가 될 수 있다. 여기서 중요한 건, SoC 가 OFF 될 때, Cores 들의 상태를 검사하지 않았다는 것에 있다. 왜냐면, Clusters 들이 OFF 가 됬다는 것은 모든 Cores 들이 OFF 라는 것을 의미하기 때문이다.
1. Core Power States
" `Server Base System Architecture` 에서 정의한 AP cores 의 power states 는 다음과 같다.
Core Power States
Description
RUN
core 가 powered-on 상태이며, 코드를 실행 중임을 나타낸다.
IDLE_STANDBY
core 가 `WFI` 상태임을 나타낸다. full context 가 유지되기 때문에, context saving & restoration 작업이 필요없다. 이 상태는 interrupt 및 debug request 를 통해서 resume 될 수 있다.
위에 내용이 PCSA 에서 제시하는 요구 사항이다. SoC 제조사에서는 위에 내용만 지킨다면 어떻게 구현하든 상관이없다. 리눅스 커널의 CPUIDLE 은 powered-off 가 아니기 때문에, CPU 는 polling(이 때, nop 명령을 사용) 을 하면서 대기하기 때문에 모든 context 가 유지된다.
IDLE_RETENTION
core 가 `WFI` 상태임을 나타낸다. full context 가 유지되기 때문에, context saving & restoration 작업이 필요없다. 이 상태는 interrupt 및 debug request 를 통해서 resume 될 수 있다.
IDLE_STANDBY 와 차이가 있다면, 이 상태에서는 외부에서 debug registers 에 access 할 수 없다(IDLE_STANDBY 에서는 debug registers 에 access 할 수 있다).
SLEEP
core 는 powered-off 된다. 그러나, 특정 hardware(예를 들어, GIC) 에 의해서 core 를 wake-up(powered-on) 시킬 수 있다. 예를 들어, GIC 로 부터 wake-up interrupt 를 받게 되면 core 는 wake-up 하게 된다.
이 상태에서는 context 가 retained 되지 않기 때문에, 반드시 명시적으로 이 상태가 되기전에 context 를 saving 해야 한다.
OFF
SLEEP 과 OFF 의 차이는 OFF 에서는 interrupt 에 의해 core 가 wake-up 되지 않는다는 것이다. OFF 에서 core 를 wake-up 시키는 유일한 방법은 power controller(SCP) 에게 명시적으로 core 를 powered-on 시켜달라는 request 를 날려야 한다.
software 적으로 OFF power state 와 SLEEP power state 는 서로 다르다. 그러나, 2 개의 power states 는 하드웨어적으로 동일한 power modes 를 사용할 수 있지만, 의미는 다르다. 즉, SLEEP 은 wake
" 아래 표에서 power state 와 power mode 의 대응 관계는 2 가지 조건을 기준으로 판단한다.
1. loss of context 2. wake properties
" IDLE_STANDBY 와 IDLE_RETENTION power states 는 `WFI or WFE + no loss of contex` 로 정의할 수 있다. 그리고, wake event 를 통해서 resume 된다. 그리고, RET power mode 는 autonomous 하다. 즉, software 가 context 를 saving & restoring 할 필요없다는 뜻이다.
" OFF 와 SLEEP states 은 `loss of context` 를 나타낸다. 그러나, wake-up 여부가 다르다. SLEEP 은 interrupt(wake-up interrupt 로 지정된) 에 wake-up 될 수 있지만, OFF state 는 interrupt 에 의해서 wake-up 할 수 없다.
Power Control System Architecture
" 위에서 볼 수 있다시피, power states 들과 power modes 들이 명확하게 대응하는 경우는 드물다. 그리고, core power management 에서는 Core 와 Advanced SIMD / FP 의 power mode 를 기준으로 power states 를 정의하지만, 뒤에서 볼 cluster power management 는 power states 를 정의하기 위해 더 많은 power modes 를 고려한다.
2. Cluster Power States
" PCSA 에서 정의하는 AP cluster power states 들은 다음과 같다.
Cluster Power States
Description
RUN
- 쉽기 때문에 설명은 생략한다. 그러나, 주의할 점이 하나있다. `Any` 의 의미는 `어떠한 상태로든 전환되도 상관없다` 라는 뜻이다.
SLEEP_RETENTION
- cluster 는 powered-off 지만, wake capable interrupt 를 통해서 wake-up 될 수 있다. cluster 안에 있는 최소 하나의 core 는 반드시 SLEEP state 여야 하며, 나머지 cores 들은 반드시 SLEEP 혹은 OFF state 여야 한다.
- cluster shared cache 의 내용이 유지된다.
SLEEP
- cluster 는 powered-off 지만, wake capable interrupt 를 통해서 wake-up 될 수 있다. cluster 안에 있는 최소 하나의 core 는 반드시 SLEEP state 여야 하며, 나머지 cores 들은 반드시 SLEEP 혹은 OFF state 여야 한다.
- cluster shared cache 의 내용 또한 유지되지 못한다.
OFF
- cluster 는 powered-off 이며, interrupt 를 통해서 wake-up 될 수 없음. 당연히, cluster 안에 있는 모든 cores 들 또한 OFF state 다.
- cluster shared cache 의 내용 또한 유지되지 못한다.
Power Control System Architecture
3. Device Power States
" OSPM 은 I/O devices 들이 SoC 가 SLEEP state 로 진입하는 것을 막을 수 있도록 하는 메커니즘을 가지고 있다(리눅스 커널에서 특정 device 가 wakeup source 로 등록될 경우, system suspend 를 막을 수 있다). 여기 재미있는 부분은 power state hierarchy 에서 devices 들의 level 이 processor cluster 와 동일 선상에 있다는 것이다. 나중에 리눅스 커널의 system suspend flow 를 분석하는데, 아주 중요한 지표가 되기 때문에 반드시 기억하고 있어야 할 내용이다. PCSA 에서는 `Device Power States` 를 2개로 분류했다.
1. RUN - 말 그대로 device 가 powered-on 상태이며, 동작을 수행할 수 있는 상태를 의미한다. 2. OFF - 말 그대로 device 가 powered-off 된 것을 의미한다. 이 상태에서 device 를 wake 시킬 수 있는 유일한 방법은 powered-on 밖에 없다.
4. SoC Power States
" PCSA 에서 정의하는 power states 는 총 4가지가 있다(참고로, 더 추가하는 가능하다).
SoC Power States
Description
RUN
- 쉽기 때문에 설명은 생략한다. 그러나, 주의할 점이 하나있다. `Any` 의 의미는 `어떠한 상태로든 전환되도 상관없다` 라는 뜻이다.
SLEEP
- SLEEP - SoC system 을 사용할 수 없지만, powered-off 가 된 것은 아니다. 그러나, 언제든 powered-off 가 가능한 상태다. 이 상태에서는 system counter 및 wake-up timer 와 같은 always-on domain 만 power-on 상태로 남아있다. SoC 는 wake-up timer 에 의해서 self-wake 가 가능한 상태고, system-specific wake event 에 의해서도 wake 할 수 있는 상태다.
- 적어도 하나의 processor cluster 는 반드시 SLEEP 상태여야 하고, 나머지 processor cluster 들은 반드시 SLEEP 혹은 OFF 상태여야 한다. 이 상태에서는 GIC 가 OFF 이기 때문에, processors 들을 wake 시킬 수 있는 것은 always-on domain wake events 들 뿐이다.
- 당연히, OS-managed devices 들은 모두 OFF 상태다.
DEEPSLEEP
- SoC 가 powered-off 됨을 의미한다. 이 때, system counter 부터 wake-up timer 까지 모두 off 됨을 의미한다. 이 상태에서는 system 이 스스로 wake-up 할 수 있는 방법이 없다(SLEEP 에서는 system timer(wake-up timer) 를 통해서 self-wake 가 가능했음).
- 이 상태에서는 external wake-up event 를 통해서만 wake-up 이 가능하다. 예를 들어, power-on reset 이 있다(SCP subsystems 에 wake-up detection logic 이 있기 때문에, SoC DEEPSLEEP state 에서도 SCP power domain 은 powered-on 되어있을 것이라 추측됨. 그렇다고, 이 말이 SoC DEEPSLEEP state 에서 모든 always-on power domains 들이 powered-on 이라는 것은 아님. 추측이지만, SCP power domain 만 powered-on 상태로 놓을 수 있다고 생각됨). 이 상태에서는 External DRAM memory 는 RET mode 다.
OFF
- SoC SLEEP state 와 동일하다. 한 가지 차이가 있다면, 이 상태에서는 External DRAM memory 도 OFF 다. 즉, RET mode 가 아니다. 이 상황에서는 일반적으로, non-volatile memory 에 hibernation image 를 저장하는 경우가 많음.
Power Control System Architecture
" SoC DEEPSLEEP & OFF state 에서 말하는 `external wake-up` 은 다음과 같다.
Power Control System Architecture - SCP hadware overview
- System Control Processor
" 그렇다면, PMIC 와 SCP 의 관계는 어떻게 될까[참고1]? 아래 그림은 `SCP internal hardware block diagram` 을 나타낸다. SCP 의 `Voltage Regulator Control` 모듈은 PMIC 와의 통신 인터페이스를 제공한다. 이 말은 SCP가 직접적으로 `Voltage supplies` 를 제공하는 것이 아닌, SCP를 통해서 PMIC를 컨트롤한다고 보는 것이 맞다. `PMIC Interface`는 어떤 PMIC를 사용하냐에 따라 달라질 수 있다. 대개는 I2C를 이용한다.
Power Control System Architecture - SCP hadware overview
- SCP Process Core Memory
" SCP 내부에는 별도의 ROM & RAM 을 가지고 있다. 여기서는 ROM 은 booting 용으로 사용되며, RAM 은 SCP firmware image 가 로딩된다고 보면된다. 당연히, ROM & RAM 은 on-SCP 이기 때문에, SCP 에게만 private 하다. 그러나, booting 시에 SCP firmware 를 SCP private RAM 에 loading 하려면, host processor(Corex-A) 가 SCP private RAM 에 access 할 수 있어야 한다. 이런 환경을 만들어주는 역할을 SCP private ROM 이 한다. ROM code 에 host processor 가 SCP private RAM 에 access 할 수 있도록 만들어서 SCP firmware 를 SCP private RAM 에 loading 할 수 있도록 해준다.
" SCP firmware 는 private RAM 에서만 동작한다. 즉, SoC 의 일부가 powered-off 되고, system memory 가 unavailable 하더라도, SCP 는 동작할 수 있어야 한다.
- System Counters and Generic Timers
" system counter 는 system 에게 시간에 대한 정보를 제공하는 역할을 한다. `Generic Timers` 같은 경우는 이 counter value 를 사용해서 interrupt 및 wake-event 를 발생시킨다. primary system counter 같은 경우는 시스템에 존재하는 다양한 components 들에게 제공된다. 이 counter value 를 통해서 모든 compoentns(subsystems) 들은 모두 같은(일관된) 시간 정보를 가지게 된다. 즉, primary system counter 을 통해서 시간을 동기화 시킨다고 보면된다. 이 때, components 로는 application processor 부터 debug infrastructure 등이 있다.
" SCP 에는 2 개의 counters 가 존재한다.
1. primary system counter - primary system counter value 는 application processors 및 debug infrastructure 등에 일관된 시간 정보를 제공한다. primary system counter resolution 은 소비 전력 때문에, SoC SLEEP 상태에서 powered-off 될 수 있는 clock sosurce 를 사용한다.
2. secondary system counter - real-time clock source (RTC) 를 사용하는 low speed counter 를 제공한다. 이 counter 의 목적은 primary system counter 를 대신해서 SoC SLEEP 에서 시간을 계속 유지하기 위해 사용된다. `Generic Timers` 같은 경우 secondary system counter 를 사용해서 SoC SLEEP 에서도 wake-up events 를 발생시킬 수 있다.
Power Control System Architecture - SCP hadware overview
" 위 내용에서 볼 수 있다시피, SCP 는 SoC SLEEP 이 시작되는 시점과 종료 시점에 일관된 시간 정보를 유지할 책임이 있다.
- Messaging Interface
" OSPM 과 SCP 가 communication 하기 위해서 SCMI software interface 를 따라야 한다고 했다. 그런데, SCMI 는 결국 데이터 포맷을 어떻게 할 것인지에 대한 규정이다. 데이터를 어떤 방식으로 주고 받을지 결국 하드웨어의 지원이 필요하다. 예를 들어, UART 로 받을 것인지, interrupt 를 통해 받을 것인지, shared memory 로 통신할 것인지 등등. 결국, OPSM 과 SCP 의 data communication 을 하기 위해서는 2가지 조건이 충족되어야 한다.
1. mailbox memory 에 message 를 저장한다. 2. doorbell register 를 사용해서 SCP interrupt 를 생성한다.
2. SCP 가 interrupt 를 수신한다.
1. mailbox memory 에서 message 를 읽는다. 2. doorbell interrupt 를 clear 한다.
3. SCP 는 message 에 작성된 내용을 기반으로 동작을 수행한다. 그리고, SCP 는 response 로 OSPM 의 callback response 를 호출한다.
" `device power management` 측면에서 보면, 위에서 언급된 communication 은 `OS-managed devices` 만을 다루고 있다. 그렇다면, `self-managed devices or subsystems` 들이 포함된 시스템들은 어떻게 communication 할까? 단순하다. SCP 에 self-managed devices or subsystems 들과 communication 할 수 있는 추가적인 messaging capability 를 구현하고 있어야 한다.
- Peripheral Access
" 아래 block diagram 에서 볼 수 있다시피, SCP 에는 peripherals 이 2 개의 파트로 나눠볼 수 있다.
1. Shared Peripherals 2. Private Peripherals
" 아래 block diagram 에서 볼 수 있다시피, 대부분의 SCP peripherals 들은 `private peripherals` 에 속한다. 그러나, 2 개의 peripherals 은 예외다. 이러한 peripherals 들을 `shared peripherals` 이라고 부르며, shared peripehrals 들은 SCP address space 와 AP address space 에 모두 mapping 된다.
1. Primary system counter - `Generic Timer specification` 에 의하면, AP software 는 반드시 system counter 에 access 할 수 있어야 한다.
2. Messaging Interface - 위에 `Messaging interface` 를 간단하게 구현하기 위해서는 shared access 가 필요하다.
Power Control System Architecture - SCP hadware overview
- Power Control Framework
" 이제부터는 PCSA 의 hardware architecture 에 대해 알아볼 것이다. PCF(Power Control Framework) 는 PPU 라는 hardware component 를 통해서 power domain 을 control 할 수 있다. PPU 는 power domain control 기능만을 위해서 제작된 hardware 다. 여기서 power domain control 은 SCP 에 의해서 프로그래밍된 `power policies` 들을 의미한다. 아래에서 보겠지만, power policy 란 power mode 를 의미한다. 즉, PPU 는 SCP 에게 특정 power policy(mode) 를 진입하라는 명령을 받게되면(PPU 와 SCP 의 communcation 은 software interfce 를 통해서 이루어진다), PPU 는 자신이 맡고 있는 power domain 의 mode 를 변경한다.
" 아래 그림은 PCF 의 전반적인 구조를 나타낸다. 우리는 여기서 power domain 관련 내용만 살펴본다. 참고로, 아래 그림에서 왼쪽 `Power Domain` 과 오른쪽 2개의 Power Domain 은 차이가 없다. 단지, Power Domain 안에 어떤 components 들이 있는지를 보여주기 위해 왼쪽 그림에서는 내부 구조까지 보여준 것이다.
Power Control System Architecture
" 아래 그림은 SCP 가 `SW IF` 를 통해서 PPU 를 컨트롤하는 것을 보여준다. PPU 는 PCSM(Power Control State Mahine) 에 하드웨어적으로 연결되어 있는 LPI 중에서 P-channel 을 통해서 PCSM 에게 SCP 의 명령을 전달한다. PSCM 은 P-channel 을 통해서 전달 내용을 power mode 로 컨버팅한뒤 해당 내용을 power-gated domain 에 적용한다. 그런데, P-channel 을 통한 power mode 의 컨버팅이라는 것이 무슨말일까?
Power Control System Architecture
" PPU 는 2 가지 modes 를 지원한다.
1. power mode 2. operating mode
" PPU 는 반드시 power mode 를 지원해야 한다. 그러나, operation mode 는 optional 이다. 이 글은 PCSA Overview 를 다루는 글 이기 때문에 power mode 대허서만 알아본다. 위 그림에서 볼 수 있다시피, PPU 는 power management 관련 굉장히 많은 일들을 수행한다. 그런데, PPU 의 power mode 란 무슨 뜻일까?
그러다 보니, clock, reset, isolation 등과 같은 기능은 자신이 맡고, 나머지 power switch, retention 등은 PSCM 에게 위임한다. 즉, SCP 로부터 clock control 을 요청받으면, PPU 에게 끝나고(SCP->PPU->Component), power switch control 을 요청받으면, PPU 는 PSCM 에게 위임하게 된다(SCP->PPU->PSCM->Component).
" 아래 테이블은 PPU 에서 지원하는 power modes 를 나타낸다. PPU 는 반드시 on(ON), warm reset(WARM_RST), off(OFF) modes 들은 지원해야 한다. 나머지 power modes 들은 optional 이다.
Power Policy Unit Architecture Specification Version 1.1
" 아래의 표는 PPU 의 power modes 에 따른 Logic 과 RAM 의 power mode 를 보여준다. 그리고, 각 PPU 의 power modes 에 세분화된 operating mode 를 제시하고 있다. 예를 들어, PPU 의 power mode 가 MEM_RET 이여도, operating mode 에 따라 RAM 의 retention 정도가 다름을 보여준다.
Power Policy Unit Architecture Specification Version 1.1
" 현대의 SoC 안에는 다양한 subsystems 들이 존재한다. 그리고, 각 subsystem 들을 컨트롤하는 `Local Control Processor(LCP)` 가 존재한다. 예를 들어, Qualcomm MSM 시리즈는 AP 와 MODEM 을 하나의 SoC 에 통합시킨 칩을 의미한다. 이 때, AP 와 MODEM 은 별도의 processor 로 동작하며, 각각을 APSS(Application Processor Sub-System), MPSS(Modem Processor Sub-System) 라고 부른다. 그리고, PCSA 구조를 따르는 Qualcomm 칩에서는 AOSS(Always-On Sub-System) 까지 추가되었다.
Power Control System Architecture
" subsystems 들로 이루어진 SoC 에서 power domain 구조 또한 `relatively always-on domain(상대적으로 항상 먼저 power-on 되어 있어야 하는 power domain)` 에 의존한다. 즉, 자신이 속한 power domain 보다 항상 먼저 power-on 되어야 하는 power domain 에 따라 power-on / power-off 가 결정된다는 것이다. 위 그림에서 Always On Domain 이 powered-off 되기 위해서는 `System Interconnect` 가 포함된 power domain 이 먼저 powered-off 가 되어야 한다. 그렇다면, LPC 가 powered-off 되기 위해서는 LPC 가 속한 power domain 에 `relatively always-on domain` 의 PPU 에 의존하게 된다. 아래 그림에서 빨간색 박스로 친 부분이 LPC power domain 의 relatively always-on domain 이 된다.
" 이 PPU 는 SCP 에 의해 control 되며, 또한 SCP 가 빨간색 박스 PPU 를 control 함으로써, LCP 와 동일 선상에 있는 모든 power domains 들을 control 할 수 있다는 뜻이된다(빨간 점선 표시가 이 내용을 의미한다). 그렇다면, LCP 는 자신이 속한 power domain 안에 PPU 를 컨트롤해서 아래의 빨간색 박스의 power domains 들을 컨트롤할 수 도 있다. 그러나, 네온색으로 표시된(자신이 속한 power domain) 은 LPC 가 control 할 수 가 없다.
