ACPI (Advanced Configuration and Power Interface)

ACPI 심화: 아키텍처 4계층, 네임스페이스, FADT/MADT/DMAR/HMAT/BERT 테이블, G/S/D-state 전원 관리, 열 관리, GPE/SCI, Embedded Controller, Operation Region, 핫플러그, 커널 ACPI 서브시스템, 디버깅

ACPI 아키텍처 4계층, 네임스페이스, 주요 테이블 심화, 전원 상태 계층(G/S/D), 열 관리, GPE/SCI, Embedded Controller, Operation Region, 핫플러그, 커널 ACPI 서브시스템까지 — 리눅스 커널의 ACPI 구현을 소스 코드 수준에서 분석합니다.

ACPI 아키텍처 개요

ACPI(Advanced Configuration and Power Interface)는 OS가 하드웨어 구성 탐색, 전원 관리, 열 관리를 수행하기 위한 플랫폼 독립적 인터페이스 규격입니다. 1996년 Intel/Microsoft/Toshiba가 공동 개발했으며, 2013년부터 UEFI Forum이 관리합니다.

스펙 버전 역사

4대 구성요소

ACPI 규격은 네 가지 핵심 구성요소로 이루어집니다:

1. ACPI Tables — RSDP → XSDT → {FADT, MADT, DMAR, HMAT, ...} 계층 구조의 정적 데이터 테이블. 펌웨어가 메모리에 배치합니다.
2. ACPI Namespace — 디바이스, 메서드, 오브젝트를 트리 구조로 조직하는 계층적 이름 공간. AML 코드가 정의합니다.
3. AML Interpreter — DSDT/SSDT의 AML 바이트코드를 실행하는 커널 내 인터프리터. 리눅스는 ACPICA(ACPI Component Architecture) 코드를 사용합니다.
4. ACPI Event Model — SCI(System Control Interrupt)와 GPE(General Purpose Event)를 통한 비동기 하드웨어 이벤트 처리.

RSDP에서 네임스페이스까지

부팅 초기에 커널은 먼저 ACPI의 "입구"를 찾아야 합니다. UEFI 환경에서는 EFI Configuration Table을 통해 RSDP를 얻고, 전통적인 x86 환경에서는 EBDA 또는 BIOS 고메모리 영역을 스캔해 RSDP 시그니처를 찾습니다. 이후 RSDP가 가리키는 XSDT/RSDT를 검증한 뒤, FADT와 DSDT/SSDT를 로드해 네임스페이스와 실행 메서드를 준비합니다.

ACPI 네임스페이스

ACPI 네임스페이스는 역 트리(inverted tree) 구조로, 루트 스코프(\) 아래에 모든 ACPI 오브젝트가 계층적으로 배치됩니다. DSDT/SSDT의 ASL 코드가 네임스페이스를 정의하며, 커널의 ACPICA 인터프리터가 이를 파싱하여 내부 트리로 구축합니다.

루트 스코프 트리

디바이스 열거 흐름

커널 부팅 시 ACPI 서브시스템은 네임스페이스를 순회하며 모든 디바이스를 열거합니다:

/* drivers/acpi/scan.c — ACPI 디바이스 열거 핵심 흐름 */

/* 1단계: 네임스페이스 순회 — 각 노드마다 콜백 호출 */
int acpi_bus_scan(acpi_handle handle)
{
    /* 루트부터 DFS(깊이 우선)로 네임스페이스 순회 */
    acpi_walk_namespace(ACPI_TYPE_ANY, handle,
                        ACPI_UINT32_MAX,
                        acpi_bus_check_add,  /* descending */
                        acpi_bus_attach,     /* ascending  */
                        NULL, (void **)&device);
    return 0;
}

/* 2단계: acpi_device 생성 */
static acpi_status acpi_bus_check_add(acpi_handle handle, ...)
{
    /* _STA 메서드 평가 — 디바이스 존재/활성 확인 */
    acpi_bus_get_status(device);

    /* _HID/_CID 평가 — 하드웨어 ID 추출 */
    acpi_device_add(device, ...);
}

/* 3단계: 드라이버 매칭 — acpi_device_id 테이블 비교 */
static void acpi_bus_attach(struct acpi_device *device)
{
    /* ACPI 드라이버 또는 platform_device로 바인딩 */
    device_attach(&device->dev);
}

핵심 오브젝트: 식별, 자원, 속성

네임스페이스의 모든 노드가 동일하게 취급되지는 않습니다. Linux는 _HID, _CID, _ADR, _STA, _CRS 같은 표준 오브젝트를 우선 읽어 열거 여부와 자원 배치를 결정합니다. 반대로 PCI나 USB처럼 본래 자체 열거 메커니즘이 있는 버스는 ACPI가 "보조 구성 정보"를 제공하는 역할을 맡습니다.

펌웨어와 OS의 협상: _OSI, _REV, _OSC

ACPI는 단순 기술 테이블만이 아니라 펌웨어와 OS가 서로 능력을 타협하는 인터페이스도 정의합니다. 이 협상은 장치 열거보다 더 미묘한 호환성 문제를 일으키므로, 부팅 옵션과 PCIe 네이티브 제어 문제를 볼 때 특히 중요합니다.

Notify 메커니즘

ACPI Notify는 펌웨어가 OS에 비동기 이벤트를 알리는 메커니즘입니다. AML 코드에서 Notify(device, value)를 호출하면 커널의 등록된 핸들러가 실행됩니다.

주요 ACPI 테이블 심화

