Andra ACPI-namnområdesobjekt

För vissa specifika enhetsklasser finns det krav på att ytterligare ACPI-namnområdesobjekt (Advanced Configuration and Power Interface) ska visas under enheterna i namnområdet. I det här avsnittet visas de ytterligare objekt som krävs för SoC-baserade plattformar.

Identifieringsobjekt för processor

Processorer måste räknas upp i ACPI-namnområdet. Processorer deklareras under \_SB med instruktionen "Enhet" som med andra enheter på plattformen. Processorenheter måste innehålla följande objekt:

• _HID: ACPI0007
• _UID: Ett unikt nummer som matchar processorns post i MADT.

Visningsspecifika objekt

Mer information om visningsspecifika objekt finns i Bilaga B, "Videotillägg" i ACPI 5.0-specifikationen.

Display-Specific objektkrav

USB-värdstyrenheter och -enheter

USB-värdstyrenheter används på SoC-plattformar för att ansluta interna och externa enheter. Windows innehåller inkorgsdrivrutiner för vanliga USB-värdstyrenheter som är kompatibla med EHCI- eller XHCI-specifikationerna.

På SoC-baserade plattformar kan USB-värdstyrenheten identifieras av ACPI. Windows använder följande ACPI-namnområdesobjekt när du räknar upp och konfigurerar kompatibel USB-maskinvara:

• Ett leverantörstilldelat ACPI-kompatibelt maskinvaru-ID (_HID).

• Ett unikt ID-objekt (_UID) om det finns mer än en instans av USB-styrenheten i namnområdet (dvs. två eller flera noder som har identiska enhetsidentifieringsobjekt).

• Ett kompatibelt ID (_CID) för EHCI- eller XHCI-standardkompatibel USB-värdstyrenhet (EHCI: PNP0D20) (XHCI: PNP0D10).

• Aktuella resursinställningar (_CRS) som tilldelats USB-styrenheten. Styrenhetens resurser beskrivs i lämplig maskinvarugränssnittsspecifikation (EHCI eller XHCI).

USB-enhetsspecifik metod (_DSM)

Windows definierar en Device-Specific-metod (_DSM) för att stödja enhetsklassspecifik konfiguration av USB-undersystemet. Mer information finns i USB Device-Specific-metoden.

Stöd för USB-integrerad transaktionsöversättare (TT) (_HRV)

Standard-EHCI-värdstyrenheter stöder endast höghastighets-USB-enheter. På SoC-plattformar har Windows stöd för två vanliga modeller av EHCI-kompatibla värdstyrenheter som implementerar en integrerad transaktionsöversättare för USB-enheter med låg hastighet och full hastighet. Objektet Maskinvarurevision (_HRV) anger typen av integrerat TT-stöd till USB-värdstyrenhetens drivrutin.

_HRV anges enligt följande kriterier:

• NoIntegratedTT – _HRV = 0

  Standard-EHCI-värdkontroller implementerar inte integrerade transaktionsöversättare, och ett _HRV-värde på 0 är endast giltigt för dessa kontroller. Det är inte nödvändigt att ta med _HRV-objektet för dessa kontrollanter.

• IntegratedTTSpeedInPortSc – _HRV = 1

  Aktivera integrerat TT-stöd. Den här versionen av gränssnittet innehåller LowSpeed- och HiSpeed-bitarna i själva PORTSC-registret. Dessa bitar befinner sig vid bitpositionerna 26 och 27, respektive. När du fastställer hastigheten läser EHCI-drivrutinen PORTSC och extraherar hastighetsinformationen från dessa bitar.

• IntegratedTTSpeedInHostPc – _HRV = 2

  Aktivera integrerat TT-stöd. Den här versionen av gränssnittet innehåller LowSpeed- och HiSpeed-bitarna i ett separat HOSTPC-register. När EHCI-drivrutinen behöver fastställa porthastigheten läser den HOSTPC-registret som motsvarar porten av intresse och extraherar hastighetsinformationen.

Stöd för USB XHCI D3cold

Förutom selektivt uppehåll kan interna USB-enheter som är anslutna till XHCI-styrenheter försättas i ett D3cold-tillstånd och stängas av när de inte används. Mer information finns i Enhetens energisparfunktioner. Alla USB-enhetsfunktionsdrivrutiner måste anmäla sig till D3cold.

