장치 관리 네임스페이스 개체

  • 아티클

ACPI 5.0 사양은 장치를 관리하는 데 사용할 수 있는 여러 유형의 네임스페이스 개체를 정의합니다. 예를 들어 장치 식별 개체는 자식 장치의 하드웨어 열거를 지원하지 않는 버스(예: I2C)에 연결되는 장치의 ID 정보를 포함합니다. 다른 유형의 네임스페이스 개체는 시스템 리소스를 지정하고 장치 종속성을 설명하며 어떤 장치를 사용하지 않도록 설정할 수 있는지를 나타낼 수 있습니다.

Windows의 장치 식별

Windows 플러그 앤 플레이는 장치 열거자에서 제공하는 장치 식별자를 기반으로 장치 드라이버를 찾아 로드합니다. 열거자는 장치에서 ID 정보를 추출하는 방법을 알고 있는 버스 드라이버입니다. 일부 버스(예: PCI, SD 및 USB)에는 이 추출을 수행하는 하드웨어 정의 메커니즘이 있습니다. 이러한 메커니즘이 없는 버스(예: 프로세서 버스 또는 SPB(Simple Peripheral Bus))의 경우 ACPI가 네임스페이스에 식별 개체를 정의합니다.

Windows ACPI 드라이버인 Acpi.sys는 이러한 개체에서 찾은 값을 드라이버의 요구 사항에 따라 장치를 매우 구체적으로 또는 매우 일반적으로 식별할 수 있는 다양한 장치 식별자 문자열로 어셈블합니다. ACPI 열거 장치를 식별하기 위해 만든 몇 가지 문자열 패턴은 다음과 같습니다.

ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn
ACPI\VEN_vvv[v]&DEV_dddd&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd
ACPI\vvv[v]dddd

장치 관리자를 열고 열거된 장치의 Hardware IDs 및 Compatible IDs 속성을 검사하여 Windows에서 장치에 대해 만든 장치 식별자를 확인할 수 있습니다. 이러한 각 문자열을 INF 파일에 지정하여 장치에 대해 로드할 드라이버를 식별할 수 있습니다. INF 일치 순서는 가장 구체적인 하드웨어 식별자(우선 순위가 가장 높은 드라이버)부터 가장 덜 구체적인 식별자(우선 순위가 가장 낮은 드라이버)의 순서입니다. 장치의 특정 기능에 대해 더 많이 아는 드라이버가 덜 구체적인(따라서 장치 기능의 하위 집합만 지원함) 드라이버를 대체할 수 있도록 하기 위해서입니다.

장치 식별자는 INF에만 일치에 사용되어야 하고 장치 드라이버에 의해 구문 분석되거나 처리되어서는 안 됩니다. 장치 드라이버가 로드된 대상인 특정 하드웨어를 식별해야 할 경우 권장되는 방법은 설치 시 INF 파일이 적절한 레지스트리 키를 설정하도록 하는 것입니다. 그러면 드라이버가 초기화 중에 이러한 키에 액세스하여 필요한 정보를 가져올 수 있습니다.

ACPI의 장치 식별

하드웨어 ID(_HID)

ACPI에서 장치를 식별하기 위한 최소 요구 사항은 하드웨어 ID(_HID) 개체입니다. _HID는 "ABC[D]xxxx" 형식의 문자열을 반환합니다. 여기서 "ABC[D]"는 장치의 제조업체를 식별하는 3자리 또는 4자리 문자열("공급업체 ID")이고, xxxx는 해당 공급업체에서 제조한 특정 장치를 식별하는 16진수("장치 ID")입니다. 공급업체 ID는 업계에서 고유해야 합니다. Microsoft는 고유하도록 하기 위해 이러한 문자열을 할당합니다. 공급업체 ID는 플러그 앤 플레이 ID - PNPID 요청에서 가져올 수 있습니다.

참고  ACPI 5.0은 _HID 및 기타 식별 개체에 PCI 할당 공급업체 ID 사용도 지원하므로 Microsoft에서 공급업체 ID를 가져올 필요가 없을 수도 있습니다. 하드웨어 ID 요구 사항에 대한 자세한 내용은 ACPI 5.0 사양의 섹션 6.1.5 "_HID (Hardware ID)(_HID(하드웨어 ID))"를 참조하세요.

 

