Udostępnij przez

Obiekty przestrzeni nazw zarządzania urządzeniami

Specyfikacja ACPI 5.0 definiuje kilka typów obiektów przestrzeni nazw, których można użyć do zarządzania urządzeniami. Na przykład obiekty identyfikacji urządzeń zawierają informacje identyfikacyjne dla urządzeń, które łączą się z magistralami, takimi jak I2C, a nie obsługują enumeracji sprzętowej urządzeń podrzędnych. Inne typy obiektów przestrzeni nazw mogą określać zasoby systemowe, opisywać zależności urządzeń i wskazywać, które urządzenia mogą być wyłączone.

Identyfikacja urządzenia w systemie Windows

Plug and Play systemu Windows wyszukuje i ładuje sterowniki urządzeń na podstawie identyfikatora urządzenia dostarczonego przez enumerator. Moduły wyliczające to moduły magistrali, które potrafią wyodrębnić informacje identyfikacyjne z urządzenia. Niektóre magistrale (takie jak PCI, SD i USB) mają zdefiniowane sprzętowo mechanizmy wyodrębniania. W przypadku magistrali, które nie są obsługiwane (takich jak magistrala procesora lub prosta magistrala peryferyjna), ACPI definiuje obiekty identyfikacyjne w przestrzeni nazw.

Sterownik Windows ACPI, Acpi.sys, zestawuje wartości znalezione w tych obiektach w różnych ciągach identyfikatora urządzenia, które mogą identyfikować urządzenie w szczególności lub ogólnie, w zależności od potrzeb sterownika. Niektóre wzorce znaków utworzone w celu zidentyfikowania wyliczonych urządzeń ACPI to:

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

Identyfikatory urządzeń tworzone przez system Windows dla Twojego urządzenia można wyświetlić, otwierając Menedżera urządzeń i sprawdzając właściwości identyfikatory sprzętu i zgodne identyfikatory wyliczonego urządzenia. Każdy z tych ciągów jest dostępny do określenia w pliku INF w celu zidentyfikowania sterownika do załadowania dla urządzenia. Kolejność dopasowywania INF pochodzi od najbardziej określonego identyfikatora sprzętu (najbardziej preferowanego sterownika) do najmniej określonego identyfikatora (najmniej preferowanego sterownika), aby sterowniki, które wiedzą więcej o określonych funkcjach urządzenia, mogą zastąpić te, które są mniej specyficzne (i w związku z tym obsługiwać tylko podzestaw funkcji urządzenia).

Identyfikatory urządzeń powinny być używane tylko do dopasowywania INF i nigdy nie powinny być analizowane ani przetwarzane przez sterownik urządzenia. Jeśli sterownik urządzenia musi zidentyfikować określony sprzęt, dla którego został załadowany, zalecaną metodą jest ustawienie odpowiednich kluczy rejestru w czasie instalacji pliku INF. Sterownik może następnie uzyskać dostęp do tych kluczy podczas inicjowania, aby uzyskać wymagane informacje.

Identyfikacja urządzenia w programie ACPI

Identyfikator sprzętu (_HID)

Minimalnym wymaganiem do identyfikacji urządzenia w ACPI jest obiekt Identyfikator sprzętu (_HID). _HID zwraca ciąg o formacie "ABC[D]xxxx", gdzie "ABC[D]" jest ciągiem 3-znakowym lub 4-znakowym, który identyfikuje producenta urządzenia (identyfikator dostawcy), a xxxx jest szesnastkowym numerem identyfikującym określone urządzenie produkowane przez tego dostawcę (identyfikator urządzenia). Identyfikatory dostawców muszą być unikatowe w całej branży. Firma Microsoft przydziela te ciągi, aby upewnić się, że są one unikatowe. Identyfikatory dostawców można uzyskać z Plug and Play ID - PNPID Request.

Interfejs ACPI 5.0 obsługuje również używanie identyfikatorów sprzedawców przypisanych do PCI w _HID i innych obiektach identyfikacyjnych, więc może nie być konieczne uzyskanie identyfikatora sprzedawcy od firmy Microsoft. Aby uzyskać więcej informacji na temat wymagań dotyczących identyfikacji sprzętu, zobacz sekcję 6.1.5, "_HID (identyfikator sprzętu)" specyfikacji ACPI 5.0.

