USB 이중 역할 드라이버 스택 아키텍처

이제 데스크톱 버전(Home, Pro, Enterprise 및 Education)용 Windows 10 및 Windows 10 Mobile부터 USB 이중 역할 컨트롤러가 Windows에서 지원됩니다.

소개

USB 이중 역할 기능을 사용하면 시스템이 USB 디바이스 또는 USB 호스트가 될 수 있습니다. USB 이중 역할에 대한 자세한 사양은 이동 정보 페이지의 USB-IF USB에서 찾을 수 있습니다.

이중 역할 기능을 사용하면 휴대폰 또는 태블릿과 같은 모바일 디바이스가 자신을 디바이스 또는 호스트로 지정할 수 있습니다.

모바일 디바이스가 함수 모드에 있는 경우 PC 또는 연결된 모바일 디바이스의 호스트 역할을 하는 다른 디바이스에 연결됩니다.

모바일 디바이스가 호스트 모드인 경우 사용자는 마우스 또는 키보드와 같은 디바이스를 연결할 수 있습니다. 이 경우 모바일 디바이스는 연결된 디바이스를 호스트합니다.

Windows 10에서 USB 이중 역할에 대한 지원을 제공하여 다음과 같은 이점을 제공합니다.

• USB를 통한 모바일 주변 장치 연결은 Bluetooth와 같은 무선 프로토콜에 비해 더 큰 데이터 대역폭을 제공합니다.
• 연결된 상태에서 USB를 통해 배터리를 충전하고 다른 USB 디바이스와 통신하는 옵션입니다(필요한 하드웨어 지원이 있는 한).
• 모든 작업에 대해 스마트폰과 같은 모바일 장치를 소유할 가능성이 가장 큰 고객을 사용하도록 설정합니다. 이 기능을 사용하면 모바일 디바이스가 도킹되어 주변 장치를 호스팅하는 유선 도킹 시나리오에서 생산성이 향상됩니다.

다음 표에서는 데스크톱 및 모바일 버전의 Windows에서 사용할 수 있는 호스트 클래스 드라이버 목록을 보여 줍니다.

테이블의 클래스 드라이버는 Windows 10에 대해 선택된 주요 시나리오에 따라 디바이스 클래스 원격 분석을 기반으로 선택되었습니다. Windows 10 Mobile에서 주요 디바이스를 지원하기 위해 제한된 수의 받은 편지함, 타사 호스트 드라이버를 포함할 계획입니다. 데스크톱용 Windows 10 버전의 경우 이러한 드라이버는 OEM 웹 사이트 또는 WU(Windows 업데이트)를 통해 사용할 수 있습니다.

Windows 10 Mobile의 경우 받은 편지함이 포함되지 않은 타사 드라이버는 창 업데이트에서 사용할 수 없습니다. USB 호스트 스택 + HID의 디스크 공간은 작게 유지됩니다. 따라서 모든 클래스 드라이버와 몇 가지 타사 드라이버가 Windows 10 Mobile용 받은 편지함에 포함되어 있지는 않습니다. 타사 드라이버를 사용할 수 있도록 하려는 OEM은 BSP(보드 지원 패키지)를 사용하여 모바일 디바이스의 OS 이미지에 추가할 수 있습니다.

다음 표에서는 Windows 모바일 버전에서 사용할 수 있는 함수 클래스 드라이버를 보여 줍니다.

디바이스 첨부 파일 데이터를 모니터링하여 디바이스 클래스 인기 목록 업데이트로 더 많은 클래스 드라이버 지원을 제공해야 하는지 알려 줍니다.

드라이버 구현

Microsoft URS(USB 역할 스위치) 드라이버를 사용하면 시스템 구현자가 플랫폼의 이중 역할 USB 기능을 활용할 수 있습니다.

URS 드라이버는 단일 포트를 통해 호스트 및 주변 장치 역할 모두에서 작동할 수 있는 단일 USB 컨트롤러를 사용하는 플랫폼에 이중 역할 기능을 제공하기 위한 것입니다. 주변 장치 역할을 함수 역할이라고도 합니다. URS 드라이버는 포트의 현재 역할을 관리합니다. URS 드라이버는 플랫폼의 하드웨어 이벤트를 기반으로 적절한 소프트웨어 스택을 로드하고 언로드합니다.

