Linuxディスプレイはコールドブート後に動作し、ドライバがパネルの遷移成功を報告してもレジューム後にブランクのままになることがある。調査するには、ソフトウェア状態をパネルが要求するレール、リセット、ビデオ、バックライトのイベントと比較する。.
prepare、enable、disable、unprepareはライフサイクルの境界を記述する。これらは特定の電気的シーケンスを保証するものではない。本分析ではLinux v6.12の例を用いて、コールドブート、ウォームリスタート、レジュームに対するイベントベースの調査を構築する。特定のモジュールに対する電圧、リセット極性、遅延値、コマンドを規定するものではない。.
コールバックを解釈する前に電気的契約を定義する
正確なパネルまたはモジュールのドキュメントとボードリビジョンから始める。要求されるイベント順序、最小または最大間隔、電力有効や電力オフなどのイベントを定義する閾値を特定する。ソフトウェア要求から測定された遅延は、データシートの要件と同じ基準を使用しない場合がある。.
関連するすべてのアクションに所有者を割り当てる。パネルドライバ、レギュレータプロバイダ、ブリッジ、ディスプレイコントローラ、バックライトドライバ、ファームウェア、または他のボードコンポーネントがシーケンスの異なる部分を所有する場合がある。リセット信号には独自の文書化された所有者が必要であり、都合の良いGPIO名から推測してはならない。.
次に、意図する遷移をイベント契約として記述する。各要件について、開始イベント、終了イベント、許容間隔、証拠源を記録する。これにより、失敗したリスタートは、任意のスリープを追加する誘いではなく、特定の関係に関する問題となる。.
一部の要件は、複数のレール、有効なビデオ、または放電条件に関係する場合がある。以下の簡略化されたイベント例はそれらの要件を置き換えるものではない。ドキュメントが本質的な条件を不明確なままにしている場合は、シーケンスが正しいと主張する前にそのギャップを解決する。.
エラー動作を含む、インストール済みのLinuxライフサイクルを読む
Linux v6.12では、DRMパネルコアがパネルコールバックを呼び出し、ライフサイクル状態を追跡する。enableは関連するバックライトを有効にする前にパネルenableコールバックを呼び出し、disableはパネルdisableコールバックの前にバックライトを処理する。unprepareは別の遷移である。このバージョンでは、パネルenableコールバックの成功後、バックライト有効化の失敗はログに記録されるが、 drm_panel_enable() は依然としてゼロを返す。.[1]
実用的な推論は限定的である：外側の戻り値の成功は、照明が成功した証拠ではない。すべての失敗が単一の戻り値を通じて伝播すると仮定するのではなく、関連するログと下位レベルの結果を検査する。プロジェクトのカーネルとパッチにおける実装を確認する。この例はすべてのリリースに関する約束ではない。.
また、呼び出された遷移と物理的イベントを区別する。ソフトウェア状態は冗長なコールバック作業を防ぐことができるが、ハードウェアはリスタートをまたいで状態を保持する場合がある。実際に何が実行され、各アクションが何を制御したかを確立する。preparedと記録されたログエントリは、リセットがトグルされたことや電源が有効閾値を超えたことを示すものではない。.
ランタイム電力管理は実際の電力イベントを移動させる可能性がある
Linux v6.12のpanel-simpleはこの分離を示している。prepareはランタイム電力を取得し、unprepareはオートサスペンド解放を要求する。そのランタイムサスペンドパスはenable GPIOを変更しレギュレータを無効化し、ランタイムレジュームはそれらを有効化し記述子固有の待機を適用する。遅延は個々のパネル記述子に属する。enable GPIOは自動的にリセットピンではない。.[2]
したがって、unprepare呼び出しの時刻は物理的な電源除去の時刻である必要はない。後のprepareは保留中のランタイム電力遷移と相互作用する可能性がある。4つのライフサイクル名から直接電力波形を描くのではなく、実際の実行パスを読む。.
これは1つのドライバファミリの例であり、すべてのパネルドライバのテンプレートではない。異なるモジュールは別のドライバ、ブリッジシーケンス、またはファームウェア制御の電力パスを使用する場合がある。ソースコードの記述子フィールドも普遍的なDevice Treeプロパティを確立するものではない。類似した名前の内部フィールドから遅延設定を発明することを避ける。.
レギュレータの解放はレールの放電を証明しない
Linux v6.12のレギュレータAPIは、バランスの取れた参照カウント式の有効化および無効化操作を使用する。共有コンシューマと制約により、1つのコンシューマが無効化した後もレギュレータが有効なままになる場合がある。.[3] したがって、パネルコンシューマの解放は、そのレールが物理的にオフになった証拠ではない。.
この区別は、パネルが次の電源投入前にオフ間隔を必要とする場合に重要である。間隔は指定された物理的条件を基準としなければならない。要件がレールが定義された閾値を下回ったときに始まる場合、 regulator_disable() からのタイミングでは利用可能なオフ時間を過大に評価する可能性がある。.
共有電源はこのコンシューマを通じた意図する電源サイクルを妨げる場合がある。どのコンシューマがレールを保持しているか、ボードが必要なオフ閾値に到達できるかを記録する。意図する電力アーキテクチャをハードウェアおよびドライバの所有者と解決する。.
物理的なオフイベントの証拠がなければ、そのタイムスタンプは不明のままである。有効化要求も同様に、パネル電源がいつ有効になるかを確立するものではない。.
架空のタイミング台帳でイベント基準を比較する
以下の例は制約チェックを示すためだけに架空のイベントと最小間隔を使用している。すべてのタイムスタンプは1つの想定タイムライン上のミリ秒単位である。いずれも実際のパネルに対する推奨ではなく、波形は測定されていない。.
| 架空のイベント | 時刻 |
|---|---|
| レールが定義された有効条件に到達 | 8 ms |
| リセットが解放される | 15 ms |
| ビデオが定義された有効条件に到達 | 23 ms |
| バックライトがオンになる | 38 ms |
| レールが定義されたオフ閾値を下回る | 70 ms |
| 次の電源有効化が発生 | 110 ms |
| 想定される要件 | 計算された間隔 | 想定下での結果 |
|---|---|---|
| レール有効からリセット解放まで：少なくとも5 ms | 15 – 8 = 7 ms | 想定される最小値を満たす |
| 有効ビデオからバックライトまで：少なくとも12 ms | 38 – 23 = 15 ms | 想定される最小値を満たす |
| 物理的オフ閾値から次のイネーブルまで：少なくとも50 ms | 110 – 70 = 40 ms | 想定される最小値を満たさない |
その架空のオフ間隔制約のみを考慮した場合、最も早い次のイネーブルは70 + 50 = 120 msとなる。他の要件については別途確認が必要である。最初の2つの通過した間隔は、その失敗した再起動条件を救済しない。物理的オフのタイムスタンプが欠落している場合、最後の結果は通過ではなく不明となる。これは以前のソフトウェア要求から計算されたものではない。.
実際の台帳では、異なるイベント、順序、最小・最大ウィンドウ、閾値、またはタイムアウトが必要となる場合がある。証拠を確認する際には、それらの定義を保持すること。正確な減算であっても、誤ったアンカーに基づいて構築されたシーケンスを検証することはできない。タイムスタンプの不確実性が制限を超える場合、丸められた値から通過を強制するのではなく、結果を不確定としてマークすること。.
コールドブート、ウォームリスタート、レジュームを別個のパスとして比較する
各パスのエントリ状態を記録する。コールドブートは、ディスプレイの無効化に続く有効化とは異なる物理的状態から開始する場合がある。サスペンドとレジュームは、一部のリソースを保持しながら他のリソースを変更する場合がある。これらはすべてのLinuxシステムに関する仮定ではなく、ターゲット上で確立すべき可能性である。.
どのコールバックが実行され、どのランタイム電力操作が完了し、どの物理的イベントが続くかを比較する。欠落したイベントは、より長い遅延よりも情報量が多い場合がある。例えば、リリース要求後の待機は、別のコンシューマが供給を有効に保っている場合、オフ状態を証明できない。.
証拠が許す限り、共通のタイムスタンプ基準を維持する。記録が関数エントリ、プロバイダアクション、物理的閾値、または可視出力のいずれを記述しているかを明示する。それらの意味と測定の不確実性が同一であるかのように、1つのタイムライン上に配置してはならない。.
記録を比較する際には、同じ定義されたイメージと遷移条件を使用する。有効なビデオと失敗したバックライトパスを持つパネルは、ビデオが有効にならないパネルとは異なる調査が必要である。可視的な暗さだけではそれらを区別できない。.
欠落した関係から次のチェックを選択する
| 証拠のギャップ | 確立すべき次の関係 |
|---|---|
| イネーブルがゼロを返すが照明がない | パネルコールバック結果、バックライトログ、実際のバックライト結果 |
| アンプリペアがログに記録されるがレールがアクティブのまま | ランタイム電力の完了、供給共有、制約 |
| コールドブートは動作するがクイックリスタートが失敗する | 物理的オフ条件と必要な再起動間隔 |
| リセット動作が不確実 | 実際の信号識別、オーナー、文書化された要件 |
| 有用なコンテンツの前にバックライトが表示される | 定義された有効ビデオイベントと照明タイミングの比較 |
これらは独自の診断ではなく、条件付きの調査方向である。実際のドライバパスと文書化されたパネル要件から次のチェックを選択し、記録を比較する際にはイベント定義を保持すること。.
関連レイヤーについては、次を参照： LCDピクセルクロックとタイミングガイド そして LCDバックライト調光検証. 。有効なリンク設定または調光設定は、パネルのライフサイクルが電力イベント契約を満たすことを確立しない。.
レビュー用にソフトウェアとイベントの両方の証拠を提供する
条件付き統合レビューについては、, RJY Displayにお問い合わせください。 モジュール、コントローラ、ボードリビジョン；正確なシーケンス要件；カーネルとパネルドライバ；電力とリセットのオーナーシップ；遷移ログ；および測定されたイベント記録を含めること。どの事実が不明のままであるかを特定する。これは、標準的な遅延、保証された電源サイクル、または普遍的な互換性を仮定することなく、範囲を限定した技術的議論を支援する。.