ACPI는 수십 종의 테이블을 정의합니다. 여기서는 UEFI 페이지에서 다룬 테이블 계층 구조를 전제로, 각 테이블의 내부 구조와 커널 파싱 로직을 심화합니다.

FADT (Fixed ACPI Description Table)

FADT는 ACPI의 "마스터 테이블"로, PM 레지스터 주소, SCI 인터럽트 번호, FACS/DSDT 포인터, 그리고 시스템 전체의 ACPI 동작 플래그를 담습니다.

/* include/acpi/actbl.h — FADT 핵심 필드 (ACPI 6.6 기준) */
struct acpi_table_fadt {
    struct acpi_table_header header;  /* "FACP" 시그니처 */
    u32 facs;                         /* FACS 물리 주소 (32-bit) */
    u32 dsdt;                         /* DSDT 물리 주소 (32-bit) */
    u8  preferred_profile;             /* PM 프로필: Desktop/Mobile/Server */
    u16 sci_interrupt;                 /* SCI IRQ 번호 (보통 9) */
    u32 smi_command;                   /* SMI 커맨드 포트 (ACPI enable) */
    u8  acpi_enable;                   /* SMI로 보낼 ACPI 활성화 값 */
    u8  acpi_disable;                  /* SMI로 보낼 ACPI 비활성화 값 */

    /* PM1a/PM1b 레지스터 블록 */
    u32 pm1a_event_block;              /* PM1a_STS + PM1a_EN */
    u32 pm1b_event_block;              /* PM1b_STS + PM1b_EN (선택) */
    u32 pm1a_control_block;            /* SLP_TYP, SLP_EN 비트 */
    u32 pm1b_control_block;

    /* GPE 레지스터 블록 */
    u32 gpe0_block;                    /* GPE0_STS + GPE0_EN */
    u32 gpe1_block;                    /* GPE1_STS + GPE1_EN (선택) */
    u8  gpe0_block_length;
    u8  gpe1_block_length;

    u32 flags;                         /* 주요 플래그 비트 */
#define ACPI_FADT_HW_REDUCED      (1 << 20)  /* HW-Reduced 모드 (ARM) */
#define ACPI_FADT_LOW_POWER_S0    (1 << 21)  /* S0ix/Modern Standby */

    /* ACPI 2.0+ 64-bit 확장 주소 */
    struct acpi_generic_address xfacs;
    struct acpi_generic_address xdsdt;
    struct acpi_generic_address xpm1a_event_block;
    /* ... */
};

MADT (Multiple APIC Description Table)

MADT는 시스템의 인터럽트 컨트롤러(APIC, GIC) 토폴로지를 기술합니다. 가변 길이 서브타입 엔트리의 배열로 구성됩니다.

/* MADT 서브타입 — include/acpi/actbl1.h */
enum acpi_madt_type {
    ACPI_MADT_TYPE_LOCAL_APIC           = 0,  /* 프로세서 Local APIC */
    ACPI_MADT_TYPE_IO_APIC              = 1,  /* I/O APIC */
    ACPI_MADT_TYPE_INTERRUPT_OVERRIDE   = 2,  /* ISA IRQ 재매핑 */
    ACPI_MADT_TYPE_NMI_SOURCE           = 3,  /* NMI 소스 */
    ACPI_MADT_TYPE_LOCAL_APIC_NMI       = 4,  /* Local APIC NMI (LINT) */
    ACPI_MADT_TYPE_LOCAL_X2APIC         = 9,  /* x2APIC (APIC ID > 255) */
    ACPI_MADT_TYPE_LOCAL_X2APIC_NMI     = 10, /* x2APIC NMI */
    ACPI_MADT_TYPE_GENERIC_INTERRUPT    = 11, /* ARM GIC CPU Interface */
    ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR  = 12, /* ARM GIC Distributor */
    ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR = 14, /* ARM GICv3 Redistributor */
    ACPI_MADT_TYPE_GENERIC_ITS          = 15, /* ARM GIC ITS */
    ACPI_MADT_TYPE_MULTIPROC_WAKEUP    = 16, /* Multiprocessor Wakeup (v6.4) */
};

/* Local APIC 서브타입 구조체 */
struct acpi_madt_local_apic {
    struct acpi_subtable_header header;  /* type=0, length=8 */
    u8  processor_id;                    /* ACPI Processor UID */
    u8  id;                               /* Local APIC ID */
    u32 lapic_flags;                     /* bit 0: Enabled */
};

DMAR / IVRS (IOMMU 테이블)

DMA Remapping(Intel VT-d)과 I/O Virtualization(AMD-Vi)의 하드웨어 유닛 정보를 기술합니다.

/* Intel DMAR — include/acpi/actbl2.h */
struct acpi_dmar_hardware_unit {       /* DRHD — DMA Remapping HW Unit */
    struct acpi_dmar_header header;
    u8  flags;
#define ACPI_DMAR_INCLUDE_ALL    (1)    /* 모든 디바이스에 적용 */
    u8  reserved;
    u16 segment;                        /* PCI 세그먼트 번호 */
    u64 address;                        /* 레지스터 베이스 주소 */
    /* 이후 가변 길이 Device Scope 엔트리 */
};

/* RMRR — Reserved Memory Region Reporting */
struct acpi_dmar_reserved_memory {
    struct acpi_dmar_header header;
    u16 reserved;
    u16 segment;
    u64 base_address;                   /* 예약 영역 시작 */
    u64 end_address;                    /* 예약 영역 끝 */
};

