Un display Linux può funzionare dopo un avvio a freddo e rimanere vuoto dopo la ripresa, anche se il driver segnala transizioni del pannello riuscite. Per indagare, confrontare lo stato software con gli eventi di alimentazione, reset, video e retroilluminazione richiesti dal pannello.
Prepare, enable, disable e unprepare descrivono i confini del ciclo di vita. Non certificano una particolare sequenza elettrica. Questa analisi utilizza esempi di Linux v6.12 per costruire un'indagine basata sugli eventi per avvio a freddo, riavvio a caldo e ripresa. Non prescrive tensione, polarità del reset, valori di ritardo o comandi per uno specifico modulo.
Definire il contratto elettrico prima di interpretare i callback
Partire dalla documentazione esatta del pannello o del modulo e dalla revisione della scheda. Identificare l'ordine degli eventi richiesto, eventuali intervalli minimi o massimi e le soglie che definiscono eventi come alimentazione valida o alimentazione disattivata. Un ritardo misurato da una richiesta software potrebbe non utilizzare lo stesso riferimento del requisito del datasheet.
Assegnare un proprietario a ogni azione rilevante. Il driver del pannello, il fornitore del regolatore, il bridge, il controller del display, il driver della retroilluminazione, il firmware o un altro componente della scheda possono essere proprietari di parti diverse della sequenza. Un segnale di reset necessita del proprio proprietario documentato; non inferirlo da un nome GPIO conveniente.
Descrivere quindi la transizione prevista come un contratto di eventi. Per ogni requisito, registrare l'evento iniziale, l'evento finale, l'intervallo consentito e la fonte di evidenza. Questo rende un riavvio fallito una questione relativa a una relazione specifica anziché un invito ad aggiungere sleep arbitrari.
Alcuni requisiti possono riguardare più rail, video valido o condizioni di scarica. Gli esempi semplificati di eventi riportati di seguito non sostituiscono tali requisiti. Se la documentazione lascia poco chiara una condizione essenziale, risolvere tale lacuna prima di dichiarare corretta la sequenza.
Leggere il ciclo di vita Linux installato, incluso il comportamento in caso di errore
In Linux v6.12, il core del pannello DRM invoca i callback del pannello e traccia lo stato del ciclo di vita. Enable chiama il callback di enable del pannello prima di abilitare la retroilluminazione associata; disable gestisce la retroilluminazione prima del callback di disable del pannello. Unprepare è una transizione separata. In questa versione, dopo un callback di enable del pannello riuscito, un fallimento nell'abilitazione della retroilluminazione viene registrato ma drm_panel_enable() restituisce comunque zero.[1]
L'inferenza pratica è limitata: un ritorno esterno riuscito non è prova che l'illuminazione sia riuscita. Ispezionare i log rilevanti e gli esiti di livello inferiore invece di presumere che ogni fallimento si propaghi attraverso un unico valore di ritorno. Confermare l'implementazione nel kernel e nelle patch del progetto; l'esempio non è una garanzia per ogni release.
Distinguere inoltre una transizione invocata da un evento fisico. Uno stato software può impedire lavoro ridondante nei callback, mentre l'hardware può mantenere lo stato attraverso un riavvio. Stabilire cosa è effettivamente stato eseguito e cosa ha controllato ogni azione. Una voce di log che indica prepared non dimostra che il reset sia stato commutato o che un'alimentazione abbia superato una soglia valida.
La gestione energetica a runtime può spostare l'evento energetico effettivo
In Linux v6.12 panel-simple illustra questa separazione. Prepare acquisisce l'alimentazione runtime; unprepare richiede un rilascio con autosuspend. Il suo percorso di suspend runtime modifica il GPIO di enable e disabilita il regolatore, mentre il resume runtime li abilita e applica attese specifiche del descrittore. I ritardi appartengono ai singoli descrittori del pannello. Il GPIO di enable non è automaticamente un pin di reset.[2]
Di conseguenza, il momento di una chiamata unprepare non deve coincidere con il momento della rimozione fisica dell'alimentazione. Un prepare successivo può interagire con una transizione di alimentazione runtime in sospeso. Leggere il percorso di esecuzione effettivo invece di tracciare una forma d'onda di alimentazione direttamente dai quattro nomi del ciclo di vita.
Questo è un esempio di una famiglia di driver, non un modello per tutti i driver di pannello. Un modulo diverso può utilizzare un altro driver, una sequenza bridge o un percorso di alimentazione controllato dal firmware. I campi del descrittore nel codice sorgente inoltre non stabiliscono proprietà Device Tree universali. Evitare di inventare un'impostazione di ritardo da un campo interno con nome simile.
Il rilascio di un regolatore non prova che un rail sia scarico
L'API dei regolatori di Linux v6.12 utilizza operazioni di enable e disable bilanciate e con conteggio dei riferimenti. Consumatori condivisi e vincoli possono mantenere un regolatore abilitato dopo che un consumatore lo ha disabilitato.[3] Il rilascio da parte di un consumatore del pannello non è quindi prova che il suo rail si sia fisicamente spento.
Questa distinzione è importante quando un pannello richiede un intervallo di off prima della successiva accensione. L'intervallo deve utilizzare la condizione fisica specificata come riferimento. Se il requisito inizia quando un rail scende sotto una soglia definita, temporizzare da regulator_disable() può invece sovrastimare il tempo di off disponibile.
Un'alimentazione condivisa può impedire il ciclo di alimentazione previsto attraverso questo consumatore. Registrare quale consumatore mantiene il rail e se la scheda può raggiungere la soglia di off richiesta. Risolvere l'architettura di alimentazione prevista con i proprietari dell'hardware e del driver.
Senza evidenza dell'evento fisico di off, il suo timestamp rimane sconosciuto. Allo stesso modo, una richiesta di enable non stabilisce quando l'alimentazione del pannello diventa valida.
Confrontare i riferimenti degli eventi con un registro temporale fittizio
L'esempio seguente utilizza eventi inventati e intervalli minimi unicamente per dimostrare la verifica dei vincoli. Ogni timestamp è in millisecondi su una linea temporale assunta. Nessuno è una raccomandazione per un pannello reale e nessuna forma d'onda è stata misurata.
| Evento fittizio | Tempo |
|---|---|
| Il rail raggiunge la sua condizione valida definita | 8 ms |
| Il reset viene rilasciato | 15 ms |
| Il video raggiunge la sua condizione valida definita | 23 ms |
| La retroilluminazione si accende | 38 ms |
| Il rail scende sotto la soglia di off definita | 70 ms |
| Si verifica la successiva abilitazione dell'alimentazione | 110 ms |
| Requisito assunto | Intervallo calcolato | Risultato secondo l'assunzione |
|---|---|---|
| Rail valido fino al rilascio del reset: almeno 5 ms | 15 – 8 = 7 ms | Soddisfa il minimo assunto |
| Video valido per retroilluminazione: almeno 12 ms | 38 – 23 = 15 ms | Soddisfa il minimo assunto |
| Soglia di spegnimento fisico per la successiva abilitazione: almeno 50 ms | 110 – 70 = 40 ms | Non supera il minimo presunto |
Solo per quel vincolo fittizio sull'intervallo di spegnimento, la prima abilitazione successiva sarebbe 70 + 50 = 120 ms. Altri requisiti richiederebbero comunque verifiche separate. I primi due intervalli superati non salvano quella condizione di riavvio fallita. Se il timestamp di spegnimento fisico fosse mancante, l'ultimo risultato sarebbe sconosciuto anziché un superamento calcolato da una precedente richiesta software.
Un registro reale può richiedere eventi, ordinamenti, finestre minime e massime, soglie o timeout diversi. Conservare tali definizioni durante la verifica delle evidenze. Anche una sottrazione corretta non può validare una sequenza costruita su ancore errate. Se l'incertezza del timestamp supera un limite, contrassegnare il risultato come inconcludente anziché forzare un superamento da valori arrotondati.
Confrontare avvio a freddo, riavvio a caldo e ripresa come percorsi distinti
Registrare lo stato di ingresso per ciascun percorso. L'avvio a freddo può iniziare da una condizione fisica diversa rispetto a una disabilitazione del display seguita da un'abilitazione. Sospensione e ripresa possono conservare alcune risorse mentre ne modificano altre. Queste sono possibilità da stabilire sul target, non assunzioni valide per ogni sistema Linux.
Confrontare quali callback vengono eseguiti, quali operazioni di runtime-power vengono completate e quali eventi fisici ne conseguono. Un evento mancante può essere più informativo di un ritardo più lungo. Ad esempio, attendere dopo una richiesta di rilascio non può dimostrare una condizione di spegnimento quando un altro consumatore mantiene l'alimentazione abilitata.
Mantenere una base temporale comune dove le evidenze lo consentono. Dichiarare se un record descrive un ingresso in funzione, un'azione del provider, una soglia fisica o un output visibile. Non collocarli su un'unica linea temporale come se i loro significati e l'incertezza di misurazione fossero identici.
Utilizzare la stessa immagine definita e le stesse condizioni di transizione nel confronto dei record. Un pannello con video valido e un percorso di retroilluminazione fallito richiede un'indagine diversa da un pannello il cui video non diventa mai valido. L'oscuramento visibile da solo non li distingue.
Scegliere la verifica successiva dalla relazione mancante
| Lacuna nelle evidenze | Prossima relazione da stabilire |
|---|---|
| L'abilitazione restituisce zero ma l'illuminazione è assente | Risultato della callback del pannello, log della retroilluminazione e esito effettivo della retroilluminazione |
| L'unprepare è registrato ma il rail rimane attivo | Completamento del runtime-power, condivisione dell'alimentazione e vincoli |
| L'avvio a freddo funziona mentre il riavvio rapido fallisce | Condizione di spegnimento fisico e intervallo di riavvio richiesto |
| Il comportamento del reset è incerto | Identità effettiva del segnale, proprietario e requisito documentato |
| La retroilluminazione appare prima del contenuto utile | Evento di video valido definito rispetto alla temporizzazione dell'illuminazione |
Queste sono direzioni di indagine condizionali, non diagnosi univoche. Selezionare la verifica successiva dal percorso effettivo del driver e dai requisiti documentati del pannello, e conservare le definizioni degli eventi nel confronto dei record.
Per i layer correlati, vedere la clock pixel e temporizzazione LCD e Validazione del dimming della retroilluminazione LCD. Una configurazione di link valida o un'impostazione di dimming non stabilisce che il ciclo di vita del pannello soddisfi il suo contratto sugli eventi di alimentazione.
Fornire sia evidenze software che evidenze sugli eventi per la revisione
Per una revisione di integrazione condizionale, RJY Display con le revisioni del modulo, del controller e della scheda; i requisiti esatti di sequenziamento; il kernel e il driver del pannello; la proprietà di alimentazione e reset; i log delle transizioni; e i record degli eventi misurati. Identificare quali fatti rimangono sconosciuti. Questo supporta una discussione tecnica con ambito definito senza assumere un ritardo standard, un ciclo di alimentazione garantito o una compatibilità universale.
