Séquençage de l'alimentation du panneau TFT sous Linux : Cycle de vie et événements physiques

Un affichage Linux peut fonctionner après un démarrage à froid et rester blanc après une reprise, même si le pilote signale des transitions de panneau réussies. Pour enquêter, comparez l'état logiciel avec les événements de rail, de réinitialisation, de vidéo et de rétroéclairage requis par le panneau.

Prepare, enable, disable et unprepare décrivent des frontières de cycle de vie. Ils ne certifient pas une séquence électrique particulière. Cette analyse utilise des exemples de Linux v6.12 pour construire une investigation basée sur les événements pour le démarrage à froid, le redémarrage à chaud et la reprise. Elle ne prescrit pas de tension, de polarité de réinitialisation, de valeurs de délai ou de commandes pour un module spécifique.

Définir le contrat électrique avant d'interpréter les callbacks

Commencez par la documentation exacte du panneau ou du module et la révision de la carte. Identifiez l'ordre des événements requis, les intervalles minimaux ou maximaux, et les seuils qui définissent des événements tels que puissance valide ou mise hors tension. Un délai mesuré à partir d'une requête logicielle peut ne pas utiliser la même ancre que l'exigence de la fiche technique.

Attribuez un propriétaire à chaque action pertinente. Le pilote de panneau, le fournisseur de régulateur, le bridge, le contrôleur d'affichage, le pilote de rétroéclairage, le firmware ou un autre composant de la carte peuvent posséder différentes parties de la séquence. Un signal de réinitialisation nécessite son propre propriétaire documenté ; n'en déduisez pas un à partir d'un nom de GPIO pratique.

Décrivez ensuite la transition prévue comme un contrat d'événements. Pour chaque exigence, enregistrez l'événement de départ, l'événement de fin, l'intervalle autorisé et la source de preuve. Cela fait d'un redémarrage échoué une question sur une relation spécifique plutôt qu'une invitation à ajouter des veilles arbitraires.

Certaines exigences peuvent concerner plusieurs rails, une vidéo valide ou des conditions de décharge. Les exemples d'événements simplifiés ci-dessous ne remplacent pas ces exigences. Si la documentation laisse une condition essentielle floue, résolvez cette lacune avant de prétendre que la séquence est correcte.

Lire le cycle de vie Linux installé, y compris le comportement en cas d'erreur

Dans Linux v6.12, le cœur de panneau DRM invoque les callbacks de panneau et suit l'état du cycle de vie. Enable appelle le callback enable du panneau avant d'activer le rétroéclairage associé ; disable gère le rétroéclairage avant le callback disable du panneau. Unprepare est une transition séparée. Dans cette version, après un callback enable de panneau réussi, un échec d'activation du rétroéclairage est journalisé mais drm_panel_enable() retourne toujours zéro.^[1]

L'inférence pratique est étroite : un retour externe réussi n'est pas la preuve que l'illumination a réussi. Inspectez les journaux pertinents et les résultats de niveau inférieur au lieu de supposer que chaque échec se propage via une seule valeur de retour. Confirmez l'implémentation dans le noyau et les correctifs du projet ; l'exemple n'est pas une promesse concernant chaque version.

Distinguez également une transition invoquée d'un événement physique. Un état logiciel peut empêcher un travail de callback redondant, tandis que le matériel peut conserver son état à travers un redémarrage. Établissez ce qui s'est réellement exécuté et ce que chaque action contrôlait. Une entrée de journal indiquant « prepared » ne montre pas que la réinitialisation a basculé ou qu'une alimentation a franchi un seuil valide.

La gestion de l'alimentation à l'exécution peut déplacer l'événement d'alimentation réel

Le panel-simple de Linux v6.12 illustre cette séparation. Prepare acquiert la puissance à l'exécution ; unprepare demande une libération par autosuspend. Son chemin de suspension à l'exécution modifie le GPIO d'activation et désactive le régulateur, tandis que la reprise à l'exécution les active et applique des attentes spécifiques au descripteur. Les délais appartiennent aux descripteurs de panneau individuels. Le GPIO d'activation n'est pas automatiquement une broche de réinitialisation.^[2]

Par conséquent, le moment d'un appel unprepare ne doit pas nécessairement être le moment du retrait physique de l'alimentation. Un prepare ultérieur peut interagir avec une transition de puissance à l'exécution en attente. Lisez le chemin d'exécution réel plutôt que de dessiner une forme d'onde d'alimentation directement à partir des quatre noms de cycle de vie.

Ceci est un exemple d'une famille de pilotes, pas un modèle pour tous les pilotes de panneau. Un module différent peut utiliser un autre pilote, une autre séquence de bridge ou un chemin d'alimentation contrôlé par firmware. Les champs de descripteur dans le code source n'établissent pas non plus de propriétés universelles de l'arbre de périphériques. Évitez d'inventer un paramètre de délai à partir d'un champ interne au nom similaire.

Une libération de régulateur ne prouve pas qu'un rail est déchargé