/* 커널 DMAR 초기화 — drivers/iommu/intel/dmar.c */
int __init dmar_table_init(void)
{
    dmar_walk_dmar_table((struct acpi_table_dmar *)dmar_tbl,
                         DMAR_MAX_TYPE, dmar_cb);
    /* DRHD → iommu 할당, RMRR → identity mapping 설정 */
}

HMAT (Heterogeneous Memory Attribute Table)

HMAT는 이기종 메모리 토폴로지(HBM, CXL 메모리, PMEM 등)의 대역폭/지연 속성을 기술합니다. NUMA 페이지에서 다룬 SRAT/SLIT이 노드 간 거리를 표현하는 반면, HMAT는 이니시에이터(CPU)↔타겟(메모리) 쌍의 정량적 성능 수치를 제공합니다.

/* HMAT 메모리 근접성 도메인 속성 — include/acpi/actbl2.h */
struct acpi_hmat_locality {
    struct acpi_hmat_structure header;
    u8  flags;
    u8  data_type;                       /* 0=Access Latency, 1=Read Latency */
                                          /* 2=Write Latency, 3=Access BW    */
                                          /* 4=Read BW, 5=Write BW           */
    u8  min_transfer_size;
    u8  reserved;
    u32 number_of_initiator_pds;         /* 이니시에이터 도메인 수 */
    u32 number_of_target_pds;             /* 타겟 도메인 수 */
    u64 entry_base_unit;                  /* 나노초 또는 MB/s 기본 단위 */
    /* 이후 initiator PD 배열 + target PD 배열 + entry 행렬 */
};

/* 커널 HMAT 파싱 — drivers/acpi/numa/hmat.c */
static int __init hmat_parse_locality(union acpi_subtable_headers *header, ...)
{
    /* 지연/대역폭 행렬을 memory target에 연결 */
    hmat_update_target_access(target, locality, entry);
    /* → /sys/devices/system/node/nodeN/access0/initiators/ */
}

BERT / HEST / ERST / EINJ (하드웨어 에러 처리)

APEI(ACPI Platform Error Interface) 프레임워크는 4개의 테이블로 구성되며, 머신체크(MCE)를 넘어선 플랫폼 수준 에러 처리를 지원합니다.

APEI / GHES 로그를 읽는 순서

GHES는 "에러가 났다"는 사실만 던지는 것이 아니라, 펌웨어가 기록한 CPER(Common Platform Error Record)를 커널이 해석해 printk로 풀어주는 구조입니다. 따라서 실제 분석은 "HEST가 어떤 source를 정의했는가"와 "runtime에 어떤 CPER section이 올라왔는가"를 함께 봐야 합니다.

# 전형적인 GHES 로그 흐름 예시
{Hardware Error}: Hardware error from APEI Generic Hardware Error Source: 0
{Hardware Error}: It has been corrected by h/w and requires no further action
{Hardware Error}: event severity: corrected
{Hardware Error}: section_type: PCIe error
{Hardware Error}: port_type: PCIe end point
{Hardware Error}: device_id: 0000:5e:00.0

놓치기 쉬운 보조 테이블

실제 플랫폼 디버깅에서는 FADT나 MADT만으로 끝나지 않습니다. 아래 테이블들은 "왜 이 플랫폼만 이렇게 동작하는가"를 설명하는 단서가 되는 경우가 많습니다.

ACPI 전원 관리 심화

ACPI는 시스템 전체(Global/Sleep)부터 개별 디바이스(Device)까지 계층적 전원 상태를 정의합니다.

G-states (Global States)

G-states는 시스템 전체의 전원 상태를 나타냅니다:

• G0 (Working) — 시스템 정상 동작. CPU가 S0에서 명령 실행 중.
• G1 (Sleeping) — 시스템 절전. S1~S4 중 하나의 Sleep state.
• G2 (Soft Off) — S5, OS가 종료되었으나 PSU 대기 전원 공급. 전원 버튼으로 재시작 가능.
• G3 (Mechanical Off) — 전원 완전 차단. PSU 스위치 또는 전원 코드 분리 상태.

S-states (Sleep States)

Linux 절전 인터페이스와 ACPI 매핑

리눅스 사용자는 보통 /sys/power/state와 /sys/power/mem_sleep를 통해 절전을 보지만, 이 인터페이스는 ACPI S-state와 완전히 1:1 대응하지는 않습니다. 특히 s2idle은 소프트웨어적으로 모든 장치를 저전력으로 내리는 일반 메커니즘이며, 플랫폼이 충분히 협조할 때만 실제 S0ix residency가 깊게 쌓입니다.

S0ix / Modern Standby

S0ix는 ACPI의 Low Power S0 Idle capability를 실무에서 부르는 표현입니다. 인텔의 Modern Standby 용어와 자주 함께 쓰이지만, 본질은 "시스템이 S0에 머문 채 플랫폼 전체가 깊은 저전력 residency로 진입하는 것"입니다. FADT의 LOW_POWER_S0 플래그(bit 21)는 이 가능성을 알리며, 실제 residency 품질은 LPIT와 SoC 전원 컨트롤러 구현에 좌우됩니다.

/* drivers/acpi/sleep.c — S0ix 지원 확인 */
static bool acpi_s2idle_supported(void)
{
    /* FADT LOW_POWER_S0 플래그 확인 */
    if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) {
        /* LPIT (Low Power Idle Table) 파싱 */
        lpit_read_residency_count_address();
        return true;
    }
    return false;
}