USB-portspecifika objekt

Windows måste känna till synlighet och anslutningsförmåga för USB-portar i systemet. Detta krävs för att ge användaren korrekt information om portar och enheter. Två objekt, fysisk enhetsplats (_PLD) och USB-portfunktioner (_UPC), används för detta ändamål. Mer information finns i följande:

• Avsnitten 6.1.6, "Device Identification Objects" och 9.13.1, "USB 2.0 Host Controllers and _UPC and _PLD", i ACPI 5.0-specifikationen.

• Använda ACPI för att konfigurera USB-portar på en dator.

SD-värdkontrollanter och -enheter

SD-värdstyrenheter används på SoC-plattformar för åtkomst till lagring samt I/O-enheter. Windows innehåller en inkorgsdrivrutin för värdstyrenhetsmaskinvara av SDA-standard. För kompatibilitet med den här drivrutinen måste en SD-värdstyrenhetsenhet följa SD-associationens SD-värdstyrenhetsspecifikation.

På SoC-plattformar kan SD-värdstyrenheten identifieras av ACPI. Windows använder följande ACPI-namnområdesobjekt när du räknar upp och konfigurerar kompatibel SD-maskinvara:

• Ett leverantörstilldelat ACPI-kompatibelt maskinvaru-ID (_HID).

• Ett unikt ID-objekt (_UID) om det finns mer än en instans av SD-styrenheten i namnområdet (dvs. två eller flera noder som har identiska enhetsidentifieringsobjekt).

• Ett kompatibelt ID (_CID) för en SD-värdstyrenhet som är kompatibel med SDA-standarden (PNP0D40).

• Aktuella resursinställningar (_CRS) som tilldelats kontrollanten. Kontrollantens resurser beskrivs på följande sätt:

  • Maskinvaruresurser för alla implementerade slottar ingår. Ett fack är en anslutningspunkt på SDIO-bussen för ett minne eller en I/O-enhet. Varje fack är associerat med en standarduppsättning register och ett avbrott i SD-värdstyrenheten, som används för kommunikation med den anslutna enheten. SD-kontrollörer kan implementera vilket antal platser som helst, men på SoC-plattformar finns det vanligtvis endast en.

  • Fackresurser visas tillsammans i ordning efter facknummer (fack 0:s resurser är först, fack 1:s resurser är tvåa och så vidare).

  • För varje fack visas resurserna i följande ordning:

    • Basadressen för SD-standardregistret som angetts för facket.

    • SD-standardavbrott för kortplatsen.

    • En GPIO-avbrottsresurs för facket för infogningar och borttagningar av signalkort (om standardgränssnittet för SD-kortidentifiering inte stöds under alla strömtillstånd).

    • En GPIO-indataresurs för facket för att läsa om ett kort för närvarande finns i facket (om standardgränssnittet för SD-kortidentifiering inte stöds under alla energispartillstånd). Använder samma pinne som införings-/borttagningsavbrottet.

    • En andra GPIO-indataresurs för att läsa om kortet i facket är skrivskyddat (om standardgränssnittet för SD-skrivskydd inte stöds under alla energispartillstånd).

Avbrott måste vara väckningskompatibla (beskrivs som "SharedAndWake" eller "ExclusiveAndWake").

Inbäddade SD-enheter

SD-anslutna enheter räknas upp av SD-busschauffören. SD-enheter som är integrerade i plattformen måste också anges i ACPI-namnområdet som underordnade till SD-värdstyrenheten. Det här kravet gör det möjligt för operativsystemet att associera den bussuppräknade enheten med de plattformsspecifika attribut som tillhandahålls för enheten av ACPI-objekt (till exempel icke-återanvändbarhet, enhetskrafttillstånd, förbrukade GPIO- eller SPB-resurser och så vidare). För att göra den här associationen kräver enhetens namnområde objektet Address (_ADR), som kommunicerar enhetens adress på SDIO-bussen. Objektet _ADR returnerar ett heltal.

För SDIO-bussen definieras värdet för det här heltalet på följande sätt:

• Högsta ord – facknummer (0 – första fack)

• Lågt ord – funktionsnummer (se SD-specifikation för definitioner.)

