Wejścia/wyjścia ogólnego przeznaczenia (GPIO)

System na układach zintegrowanych SoC (SoC) intensywnie wykorzystuje wyprowadzenia we/wy ogólnego przeznaczenia (GPIO). W przypadku platform opartych na soC system Windows definiuje ogólną abstrakcję sprzętu GPIO, a ta abstrakcja wymaga obsługi z przestrzeni nazw Advanced Configuration and Power Interface (ACPI).

Abstrakcja GPIO jest obsługiwana przez definicje specyfikacji ACPI 5.0 wymienione w tym artykule.

Aby sprawdzić, czy kontroler GPIO spełnia wszystkie wymagania dotyczące platformy systemu Windows, zobacz Lista kontrolna wymagań kontrolera GPIO.

Urządzenia kontrolera GPIO

System Windows obsługuje kontrolery GPIO. Kontrolery GPIO zapewniają różne funkcje dla urządzeń peryferyjnych, w tym przerwań, sygnałów wejściowych i sygnałów wyjściowych. Funkcje gpIO są modelowane jako urządzenie kontrolera GPIO w przestrzeni nazw. Rozszerzenie struktury GPIO (GpioClx) modeluje urządzenie kontrolera GPIO jako podzielone na kilka banków pinów. Każdy bank pinów ma 64 lub mniej konfigurowalnych pinów. Banki w kontrolerze GPIO są uporządkowane zgodnie z pozycją wyprowadzeń w przestrzeni pinów GPIO względnej do kontrolera. Na przykład, bank 0 zawiera piny 0-31 na kontrolerze, bank 1 zawiera piny 32-63, itd. Wszystkie banki mają taką samą liczbę pinów, z wyjątkiem ostatniego banku, który może mieć mniej. Banki są istotne dla oprogramowania układowego ACPI, ponieważ oprogramowanie układowe musi zgłosić mapowanie zasobów przerwania systemu do banków, zgodnie z opisem poniżej w sekcji Obiekty przestrzeni nazw GPIO.

Każdy pin w banku ma zestaw parametrów (na przykład dane wyjściowe, przerwanie czułe na poziom, eliminacja drgań wejściowych itd.), które opisują sposób konfigurowania pinu.

Kontrolery GPIO i przerwania typu ActiveBoth

Funkcją niektórych kontrolerów GPIO jest możliwość generowania przerwań na obu zboczach sygnału (narastającego, czyli ActiveHigh, oraz opadającego, czyli ActiveLow). Jest to przydatne w różnych aplikacjach, w tym w interfejsie przycisku, gdzie zdarzenia naciśnięcia przycisku (jedna krawędź) i zdarzenia zwolnienia przycisku (przeciwległe krawędzie) mają znaczenie. Ta funkcja jest nazywana "ActiveBoth".

Logicznie, sygnały ActiveBoth mają zarówno stan zaznaczony, jak i niezaznaczony, niezależnie od tego, czy są to chwilowe asercje (na przykład przyciski), czy nieokreślone długie asercje (na przykład włożenie wtyczki słuchawkowej). Wykrywanie krawędzi dla przerwań ActiveBoth może być zaimplementowane na sprzęcie kontrolera GPIO (sprzęt ActiveBoth) lub emulowane w oprogramowaniu sterowników GPIO (emulowane ActiveBoth). System Windows wymaga, aby kontrolery GPIO, które implementują ActiveBoth, używały emulowanego ActiveBoth. Jest to wymagane w celu zapewnienia niezawodnej obsługi podwójnych przerwań dla wszystkich scenariuszy. W przypadku emulacji ActiveBoth obowiązują następujące wymagania sprzętowe:

1. Kontrolery GPIO, które obsługują przerwania ActiveBoth, muszą obsługiwać przerwania w trybie poziomym i muszą obsługiwać ponowne programowanie polaryzacji przerwań dynamicznie w czasie wykonywania.