Zgodny identyfikator (_CID)

Firma Microsoft zarezerwowała identyfikator dostawcy "PNP" dla urządzeń zgodnych z sterownikami skrzynki odbiorczej dostarczanymi z systemem Windows. System Windows definiuje wiele identyfikatorów urządzeń do użycia z tym identyfikatorem dostawcy, których można użyć do załadowania sterownika dostarczonego przez system Windows dla urządzenia. Oddzielny obiekt, obiekt zgodnego identyfikatora (_CID), służy do zwrócenia tych identyfikatorów. System Windows zawsze preferuje identyfikatory sprzętu (zwracane przez _HID) względem zgodnych identyfikatorów (zwracanych przez _CID) w dopasowywaniu INF i wybieraniu sterowników. Ta preferencja umożliwia traktowanie sterownika dostarczonego przez system Windows jako sterownika domyślnego, jeśli sterownik specyficzny dla dostawcy jest niedostępny. Identyfikatory zgodne przedstawione w poniższej tabeli są nowo utworzone do użycia na platformach SoC.

Identyfikator zgodności Opis
PNP0C40 Tablica przycisków zgodna z systemem Windows
PNP0C50 Urządzenie zgodne ze standardem HID-over-I2C
PNP0C60 Czujnik wyświetlacza konwertowalnego laptopa
PNP0C70 Czujnik dokujący
PNP0D10 Kontroler USB zgodny ze standardem XHCI z obsługą debugowania.
PNP0D15 Kontroler USB zgodny z XHCI bez standardowego debugowania
PNP0D20 Kontroler USB zgodny ze standardem EHCI bez standardowego debugowania
PNP0D25 Kontroler USB zgodny ze standardem EHCI z obsługą standardowej funkcji debugowania
PNP0D40 Zgodny ze standardem SDA kontroler hosta SD
PNP0D80 Kontroler zarządzania energią zgodną z systemem Windows

Identyfikator podsystemu (_SUB), rewizja sprzętowa (_HRV) i klasa (_CLS)

AcpI 5.0 definiuje _SUB, _HRV i _CLS obiektów, których można używać wraz z _HID do tworzenia identyfikatorów, które bardziej jednoznacznie identyfikują określoną wersję, integrację lub poprawkę sprzętu urządzenia lub wskazać członkostwo w klasie urządzenia zdefiniowanej przez PCI. Te obiekty są zazwyczaj opcjonalne, ale mogą być wymagane przez niektóre klasy urządzeń w systemie Windows. Aby uzyskać więcej informacji na temat tych obiektów, zobacz sekcję 6.1, "Obiekty identyfikacji urządzeń" specyfikacji ACPI 5.0.

Dla łatwości serwisowania, istnieje wymaganie zestawu certyfikacji sprzętu systemu Windows (HCK), aby identyfikatory urządzeń w systemach OEM były identyfikatorami czteroczęściowymi. Cztery części to identyfikator dostawcy, identyfikator urządzenia, identyfikator dostawcy podsystemu (OEM) i identyfikator urządzenia podsystemu (OEM). W związku z tym obiekt Identyfikator podsystemu (_SUB) jest wymagany dla platform OEM.

Device-Specific: metoda (_DSM)

Metoda _DSM jest zdefiniowana w sekcji 9.14.1, "_DSM (metoda specyficzna dla urządzenia)" specyfikacji ACPI 5.0. Ta metoda zapewnia poszczególne funkcje danych i sterowania specyficzne dla urządzenia, które mogą być wywoływane przez sterownik urządzenia bez konfliktu z innymi takimi metodami specyficznymi dla urządzenia. _DSM dla określonego urządzenia lub klasy urządzenia definiuje identyfikator UUID (GUID), który gwarantuje, że nie będzie zderzać się z innymi identyfikatorami UUID. Dla każdego identyfikatora UUID istnieje zestaw zdefiniowanych funkcji, które metoda _DSM może zaimplementować w celu zapewnienia danych lub wykonywania funkcji kontrolnych dla sterownika. Dane specyficzne dla klasy i formaty danych są udostępniane w osobnych specyfikacjach dotyczących klasy urządzenia, a także są również omówione w ACPI Device-Specific Methods (Metody Device-Specific ACPI).