/* /sys/power/mem_sleep 에서 s2idle 선택:
 * echo s2idle > /sys/power/mem_sleep
 * echo mem > /sys/power/state
 *
 * Intel PMC 기반 시스템이라면 S0ix residency 확인:
 * cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec */

여기서 중요한 점은 s2idle이 "진입 방법"이고 S0ix는 "플랫폼이 실제 달성한 전력 상태"라는 것입니다. 장치 드라이버 한 개가 runtime suspend에 실패해도 사용자는 절전에 들어간 것처럼 보이지만, 실제 전력은 S0ix에 못 미치는 경우가 흔합니다.

D-states (Device Power States)

각 디바이스는 독립적으로 D0~D3cold 전원 상태를 가집니다:

• D0 (Fully On) — 디바이스 완전 동작 상태
• D1, D2 — 중간 절전 (디바이스 클래스별 정의)
• D3hot — 소프트웨어적 전원 차단, PCI 설정 공간 접근 가능, Vaux 유지
• D3cold — 물리적 전원 차단, 버스 전원 제거, 재초기화 필요

/* drivers/acpi/device_pm.c — 디바이스 전원 상태 전환 */
int acpi_device_set_power(struct acpi_device *device, int state)
{
    /* 현재 상태 확인 */
    int cur_state;
    acpi_device_get_power(device, &cur_state);

    if (state == ACPI_STATE_D3_COLD) {
        /* D3cold: _PS3 실행 후 전원 리소스 해제 */
        acpi_evaluate_object(device->handle, "_PS3", NULL, NULL);
        acpi_power_off_list(&device->power.states[state].resources);
    } else if (state == ACPI_STATE_D0) {
        /* D0 복원: 전원 리소스 켜기 → _PS0 실행 */
        acpi_power_on_list(&device->power.states[state].resources);
        acpi_evaluate_object(device->handle, "_PS0", NULL, NULL);
    }
    return 0;
}

Power Resource Objects와 _PR0/_PR3

D-state 설명만 보면 장치 전원이 개별 메서드 _PS0/_PS3로만 전환되는 것처럼 보이지만, 실제 플랫폼은 하나의 전원 레일이나 클럭 공급원을 여러 장치가 공유하는 경우가 많습니다. 이때 ACPI는 Power Resource 오브젝트를 별도로 만들고, 각 장치가 D-state별로 어떤 리소스를 필요로 하는지 _PR0~_PR3로 연결합니다.

C/P-states와 ACPI 관계

C-states(CPU Idle)와 P-states(CPU Performance)는 ACPI가 정의한 프로세서 전원 상태입니다. 자세한 P-state/CPPC 구현은 ktime/Clock 페이지를 참조하세요.

/* ACPI _CST (C-State) 메서드 — 커널 cpuidle 연동 */

/* ASL에서 _CST 반환 형식:
 * Package {
 *   NumEntries,
 *   Package { Register, Type, Latency, Power },  // C1
 *   Package { Register, Type, Latency, Power },  // C2
 *   Package { Register, Type, Latency, Power },  // C3
 * }
 */

/* drivers/acpi/processor_idle.c */
static int acpi_processor_get_cstate_info(struct acpi_processor *pr)
{
    /* _CST 평가하여 C-state 정보 추출 */
    status = acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer);

    /* cpuidle 프레임워크에 C-state 등록 */
    for (i = 1; i <= pr->power.count; i++) {
        cx = &pr->power.states[i];
        /* C1: MWAIT, C2: IO port, C3: MWAIT + BM check */
    }
}

CPPC와 PPTT: 추상 성능 스케일과 토폴로지

전통적인 ACPI P-state는 소수의 성능 점을 정의하는 방식이라 현대 CPU의 세밀한 제어에는 한계가 있습니다. CPPC(Collaborative Processor Performance Control)는 주파수 대신 "연속적이고 단위 없는 추상 성능 스케일"을 제공해, OS가 목표 성능만 제시하고 하드웨어가 세부 동작을 조정할 수 있게 합니다. Linux는 이를 cppc_acpi, amd-pstate, 일부 플랫폼의 pcc-cpufreq 경로로 소비합니다.

# CPU0의 CPPC 노출 확인
$ ls /sys/devices/system/cpu/cpu0/acpi_cppc/
feedback_ctrs  highest_perf  lowest_freq  lowest_nonlinear_perf
lowest_perf    nominal_freq  nominal_perf reference_perf

# 대표 값 확인
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_perf
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/feedback_ctrs

ACPI 열 관리

ACPI Thermal Zone은 펌웨어와 OS 간 열 관리 인터페이스를 정의합니다. ASL 코드로 온도 임계값과 쿨링 정책을 선언하면, 커널의 thermal 프레임워크가 이를 실행합니다.

Thermal Zone ASL 메서드

/* Thermal Zone 정의 예시 (ASL) */
ThermalZone (TZ00, 0) {
    /* 현재 온도 반환 (단위: 0.1K, 3000 = 27°C) */
    Method (_TMP, 0, Serialized) {
        Return (\_SB.EC0.RTMP())
    }

    /* Passive cooling 임계 온도 */
    Method (_PSV, 0) { Return (3630) }  /* 90°C */

    /* Passive cooling 대상 프로세서 리스트 */
    Method (_PSL, 0) {
        Return (Package () { \_PR.CPU0, \_PR.CPU1 })
    }

    /* Passive cooling 계수: 온도 추적 반응 속도 */
    Name (_TC1, 1)   /* 현재 온도에 대한 가중치 */
    Name (_TC2, 5)   /* 이전 온도에 대한 가중치 */
    Name (_TSP, 100) /* 폴링 주기 (0.1초 단위, 10초) */

    /* Critical 온도 — 이 온도 초과 시 즉시 셧다운 */
    Method (_CRT, 0) { Return (3830) }  /* 110°C */

    /* Hot 온도 — S4(hibernate) 전환 트리거 */
    Method (_HOT, 0) { Return (3780) }  /* 105°C */
}