호환 가능 ID(_CID)

Microsoft는 Windows와 함께 제공되는 드라이버와 호환되는 장치의 공급업체 ID "PNP"를 예약했습니다. Windows는 장치에 대해 Windows에서 제공하는 드라이버를 로드하는 데 사용될 수 있는 이 공급업체 ID와 함께 사용하도록 여러 장치 ID를 정의합니다. 별도의 개체인 호환 가능 ID(_CID) 개체는 이러한 식별자를 반환하는 데 사용됩니다. Windows는 항상 INF 일치 및 드라이버 선택에서 호환 가능 ID(_CID에서 반환됨)보다 하드웨어 ID(_HID에서 반환됨)를 선호합니다. 공급업체에서 제공한 장치별 드라이버를 사용할 수 없는 경우 이러한 선호에 따라 Windows 제공 드라이버를 기본 드라이버로 간주할 수 있습니다. 다음 표의 호환 가능 ID는 SoC 플랫폼에 사용하도록 새롭게 만들어졌습니다.

호환 가능 ID 설명
PNP0C40 Windows 호환 단추 배열
PNP0C50 HID-over-I²C 규격 장치
PNP0C60 컨버터블 노트북 디스플레이 센서 장치
PNP0C70 도크 센서 장치
PNP0D10 XHCI Compliant USB Controller(표준 디버그 포함)
PNP0D15 XHCI Compliant USB Controller(표준 디버그 제외)
PNP0D20 EHCI Compliant USB Controller(표준 디버그 제외)
PNP0D25 EHCI Compliant USB Controller(표준 디버그 포함)
PNP0D40 SDA Standard Compliant SD Host Controller
PNP0D80 Windows 호환 시스템 전원 관리 컨트롤러

 

하위 시스템 ID(_SUB), 하드웨어 수정(_HRV) 및 클래스(_CLS)

ACPI 5.0은 장치의 특정 버전, 통합 또는 하드웨어 수정을 보다 고유하게 식별하거나 PCI 정의 장치 클래스의 멤버 자격을 나타내는 식별자를 만들기 위해 _HID와 함께 사용될 수 있는 _SUB, _HRV 및 _CLS 개체를 정의합니다. 이러한 개체는 일반적으로 옵션이지만 Windows의 특정 장치 클래스에 필요할 수 있습니다. 이러한 개체에 대한 자세한 내용은 ACPI 5.0 사양의 섹션 6.1 "Device Identification Objects(장치 식별 개체)"를 참조하세요.

서비스 가능성의 경우 OEM 시스템에서 장치 ID가 "네 부분으로 이루어진" ID여야 한다는 Windows HCK(하드웨어 인증 키트) 요구 사항이 있습니다. 네 부분은 공급업체 ID, 장치 ID, 하위 시스템 공급업체(OEM) ID 및 하위 시스템(OEM) 장치 ID입니다. 따라서 OEM 플랫폼에 하위 시스템 ID(_SUB) 개체가 필요합니다.

장치별 메서드(_DSM)

_DSM 메서드는 ACPI 5.0 사양의 섹션 9.14.1 "_DSM (Device Specific Method)(_DSM(장치별 메서드))"에 정의되어 있습니다. 이 메서드는 장치 드라이버가 다른 장치별 메서드와의 충돌 없이 호출할 수 있는 개별 장치별 데이터 및 제어 함수를 제공합니다. 특정 장치 또는 장치 클래스의 _DSM은 다른 UUID와 충돌하지 않도록 보장되는 UUID(GUID)를 정의합니다. 각 UUID의 경우 _DSM 메서드가 데이터를 제공하거나 드라이버에 대한 제어 함수를 수행하기 위해 구현할 수 있는 정의된 함수 집합이 있습니다. 클래스별 데이터 및 데이터 형식은 별도의 장치 클래스별 사양에서 제공하며 ACPI 장치별 메서드에도 설명되어 있습니다.

주소(_ADR) 및 고유 ID(_UID)