Ett inbäddat SD-enhetsnamnområde måste också innehålla:

• Ett remove-metodobjekt (_RMV) som returnerar 0 (för att indikera att enheten inte kan tas bort).

• Ett _CRS objekt för de sidobandsresurser som enheten kräver (till exempel GPIO-stift eller SPB-anslutningar) om det behövs.

Bildklassenheter (kameror)

Kameraenheter kan listas av drivrutinen för grafikkortet eller via USB. I båda fallen måste Windows känna till kamerans fysiska plats så att lämpligt användargränssnitt kan visas. För att göra detta ingår kameraenheter som är inbyggda i systemets chassi och har mekaniskt fast riktning i ACPI-namnområdet och tillhandahåller objektet Fysisk enhetsplats (_PLD). Detta kräver:

• Kameraenheten ska visas som en underordnad enhet (kapslad enhet) till räknarenheten, antingen GPU-enheten eller USB-enheten.

• Kameraenheten för att ange adressobjektet (_ADR) som innehåller kamerans adress på den överordnade enhetens buss.

  • För USB, se ACPI-namnrymdshierarki och _ADR för inbäddade USB-enheter i nästa avsnitt nedan.

  • För grafik är detta den identifierare som anges i den _DOD metod som anges under GPU-enheten. Mer information finns i bilaga B, "Videotillägg" i ACPI 5.0-specifikationen.

• Kameraenheten som tillhandahåller _PLD-objektet.

• Om det finns några sidobandsresurser som krävs av kameradrivrutinen (till exempel GPIO-avbrott eller I/O-anslutningar eller en SPB-anslutning) tillhandahålls _CRS-objektet för dessa resurser.

I det _PLD objektet anges fältet Panel (bitar 67-69), Lid-fältet (bit 66) och Dock-fältet (bit 65) till korrekta värden för den yta som kameran är monterad på. Alla andra fält är valfria. För handhållna mobila enheter, inklusive surfplattor, är den främre panelen den som håller bildskärmen, och dess ursprung är i det nedre vänstra hörnet när skärmen visas i stående orientering. Med den här referensen anger "Front" att kameran visar användaren (webbkameran), medan "Back" anger att kameran ser bort från användaren (stillbilds- eller videokamera). Mer information finns i avsnitt 6.1.8, "_PLD (fysisk plats för enhet)", i ACPI 5.0-specifikationen.

ACPI-namnområdeshierarki och _ADR för inbäddade USB-enheter

När du lägger till inbäddade USB-enheter i ACPI-namnområdet måste hierarkin för enhetsnoderna exakt matcha den för de enheter som räknas upp av Windows USB-drivrutinen. Detta kan fastställas genom att undersöka Windows Device Manager i läget "Visa efter anslutning". Hela hierarkin, som börjar från USB-värdstyrenheten och sträcker sig ned till den inbäddade enheten, måste inkluderas. Egenskapen "Adress" som anges i Enhetshanteraren för varje enhet är den adress som den inbyggda programvaran måste rapportera i enhetens _ADR.

ACPI 5.0-specifikationen definierar adresserna för USB-enheter enligt följande:

USB-rothubb: Endast underordnad till värdstyrenheten. Det måste ha en _ADR på 0. Inga andra barn eller värden för _ADR tillåts.

USB-portar: Portnummer (1-n)

USB-enheter som är anslutna till en viss port delar adressen till den porten.

Om enheten som är ansluten till en port är en sammansatt USB-enhet måste funktioner i den sammansatta enheten använda följande adress:

USB-funktion i en sammansatt USB-enhet: Portnumret för den port som den sammansatta enheten är ansluten till, PLUS funktionens första gränssnittsnummer. (Aritmetiktillägg).

Mer information finns i Identifiera platsen för interna kameror.

ASL-kodexempel

I följande ASL-kodexempel beskrivs en USB-webbkamera som är direkt ansluten till USB-port 3.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {         // the Root HUB
     Name (_ADR, ZERO)      // Address is always 0.
     Device (CAM0) {          // Camera connected directly to USB
                       //   port number 3 under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
    } // End of Root Hub Device
}  // End of EHCI device