커널 thermal 프레임워크 연동

/* drivers/acpi/thermal.c — ACPI thermal zone 등록 */
static int acpi_thermal_add(struct acpi_device *device)
{
    struct acpi_thermal *tz;

    /* ACPI thermal zone 정보 수집 */
    acpi_thermal_get_temperature(tz);       /* _TMP */
    acpi_thermal_get_trip_points(tz);       /* _CRT, _HOT, _PSV, _ACx */

    /* 커널 thermal 프레임워크에 등록 */
    tz->thermal_zone = thermal_zone_device_register(
        "acpitz",               /* 이름 */
        trips,                   /* trip point 수 */
        tz,                      /* 드라이버 데이터 */
        &acpi_thermal_zone_ops,  /* get_temp, get_trip_type ... */
        NULL, passive_delay, polling_delay
    );
}

sysfs 인터페이스

# Thermal zone 정보 확인
$ ls /sys/class/thermal/thermal_zone0/
temp  type  trip_point_0_temp  trip_point_0_type  policy  mode

# 현재 온도 (밀리도, 45000 = 45°C)
$ cat /sys/class/thermal/thermal_zone0/temp
45000

# trip point 확인
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_type
critical
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_temp
110000

# 쿨링 디바이스 상태
$ cat /sys/class/thermal/cooling_device0/type
Processor
$ cat /sys/class/thermal/cooling_device0/cur_state
0
$ cat /sys/class/thermal/cooling_device0/max_state
10

GPE & SCI

ACPI 이벤트 모델의 핵심은 SCI(System Control Interrupt)와 GPE(General Purpose Event)입니다. 모든 ACPI 런타임 이벤트는 SCI를 통해 커널에 전달됩니다.

SCI (System Control Interrupt)

SCI는 ACPI 이벤트를 전달하는 공유 레벨 트리거 인터럽트입니다. FADT의 sci_interrupt 필드(보통 IRQ 9)로 지정됩니다. 하나의 SCI로 전원 버튼, 뚜껑 닫힘, GPE, EC 이벤트 등 모든 ACPI 이벤트가 멀티플렉싱됩니다.

GPE 블록 레지스터

GPE 블록은 Status/Enable 레지스터 쌍으로 구성됩니다. FADT에 GPE0/GPE1 블록 주소가 정의되며, 각 비트가 하나의 GPE 이벤트에 대응합니다.

커널 GPE 처리

/* drivers/acpi/acpica/evgpe.c — GPE 처리 흐름 */

/* GPE 핸들러 등록 */
acpi_status acpi_install_gpe_handler(
    acpi_handle gpe_device,
    u32 gpe_number,
    u32 type,                          /* ACPI_GPE_LEVEL/EDGE_TRIGGERED */
    acpi_gpe_handler address,          /* 콜백 함수 */
    void *context)
{
    /* GPE 번호에 해당하는 레지스터 비트 계산 */
    gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);

    /* 핸들러를 GPE 이벤트에 연결 */
    gpe_event_info->dispatch.handler = handler;
    acpi_ev_enable_gpe(gpe_event_info);
}

/* SCI → GPE dispatch 경로:
 * acpi_ev_sci_xrupt_handler()
 *  → acpi_ev_gpe_detect()        (어떤 GPE 비트가 set되었는지 확인)
 *   → acpi_ev_gpe_dispatch()     (해당 GPE의 핸들러 또는 _Lxx/_Exx 실행)
 */

# GPE 인터럽트 통계 확인
$ cat /sys/firmware/acpi/interrupts/gpe_all
    1247

# 개별 GPE 확인 (GPE 0x6E = 리드 닫힘/열림 이벤트 등)
$ cat /sys/firmware/acpi/interrupts/gpe6E
      23   enabled   unmasked

# SCI 총 인터럽트 수
$ cat /sys/firmware/acpi/interrupts/sci
    1523

# 문제 있는 GPE 비활성화 (GPE storm 대응)
$ echo disable > /sys/firmware/acpi/interrupts/gpe6E

Embedded Controller (EC)

EC(Embedded Controller)는 노트북/랩톱에서 배터리, 팬, 키보드, 온도 센서 등을 제어하는 마이크로컨트롤러입니다. x86 I/O 포트(0x62/0x66)를 통해 호스트 CPU와 통신합니다.

EC 프로토콜

/* EC I/O 포트 및 상태 비트 */
#define ACPI_EC_DATA_PORT     0x62   /* 데이터 레지스터 */
#define ACPI_EC_COMMAND_PORT  0x66   /* 커맨드/상태 레지스터 */

/* 상태 레지스터 비트 */
#define ACPI_EC_FLAG_OBF      0x01   /* Output Buffer Full */
#define ACPI_EC_FLAG_IBF      0x02   /* Input Buffer Full */
#define ACPI_EC_FLAG_SCI_EVT  0x20   /* SCI Event Pending */