장치 식별에 대한 다음과 같은 세 가지 추가 요구 사항이 있습니다.

  • 하드웨어 열거 가능 부모 버스(예: SDIO, USB HSIC)에 연결되지만 플랫폼별 기능 또는 컨트롤(예: 측파대 전원 또는 절전 모드 해제 인터럽트)이 있는 장치의 경우 _HID가 사용되지 않습니다. 대신 앞에서 설명한 대로 부모 버스 드라이버에서 장치 식별자를 만듭니다. 그러나 이 경우 주소 개체(_ADR)가 장치의 ACPI 네임스페이스에 있어야 합니다. 이 개체를 통해 운영 체제는 버스 열거 장치를 해당 ACPI 설명 기능 또는 컨트롤과 연결할 수 있습니다.
  • 각 블록에 같은 장치 식별 개체가 있도록 특정 IP 블록의 여러 인스턴스가 사용되는 플랫폼의 경우 운영 체제가 블록을 구분할 수 있도록 고유 식별자(_UID) 개체가 필요합니다.
  • 특정 네임스페이스 범위에 있는 두 장치의 이름이 같을 수 없습니다.

장치 구성 개체

네임스페이스에서 식별되는 각 장치의 경우 장치에서 사용되는 시스템 리소스(메모리 주소, 인터럽트 등)를 현재 리소스 설정(_CRS) 개체에서도 보고해야 합니다. 장치의 리소스 구성(_SRS) 변경을 위해 여러 가능한 리소스 구성(_PRS) 및 컨트롤을 보고하는 기능이 지원되지만 옵션입니다.

SoC 플랫폼에 대한 새로운 기능은 장치가 사용할 수 있는 GPIO 및 SPB(Simple Peripheral Bus) 리소스입니다. 자세한 내용은 GPIO(범용 I/O) 및 SPB(Simple Peripheral Bus)를 참조하세요.

SoC 플랫폼에 대한 또 다른 새로운 기능은 범용 고정 DMA 설명자입니다. FixedDMA 설명자는 여러 시스템 장치에서 DMA 컨트롤러 하드웨어를 공유하는 것을 지원합니다. 특정 시스템 장치에 정적으로 할당되는 DMA 리소스(요청 라인 및 채널 레지스터)는 FixedDMA 설명자에 나열됩니다. 자세한 내용은 ACPI 5.0 사양의 섹션 19.5.49 "FixedDMA (DMA Resource Descriptor Macro)(FixedDMA(DMA 리소스 설명자 매크로))"를 참조하세요.

장치 상태 변경

ACPI 열거 장치를 다양한 이유로 사용하지 않도록 설정하거나 제거할 수 있습니다. 상태(_STA) 개체는 이러한 상태 변경을 운영 체제에 전달할 수 있도록 제공됩니다. _STA에 대한 설명은 ACPI 5.0 사양의 섹션 6.3.7을 참조하세요. Windows에서는 _STA를 사용하여 장치가 열거되어야 하는지, 사용 안 함으로 표시되어야 하는지 또는 사용자에게 표시되지 않아야 하는지를 결정합니다. 펌웨어의 이 컨트롤은 도킹, USB OTG 호스트-함수 전환 등 여러 적용 분야에 유용합니다.

또한 ACPI는 도크의 일부로 제거되는 장치 등 ASL에서 플랫폼의 이벤트에 대해 드라이버에 알리는 데 사용할 수 있는 알림 메커니즘을 제공합니다. 일반적으로 ACPI 장치 상태가 변경되면 펌웨어가 "장치 확인" 또는 "버스 확인" 알림을 수행하여 Windows가 장치를 다시 열거하고 해당 _STA를 다시 평가하도록 해야 합니다. ACPI 알림에 대한 자세한 내용은 ACPI 5.0 사양의 섹션 5.6.6 "Device Object Notifications(장치 개체 알림)"를 참조하세요.

사용/사용 안 함

Windows 플러그 앤 플레이의 일부로 드라이버는 사용자 또는 시스템에 의해 동적으로 사용 및 사용 안 함으로 설정될 수 있습니다(예: 드라이버 업데이트).