L'API de régulateur de Linux v6.12 utilise des opérations d'activation et de désactivation équilibrées et comptées par références. Des consommateurs partagés et des contraintes peuvent maintenir un régulateur activé après qu'un consommateur l'a désactivé.^[3] La libération par un consommateur de panneau n'est donc pas la preuve que son rail s'est physiquement éteint.

Cette distinction est importante lorsqu'un panneau nécessite un intervalle hors tension avant la prochaine mise sous tension. L'intervalle doit utiliser la condition physique spécifiée comme ancre. Si l'exigence commence lorsqu'un rail descend en dessous d'un seuil défini, une mesure à partir de regulator_disable() peut au contraire surestimer le temps hors tension disponible.

Une alimentation partagée peut empêcher le cycle d'alimentation prévu via ce consommateur. Enregistrez quel consommateur retient le rail et si la carte peut atteindre le seuil hors tension requis. Résolvez l'architecture d'alimentation prévue avec les responsables du matériel et du pilote.

Sans preuve de l'événement physique de mise hors tension, son horodatage reste inconnu. Une requête d'activation n'établit pas non plus quand l'alimentation du panneau devient valide.

Comparer les ancres d'événements avec un registre de chronologie fictif

L'exemple suivant utilise des événements inventés et des intervalles minimaux uniquement pour démontrer la vérification des contraintes. Chaque horodatage est en millisecondes sur une chronologie supposée. Aucun n'est une recommandation pour un panneau réel, et aucune forme d'onde n'a été mesurée.

Pour cette seule contrainte fictive d'intervalle d'extinction, la prochaine activation la plus précoce serait 70 + 50 = 120 ms. D'autres exigences nécessiteraient encore des vérifications séparées. Les deux premiers intervalles conformes ne sauvent pas cette condition de redémarrage échouée. Si l'horodatage physique d'extinction était manquant, le dernier résultat serait inconnu plutôt qu'un succès calculé à partir d'une demande logicielle antérieure.

Un registre réel peut exiger des événements, un ordonnancement, des fenêtres minimales et maximales, des seuils ou des délais d'expiration différents. Préservez ces définitions lors de la vérification des preuves. Même une soustraction correcte ne peut valider une séquence construite autour de mauvais ancrages. Si l'incertitude d'horodatage franchit une limite, marquez le résultat comme non concluant plutôt que de forcer un succès à partir de valeurs arrondies.

Comparez le démarrage à froid, le redémarrage à chaud et la reprise comme des chemins distincts

Enregistrez l'état d'entrée pour chaque chemin. Le démarrage à froid peut partir d'une condition physique différente d'une désactivation suivie d'une activation de l'affichage. La suspension et la reprise peuvent conserver certaines ressources tout en en modifiant d'autres. Ce sont des possibilités à établir sur la cible, et non des hypothèses sur tout système Linux.

Comparez quels callbacks s'exécutent, quelles opérations de gestion d'énergie à l'exécution se terminent et quels événements physiques suivent. Un événement manquant peut être plus informatif qu'un délai plus long. Par exemple, attendre après une demande de libération ne peut prouver un état d'extinction lorsqu'un autre consommateur maintient l'alimentation activée.

Conservez une base temporelle commune lorsque les preuves le permettent. Précisez si un enregistrement décrit une entrée de fonction, une action du fournisseur, un seuil physique ou une sortie visible. Ne les placez pas sur une même chronologie comme si leurs significations et leur incertitude de mesure étaient identiques.

Utilisez la même image définie et les mêmes conditions de transition lors de la comparaison des enregistrements. Un panneau avec vidéo valide et un chemin de rétroéclairage défaillant nécessite une investigation différente d'un panneau dont la vidéo ne devient jamais valide. L'obscurité visible seule ne permet pas de les distinguer.

Choisissez la prochaine vérification à partir de la relation manquante

Ce sont des directions d'investigation conditionnelles et non des diagnostics uniques. Sélectionnez la prochaine vérification à partir du chemin réel du pilote et des exigences documentées du panneau, et préservez les définitions d'événements lors de la comparaison des enregistrements.

Pour les couches associées, voir la guide du pixel clock et du timing LCD de RJY et Validation de la gradation du rétroéclairage LCD. Une configuration de liaison valide ou un réglage de gradation n'établit pas que le cycle de vie du panneau respecte son contrat d'événements d'alimentation.

Fournissez des preuves logicielles et événementielles pour examen

Pour un examen d'intégration conditionnel, contactez RJY Display avec les révisions du module, du contrôleur et de la carte ; les exigences exactes de séquencement ; le noyau et le pilote du panneau ; la propriété de l'alimentation et de la réinitialisation ; les journaux de transition ; et les enregistrements d'événements mesurés. Identifiez les faits qui restent inconnus. Cela soutient une discussion technique délimitée sans supposer un délai standard, un cycle d'alimentation garanti ou une compatibilité universelle.

Références

1. Linux v6.12 : implémentation du cycle de vie du cœur de panneau DRM.
2. Linux v6.12 : implémentation de panel-simple.
3. Linux v6.12 : API Regulator.