Condividi tramite

GPIO (I/O per utilizzo generico)

  • Articolo

Il sistema in un circuito integrato Chip (SoC) usa ampiamente i pin di I/O (GPIO) per utilizzo generico. Per le piattaforme basate su SoC, Windows definisce un'astrazione generale per l'hardware GPIO e questa astrazione richiede il supporto dello spazio dei nomi Advanced Configuration and Power Interface (ACPI).

L'astrazione GPIO è supportata dalle definizioni di specifica ACPI 5.0 elencate in questo articolo.

Per verificare che il controller GPIO soddisfi tutti i requisiti della piattaforma Windows, vedere Elenco di controllo dei requisiti del controller GPIO.

Dispositivi controller GPIO

Windows supporta i controller GPIO. I controller GPIO offrono diverse funzioni per i dispositivi periferici, tra cui interruzioni, segnali di input e segnale di output. Le funzionalità GPIO vengono modellate come dispositivo controller GPIO nello spazio dei nomi. L'estensione del framework GPIO (GpioClx) modella il dispositivo controller GPIO come partizionato in alcune banche di pin. Ogni banca pin ha 64 o meno pin configurabili. Le banche in un controller GPIO vengono ordinate in relazione alla posizione dei pin all'interno dello spazio del pin GPIO relativo al controller. Ad esempio, la banca 0 contiene pin 0-31 sul controller, la banca 1 contiene pin 32-63 e così via. Tutte le banche hanno lo stesso numero di pin, ad eccezione dell'ultima banca, che potrebbe avere meno. Le banche sono significative per il firmware ACPI perché il firmware deve segnalare il mapping delle risorse di interruzione del sistema alle banche, come descritto nella sezione degli oggetti dello spazio dei nomi GPIO di seguito.

Ogni pin in una banca ha un set di parametri (ad esempio, interruzioni sensibili a livello, input de-rimbalzato e così via) che descrivono come configurare il pin.

Controller GPIO e interruzioni di ActiveBoth

Una funzionalità di alcuni controller GPIO è la possibilità di generare interruzioni su entrambi i bordi di un segnale (aumento o bordi ActiveHigh e caduta o bordi ActiveLow). Ciò è utile in diverse applicazioni, tra cui l'interfaccia del pulsante, in cui gli eventi di pressione del pulsante (un bordo) e di rilascio dei pulsanti (il bordo opposto) sono significativi. Questa funzionalità viene definita "ActiveBoth".

Logicamente, i segnali ActiveBoth hanno uno stato asserzionato e non inserito, indipendentemente dal fatto che siano asserzioni momentanee (ad esempio, pushbutton) o asserzioni a tempo indefinito (ad esempio, inserimenti jack cuffie). Il rilevamento perimetrale per gli interruzioni di ActiveBoth può essere implementato nell'hardware del controller GPIO (hardware ActiveBoth) o emulato nel software driver GPIO (emulato ActiveBoth). Windows richiede che i controller GPIO che implementano ActiveBoth debbano usare ActiveBoth emulati. Ciò è necessario per garantire una gestione affidabile degli interruzioni a doppio bordo per tutti gli scenari. Al supporto dell'emulazione ActiveBoth, si applicano i requisiti hardware seguenti:

  1. I controller GPIO che supportano gli interruzioni di ActiveBoth devono supportare gli interruzioni in modalità livello e devono supportare nuovamente la polarità dell'interruzione in modo dinamico in fase di esecuzione.

  2. Per ridurre al minimo il rischio di errori di I/O, Windows preferisce l'uso dei controller GPIO con mapping della memoria anziché dei controller GPIO connessi a SPB. Infatti, per il dispositivo Matrice pulsante Windows (PNP0C40), è necessario che l'interruzione di ActiveBoth GPIO per questo dispositivo si connetti a un controller GPIO mappato alla memoria e non a un controller SPB connesso. Per determinare quali interruzioni del pulsante devono essere ActiveBoth, vedere la sezione Dispositivi Button nell'argomento Altri oggetti dello spazio dei nomi ACPI .

  3. Per stabilire uno stato iniziale deterministico per i segnali di interruzione activeBoth, lo stack di dispositivi Windows GPIO garantisce che il primo interruzione generato dopo la connessione dell'interruzione da parte del driver sarà sempre per lo stato asserto del segnale. Lo stack presuppone inoltre che lo stato asserente di tutte le righe di interruzione ActiveBoth sia basso (il bordo ActiveLow) per impostazione predefinita. Se non si tratta del caso nella piattaforma, è possibile eseguire l'override del valore predefinito includendo il controller GPIO Device-Specific Metodo (_DSM) nello spazio dei nomi del controller. Per altre informazioni su questo metodo, vedere Il metodo Device-Specific controller GPIO (_DSM).