2. Aby zminimalizować ryzyko błędów we/wy, system Windows preferuje użycie kontrolerów GPIO z mapowaną pamięcią zamiast kontrolerów GPIO połączonych za pomocą SPB. W rzeczywistości w przypadku urządzenia tablicy przycisków systemu Windows (PNP0C40) wymagane jest, aby przerwania GPIO typu ActiveBoth dla tego urządzenia łączyły się z kontrolerem GPIO mapowanym w pamięci, a nie z połączonym z SPB. Aby określić, które przerwania przycisku muszą być ustawione jako ActiveBoth, zobacz sekcję Urządzenia przycisków w temacie Inne obiekty przestrzeni nazw ACPI.

3. Aby ustanowić deterministyczny stan początkowy dla sygnałów przerwania typu ActiveBoth, stos urządzeń GPIO systemu Windows gwarantuje, że pierwsze przerwanie wygenerowane po połączeniu przez sterownik będzie zawsze odpowiadać stanowi asertywnemu sygnału. W dalszej części stosu przyjęto założenie, że asercyjny stan wszystkich linii przerwań ActiveBoth jest domyślnie niski poziom logiki (krawędź ActiveLow). Jeśli tak nie jest w przypadku platformy, możesz zastąpić wartość domyślną, włączając kontroler GPIO Device-Specific Method (_DSM) w przestrzeni nazw kontrolera. Aby uzyskać więcej informacji na temat tej metody, zobacz GpIO Controller Device-Specific Method (_DSM).

Trzecie wymaganie na powyższej liście oznacza, że sterownik urządzenia korzystającego z ActiveBoth może otrzymać przerwanie natychmiast po zainicjowaniu (po nawiązaniu połączenia z przerwaniem), jeśli sygnał przy wyprowadzeniu GPIO znajduje się w stanie aktywnym w tym czasie. Jest to możliwe, a nawet prawdopodobne dla niektórych urządzeń (na przykład słuchawek) i musi być obsługiwane w sterowniku.

Aby obsługiwać emulowaną funkcję ActiveBoth, kontroler GPIO musi włączyć emulację ActiveBoth ("wybrać") przez zaimplementowanie funkcji wywołania zwrotnego CLIENT_ReconfigureInterrupt oraz przez ustawienie flagi EmulateActiveBoth w podstawowej strukturze informacji, którą funkcja wywołania zwrotnego sterownika CLIENT_QueryControllerBasicInformation dostarcza do GpioClx. Aby uzyskać więcej informacji, sprawdź General-Purpose I/O (GPIO) sterowniki.

Obiekty przestrzeni nazw GPIO

Kontrolery GPIO i urządzenia peryferyjne, które się z nimi łączą, są wyliczane przez ACPI. Połączenie między nimi jest opisane przy użyciu deskryptorów zasobów połączenia GPIO. Aby uzyskać więcej informacji, zobacz sekcję 6.4.3.8, "Deskryptory połączeń" specyfikacji ACPI 5.0.

Obiekty identyfikacji i konfiguracji urządzenia

Przestrzeń nazw ACPI urządzenia kontrolera GPIO obejmuje następujące elementy:

• Obiekt zgodny ze specyfikacją ACPI (_HID) przypisany przez dostawcę.
• Zestaw skonsumowanych zasobów obiektu _CRS.
• Unikatowy obiekt identyfikatora (_UID), jeśli istnieje więcej niż jedno wystąpienie kontrolera GPIO w przestrzeni nazw (czyli dwa lub więcej węzłów przestrzeni nazw, które mają te same obiekty identyfikacji urządzenia).

