상태 등록 전에 DT 계약을 확인합니다
Linux v6.18의 DT 기반 cpuidle-psci.c는 CPU의 enable-method가 psci인지 확인하고 arm,idle-state를 읽습니다. 깊은 상태의 arm,psci-suspend-param을 검사해 CPU별 배열에 보관합니다. 이 숫자는 CPUIdle 배열의 index 자체와 같은 의미가 아닙니다.
state 0은 WFI입니다. DT 깊은 상태가 없어 이 driver가 등록되지 않아도, 기본 아키텍처 경로의 WFI까지 없어진다는 뜻은 아닙니다. 2015년 cpuidle-arm64.c와 빌려 쓴 ARM32 DTS 예시를 현재 보드의 구성으로 복사하지 않습니다.
WFI와 깊은 상태의 경로가 갈립니다
일반 진입 함수 psci_enter_idle_state()는 CPU_PM_CPU_IDLE_ENTER_PARAM_RCU 매크로를 사용합니다. index 0이면 매크로가 cpu_do_idle() 후 반환하므로 psci_cpu_suspend_enter()를 호출하지 않습니다. 0이 아닌 상태는 CPU PM 진입이 성공해야 저장된 parameter로 저수준 진입 함수를 부릅니다.
공유 전원 도메인의 계층형 경로는 별도입니다. v6.18은 OSI 지원 아래 가장 깊은 상태에 domain callback을 연결하며, PREEMPT_RT의 일반 idle에서는 이 연결을 사용하지 않습니다. 모든 선택을 단일 CPU의 같은 PSCI 호출로 설명하면 안 됩니다.
등록·선택·실행·측정을 구분합니다
governor는 허용 복귀 지연과 예상 유휴 시간을 고려해 상태를 고르고 driver가 진입을 요청합니다. current_driver와 CPU별 state 목록은 등록 상태를, usage/time 등은 커널의 통계를 보여 줍니다. 통계가 실제 하드웨어 체류 시간이나 전력 절감량을 그대로 측정한 값이라고 단정하지 않습니다.
문제를 재현할 때는 보드·DT·커널·펌웨어 버전, 요청한 index와 parameter, 오류 반환과 복귀 결과를 같은 기록에 연결합니다. 실제 절감 효과는 별도의 전력 측정이 필요합니다. CPU hotplug나 시스템 전체 suspend를 이 per-CPU idle 경로와 같은 동작으로 취급하지 않습니다. 여기서는 장치에서 suspend를 실행하지 않았습니다.
- DT와 등록
상태 참조·parameter·driver를 확인
- 선택과 진입
state 0의 WFI와 깊은 상태를 분기
- 복귀와 실측
오류·복귀 로그와 별도 전력 측정을 대조
CPUFreq·Devfreq·OPP의 역할
앞선 CPUIdle은 실행할 일이 없는 CPU의 유휴 상태 진입을 다룹니다. 실행 중인 CPU나 장치의 성능 수준을 바꾸는 일은 다른 경로입니다. 이 비교 절은 Linux v6.18.37의 문서와 API를 기준으로 하며, 앞선 v6.18 PSCI 진입 분석을 다른 버전으로 바꾼 것은 아닙니다.
| 구성 요소 | 주된 책임 | 같은 뜻이 아닌 것 |
|---|---|---|
| CPUFreq | CPU 성능 제어를 공유하는 cpufreq_policy, 목표 선택과 scaling driver 연결 | 논리 CPU마다 반드시 독립된 주파수 제어 |
| Devfreq | GPU·메모리 컨트롤러 같은 장치의 governor와 devfreq_dev_profile 연결 | 모든 장치가 같은 사용률 공식·전압 제어를 사용 |
| OPP | 장치별 성능 상태, 사용 가능 여부, 조회·전환 helper | 테이블만 있으면 목표 선택·전환 성공·절감 효과까지 입증됨 |
| CPUIdle | 일이 없는 CPU가 진입할 유휴 상태와 복귀 지연 조건 | 실행 중인 CPU의 주파수 목표와 동일한 결정 |
| runtime PM | 장치의 runtime suspend/resume 및 관련 상태 관리 | 항상 실제 전원 차단이나 주파수 0을 뜻함 |
cpufreq_policy는 같은 하드웨어 성능 제어 인터페이스를 공유하는 CPU들을 묶습니다. CPU별 포인터가 있어도 같은 policy를 가리킬 수 있습니다. 일반 경로에서 core는 공통 구조를, governor는 필요한 성능 목표를, scaling driver는 하드웨어 접속을 맡습니다. 다만 드라이버가 governor 계층을 우회해 자체 성능 선택을 구현할 수 있으므로, 모든 플랫폼이 반드시 같은 세 단계를 거친다고 단정하지 않습니다. CPUFreq policy와 driver 설명
Devfreq에서 장치의 target() callback은 요청 주파수에 맞는 동작점을 적용하고, 반환하기 전에 주파수 인자를 실제 현재 값으로 갱신해야 합니다. get_dev_status()의 busy/total 시간 같은 정보는 해당 governor와 장치가 지원하는 방식으로 해석해야 합니다. polling 간격을 0으로 두면 polling이 꺼집니다. 따라서 governor 이름이 있거나 profile이 있다고 해서 주기적인 사용률 측정과 전압 조정이 모두 동작하는 것은 아닙니다. Devfreq profile 계약
OPP는 장치가 지원하는 성능 지점과 가용성을 표현하며, 온도 등의 조건에 따라 일부 지점이 비활성화될 수 있습니다. 테이블에 주파수가 적혀 있다고 해서 지금 그 주파수를 쓸 수 있는 것은 아닙니다. 또한 OPP 라이브러리는 수동적인 목록만이 아닙니다. dev_pm_opp_set_rate()와 dev_pm_opp_set_opp() 같은 전환 API도 제공합니다. 그렇다고 테이블을 읽은 것만으로 해당 보드의 clock·regulator·의존 성능 상태가 올바르게 설정됐거나 전환에 성공했다는 뜻은 아닙니다. OPP 가용성 · 조회·전환 API
runtime PM의 suspended도 물리적인 저전력 상태를 반드시 뜻하지 않습니다. 공식 계약은 resume 전까지 장치가 데이터를 처리하거나 CPU·RAM과 통신하지 않는 상태를 구분합니다. 실제로 어느 전원·클럭을 제어하는지는 장치와 subsystem 구현에 달려 있습니다. runtime PM callback 계약 · CPUIdle의 유휴 상태
설정된 한계, 선택한 목표, 실제 주파수 전환, 처리 성능, 소비 전력은 서로 다른 증거입니다. 전압·주파수만으로 모든 보드의 절감률을 약속하지 않습니다. 이 절에서는 governor나 sysfs 값을 변경하지 않았으며 보드의 전력·전환 지연을 측정하지 않았습니다.
English summary
CPUFreq policies group CPUs sharing performance controls; some drivers bypass generic governors. Devfreq connects device-specific target/status callbacks to governors. OPP provides available performance points and transition helpers, not an automatic proof of board support or savings. CPUIdle and runtime PM concern distinct idle/suspend contracts; software suspended status alone does not guarantee physical low power. No board settings were changed or power measurements made.