Il terzo requisito nell'elenco precedente implica che il driver per un dispositivo che usa ActiveBoth potrebbe ricevere un interruzione immediatamente dopo l'inizializzazione (connessione) all'interruzione, se il segnale nel pin GPIO si trova nello stato asserto in quel momento. Questo è possibile, e anche probabilmente per alcuni dispositivi (ad esempio, cuffie), e deve essere supportato nel driver.

Per supportare ActiveBoth emulato, il driver del controller GPIO deve abilitare l'emulazione activeBoth ("opt-in") implementando una funzione di callback CLIENT_ReconfigureInterrupt e impostando il flag EmulateActiveBoth nella struttura di informazioni di base fornita dalla funzione di callback CLIENT_QueryControllerBasicInformation del driver a GpioClx. Per altre informazioni, vedere Driver di I/O (GPIO) per utilizzo generico.

Oggetti spazio dei nomi GPIO

I controller GPIO e le periferiche che si connettono a loro, vengono enumerati da ACPI. La connessione tra di esse è descritta usando descrittori di risorse di connessione GPIO. Per altre informazioni, vedere la sezione 6.4.3.8, "Descrittori di connessione", della specifica ACPI 5.0.

Identificazione e configurazione dei dispositivi

Uno spazio dei nomi ACPI del dispositivo controller GPIO include quanto segue:

  • Oggetto HARDWARE (_HID) conforme al fornitore.
  • Insieme di risorse usate (_CRS).
  • Oggetto UNIQUE ID (_UID), se è presente più di un'istanza del controller GPIO nello spazio dei nomi , ovvero due o più nodi dello spazio dei nomi con gli stessi oggetti di identificazione del dispositivo.

La _CRS del controller GPIO contiene tutte le risorse (spazio indirizzi per registri, interruzioni di sistema e così via) usate da tutte le banche nel controller GPIO. Il mapping delle risorse da risorsa a banca viene rappresentato nell'ordine in cui le risorse di interruzione sono elencate nella _CRS, ovvero il primo interruzione elencato viene assegnato alla banca 0, quello successivo elencato viene assegnato alla banca 1 e così via. Le banche possono condividere le risorse di interruzione, nel qual caso l'interruzione viene elencata una volta per ogni banca connessa, nell'ordine bancario e viene configurata come condivisa.

Descrittori delle risorse di connessione GPIO

La relazione tra le periferiche e i pin GPIO a cui sono connessi è descritta al sistema operativo dai descrittori delle risorse di connessione GPIO. Questi descrittori di risorse possono definire due tipi di connessioni GPIO: connessioni di interruzione GPIO e connessioni I/O GPIO. Le periferiche includono descrittori di connessione GPIO nei relativi _CRS per tutti i pin di I/O GPIO e di interruzione connessi. Se un interruzione connessa è in grado di riattivare il sistema da uno stato di inattività a bassa potenza, deve essere configurato come ExclusiveAndWake o SharedAndWake. Per altre informazioni, vedere Gestione energia del dispositivo.

I descrittori sono definiti nella sezione 6.4.3.8.1, "GPIO Connection Descriptor", della specifica ACPI 5.0. Le macro del modello di risorse ASL per questi descrittori sono descritte nella sezione 19.5.53, "GpioInt (GPIO Interrupt Connection Resource Descriptor Macro)" della specifica ACPI 5.0.

Eventi ACPI segnalati da GPIO

ACPI definisce un modello di evento della piattaforma che consente di segnalare e comunicare gli eventi hardware nella piattaforma al driver ACPI. Windows fornisce un servizio di notifica per comunicare gli eventi della piattaforma ai driver di dispositivo. Molti driver in arrivo si basano su questo servizio per fornire supporto per i dispositivi definiti da ACPI, ad esempio Il pulsante di alimentazione del metodo di controllo, il dispositivo LID, la batteria del metodo di controllo, la zona termica e così via. Per altre informazioni sulle notifiche, vedere la sezione 5.6.5,"GPIO-Signaled ACPI Events", della specifica ACPI.