_CRS kontrolera GPIO zawiera wszystkie zasoby (przestrzeń adresową rejestrów, przerwania systemowe itd.) zużywane przez wszystkie banki kontrolera GPIO. Mapowanie zasobów przerwań do banków jest reprezentowane w kolejności, w której zasoby przerwań są wymienione w _CRS — czyli pierwsze przerwanie wymienione jest przypisane do banku 0, kolejne przerwanie wymienione jest przypisane do banku 1 i tak dalej. Banki mogą udostępniać zasoby przerwania, w tym przypadku przerwanie jest wyświetlane raz dla każdego banku połączonego z nim, w porządku bankowym i jest skonfigurowane jako Udostępnione.

Deskryptory zasobów połączenia gpIO

Relacja między urządzeniami peryferyjnymi a wyprowadzeniami GPIO, z którymi są połączone, jest opisana w systemie operacyjnym przez deskryptory zasobów połączenia GPIO. Te deskryptory zasobów mogą definiować dwa typy połączeń GPIO: połączenia przerwania GPIO i połączenia we/wy gpIO. Urządzenia peryferyjne obejmują deskryptory połączeń GPIO w ich _CRS dla wszystkich we/wy GPIO i wyprowadzeń przerwań podłączonych. Jeśli połączone przerwanie może wznowić działanie (może obudzić system ze stanu bezczynności o niskim zużyciu energii), należy je skonfigurować jako ExclusiveAndWake lub SharedAndWake. Aby uzyskać więcej informacji, zobacz Zarządzanie energią urządzeń.

Deskryptory są zdefiniowane w sekcji 6.4.3.8.1, "GPIO Connection Descriptor" ze specyfikacji ACPI 5.0. Makra szablonu zasobu ASL dla tych deskryptorów są opisane w sekcji 19.5.53, "GpioInt (Makro deskryptora zasobu przerwania GPIO)" specyfikacji ACPI 5.0.

Zdarzenia ACPI sygnalizowane przez gpIO

ACPI definiuje model zdarzeń platformy, który umożliwia zasygnalizowanie i przekazywanie zdarzeń sprzętowych na platformie do sterownika ACPI. System Windows udostępnia usługę powiadomień służącą do przekazywania zdarzeń platformy do sterowników urządzeń. Wiele sterowników skrzynki odbiorczej polega na tej usłudze, aby zapewnić obsługę urządzeń zdefiniowanych przez ACPI, takich jak przycisk zasilania metody sterowania, urządzenie LID, bateria metody sterowania, strefa cieplna itd. Aby uzyskać więcej informacji na temat powiadomień, zobacz sekcję 5.6.5, "GPIO-Signaled zdarzenia ACPI" specyfikacji ACPI.

W przypadku platform SoC przerwania GPIO są używane do sygnalizowania zdarzeń platformy. Każde urządzenie przestrzeni nazw ("urządzenie źródła zdarzeń ACPI"), które sygnalizuje zdarzenia do sterownika przy użyciu operatora powiadamiania ASL, wymaga następujących elementów:

• Węzeł nazw w przestrzeni kontrolera GPIO, z którym połączony jest sygnał zdarzenia ACPI, musi zawierać zasób typu GpioInt dla tego pinu w obiekcie Informacje o Zdarzeniach ACPI (_AEI) (zobacz sekcję 2.4.2.3.1, "Obiekt Informacje o Zdarzeniach ACPI (_AEI)", poniżej). Zasób GpioInt musi być skonfigurowany jako nieudostępny (wyłączny).

• Węzeł kontrolera musi również zawierać metodę sterowania Edge (_Exx), Level (_Lxx) lub Event (_EVT) dla każdego pinu wskazanego w obiekcie _AEI.

Sterownik ACPI obsługuje wymienione przerwanie GPIO i ocenia metodę kontroli Edge, Level lub Event. Metoda sterowania uspokaja zdarzenie sprzętowe w razie potrzeby i wykonuje wymagany operator Notify na węźle przestrzeni nazw urządzenia źródła zdarzeń. System Windows następnie wysyła powiadomienie do sterownika urządzenia. Za pomocą tego samego zasobu GpioInt można zasygnalizować wiele zdarzeń, jeśli metoda kontroli zdarzeń może wysyłać zapytania dotyczące sprzętu w celu określenia, które zdarzenie miało miejsce. Następnie metoda musi powiadomić odpowiednie urządzenie o prawidłowym kodzie powiadomienia.