I följande ASL-kodexempel beskrivs en SAMMANSATT USB-enhet som implementerar en webbkamera som funktion 2.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {
     Name (_ADR, ZERO)
     Device (CUSB) {        // Composite USB device
                    //   connected to USB port number 3
                    //   under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Device (CAM0) { // Camera function within the
                    //   Composite USB device.
                Name (_ADR, 5)  // Camera function has a first
                    //   Interface number of 2, so
                    //   Address is 3 + 2  = 5.
                Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
        } // End of Composite USB Device
    } // End of Root Hub Device
}  // End of EHCI device

I följande ASL-kodexempel beskrivs en webbkamera som är ansluten via I2C.

Device (GPU0) {
    ... // Other objects required for graphics devices
    Name (_DOD, Package ()  // Identifies the children of this graphics device.
                // Each integer must be unique within the GPU0 namespace.
                {
                    0x00024321,  // The ID for CAM0. It is a non-VGA
                    //   device, cannot be detected by
                    //   the VGA BIOS, and uses a vendor-
                    //   specific ID format in bits 15:0
                    //   (see the _DOD specification).
                    ...     // Other child device IDs (for
                    //   example, display output ports)
                })
    Device (CAM0) {
        Name (_ADR, 0x00024321) // The identifier for this device
                    //   (Same as in _DOD above)
        Name (_CRS, ResourceTemplate()
            {
            // I2C Resource
            // GPIO interrupt resource(s), if required by
            //   driver
            // GPIO I/O resource(s), if required by driver
                ...
            })
        Method (_PLD, 0, Serialized) {...}
    } // End of CAM0 device
} // End of GPU0 device

HID-over-I2C-enheter

Windows innehåller en klassdrivrutin för Human Interface Devices (HID). Den här drivrutinen ger allmänt stöd för ett brett utbud av indataenheter (till exempel pekpaneler, tangentbord, möss och sensorer). På SoC-plattformar kan HID-enheter anslutas till plattformen via I2C och räknas upp av ACPI. För kompatibilitet med HID-klassstöd i Windows används följande namnområdesobjekt:

• En leverantörsspecifik _HID

• En _CID av PNP0C50

• En _CRS med:

  • En I2CSerialBusConnection-resurs för åtkomst till enheten

  • En GpioInt-resurs för avbrott

• HIDI2C-_DSM-metoden för att returnera HID Descriptor Register-adressen på enheten. Mer information finns i HIDI2C Device-Specific-metoden (_DSM).

Knappenheter

För SoC-plattformar stöder Windows både den ACPI-definierade strömbrytarknappen för kontrollmetod och en Windows-kompatibel femknapparsrad. Strömknappen, oavsett om den implementeras som en AVSI-kontrollmetod, eller som en del av den Windows-kompatibla knappmatrisen, gör följande:

• Orsakar att plattformen slås på om den är avstängd.

• Genererar händelsen för åsidosättning av strömknappen när den hålls nedtryckt. Mer information finns i avsnitt 4.8.2.2.1.3, "Åsidosättning av strömknapp" i ACPI 5.0-specifikationen.

Kontrollmetodens strömknapp

Clamshell-designs och andra system med inbyggda eller anslutna tangentbord implementerar den ACPI-definierade kontrollmetodens strömknapp (avsnitt 4.8.2.2.1.2 i ACPI 5.0-specifikationen) med hjälp av GPIO-Signaled ACPI-händelser (avsnitt 5.6.5 i ACPI 5.0-specifikationen). För att stödja strömknappsenheten, använd namnområdet:

• Beskriver strömknappens GPIO-avbrottsstift som en icke-delad (exklusiv) GPIO-avbrottsresurs.

• Visar en lista över strömknappens GPIO-avbrottsresurs i det _AEI objektet för GPIO-styrenheten som den är ansluten till.

• Tillhandahåller den associerade händelsemetoden (Lxx/Exx/EVT) under GPIO-styrenheten. Den här händelsehanteringsmetoden meddelar drivrutinen för Control Method-knappen i operativsystemet att knapphändelsen har inträffat.

Mer information finns i Maskinvaruknappar för Windows 8-surfplattor och konvertibla enheter.

Windows-kompatibel knappmatris