Per le piattaforme SoC, gli interruzioni GPIO vengono usati per segnalare gli eventi della piattaforma. Qualsiasi dispositivo dello spazio dei nomi ("origine eventi ACPI") che segnala gli eventi al driver usando l'operatore ASL Notify richiede quanto segue:

  • Il nodo dello spazio dei nomi del controller GPIO a cui è connesso il segnale di evento ACPI deve includere una risorsa GpioInt per tale pin nell'oggetto ACPI Event Information (_AEI) (vedere la sezione 2.4.2.3.1, "ACPI Event Information (_AEI) Object", di seguito. La risorsa GpioInt deve essere configurata come non condivisa (esclusiva).

  • Il nodo del controller deve contenere anche un metodo di controllo Edge (_Exx), Level (_Lxx) o Event (_EVT) per ogni pin elencato nell'oggetto _AEI.

Il driver ACPI gestisce l'interruzione GPIO elencata e valuta il metodo di controllo Edge, Level o Event per esso. Il metodo di controllo chiude l'evento hardware, se necessario ed esegue l'operatore Notify richiesto nel nodo dello spazio dei nomi del dispositivo dell'origine eventi. Windows invia quindi la notifica al driver del dispositivo. È possibile segnalare più eventi sulla stessa risorsa GpioInt se il metodo di controllo eventi può eseguire query sull'hardware per determinare quale evento si è verificato. Il metodo deve quindi inviare una notifica al dispositivo corretto con il codice di notifica corretto.

Oggetto ACPI Event Information (_AEI) Come accennato in precedenza, lo spazio dei nomi del controller GPIO deve contenere l'oggetto _AEI per supportare gli eventi ACPI. L'oggetto _AEI (vedere la sezione 5.6.5.2 nella specifica ACPI 5.0) restituisce un buffer modello di risorse contenente solo descrittori GpioInt che segnalano eventi ACPI tramite questo controller GPIO. Ogni descrittore corrisponde a un dispositivo di origine evento ACPI ed è dedicato a tale dispositivo (non condiviso tra i dispositivi).

Aree dell'operazione GeneralPurposeIO (OpRegions)

I controller GPIO vengono spesso usati dal firmware della piattaforma per supportare qualsiasi numero di funzionalità hardware della piattaforma, ad esempio il controllo dell'alimentazione e degli orologi o l'impostazione delle modalità nei dispositivi. Per supportare l'uso di I/O GPIO dai metodi di controllo ASL, ACPI 5.0 definisce un nuovo tipo OpRegion, "GeneralPurposeIO".

GeneralPurposeIO OpRegions (vedere la sezione 5.5.2.4.4 della specifica ACPI 5.0) vengono dichiarati all'interno dell'ambito dello spazio dei nomi del dispositivo controller GPIO il cui driver gestirà l'I/O. Dichiarazioni di campo GeneralPurposeIO (vedere la sezione 5.5.2.4.4.1 della specifica ACPI 5.0) assegnano nomi ai pin GPIO che devono essere accessibili all'interno di un'istanza GeneralePurposeIO OpRegion. Le risorse di connessione GpioIO (vedere la sezione 19.5.53 della specifica ACPI 5.0) vengono usate all'interno della dichiarazione Field per specificare i numeri di pin e la configurazione per un particolare riferimento al campo. Il numero totale di bit di campo denominati che seguono un descrittore di connessione deve corrispondere al numero di pin elencati nel descrittore.

I campi in un OpRegion possono essere dichiarati ovunque nello spazio dei nomi e accessibili da qualsiasi metodo nello spazio dei nomi. La direzione degli accessi a un oggetto GeneralPurposeIO OpRegion è determinata dal primo accesso (lettura o scrittura) e non può essere modificato.

Poiché l'accesso opRegion viene fornito dal driver del dispositivo del controller GPIO (il "Gestore opRegion"), i metodi devono prestare attenzione a non accedere a un opregion fino a quando non è disponibile il driver. Il codice ASL può tenere traccia dello stato del gestore OpRegion includendo un metodo Region (_REG) nel dispositivo controller GPIO (vedere la sezione 6.5.4 della specifica ACPI 5.0). Inoltre, l'oggetto OpRegion Dependencies (_DEP) (vedere la sezione 6.5.8 della specifica ACPI 5.0) può essere usato in qualsiasi dispositivo con un metodo che accede ai campi GPIO OpRegion, se necessario. Vedere la sezione Dipendenze dispositivo nell'argomento Oggetti dello spazio dei nomi Gestione dispositivi per una discussione su quando usare _DEP. È importante che i driver non vengano assegnati alle risorse di I/O GPIO assegnate anche a GeneralPurposeIO OpRegions. Le opregions sono per l'uso esclusivo dei metodi di controllo ASL.