다음을 통해 공유


디바이스 관리 네임스페이스 개체

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

Windows의 디바이스 식별

Windows 플러그 앤 플레이 디바이스의 열거자가 제공하는 디바이스 식별자를 기반으로 디바이스 드라이버를 찾아 로드합니다. 열거자는 디바이스에서 식별 정보를 추출하는 방법을 알고 있는 버스 드라이버입니다. 일부 버스(예: PCI, SD 및 USB)에는 이 추출을 수행하는 하드웨어 정의 메커니즘이 있습니다. 프로세서 버스 또는 간단한 주변 버스와 같이 그렇지 않은 버스의 경우 ACPI는 네임스페이스에서 식별 개체를 정의합니다.

Acpi.sys Windows ACPI 드라이버는 이러한 개체에 있는 값을 드라이버의 요구 사항에 따라 디바이스를 구체적으로 또는 일반적으로 식별할 수 있는 다양한 디바이스 식별자 문자열로 어셈블합니다. 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

장치 관리자 열고 열거된 디바이스의 하드웨어 ID 및 호환 ID 속성을 검사하여 Windows에서 디바이스에 대해 만드는 디바이스 식별자를 볼 수 있습니다. 이러한 각 문자열을 INF 파일에 지정하여 디바이스에 로드할 드라이버를 식별할 수 있습니다. INF 일치 순서는 가장 구체적인 하드웨어 식별자(가장 선호되는 드라이버)에서 최소 특정 식별자(최소 기본 설정 드라이버)까지입니다. 따라서 디바이스의 특정 기능에 대해 자세히 알고 있는 드라이버는 덜 구체적인 드라이버(따라서 디바이스 기능의 하위 집합만 지원)를 대체할 수 있습니다.

디바이스 식별자는 INF 일치에만 사용해야 하며 디바이스 드라이버에서 구문 분석하거나 처리해서는 안 됩니다. 디바이스 드라이버가 로드된 특정 하드웨어를 식별해야 하는 경우 설치 시 INF 파일이 적절한 레지스트리 키를 설정하도록 하는 것이 좋습니다. 그런 다음, 드라이버는 초기화 중에 이러한 키에 액세스하여 필요한 정보를 얻을 수 있습니다.

ACPI의 디바이스 식별

하드웨어 ID(_HID)

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

ACPI 5.0은 _HID 및 기타 식별 개체에서 PCI 할당 공급업체 ID의 사용을 지원하므로 Microsoft에서 공급업체 ID를 가져올 필요가 없을 수도 있습니다. 하드웨어 식별 요구 사항에 대한 자세한 내용은 ACPI 5.0 사양의 섹션 6.1.5, "_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-I2C 규격 디바이스
PNP0C60 컨버터블 노트북 디스플레이 센서 디바이스
PNP0C70 도킹 센서 디바이스
PNP0D10 표준 디버그를 사용하는 XHCI 규격 USB 컨트롤러
PNP0D15 표준 디버그가 없는 XHCI 규격 USB 컨트롤러
PNP0D20 표준 디버그가 없는 EHCI 규격 USB 컨트롤러
PNP0D25 표준 디버그를 사용하는 EHCI 규격 USB 컨트롤러
PNP0D40 SDA 표준 규격 SD 호스트 컨트롤러
PNP0D80 Windows 호환 시스템 전원 관리 컨트롤러

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

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

서비스성을 위해 OEM 시스템의 디바이스 ID가 "4부분" ID여야 하는 Windows HCK(하드웨어 인증 키트) 요구 사항이 있습니다. 네 가지 부분은 공급업체 ID, 디바이스 ID, OEM(하위 시스템 공급업체) ID 및 OEM(하위 시스템) 디바이스 ID입니다. 따라서 OEM 플랫폼에는 하위 시스템 ID(_SUB) 개체가 필요합니다.

Device-Specific 메서드(_DSM)

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

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

디바이스 식별을 위한 세 가지 추가 요구 사항이 있습니다.

  • 하드웨어 열거 가능 부모 버스(예: SDIO, USB HSIC)에 연결하지만 플랫폼별 기능 또는 컨트롤(예: 사이드밴드 전원 또는 절전 모드 해제 인터럽트)이 있는 디바이스의 경우 _HID 사용되지 않습니다. 대신 디바이스 식별자는 부모 버스 드라이버(앞에서 설명한 대로)에 의해 만들어집니다. 하지만 이 경우 _ADR(Address Object)가 디바이스의 ACPI 네임스페이스에 있어야 합니다. 이 개체를 사용하면 운영 체제에서 버스 열거형 디바이스를 ACPI 설명 기능 또는 컨트롤과 연결할 수 있습니다.
  • 특정 IP 블록의 여러 인스턴스가 사용되는 플랫폼에서 각 블록에 동일한 디바이스 식별 개체가 있도록 운영 체제가 블록을 구분할 수 있도록 하려면 _UID(Unique Identifier) 개체가 필요합니다.
  • 특정 네임스페이스 범위의 두 디바이스가 같은 이름을 가질 수 없습니다.