/* EC 커맨드 */
#define ACPI_EC_COMMAND_READ  0x80   /* 바이트 읽기 */
#define ACPI_EC_COMMAND_WRITE 0x81   /* 바이트 쓰기 */
#define ACPI_EC_COMMAND_QUERY 0x84   /* SCI 이벤트 쿼리 */
#define ACPI_EC_BURST_ENABLE  0x82   /* 버스트 모드 활성화 */

/* drivers/acpi/ec.c — EC 트랜잭션 */
static int acpi_ec_transaction(struct acpi_ec *ec,
                               struct transaction *t)
{
    /* 1. IBF가 클리어될 때까지 대기 */
    ec_poll_guard(ec);

    /* 2. 커맨드 전송 (0x66 포트) */
    outb(t->command, ec->command_addr);

    /* 3. 주소 전송 (0x62 포트) */
    outb(t->wdata[0], ec->data_addr);

    /* 4. OBF 대기 후 데이터 읽기 */
    t->rdata[0] = inb(ec->data_addr);
}

EC 이벤트와 쿼리 메서드

EC가 SCI_EVT 비트를 설정하면 커널이 Query 커맨드(0x84)를 보내 이벤트 번호를 얻고, 해당 _Qxx AML 메서드를 실행합니다.

/* drivers/acpi/ec.c — EC 이벤트 처리 */
static void acpi_ec_event_handler(struct work_struct *work)
{
    /* Query 커맨드로 이벤트 번호 획득 */
    acpi_ec_query(ec, &value);  /* value = 0x00~0xFF */

    /* 해당 _Qxx 메서드 실행 (예: _Q0D = 밝기 변경) */
    snprintf(name, sizeof(name), "_Q%02X", value);
    acpi_evaluate_object(ec->handle, name, NULL, NULL);
}

EC 디버깅

# EC 상태 확인
$ cat /sys/kernel/debug/ec/ec0/io

# EC 이벤트 로그
$ dmesg | grep -i "ec:"
[    0.512] ACPI: EC: EC started
[    0.512] ACPI: EC: interrupt mode

# EC 디버깅 활성화
$ echo 0x10 > /sys/module/acpi/parameters/debug_level

배터리, AC 어댑터, 뚜껑, 전원 버튼

노트북 계열 플랫폼에서 ACPI는 단순 부팅 테이블이 아니라 사용자 체감 기능의 핵심 제어 경로입니다. 배터리 잔량, AC 연결 여부, 뚜껑 개폐, 전원 버튼 입력은 대부분 ACPI 디바이스와 AML 메서드를 거쳐 커널 power_supply 또는 input 서브시스템으로 올라옵니다. 이 경로는 EC와 GPE에 강하게 의존하므로, 배터리 문제와 lid wake 문제는 거의 항상 함께 봐야 합니다.

/* 노트북 장치 예시 — DSDT/SSDT 디컴파일에서 자주 보는 형태 */
Device (AC) {
    Name (_HID, "ACPI0003")
    Method (_PSR, 0) { Return (\_SB.PCI0.LPCB.EC0.ACST) }
}

Device (BAT0) {
    Name (_HID, "PNP0C0A")
    Method (_BST, 0) { ... }  /* 상태: charging/discharging */
    Method (_BIX, 0) { ... }  /* 설계 용량, 제조사 정보 */
}

Device (LID0) {
    Name (_HID, "PNP0C0D")
    Method (_LID, 0) { Return (\_SB.PCI0.LPCB.EC0.LIDS) }
}

# 배터리/AC 상태 확인
$ ls /sys/class/power_supply/
AC  BAT0

$ cat /sys/class/power_supply/AC/online
1
$ cat /sys/class/power_supply/BAT0/status
Discharging
$ cat /sys/class/power_supply/BAT0/energy_now

# lid / 버튼 이벤트 확인
$ libinput debug-events | grep -i lid
$ cat /proc/acpi/button/lid/LID0/state

Operation Regions

Operation Region은 AML 코드가 시스템 자원(메모리, I/O 포트, PCI 설정, EC 등)에 접근하기 위한 주소 공간 추상화입니다. ASL에서 OperationRegion을 선언하고 Field로 개별 비트/바이트를 정의합니다.

/* ASL OperationRegion 예시 — EC 기반 배터리 정보 */
OperationRegion (ERAM, EmbeddedControl, 0x00, 0xFF)
Field (ERAM, ByteAcc, NoLock, Preserve) {
    Offset (0x20),
    BTST, 8,       /* 배터리 상태 (충전/방전) */
    BTCR, 16,      /* 배터리 현재 충전률 */
    BTVL, 16,      /* 배터리 전압 (mV) */
    Offset (0x30),
    FANS, 8,       /* 팬 속도 단계 (0~7) */
    CPUT, 8,       /* CPU 온도 */
}

/* SystemMemory 예시 — MMIO 레지스터 */
OperationRegion (GNVS, SystemMemory, 0xBF7E9000, 0x100)
Field (GNVS, AnyAcc, NoLock, Preserve) {
    OSYS, 16,      /* OS 유형 */
    LIDS, 8,       /* 뚜껑 상태 */
    PWRS, 8,       /* AC 전원 상태 */
}

/* 커널 Operation Region 핸들러 등록 — 커스텀 주소 공간 */
/* drivers/acpi/acpica/evregion.c */

acpi_status acpi_install_address_space_handler(
    acpi_handle device,
    acpi_adr_space_type space_id,   /* GPIO, GenericSerialBus 등 */
    acpi_adr_space_handler handler, /* read/write 콜백 */
    acpi_adr_space_setup setup,     /* 초기화 콜백 */
    void *context);