USB 마이크로 AB 커넥터가 있는 시스템에서 드라이버는 커넥터의 ID 핀 상태를 나타내는 하드웨어 인터럽트를 사용합니다. 이 핀은 컨트롤러가 연결에서 호스트 역할 또는 함수 역할을 가정해야 하는지 여부를 감지하는 데 사용됩니다. 자세한 내용은 USB On-The-Go 사양을 참조 하세요. USB Type-C 커넥터가 있는 시스템에서 OEM 구현자는 USB Type-C 커넥터 드라이버 프로그래밍 인터페이스를 사용하여 커넥터 클라이언트 드라이버를 제공해야 합니다. 클라이언트 드라이버는 Microsoft에서 제공하는 USB 커넥터 관리자 클래스 확장(UcmCx)과 통신하여 CC 감지, PD 메시징 등 USB Type-C 커넥터의 모든 측면을 관리합니다. 역할 전환을 위해 클라이언트 드라이버는 USB Type-C 커넥터의 상태를 URS 드라이버와 통신합니다.

다음 다이어그램에서는 URS 드라이버를 사용하는 이중 역할 컨트롤러에 대한 USB 소프트웨어 드라이버 스택을 보여 줍니다.

URS 드라이버는 이전 다이어그램에 표시된 함수 및 호스트 스택을 동시에 로드하지 않습니다. URS 드라이버는 USB 컨트롤러의 역할에 따라 함수 스택 또는 호스트 스택을 로드합니다.

하드웨어 요구 사항

URS 드라이버를 활용하는 플랫폼을 개발하여 이중 역할 USB 기능을 제공하는 경우 다음 하드웨어 요구 사항을 충족해야 합니다.

• USB 컨트롤러

  이러한 드라이버는 Microsoft에서 기본 제공 드라이버로 제공합니다.

  Synopsys DesignWare Core USB 3.0 컨트롤러. 받은 편지함 INF: UrsSynopsys.inf.

  Chipidea 고속 USB OTG 컨트롤러. 받은 편지함 INF: UrsChipidea.inf.

• ID 핀 인터럽트

  • 비 USB Type-C 시스템에 대한 하나 이상의 ID 핀 인터럽트는 다음 두 가지 방법 중 하나로 구현됩니다.

    1. 두 개의 에지 트리거 인터럽트: 커넥터의 ID 핀이 접지될 때 발생하는 인터럽트 및 ID 핀이 부동될 때 발생하는 인터럽트입니다.
    2. ID 핀이 접지될 때 활성 수준에 있는 단일 활성-둘 다 인터럽트입니다.

• USB 컨트롤러 열거형

  USB 이중 역할 컨트롤러는 ACPI 열거형이어야 합니다.

• 소프트웨어 지원

  URS 드라이버는 커넥터를 통해 VBus를 제어할 수 있는 소프트웨어 인터페이스를 기대합니다. 이 인터페이스는 SoC 관련입니다. 자세한 내용은 SoC 공급업체에 문의하세요.

이러한 USB OTG 기능은 Windows에서 지원되지 않습니다.

• ACA(액세서리 충전기 어댑터 감지).
• SRP(세션 요청 프로토콜).
• HNP(호스트 협상 프로토콜).
• ADP(Attach Detection Protocol).

ACPI 시스템 구성

URS 드라이버를 사용하려면 시스템에 대한 ACPI 정의 파일을 만들어야 합니다. 또한 고려해야 할 몇 가지 드라이버 관련 고려 사항이 있습니다.

다음은 USB 이중 역할 컨트롤러에 대한 샘플 ACPI 정의입니다.

//
// You may name the device whatever you want; we don't depend on it being called 'URS0'.
//
Device(URS0)
{
    //
    // Replace with your own hardware ID. Microsoft will add it to the inbox INF,
    // or you may choose to author a custom INF that uses Needs & Includes directives
    // to include sections from the inbox INF.
    //
    Name(_HID, "ABCD1234")

    Name(_CRS, ResourceTemplate() {
        //
        // The register space for the controller must be defined here.
        //
        Memory32Fixed(ReadWrite, 0xf1000000, 0xfffff)


        //
        // The ID pin interrupts, if you are using two edge-triggered interrupts.
        //
        GpioInt(Edge, ActiveHigh, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x1001}
        GpioInt(Edge, ActiveHigh, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x1002}

        //
        // Following is an example of a single active-both interrupt.
        //
        // GpioInt(Edge, ActiveBoth, Exclusive, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer, , ){0x12}
        //

        //
        // For a Type-C platform, you do not need to specify any interrupts here.
        //
    })

    //
    // This child device represents the USB host controller. This device node is in effect
    // when the controller is in host mode.
    // You may name the device whatever you want; we don't depend on it being called 'USB0'.
    //
    Device(USB0)
    {
        //
        // The host controller device node needs to have an address of '0'
        //
        Name(_ADR, 0)
        Name(_CRS, ResourceTemplate() {

            //
            // The controller interrupt.
            //
            Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive, , , ){0x10}
        })
    }

    //
    // This child device represents the USB function controller. This device node is in effect
    // when the controller is in device/function/peripheral mode.
    // You may name the device whatever you want; we don't depend on it being called 'UFN0'.
    //
    Device(UFN0)
    {
        //
        // The function controller device node needs to have an address of '1'
        //
        Name(_ADR, 1)
        Name(_CRS, ResourceTemplate() {

            //
            // The controller interrupt (this could be the same as the one defined in
            // the host controller).
            //
            Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive, , , ){0x11}
        })
    }
}