디바이스 구성 개체

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

SoC 플랫폼의 새로운 기능은 디바이스에서 사용할 수 있는 GPIO 및 간단한 SPB(주변 버스) 리소스입니다. 자세한 내용은 범용 I/O(GPIO)SPB(Simple Peripheral Bus)를 참조하세요.

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

디바이스 상태 변경

ACPI 열거형 디바이스는 다양한 이유로 사용하지 않도록 설정하거나 제거할 수 있습니다. Status(_STA) 개체는 이러한 상태 변경 내용을 운영 체제에 전달할 수 있도록 하기 위해 제공됩니다. _STA 대한 설명은 ACPI 5.0 사양의 섹션 6.3.7을 참조하세요. Windows는 _STA 사용하여 디바이스를 열거해야 하는지, 비활성화된 것으로 표시할지, 아니면 사용자에게 표시되지 않아야 하는지를 결정합니다. 펌웨어의 이 컨트롤은 도킹 및 USB OTG 호스트-기능 전환을 비롯한 많은 애플리케이션에 유용합니다.

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

설정/해제

Windows 플러그 앤 플레이 일부로 드라이버는 사용자 또는 시스템에서 동적으로 사용하도록 설정하고 사용하지 않도록 설정할 수 있어야 합니다(예: 드라이버 업데이트).

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

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

  • _STA 디바이스를 사용하지 않도록 설정할 때마다 "리소스 사용 및 디코딩" 비트를 지워야 합니다.
  • 디바이스는 디바이스 하드웨어를 다시 사용하도록 설정하고 _STA 위의 비트를 설정하려면 _SRS(리소스 설정) 개체를 제공해야 합니다.

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

디바이스 종속성

일반적으로 특정 플랫폼의 디바이스 간에 하드웨어 종속성이 있습니다. Windows에서는 이러한 모든 종속성을 설명하여 시스템에서 상황이 동적으로 변경될 때 모든 디바이스가 올바르게 작동하도록 해야 합니다(디바이스 전원이 제거되고 드라이버가 중지되고 시작됨). ACPI에서 디바이스 간의 종속성은 다음과 같은 방법으로 설명됩니다.

  1. 네임스페이스 계층 구조입니다. 자식 디바이스인 모든 디바이스(다른 디바이스의 네임스페이스 내에 디바이스로 나열됨)는 부모 디바이스에 종속됩니다. 예를 들어 USB HSIC 디바이스는 연결된 포트(부모) 및 컨트롤러(조부모)에 따라 달라집니다. 마찬가지로, MMU(시스템 메모리 관리 단위) 디바이스의 네임스페이스 내에 나열된 GPU 디바이스는 MMU 디바이스에 따라 달라집니다.

  2. 리소스 연결. GPIO 또는 SPB 컨트롤러에 연결된 디바이스는 해당 컨트롤러에 따라 달라집니다. 이러한 유형의 종속성은 디바이스의 _CRS 연결 리소스를 포함하는 것으로 설명됩니다.

  3. OpRegion 종속성. OpRegions를 사용하여 I/O를 수행하는 ASL 제어 메서드의 경우 종속성은 제어 메서드 평가 중에만 결정되므로 운영 체제에서 암시적으로 알 수 없습니다. 이 문제는 플러그 앤 플레이 드라이버가 지역에 대한 액세스를 제공하는 GeneralPurposeIO 및 GenericSerialBus OpRegions에 적용됩니다. 이 문제를 완화하기 위해 ACPI는 OpRegion 종속성(_DEP) 개체를 정의합니다. _DEP 제어 메서드에서 OpRegion(HW 리소스)을 참조하는 모든 디바이스 네임스페이스에서 사용해야 하며, 위의 1 또는 2는 참조된 OpRegion의 연결 리소스에 이미 적용되지 않습니다. 자세한 내용은 ACPI 5.0 사양의 섹션 6.5.8, "_DEP(작업 지역 종속성)"을 참조하세요.

디바이스 드라이버 간에 소프트웨어 종속성이 있을 수도 있습니다. 이러한 종속성도 설명해야 합니다.

자세한 내용은 다음 자료를 참조하세요.