/* 예: GPIO Operation Region 핸들러
 * drivers/gpio/gpiolib-acpi.c
 * AML의 GPIO 필드 접근 → 커널 gpiod_get_value()/gpiod_set_value() 호출
 */

ACPI 핫플러그

ACPI 핫플러그는 시스템 실행 중 디바이스(PCI, CPU, 메모리)의 추가/제거를 지원합니다. 펌웨어가 Notify 이벤트를 발생시키면 커널이 디바이스 열거/해제를 수행합니다.

PCI 핫플러그

/* PCI 핫플러그 — drivers/pci/hotplug/acpiphp_glue.c */

/* 핫플러그 Notify 핸들러 */
static void handle_hotplug_event(acpi_handle handle, u32 type, ...)
{
    switch (type) {
    case ACPI_NOTIFY_BUS_CHECK:         /* 0x00 */
    case ACPI_NOTIFY_DEVICE_CHECK:      /* 0x01 */
        /* _STA 평가: 디바이스 존재 여부 확인 */
        acpiphp_check_bridge(bridge);
        /* 새 디바이스 발견 → pci_scan_slot() → 드라이버 바인딩 */
        break;
    case ACPI_NOTIFY_EJECT_REQUEST:      /* 0x03 */
        /* _EJ0 메서드 실행 → 디바이스 제거 */
        acpiphp_disable_slot(slot);
        acpi_evaluate_ej0(handle);
        break;
    }
}

/* ASL 핫플러그 디바이스 정의 예시 */
/*
 * Device (SLT0) {
 *     Name (_ADR, 0x001F0000)
 *     Method (_STA, 0) { Return (0x0F) }  // Present + Enabled
 *     Method (_EJ0, 1) { ... }            // Eject 실행
 *     Method (_RMV, 0) { Return (1) }     // Removable
 * }
 */

PCIe Native Hotplug, AER, PME와 _OSC

서버와 워크스테이션에서 "핫플러그는 되는데 AER가 안 보인다" 또는 "PCIe 포트 서비스 드라이버가 안 붙는다"는 문제의 상당수는 _OSC 협상에서 이미 결정됩니다. _OSC는 Root Port 또는 Host Bridge가 펌웨어와 OS 사이에 PCIe 서비스 제어권을 나누는 메커니즘이며, Native Hotplug, PME, AER, SHPC 같은 권한을 OS가 얻어야 Linux 쪽 포트 서비스가 완전히 활성화됩니다.

# _OSC / PCIe 서비스 관련 단서 찾기
$ dmesg | grep -Ei "_OSC|AER|pciehp|PME|hotplug"

# Root Port capability와 서비스 드라이버 확인
$ lspci -vv -s 00:1c.0
$ lsmod | grep -E "pciehp|aer|pcieport"

# 강제로 OS 제어를 선호하도록 시도할 때 쓰는 커널 파라미터 예
# pcie_ports=native
# pcie_ports=compat

CPU / 메모리 핫플러그

/* CPU 핫플러그 — drivers/acpi/acpi_processor.c */
static void acpi_processor_hotplug_notify(struct acpi_device *adev, u32 type)
{
    switch (type) {
    case ACPI_NOTIFY_BUS_CHECK:
    case ACPI_NOTIFY_DEVICE_CHECK:
        /* CPU online: cpu_up() → sched_domain 재구성 */
        acpi_bus_scan(adev->handle);
        break;
    case ACPI_NOTIFY_EJECT_REQUEST:
        /* CPU offline: cpu_down() → 프로세스 마이그레이션 */
        acpi_scan_hot_remove(adev);
        break;
    }
}

/* 메모리 핫플러그 — drivers/acpi/acpi_memhotplug.c */
/* Notify 0x00 → acpi_memory_device_add()
 *             → add_memory_resource()
 *             → online_pages()
 *
 * sysfs로 메모리 블록 온라인:
 * echo online > /sys/devices/system/memory/memoryXX/state
 */

커널 ACPI 서브시스템

drivers/acpi/ 디렉토리 구조

acpi_device 구조체

/* include/acpi/acpi_bus.h */
struct acpi_device {
    acpi_handle handle;              /* 네임스페이스 핸들 */
    struct device dev;               /* 리눅스 디바이스 모델 */

    struct acpi_device_status status; /* _STA 결과 */
    struct acpi_device_flags flags;

    struct acpi_hardware_id *pnp;    /* _HID, _CID, _UID */
    struct acpi_device_power power;  /* D-state 정보 */
    struct acpi_device_wakeup wakeup; /* 웨이크업 능력 */

    struct acpi_driver *driver;      /* 바인딩된 드라이버 */
    struct acpi_device *parent;      /* 부모 디바이스 */
    struct list_head children;       /* 자식 리스트 */
};

플랫폼 디바이스 연결 (ACPI_COMPANION)

/* ACPI 디바이스와 platform_device 연결 */
/* drivers/acpi/glue.c */

/* ACPI_COMPANION 매크로로 디바이스에서 acpi_device 접근 */
struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);

/* 드라이버에서 ACPI 매칭 테이블 정의 */
static const struct acpi_device_id my_acpi_ids[] = {
    { "PNP0C09", 0 },   /* Embedded Controller */
    { "ACPI0003", 0 },  /* AC Adapter */
    { "PNP0C0A", 0 },   /* Battery */
    { },
};
MODULE_DEVICE_TABLE(acpi, my_acpi_ids);

/* platform_driver에서 ACPI 매칭 사용 */
static struct platform_driver my_driver = {
    .driver = {
        .name = "my-acpi-device",
        .acpi_match_table = my_acpi_ids,
    },
    .probe = my_probe,
};