다음은 ACPI 파일의 주요 섹션에 대한 몇 가지 설명입니다.

• URS0은 USB 이중 역할 컨트롤러에 대한 ACPI 정의입니다. URS 드라이버는 이 ACPI 디바이스에 로드됩니다.

• USB0 및 UFN0은 URS0 범위 내의 자식 디바이스입니다. USB0 및 UFN0은 각각 URS 드라이버로 열거된 두 자식 스택과 호스트 및 함수 스택을 나타냅니다. _ADR ACPI가 이러한 디바이스 정의를 URS 드라이버가 만드는 디바이스 개체와 일치시키는 방법입니다.

• 컨트롤러가 두 역할에 대해 동일한 인터럽트 사용 하는 경우 동일한 컨트롤러 인터럽트는 두 자식 디바이스에서 설명할 수 있습니다. 이 경우에도 인터럽트는 여전히 "배타적"으로 설명될 수 있습니다.

• 필요에 따라 이 ACPI 정의 파일을 추가할 수 있습니다. 예를 들어 ACPI 정의 파일의 디바이스에서 다른 필요한 메서드 또는 속성을 설정할 수 있습니다. 이러한 추가는 URS 드라이버의 작동을 방해하지 않습니다. 스택에 필요한 다른 모든 리소스는 적절한 디바이스의 _CRS 설명될 수도 있습니다.

URS 드라이버는 호스트 및 함수 스택에 하드웨어 ID를 할당합니다. 이러한 하드웨어 ID는 URS 디바이스의 하드웨어 ID에서 파생됩니다. 예를 들어 하드웨어 ID가 ACPI\ABCD1234 URS 디바이스가 있는 경우 URS 드라이버는 다음과 같이 호스트 및 함수 스택에 대한 하드웨어 ID를 만듭니다.

• 호스트 스택: URS\ABCD1234&HOST

• 함수 스택: URS\ABCD1234&FUNCTION

INF 드라이버 설치 패키지

타사 드라이버 패키지는 필요한 경우 이 체계에 종속할 수 있습니다.

IHV 또는 OEM이고 고유한 드라이버 패키지를 제공할 생각인 경우 고려해야 할 몇 가지 사항은 다음과 같습니다.

• URS 드라이버 패키지

  각 플랫폼의 이중 역할 컨트롤러에 대한 하드웨어 ID는 URS용 받은 편지함 INF에 추가됩니다. 그러나 어떤 이유로든 ID를 추가할 수 없는 경우 IHV/OEM은 받은 편지함 INF가 필요/포함되고 해당 하드웨어 ID와 일치하는 INF를 드라이버 패키지에 제공할 수 있습니다.

  IHV/OEM에 드라이버 스택에 필터 드라이버가 있어야 하는 경우 이 드라이버 패키지가 필요합니다.

• 호스트 드라이버 패키지

  받은 편지함 usbxhci.inf 가 필요/포함되고 호스트 디바이스 하드웨어 ID와 일치하는 IHV/OEM 제공 드라이버 패키지가 필요합니다. 하드웨어 ID 일치는 이전 섹션에서 설명한 체계를 기반으로 합니다.

  IHV/OEM에 드라이버 스택에 필터 드라이버가 있어야 하는 경우 이 드라이버 패키지가 필요합니다.

  URS 드라이버가 호스트 디바이스에 대해 XHCI 호환 ID를 할당하도록 하는 작업이 진행 중입니다.

• 함수 드라이버 패키지

  받은 편지함 Ufxsynopsys.inf 가 필요/포함되고 주변 장치 하드웨어 ID와 일치하는 IHV/OEM 제공 드라이버 패키지가 필요합니다. 하드웨어 ID 일치는 이전 섹션에서 설명한 체계를 기반으로 합니다.

  IHV/OEM은 드라이버 패키지에 필터 드라이버를 포함할 수도 있습니다.

참고 항목

• 이중 역할 컨트롤러 드라이버 참조