Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
ACPI 5.0-specifikationen definierar flera typer av namnområdesobjekt som kan användas för att hantera enheter. Objekt för enhetsidentifiering innehåller till exempel identifieringsinformation för enheter som ansluter till bussar, till exempel I2C, som inte stöder maskinvaruuppräkning av underordnade enheter. Andra typer av namnområdesobjekt kan ange systemresurser, beskriva enhetsberoenden och ange vilka enheter som kan inaktiveras.
Enhetsidentifiering i Windows
Windows Plug and Play hittar och läser in enhetsdrivrutiner baserat på en enhetsidentifierare som tillhandahålls av enhetens uppräknare. Uppräknare är busschaufförer som vet hur man extraherar identifieringsinformation från enheten. Vissa bussar (till exempel PCI, SD och USB) har maskinvarudefinierade mekanismer för att utföra denna extraktion. För bussar som inte gör det (till exempel processorbussen eller en enkel kringutrustningsbuss) definierar ACPI identifieringsobjekt i namnområdet.
Windows ACPI-drivrutinen, Acpi.sys, monterar värdena som finns i dessa objekt i olika enhetsidentifierarsträngar som kan identifiera en enhet specifikt, eller allmänt, beroende på drivrutinens behov. Några av de strängmönster som skapats för att identifiera ACPI-uppräknade enheter är:
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
Du kan se de enhetsidentifierare som Windows skapar för din enhet genom att öppna Enhetshanteraren och granska egenskaperna maskinvaru-ID och kompatibla ID: n för den uppräknade enheten. Var och en av dessa strängar är tillgänglig för att anges i en INF-fil för att identifiera drivrutinen som ska läsas in för enheten. Ordningen för INF-matchning är från den mest specifika maskinvaruidentifieraren (mest föredragen drivrutin) till den minst specifika identifieraren (minst föredragen drivrutin), så att drivrutiner som vet mer om enhetens specifika funktioner kan ersätta dem som är mindre specifika (och därför endast stöder en delmängd av enhetsfunktionerna).
Enhetsidentifierare ska endast användas för INF-matchning och bör aldrig parsas eller bearbetas av enhetsdrivrutinen. Om enhetsdrivrutinen behöver identifiera den specifika maskinvara som den lästes in för är den rekommenderade metoden att ange lämpliga registernycklar för INF-filen vid installationen. Drivrutinen kan sedan komma åt dessa nycklar under initialiseringen för att hämta den nödvändiga informationen.
Enhetsidentifiering i ACPI
Maskinvaru-ID (_HID)
Minimikravet för att identifiera en enhet i ACPI är objektet Maskinvaru-ID (_HID). _HID returnerar en sträng med formatet "ABC[D]xxxx", där "ABC[D]" är en sträng på 3 tecken eller 4 tecken som identifierar enhetens tillverkare ("leverantörs-ID") och xxxx är ett hexadecimalt nummer som identifierar den specifika enhet som tillverkas av leverantören ("Enhets-ID"). Leverantörs-ID:t måste vara unika i hela branschen. Microsoft allokerar dessa strängar för att säkerställa att de är unika. Leverantörs-ID:t kan hämtas från Plug and Play-ID – PNPID-begäran.
ACPI 5.0 stöder också användning av PCI-tilldelade leverantörs-ID:er i _HID och andra identifieringsobjekt, så du kanske inte behöver hämta ett leverantörs-ID från Microsoft. Mer information om maskinvaruidentifieringskrav finns i avsnitt 6.1.5, "_HID (maskinvaru-ID)", i ACPI 5.0-specifikationen.
Kompatibelt ID (_CID)
Microsoft har reserverat leverantörs-ID:t "PNP" för enheter som är kompatibla med inkorgsdrivrutiner som levereras med Windows. Windows definierar ett antal enhets-ID:n för användning med det här leverantörs-ID:t som kan användas för att läsa in drivrutinen som tillhandahålls av Windows för en enhet. Ett separat objekt, objektet Kompatibelt ID (_CID) används för att returnera dessa identifierare. Windows föredrar alltid maskinvaru-ID :er (returneras av _HID) framför kompatibla ID:er (returneras av _CID) i INF-matchning och drivrutinsval. Med den här inställningen kan drivrutinen som tillhandahålls av Windows behandlas som en standarddrivrutin om en enhetsspecifik drivrutin som tillhandahålls av leverantören inte är tillgänglig. De kompatibla ID:na i följande tabell har nyligen skapats för användning med SoC-plattformar.
| Kompatibel identifierare | Beskrivning |
|---|---|
| PNP0C40 | Windows-kompatibel knappmatris |
| PNP0C50 | HID-over-I2C-kompatibel enhet |
| PNP0C60 | Konvertibel skärmsensorenhet för bärbar dator |
| PNP0C70 | Dockningssensor |
| PNP0D10 | XHCI-kompatibel USB-styrenhet med standardfelsökning |
| PNP0D15 | XHCI-kompatibel USB-styrenhet utan standardfelsökning |
| PNP0D20 | EHCI-kompatibel USB-styrenhet utan standardfelsökning |
| PNP0D25 | EHCI-kompatibel USB-styrenhet med standardfelsökning |
| PNP0D40 | SDA-standardkompatibel SD-värdstyrenhet |
| PNP0D80 | Windows-kompatibel systemstyrenhet för energisparfunktioner |
Undersystem-ID (_SUB), maskinvarurevision (_HRV) och klass (_CLS)
ACPI 5.0 definierar _SUB, _HRV och _CLS objekt som kan användas tillsammans med _HID för att skapa identifierare som mer unikt identifierar en specifik version, integrering eller maskinvarurevision av en enhet, eller för att ange medlemskap i en PCI-definierad enhetsklass. Dessa objekt är vanligtvis valfria, men kan krävas av vissa enhetsklasser i Windows. Mer information om dessa objekt finns i avsnitt 6.1, "Enhetsidentifieringsobjekt" i ACPI 5.0-specifikationen.
För servicebarhet finns det ett krav för Windows Hardware Certification Kit (HCK) att enhets-ID:n i OEM-system är "fyrdelade" ID:n. De fyra delarna är leverantörs-ID, enhets-ID, undersystemleverantörs-ID (OEM) och undersystemets (OEM) enhets-ID. Därför krävs objektet undersystem-ID (_SUB) för OEM-plattformar.
Device-Specific-metoden (_DSM)
Metoden _DSM definieras i avsnitt 9.14.1, "_DSM (enhetsspecifik metod)", i ACPI 5.0-specifikationen. Den här metoden tillhandahåller enskilda, enhetsspecifika data- och kontrollfunktioner som kan anropas av en enhetsdrivrutin utan att det står i konflikt med andra sådana enhetsspecifika metoder. _DSM för en viss enhets- eller enhetsklass definierar ett UUID (GUID) som garanterat inte krockar med andra UUID:er. För varje UUID finns det en uppsättning definierade funktioner som _DSM-metoden kan implementera för att tillhandahålla data eller för att utföra kontrollfunktioner för drivrutinen. Klassspecifika data- och dataformat tillhandahålls i separata enhetsklassspecifika specifikationer och beskrivs även i ACPI-Device-Specific-metoder.
Adress (_ADR) och unikt ID (_UID)
Det finns ytterligare tre krav för enhetsidentifiering:
- För enheter som ansluter till en maskinvaruuppräkningsbar överordnad buss (till exempel SDIO, USB HSIC), men som har plattformsspecifika funktioner eller kontroller (till exempel sidobandström eller aktiveringsavbrott), används inte _HID. I stället skapas enhetsidentifieraren av den överordnade bussdrivrutinen (som diskuterats tidigare). I det här fallet måste dock adressobjektet (_ADR) finnas i ACPI-namnområdet för enheten. Med det här objektet kan operativsystemet associera den bussuppräknade enheten med dess ACPI-beskrivna funktioner eller kontroller.
- På plattformar där flera instanser av ett visst IP-block används, så att varje block har samma enhetsidentifieringsobjekt, är objektet Unikt identifierare (_UID) nödvändigt för att operativsystemet ska kunna skilja mellan block.
- Inga två enheter i ett visst namnområdesomfång kan ha samma namn.
Enhetskonfigurationsobjekt
För varje enhet som identifieras i namnområdet måste systemresurserna (minnesadresser, avbrott och så vidare) som förbrukas av enheten också rapporteras av objektet Aktuella resursinställningar (_CRS). Rapportering av flera möjliga resurskonfigurationer (_PRS) och kontroller för att ändra en enhets resurskonfiguration (_SRS) stöds men är valfria.
Nytt för SoC-plattformar är GPIO- och SPB-resurser (Simple Peripheral Bus) som en enhet kan använda. Mer information finns i Allmän användning I/O (GPIO) och Simple Peripheral Bus (SPB).
Nytt för SoC-plattformar är också en generell fast DMA-beskrivning. FixedDMA-beskrivningen stöder delning av DMA-styrmaskinvara av ett antal systemenheter. DMA-resurserna (begärandelinje och kanalsregister) som har allokerats statiskt till en viss systemenhet visas i FixedDMA-beskrivningen. Mer information finns i avsnitt 19.5.49, "FixedDMA (DMA Resource Descriptor Macro)", i ACPI 5.0-specifikationen.
Ändringar i enhetsstatus
ACPI-uppräknade enheter kan inaktiveras eller tas bort av olika skäl. Objektet Status (_STA) tillhandahålls för att aktivera sådana statusändringar som ska kommuniceras till operativsystemet. En beskrivning av _STA finns i avsnitt 6.3.7 i ACPI 5.0-specifikationen. Windows använder _STA för att avgöra om enheten ska räknas upp, visas som inaktiverad eller inte synlig för användaren. Den här styrningen i den inbyggda programvaran är användbar för många tillämpningar, inklusive dockning och växling från USB OTG-värd till funktion.
Dessutom tillhandahåller ACPI en meddelandemekanism som ASL kan använda för att meddela drivrutiner för händelser på plattformen, till exempel en enhet som tas bort som en del av en docka. När statusen för en ACPI-enhet ändras måste den inbyggda programvaran i allmänhet utföra ett meddelande om "enhetskontroll" eller "busskontroll" för att windows ska räkna upp enheten igen och omvärdera dess _STA. Information om ACPI-meddelanden finns i avsnitt 5.6.6, "Meddelanden om enhetsobjekt" i ACPI 5.0-specifikationen.
Aktivera/inaktivera
Som en del av Windows Plug and Play måste drivrutinerna kunna aktiveras dynamiskt och inaktiveras av användaren eller systemet (till exempel för att uppdatera en drivrutin).
On-SoC-enheter som är integrerade i SoC-kretsen och kan inte tas bort. Drivrutiner för de flesta enheter inom SoC kan undantas från kraven för att aktivera och inaktivera. För de drivrutiner som inte är undantagna finns det drivrutinsgränssnitt som anger att drivrutinen stöder ordnad borttagning. Mer information finns i dokumentet "Reduce PNP Requirements for SoC Drivers" (Minska PNP-kraven för SoC-drivrutiner) på Webbplatsen Microsoft Connect.
Om en drivrutin stöder ordnad borttagning och enhetens maskinvara kan inaktiveras (dvs. enheten kan konfigureras för att sluta komma åt dess tilldelade resurser) kan ACPI-namnområdesnoden för enheten inkludera objektet Inaktivera (_DIS). Den här metoden utvärderas av operativsystemet när drivrutinen tas bort. Användning av _DIS har följande ytterligare krav:
- _STA måste rensa biten "aktiverad och avkoda dess resurser" när enheten är inaktiverad.
- Enheten måste ange objektet Ange resursinställningar (_SRS) för att återaktivera enhetens maskinvara och ange ovanstående bit i _STA.
Mer information finns i avsnitten 6.2.3 (_DIS), 6.2.15 (_SRS) och 6.3.7 (_STA) i ACPI 5.0-specifikationen.
Enhetsberoende
Vanligtvis finns det maskinvaruberoenden mellan enheter på en viss plattform. Windows kräver att alla sådana beroenden beskrivs så att det kan säkerställa att alla enheter fungerar korrekt när saker och ting ändras dynamiskt i systemet (enhetens ström tas bort, drivrutiner stoppas och startas och så vidare). I ACPI beskrivs beroenden mellan enheter på följande sätt:
Namnområdeshierarki. Alla enheter som är en underordnad enhet (listade som en enhet i namnområdet för en annan enhet) är beroende av den överordnade enheten. En USB HSIC-enhet är till exempel beroende av den port (överordnad) och styrenhet (morförälder) som den är ansluten till. På samma sätt är en GPU-enhet som anges i namnområdet för en MMU-enhet (systemminneshanteringsenhet) beroende av MMU-enheten.
Resursanslutningar. Enheter som är anslutna till GPIO- eller SPB-styrenheter är beroende av dessa styrenheter. Den här typen av beroende beskrivs genom att anslutningsresurser inkluderas i enhetens _CRS.
OpRegion-beroenden. För ASL-kontrollmetoder som använder OpRegions för att utföra I/O är beroenden inte implicit kända av operativsystemet eftersom de endast bestäms under kontrollmetodens utvärdering. Det här problemet gäller för GeneralPurposeIO och GenericSerialBus OpRegions där Plug and Play-drivrutiner ger åtkomst till regionen. För att åtgärda det här problemet definierar ACPI objektet OpRegion Dependency (_DEP). _DEP bör användas i alla enhetsnamnområden där en opregion (HW-resurs) refereras till av en kontrollmetod, och varken 1 eller 2 ovan gäller redan för den refererade OpRegion-anslutningsresursen. Mer information finns i avsnitt 6.5.8, "_DEP (Beroenden för åtgärdsregion)", i ACPI 5.0-specifikationen.
Det kan också finnas programvaruberoenden mellan enhetsdrivrutiner. Dessa beroenden måste också beskrivas.
Mer information finns i följande resurser:
Information om beroenden för drivrutinsbelastningsordning finns i Ange drivrutinsbelastningsordning.
För maktrelationers beroenden, se:
IoInvalidateDeviceRelations (För att utlösa etablering av strömrelationer, anropa rutinen IoInvalidateDeviceRelations med DEVICE_RELATION_TYPE enumvärdet PowerRelations.)