ACPI와 Device Tree를 어떻게 구분해 봐야 하는가

둘 다 "하드웨어를 OS에 기술한다"는 점은 같지만, 표현력과 실행 모델은 다릅니다. Device Tree는 정적 데이터 중심이고, ACPI는 데이터 테이블에 더해 AML 메서드와 런타임 조건 분기를 포함합니다. 드라이버 관점에서는 ACPI 지원을 추가할 때 DT 경로를 대체하는 것이 아니라, property / GPIO / interrupt 해석 계층을 공통화하는 방식이 일반적입니다.

디버깅 & 트러블슈팅

acpi.debug_layer / acpi.debug_level

# ACPI 디버그 레이어/레벨 활성화 (커널 CONFIG_ACPI_DEBUG=y 필요)

# 디버그 레이어 — 서브시스템별 필터링
$ echo 0xFFFFFFFF > /sys/module/acpi/parameters/debug_layer
# 주요 레이어:
# 0x00000001 = ACPI_UTILITIES     0x00000010 = ACPI_TABLES
# 0x00000020 = ACPI_EVENTS        0x00000040 = ACPI_CONTROL_METHODS
# 0x00000100 = ACPI_NAMESPACE     0x00000800 = ACPI_BUS_COMPONENT

# 디버그 레벨 — 상세도 조절
$ echo 0x0000001F > /sys/module/acpi/parameters/debug_level
# 0x01 = Error  0x02 = Warn  0x04 = Info  0x08 = Debug  0x10 = Verbose

# 부팅 시 커널 파라미터로 설정
# acpi.debug_layer=0x20 acpi.debug_level=0x1F

/sys/firmware/acpi/ 인터페이스

# ACPI 테이블 원본 덤프
$ ls /sys/firmware/acpi/tables/
APIC  DSDT  FACP  FACS  HMAT  MCFG  SRAT  SSDT*

# DSDT 디컴파일 (iasl 필요)
$ cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
$ iasl -d dsdt.aml    # → dsdt.dsl (ASL 소스)

# ACPI 이벤트 인터럽트 카운터
$ cat /sys/firmware/acpi/interrupts/sci
$ cat /sys/firmware/acpi/interrupts/gpe_all

# PM 프로필
$ cat /sys/firmware/acpi/pm_profile
Desktop

acpidump / acpixtract / iasl 실전 절차

복잡한 플랫폼에서는 DSDT 하나만 디컴파일하면 참조가 끊기기 쉽습니다. SSDT가 여러 장 겹쳐 장치 정의를 덮어쓰는 경우가 흔하므로, 가능하면 전체 테이블을 덤프하고 외부 참조를 포함해 디컴파일하는 편이 정확합니다.

# 1) 전체 ACPI 테이블 덤프 (acpica-tools 필요)
$ acpidump -b

# 2) 바이너리 테이블 분해
$ acpixtract -a acpidump.out

# 3) SSDT들을 외부 참조로 포함하여 DSDT 디컴파일
$ iasl -e ssdt*.dat -d dsdt.dat

# 4) 관심 장치/메서드 찾기
$ grep -n "Device (EC0)" dsdt.dsl
$ grep -n "_PRW" dsdt.dsl
$ grep -n "OperationRegion" dsdt.dsl
$ grep -n "_OSC" dsdt.dsl

DSDT/SSDT를 읽는 실제 패턴

디컴파일된 ASL을 처음 보면 "문법은 읽히는데 어디서부터 봐야 하는지"가 가장 어렵습니다. 실전에서는 전체 파일을 위에서 아래로 읽기보다, 문제가 난 장치의 ACPI 경로를 잡고 그 장치를 둘러싼 식별, 자원, wake, power method를 역으로 추적하는 방식이 효율적입니다.

/* SSDT/DSDT에서 자주 보는 문제 장치 예시 */
Device (XHCI) {
    Name (_ADR, 0x00140000)
    Name (_STA, 0x0F)
    Method (_CRS, 0, Serialized) { ... }
    Method (_PRW, 0, NotSerialized) {
        Return (Package () { 0x6D, 0x03 })
    }
    Name (_PR0, Package () { PR2A })
    Name (_PR3, Package () { PR3A })
    Method (_PS0, 0) { ... }
    Method (_PS3, 0) { ... }
}

ACPI 커널 파라미터 총정리

ACPI 디버깅 플레이북

ACPI 문제는 BIOS/펌웨어 AML 품질의 영향을 크게 받기 때문에, 커널 코드만 보는 방식으로는 해결이 어렵습니다. 테이블 원본, AML 디컴파일 결과, 런타임 이벤트를 함께 비교해야 합니다.

# DSDT 추출 및 디컴파일
cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
iasl -d dsdt.aml

# ACPI 디버그 레벨 상승
echo 0xFFFFFFFF > /sys/module/acpi/parameters/debug_layer
echo 0x1F > /sys/module/acpi/parameters/debug_level

# 이벤트 카운터 점검
cat /sys/firmware/acpi/interrupts/gpe_all
cat /sys/firmware/acpi/interrupts/sci

관련 문서

ACPI와 관련된 다른 주제를 더 깊이 이해하고 싶다면 다음 문서를 참고하세요.

• 부팅 과정 — ACPI 초기화
• UEFI — UEFI와 ACPI
• 전원 관리 (PM) — ACPI 전원 관리
• Device Tree — Device Tree와의 비교