on-SoC 장치는 SoC 칩에 통합되어 있으며 제거할 수 없습니다. 대부분의 on-SoC 장치용 드라이버는 사용 및 사용 안 함에 대한 요구 사항에서 제외될 수 있습니다. 제외되지 않은 드라이버의 경우 드라이버가 질서 정연한 제거를 지원함을 나타내기 위한 드라이버 인터페이스가 있습니다. 자세한 내용은 Microsoft Connect 웹 사이트의 "SoC 드라이버의 PNP 요구 사항 줄이기" 문서를 참조하세요.

드라이버가 질서 정연한 제거를 지원하는 경우 장치 하드웨어를 사용하지 않도록 설정할 수 있으면(즉, 할당된 해당 리소스에 대한 액세스를 중지하도록 장치를 구성할 수 있음) 장치의 ACPI 네임스페이스 노드가 사용 안 함(_DIS) 개체를 포함할 수 있습니다. 이 메서드는 드라이버가 제거될 때마다 운영 체제에 의해 평가됩니다. _DIS를 사용할 경우 다음과 같은 추가 요구 사항이 있습니다.

  • _STA는 장치가 사용하지 않도록 설정될 때마다 "enabled and decoding its resources" 비트를 지워야 합니다.
  • 장치는 리소스 설정 지정(_SRS) 개체를 제공하여 장치 하드웨어를 다시 사용하도록 설정하고 _STA에 위의 비트를 설정해야 합니다.

자세한 내용은 ACPI 5.0 사양의 섹션 6.2.3 (_DIS), 6.2.15 (_SRS), 6.3.7 (_STA)를 참조하세요.

장치 종속성

일반적으로 특정 플랫폼의 장치 간에는 하드웨어 종속성이 있습니다. Windows는 시스템에서 항목이 동적으로 변경되는 경우(장치 전원이 제거됨, 드라이버가 중지되었다가 시작됨 등) 모든 장치가 올바르게 작동하도록 보장할 수 있도록 이러한 모든 종속성이 설명되도록 요구합니다. ACPI에서 장치 간의 종속성은 다음과 같은 방식으로 설명됩니다.

  1. Namespace hierarchy. 자식 장치인 모든 장치(다른 장치의 네임스페이스 내에 장치로 나열됨)는 부모 장치에 종속됩니다. 예를 들어 USB HSIC 장치는 연결된 포트(부모) 및 컨트롤러(최상위)에 종속됩니다. 마찬가지로 시스템 MMU(메모리 관리 장치) 장치의 네임스페이스 내에 나열된 GPU 장치는 MMU 장치에 종속됩니다.
  2. Resource connections. GPIO 또는 SPB 컨트롤러에 연결된 장치는 해당 컨트롤러에 종속됩니다. 이 유형의 종속성은 장치의 _CRS에 연결 리소스를 포함하여 설명합니다.
  3. OpRegion dependencies. OpRegion을 사용하여 I/O를 수행하는 ASL 컨트롤 메서드의 경우 종속성이 컨트롤 메서드 평가 중에만 결정되므로 운영 체제에서 이러한 종속성을 암시적으로 알 수 없습니다. 이 문제는 특히 플러그 앤 플레이 드라이버가 해당 영역에 대한 액세스를 제공하는 GeneralPurposeIO 및 GenericSerialBus OpRegion에 해당합니다. 이 문제를 완화하기 위해 ACPI는 OpRegion 종속성(_DEP) 개체를 정의합니다. _DEP는 OpRegion(HW 리소스)이 컨트롤 메서드에 의해 참조되는 모든 장치 네임스페이스에서 사용되어야 하며 위의 1과 2는 참조된 OpRegion의 연결 리소스에 이미 적용되어 있지 않습니다. 자세한 내용은 ACPI 5.0 사양의 섹션 6.5.8 "_DEP (Operation Region Dependencies)(_DEP(작업 영역 종속성))"를 참조하세요.

장치 드라이버 간에는 소프트웨어 종속성도 있을 수 있습니다. 이러한 종속성도 설명되어야 합니다. 자세한 내용은 다음 리소스를 참조하세요.