Obiekt informacji o zdarzeniach ACPI (_AEI) Jak wspomniano wcześniej, przestrzeń nazw kontrolera GPIO musi zawierać obiekt _AEI w celu obsługi zdarzeń ACPI. Obiekt _AEI (patrz sekcja 5.6.5.2 w specyfikacji ACPI 5.0) zwraca bufor szablonu zasobu zawierający tylko deskryptory GpioInt sygnalizujące zdarzenia ACPI za pośrednictwem tego kontrolera GPIO. Każdy deskryptor odpowiada jednemu urządzeniu źródła zdarzeń ACPI i jest dedykowany dla tego urządzenia (nieudostępnianego między urządzeniami).

OgólnePurposeIO operation regions (OpRegions)

Kontrolery GPIO są często używane przez oprogramowanie układowe platformy do obsługi dowolnej liczby funkcji sprzętowych platformy, takich jak sterowanie zasilaniem i zegarami lub ustawianie trybów na urządzeniach. Aby wspierać korzystanie z we/wy GPIO z metod sterowania ASL, ACPI 5.0 definiuje nowy typ OpRegion, "GeneralPurposeIO".

GeneralPurposeIO OpRegions (patrz sekcja 5.5.2.4.4 specyfikacji ACPI 5.0) są deklarowane w zakresie przestrzeni nazw dla urządzenia kontrolera GPIO, którego sterownik będzie obsługiwać I/O. Deklaracje pól GeneralPurposeIO (patrz sekcja 5.5.2.4.4.1 specyfikacji ACPI 5.0) przypisują nazwy do pinów GPIO, które mają być dostępne w obszarze OpRegion GeneralPurposeIO. Zasoby połączeń GpioIO (patrz sekcja 19.5.53 specyfikacji ACPI 5.0) są używane w deklaracji Field w celu określenia numer(ów) pinu i konfiguracji dla danego odniesienia Field. Całkowita liczba nazwanych bitów pól po deskryptorze połączenia musi być równa liczbie wyprowadzeń wymienionych w deskryptorze.

Pola w regionie OpRegion można zadeklarować w dowolnym miejscu w przestrzeni nazw i uzyskiwać do nich dostęp z dowolnej metody w przestrzeni nazw. Kierunek dostępu do regionu GeneralPurposeIO OpRegion jest określany przez pierwszy dostęp (czyli odczyt lub zapis) i nie może być zmieniony.

Ponieważ dostęp do regionu OpRegion jest zapewniany przez sterownik urządzenia kontrolera GPIO ("OpRegion Handler"), metody muszą zadbać, aby nie uzyskać dostępu do regionu OpRegion, dopóki sterownik nie będzie dostępny. Kod ASL może śledzić stan programu obsługi OpRegion, uwzględniając metodę Region (_REG) w ramach urządzenia kontrolera GPIO (patrz sekcja 6.5.4 specyfikacji ACPI 5.0). Ponadto obiekt Zależności regionu OpRegion (_DEP) (zobacz sekcję 6.5.8 specyfikacji ACPI 5.0) może być używany w dowolnym urządzeniu, które ma metodę dostępu do pól GPIO OpRegion, jeśli jest to konieczne. Zobacz sekcję Zależności urządzeń w temacie Obiekty przestrzeni nazw zarządzania urządzeniami , aby zapoznać się z omówieniem, kiedy należy używać _DEP. Ważne jest, aby sterowniki nie zostały przypisane do zasobów we/wy gpIO, które są również przypisane do GeneralPurposeIO OpRegions. Regiony operacyjne są przeznaczone do wyłącznego używania metod kontroli ASL.