Adres (_ADR) i unikatowy identyfikator (_UID)

Istnieją trzy dodatkowe wymagania dotyczące identyfikacji urządzenia:

  • W przypadku urządzeń, które łączą się ze sprzętową wyliczalną magistralą nadrzędną (na przykład SDIO, USB HSIC), ale mają funkcje lub kontrolki specyficzne dla platformy (na przykład zasilanie boczne lub przerywanie budzenia), _HID nie jest używana. Zamiast tego identyfikator urządzenia jest tworzony przez sterownik magistrali nadrzędnej (jak wspomniano wcześniej). W takim przypadku jednak obiekt adresu (_ADR) musi znajdować się w przestrzeni nazw ACPI dla urządzenia. Ten obiekt umożliwia systemowi operacyjnemu skojarzenie urządzenia wyliczonego przez magistralę z funkcjami lub elementami sterującymi opisanymi przez ACPI.
  • Na platformach, na których jest używanych wiele wystąpień określonego bloku IP, aby każdy blok miał te same obiekty identyfikacji urządzeń, obiekt Unikatowy identyfikator (_UID) jest niezbędny do umożliwienia systemowi operacyjnemu rozróżnienia między blokami.
  • Żadne dwa urządzenia w określonym zakresie przestrzeni nazw nie mogą mieć takiej samej nazwy.

Obiekty konfiguracji urządzenia

Dla każdego urządzenia zidentyfikowanego w przestrzeni nazw zasoby systemowe (adresy pamięci, przerwania itd.) używane przez urządzenie muszą być również zgłaszane przez obiekt Bieżące ustawienia zasobów (_CRS). Raportowanie wielu możliwych konfiguracji zasobów (_PRS) i kontrolek zmiany konfiguracji zasobów urządzenia (_SRS) są obsługiwane, ale opcjonalne.

Nowością dla platform SoC są zasoby GPIO i proste zasoby szyny peryferyjnej (SPB), z których urządzenie może korzystać. Aby uzyskać więcej informacji, zobacz We/Wy ogólnego przeznaczenia (GPIO) i Simple Peripheral Bus (SPB).

Ponadto nowością dla platform SoC jest deskryptor stałego DMA ogólnego przeznaczenia. Deskryptor FixedDMA obsługuje udostępnianie sprzętu kontrolera DMA przez wiele urządzeń systemowych. Zasoby DMA (rejestry wierszy żądań i kanałów) statycznie przydzielone do określonego urządzenia systemowego są wymienione w deskryptorze FixedDMA. Aby uzyskać więcej informacji, zobacz sekcję 19.5.49, "FixedDMA (DmA Resource Descriptor Macro)" ze specyfikacji ACPI 5.0.

Zmiany stanu urządzenia

Wyliczone urządzenia ACPI można wyłączyć lub usunąć z różnych powodów. Obiekt Status (_STA) jest udostępniany w celu umożliwienia przekazywania takich zmian stanu do systemu operacyjnego. Opis _STA można znaleźć w sekcji 6.3.7 specyfikacji ACPI 5.0. System Windows używa _STA do określenia, czy urządzenie powinno być wyliczane, wyświetlane jako wyłączone lub niewidoczne dla użytkownika. Ta kontrola w oprogramowaniu układowym jest przydatna w wielu aplikacjach, w tym w przypadku stacji dokującej i przełączania z hosta do funkcji USB OTG.

Ponadto ACPI udostępnia mechanizm powiadomień, który ASL może używać do powiadamiania sterowników o zdarzeniach na platformie, takich jak usuwanie urządzenia w ramach doku. Ogólnie rzecz biorąc, gdy stan urządzenia ACPI zmieni się, oprogramowanie układowe musi wykonać "sprawdzanie urządzenia" lub "sprawdzanie magistrali", aby spowodować, że system Windows ponownie zidentyfikuje urządzenie i ponownie oceni jego _STA. Aby uzyskać informacje o powiadomieniach ACPI, zobacz sekcję 5.6.6, "Powiadomienia o obiektach urządzeń" specyfikacji ACPI 5.0.