För touch-first-plattformar (tangentbordslösa), till exempel plattor, tillhandahåller Windows en allmän drivrutin för en uppsättning med fem knappar. Varje knapp i matrisen har sin definierade funktion (se de numrerade objekten i listan nedan) och vissa kombinationer av "håll och tryck"-knappen har ytterligare betydelse i användargränssnittet. Inga knappkombinationer definieras som kräver att strömknappen hålls nere. För kompatibilitet med windows-inkorgens knappdrivrutin implementeras den Windows-kompatibla ACPI-enheten för knappmatrisen. Enheten definieras på följande sätt:

• Var och en av de fem knapparna är ansluten till sin egen dedikerade avbrottsstift på plattformen.

• Varje avbrottsstift konfigureras som en icke-delad (exklusiv), gränsutlöst (Edge) avbrottsresurs som avbryter på båda kanterna (ActiveBoth).

• Enhetens namnområde innehåller en leverantörsdefinierad _HID samt en _CID av PNP0C40.

• GPIO-avbrottsresurserna i _CRS-objektet visas i följande ordning:

  1. Avbrott motsvarande "Power"-knappen

     Knappen "Ström" måste vara väckningskapabel (ExclusiveAndWake).

  2. Avbrott som motsvarar "Windows"-knappen

     Windows-knappen måste kunna väcka systemet (ExclusiveAndWake).

  3. Avbrott motsvarande knappen "Höj volymen"

     Knappen "Volym upp" får inte vara väckningskompatibel (måste använda exklusiv).

  4. Avbrott som motsvarar knappen "Volym ned"

     Knappen "Volym ned" får inte vara väckarkompatibel (måste använda exklusivt läge).

  5. Avbrott som motsvarar knappen "Rotationslås", om det stöds

     Knappen "Rotationslås" får inte kunna väcka enheten (måste använda Exklusivt).

Mer information finns i Maskinvaruknappar för Windows 8-surfplattor och konvertibla enheter.

För att stödja utvecklingen av användargränssnittet för Windows-knappen definierar Windows en Device-Specific-metod (_DSM) för Windows-knappmatrisenheten. Mer information finns i Windows Button Array Device-Specific-metoden (_DSM).

Docka och konvertibla pc-avkänningsenheter

Windows stöder dockor och konvertibler (musselskals-/surfplatta-kombinationer) med hjälp av två avkänningsenheter i ACPI-namnområdet. Dessa enheter stöds av knappdrivrutinen för Windows-inkorgen. Observera att samma krav som gäller för knappmatrisenheten även gäller för dessa enheter:

• GPIO ActiveBoth-avbrott måste vara anslutna till en on-SoC GPIO-styrenhet (inte till en SPB-ansluten GPIO-styrenhet).

• GPIO-styrenheten måste ha stöd för avbrott i nivåläge och dynamisk polaritetsomprogrammering.

• GPIO-styrenhetens drivrutin måste använda ActiveBoth-emulering som tillhandahålls av GPIO-ramverkstillägget (GpioClx).

• Om det angivna tillståndet ("Dockad" eller "Konverterad") inte anges med låg logiknivå, används _DSM-metoden i GPIO-kontrollanten för att åsidosätta GPIO-drivrutinens stackens standardbeteende. Mer information finns i avsnittet GPIO-styrenheter i avsnittet Allmän I/O (GPIO).

Mer information finns i Maskinvaruknappar för Windows 8-surfplattor och konvertibla enheter.

Dock-avkänningsenhet

En dockningsavkänningsenhet avbryter systemet när en docka ansluts eller kopplas från systemet. Den här lägesändringsinformationen används för att uppdatera användarindata- och utdataupplevelsen efter behov. Enhetens namnområde kräver:

• En leverantörsspecifik _HID

• A _CID av PNP0C70

• En _CRS med ett ActiveBoth-avbrott

  Avbrott kan inte vara aktiveringskompatibelt.

Avkänningsenhet för konvertibla datorer

En enhet för avkänning av konvertibla PC avbryter systemet när en konvertibel dator växlar från surfplatta till bärbar dators formfaktor. Den här lägesändringsinformationen används för att uppdatera användarindata- och utdataupplevelsen efter behov. Enhetens namnområde kräver:

• En leverantörsspecifik _HID

• En _CID för PNP0C60

• En _CRS med ett ActiveBoth-avbrott

  Avbrott kan inte vara aktiveringskompatibelt.