Włączanie/wyłączanie

W ramach funkcji Plug and Play systemu Windows sterowniki muszą być dynamicznie włączone i wyłączone przez użytkownika lub przez system (na przykład w celu zaktualizowania sterownika).

Urządzenia On-SoC są zintegrowane z mikroukładem SoC i nie można ich usunąć. Sterowniki dla większości urządzeń w systemie SoC mogą być wykluczone z wymagań dotyczących włączania i wyłączania. W przypadku tych sterowników, które nie są zwolnione, istnieją interfejsy sterowników wskazujące, że sterownik obsługuje uporządkowane usuwanie. Aby uzyskać więcej informacji, zobacz dokument zatytułowany "Zmniejszenie wymagań PNP dla sterowników SoC" w witrynie internetowej programu Microsoft Connect.

Jeśli sterownik obsługuje uporządkowane usuwanie, a sprzęt urządzenia można wyłączyć (tj. urządzenie można skonfigurować tak, aby zatrzymać dostęp do przypisanych zasobów), wówczas węzeł przestrzeni nazw ACPI dla urządzenia może zawierać obiekt Disable (_DIS). Ta metoda będzie oceniana przez system operacyjny za każdym razem, gdy sterownik zostanie usunięty. Korzystanie z _DIS ma następujące dodatkowe wymagania:

  • _STA musi wyczyścić bit "włączony i dekodujący zasoby" za każdym razem, gdy urządzenie jest wyłączone.
  • Urządzenie musi podać obiekt Konfiguracja ustawień zasobów (_SRS) w celu ponownego włączenia sprzętu i ustawienia powyższego bitu w _STA.

Aby uzyskać więcej informacji, zobacz sekcje 6.2.3 (_DIS), 6.2.15 (_SRS) i 6.3.7 (_STA) specyfikacji ACPI 5.0.

Zależności urządzeń

Zazwyczaj istnieją zależności sprzętowe między urządzeniami na określonej platformie. System Windows wymaga opisania wszystkich takich zależności, aby zapewnić prawidłowe działanie wszystkich urządzeń w miarę dynamicznego zmieniania się elementów w systemie (zasilanie urządzenia jest usuwane, sterowniki są zatrzymywane i uruchamiane itd.). W programie ACPI zależności między urządzeniami są opisane w następujący sposób:

  1. Hierarchia przestrzeni nazw. Każde urządzenie podrzędne (wymienione jako urządzenie w przestrzeni nazw innego urządzenia) zależy od urządzenia głównego. Na przykład urządzenie HSIC USB jest zależne od portu (nadrzędnego) i kontrolera nadrzędnego, do którego jest podłączone. Podobnie urządzenie gpu wymienione w przestrzeni nazw urządzenia jednostki zarządzania pamięcią systemową (MMU) jest zależne od urządzenia MMU.

  2. Połączenia zasobów. Urządzenia podłączone do kontrolerów GPIO lub SPB są zależne od tych kontrolerów. Ten typ zależności jest opisany przez dołączenie zasobów połączenia w _CRS urządzenia.

  3. Zależności OpRegion W przypadku metod kontroli ASL, które używają regionów OpRegion do wykonywania operacji we/wy, zależności nie są niejawnie znane przez system operacyjny, ponieważ są one określane tylko podczas oceny metody sterowania. Ten problem dotyczy regionów GeneralPurposeIO i GenericSerialBus OpRegions, w których sterowniki Plug and Play zapewniają dostęp do regionu. Aby rozwiązać ten problem, ACPI definiuje obiekt Zależności OpRegionu (_DEP). _DEP należy użyć w dowolnej przestrzeni nazw urządzenia, w której metoda sterowania odwołuje się do zasobu OpRegionu (zasobu sprzętowego), a zasób połączenia dla wspomnianego OpRegionu nie spełnia już punktów 1 ani 2 powyżej. Aby uzyskać więcej informacji, zobacz sekcję 6.5.8", "_DEP (zależności regionu operacji)" specyfikacji ACPI 5.0.

Mogą również istnieć zależności oprogramowania między sterownikami urządzeń. Te zależności muszą być również opisane.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

  • Last updated on