JP2014517928A - 表示画像の選択的な更新によるプラットフォーム電力消費の制御 - Google Patents

Abstract

表示画像の選択的な更新によるプラットフォーム電力消費のプラットフォーム制御の制御に関する。装置の実施形態は、フレームバッファからビデオディスプレイへピクセルデータを転送するディスプレイコントローラと、フレームバッファの更新を追跡し、前の画像から変更されたピクセルデータの部分を特定する検出部とを有し、ディスプレイコントローラは、特定されたピクセルデータの部分をビデオディスプレイに供給する。

Description

本発明の実施形態は概して電子機器の分野に関し、特に、表示画像の選択的な更新によるプラットフォーム電力消費の制御のための方法及び装置に関する。

システム設計における改善にかかわらず、モバイル電子機器及び他のシステムは、動作において相当量の電力を消費する。このため、システムは、例えば、システム要素をオフし又はそれらの動作を減らすことによって、電力消費を削減するよう多種多様な機能を利用する。

システム又はデバイスの最も有意な電力消費要素は、ビデオデータをスクリーンデバイスへ供給するために利用されるディスプレイサブシステムである。

しかし、従来のデバイス及び処理は、電力消費を効率良く管理するそれらの能力に限りがある。ディスプレイサブシステムの動作は、スクリーン画像を維持するために相当量の電力を必要とし、電力消費は概して、スクリーン表示がアクティブである限り続く。

コンピュータプラットフォームのための電力管理システムの実施形態の例示である。 部分的なフレーム更新のためのシステムの実施形態の例示である。 部分的なフレーム更新の実施形態において使用されるスクリーン損傷長方形の例示である。 部分的なフレーム更新を用いる装置及びシステムの実施形態による電力消費を説明するタイミング図である。 スクリーン損傷処理のためのプロセスの実施形態を説明するフローチャートである。 スクリーン損傷を扱うプロセスの実施形態を説明するフローチャートである。 部分的なスクリーン更新のためのプロセスの実施形態を説明するフローチャートである。 部分的なスクリーン更新のためのディスプレイドライバ動作の実施形態を説明するフローチャートである。 プラットフォーム電力管理のためのシステム、装置、又はプロセスの実施形態を説明するブロック図である。 電力管理システムの実施形態における活動レジスタの例示である。 電力管理の実施形態の動作を説明するタイミング図である。 ディスプレイドライバ電力管理モジュールの動作の実施形態を説明するフローチャートである。 電力管理ユニットモジュールの動作の実施形態を説明するフローチャートである。 モバイルデバイス又は他のコンピューティングプラットフォームの実施形態を表す。

本発明の実施形態は、限定としてではなく一例として、添付の図面の各図において表される。図面において、同じ参照符号は同様の要素を参照する。

本発明の実施形態は概して、表示画像の選択的な更新によるプラットフォーム電力消費の制御に向けられている。

ここで使用されるように：
“モバイルデバイス”は、携帯電話、スマートホン、モバイルインターネットデバイス（ＭＩＤ）、携帯型コンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、及び他の同様のデバイスを含むモバイル電子機器又はシステムを意味する。

幾つかの実施形態では、方法、装置、又はシステムは、表示スクリーンの選択的な更新を提供する。幾つかの実施形態では、選択的な更新は、前の画像の送信から変更された画像の部分のみを送信することを提供する。

幾つかの実施形態では、方法、装置、又はシステムは、コンピューティングプラットフォームの電力消費を制御するようプラットフォーム電力管理とディスプレイ電力管理との間の協調を含む。コンピューティングプラットフォームは、モバイルデバイスを含むがそれに限られない、コンピューティング動作を提供するあらゆるプラットフォームを含む。幾つかの実施形態では、コンピューティングプラットフォームは、表示動作が必要とされない場合に低電力状態へ移行するか又はその状態のままあるために、ディスプレイ電力管理動作を認めるよう動作する。

従来のディスプレイサブシステムは、モバイルプラットフォームにおいて最も電力を消費するデバイスの１つであり、相当量の電力が表示の内容を維持するのに消費される。表示内容をリフレッシュ及び維持する一定の活動は、モバイルデバイスのバッテリ寿命に対して有意な影響を有する。従来の動作では、ディスプレイがアクティブである限り、次のタスクが実行される：（１）各ビデオフレームについて表示同期インタラプト（Ｖｂｌａｎｋ）を供給し、（２）完全なフレームバッファ（ＦＢ）コンテンツをビデオディスプレイへ送信する。なお、フレームバッファは、表示されるべきビデオスクリーン画像の色情報（ピクセルデータ）を記憶するプラットフォームの記憶域である。そのような動作は、デバイスにおいて相当量の電力を消費し、且つ、そのような動作は、ビデオ画像において起こる変化の量に関わらず従来の動作において追随される。

幾つかの実施形態では、装置、システム、又はプロセスは、変更される画像の部分（ここでは、“損傷”と呼ばれる。）のみが更新されるビデオディスプレイの選択的な更新を提供する。幾つかの実施形態では、プロセス（ここでは、選択的なピクセル更新（ＳＰＵ；Selective Pixel Update）又は表示部分更新（ＤＰＵ；Display Partial Update））は、装置又はシステムのための部分的なスクリーン更新を提供する。幾つかの実施形態では、装置、システム、又はプロセスは、ディスプレイの活動時間を減らすためにディスプレイの選択的な更新を利用してよく、よって、コンピューティングプラットフォームのための有意な電力節約をもたらしてよい。

従来のコンピューティングプラットフォームでは、ディスプレイパイプラインは一般的に、表示が能動的に変更されている場合に低電力モードに入ることができない。そのような動作において、ディスプレイサブシステムは、プラットフォームにおいて相当期間のアイドリングが存在しない限り、オフされない。ディスプレイが電力節約モードに入るまで、プラットフォームは一般的に、たとえプラットフォームの残りが休止するとしても、表示要求を供給するよう高電力消費モードに留まるよう要求される。モバイルデバイスにおいて、一定表示に関連する要求を供給する影響は、デバイスのバッテリ寿命の有意な消費を生じさせる。幾つかの実施形態では、プラットフォームは、プラットフォームが低電力状態へ移行すること又はより長い時間低電力状態に留まることを可能にするために、プラットフォーム電力管理とディスプレイ電力管理との統合を提供する。

表示部分更新（ＤＰＵ）は、スクリーンの変更部分のみをディスプレイへ送信して、表示トラフィックの低減により電力を節約することによって、部分的に、過度の電力消費の問題に対処する。しかし、ＤＰＵは、ディスプレイパイプラインにおいて表示更新間のより長いアイドリングを達成するが、従来の技術は、他のプラットフォーム電力管理技術と協働するよう最適化されない。従来のシステムは、プラットフォーム電力管理のセマンティクスを考慮せず、従って、独立に動作することによって、様々なサブシステムによりコヒーレントに低電力モードに入ることでコンピューティングプラットフォームにおいて電力を節約する機会は存在しない。

幾つかの実施形態では、方法、装置、又はシステムは、より精細な電力制御を提供し且つアクティブモードにおいてプラットフォームで更なる電力節約を達成するために、ＤＰＵ技術のようなディスプレイ電力管理技術を、プラットフォーム電力管理インフラストラクチャと結び付ける。幾つかの実施形態では、方法、装置、又はシステムは、コンピューティングプラットフォームの電力消費を制御するよう、プラットフォーム電力管理とディスプレイ電力管理との間の協調を含む。幾つかの実施形態では、方法、装置、又はシステムは、プラットフォーム電力管理フレームワーク技術を選択的ピクセル更新技術と結び付ける。幾つかの実施形態では、方法、装置又はシステムは、アクティブモードにおいてプラットフォームで更なる電力節約を達成するよう、ＳＰＵ技術とプラットフォーム電力管理インフラストラクチャとの間の協調を利用する。

幾つかの実施形態では、選択的なピクセル更新を提供する装置、システム、又はプロセスは、変更されるスクリーンの部分のみをビデオディスプレイへ送信する動作を提供する。幾つかの実施形態では、装置、システム、又は方法は、スクリーンの変化（損傷と呼ばれる。）を捕捉し、プラットフォーム及びディスプレイリンクにおいて電力消費を減らすようハードウェア上の特徴を活用する。

幾つかの実施形態では、選択的なピクセル更新のための装置又はシステムは、次のハードウェア要素を含む：（１）自身のフルフレームバッファを有し且つスクリーン更新が送信されない場合に画像を保つ能力を備えるビデオディスプレイ；（２）部分的なフレームバッファをビデオディスプレイへ送信する機能をサポートするハードウェアコントローラ。

従来のシステムでは、ハードウェアは、例えば、ＭＩＰＩ（登録商標）（Mobile Industry Processor Interface）タイプ１ディスプレイパネルを有してよい。ＭＩＰＩ（登録商標）ディスプレイは、１つのフルフレームバッファのデータを記憶する能力を有し、この遠隔のフレームバッファからのその画面内容をリフレッシュすることができる。従来の要素の中で、ＭＩＰＩ（登録商標）コントローラは、低減されたフレームバッファをパネル側ハードウェアへ提供するよう動作することができるが、コントローラのモードは、スクリーンのより小さい範囲において表示し、スクリーンの残りは黒色である特別な使用ケースである。ＭＩＰＩ（登録商標）コントローラは、画面の変化を追跡する能力を有さず、その特別な範囲のみを更新する。

幾つかの実施形態では、装置又はシステムは、フレームバッファの変化を追跡するハードウェアを含む。幾つかの実施形態では、選択的なピクセル更新は、スクリーンにおいて起こる変化（スクリーン損傷）を追跡するために、“損傷拡張子”（ＤＥｘ）と呼ばれるリナックス（登録商標）ウィンドウイングシステム（Ｘフレームワーク）で利用可能な既存のインフラストラクチャを利用する。

コンピューティングプラットフォームのための異なるワークロードに基づき、平均してディスプレイにおけるピクセルのたった１０％がアクティブフレーム毎に変更されることが示される。ＳＰＵは、フレームバッファの変更された部分のみを送信するので、ディスプレイ及びメモリリンク活動は有意に、ピクセルの１０％しか変更されない場合は潜在的に９０％だけ、低減され得る。幾つかの実施形態では、低減されたスクリーン更新は、プラットフォームがより深いスリープモードに入ることを可能にし、且つ、ディスプレイリンクが（ディスプレイ要素のためのクロック又は電力ゲーティングを用いて）低電力モードへ移行することを可能にするために、利用されてよい。

幾つかの実施形態では、ディスプレイ電力管理に対するＳＰＵアプローチは２つの要素から成る。すなわち、ソフトウェアは、スクリーンにおける変化を追跡し、変更されたピクセルの領域を長方形として提示し、ハードウェアは、フレームバッファの損傷領域のみを遠隔のフレームバッファへ送信することができる。幾つかの実施形態では、動作は、ディスプレイリンクが、従来のシステムよりもずっと短い期間アクティブであることを可能にし、活動がスクリーンにおいて起きない場合は、ディスプレイは、その内容をローカルのフレームバッファよりむしろ遠隔のフレームバッファからリフレッシュして、メモリ電力の節約も提供する。幾つかの実施形態では、スクリーン損傷のソフトウェア追跡はまた、更なる電力及び性能改善を提供するよう固定関数ハードウェアとして実施されてよい。

典型的な動作において、たとえディスプレイが（例えば、ウェブブラウジング又はビデオ再生において）能動的に更新されているとしても、表示更新間にシステムにおいて起こる有意なアイドル期間が存在する。幾つかの動作において、アイドル期間は、あるインターバルで低電力消費状態を可能にするようプラットフォーム電力管理コントローラによって活用される。低電力プラットフォーム電力モードは概して、ここでは中間アイドルモード（ＩＩＭ；Intermediate Idle Mode）と呼ばれる（プラットフォームがＳ０状態にあるアイドル電力モードを示し、Ｓ０はシステムの十分に動作可能な電力状態を示す。）。動作において、プラットフォームにおけるプロセッサ及び他のデバイスは、Ｓ０状態の応答性に近い応答性を保ちながら電力消費が少ないことが可能である。しかし、従来のモバイルプラットフォームでは、ディスプレイパイプラインは、メモリ、グラフィクス及びディスプレイ制御において一定の活動バーストを生じさせ、従って、ＩＩＭ状態へのエントリを妨げる。幾つかの実施形態では、ＤＰＵ技術により、フレーム間のアイドリングは増大し、従って、ＩＩＭ状態に長く留まるのを支援する。

しかし、プラットフォームの観点から、ディスプレイパイプラインは通常、プラットフォーム電力管理コントローラの電力管理ユニット（ＰＭＵ；Power Management Unit）とディスプレイパイプラインとの間の協調なしに、独立したモジュールとして扱われる。幾つかの実施形態では、方法、装置又はシステムは、システムがより長く低電力モードに留まることを可能にし、且つ、ある状況では、アクティブ状態に使われる時間を短縮するよう、それらのエンティティを協調させる。

幾つかの実施形態では、ＤＰＵ及びＩＩＭの組み合わせによる最適化において、プラットフォームのＩＩＭ決定は、電力低下状態及びプラットフォームにおける更なる電力節約を可能にするようＤＰＵディスプレイドライバへ伝えられる。幾つかの実施形態では、ＩＩＭ状態は、ディスプレイドライバがディスプレイのワークロードと関連して電力管理に関する決定を知らせることを支援するガイダンスを提供するために利用される。

幾つかの実施形態では、ＤＰＵ及びＩＩＭの協調を利用するディスプレイのための最適化の結果として、プラットフォームにおけるアイドリングの増大が達成され得る。ディスプレイパイプラインはアクティブモード電力の有意な消費部であるから、アイドリングの増大は、システムにおける電力消費の削減を提供することができる。

図１は、コンピュータプラットフォームのための電力管理システムの実施形態の例示である。幾つかの実施形態では、コンピューティングプラットフォーム１００の高度な表示は、ここで表されない他の要素もあるが、プロセッシング要素１１０及びディスプレイユニット１２０を含む。コンピューティングプラットフォーム１００は、バッテリ又は他の有限なモバイル電源で動作するモバイルデバイスであってよい。幾つかの実施形態では、コンピューティングプラットフォーム１００は、プラットフォーム電力管理ユニットモジュール又はサブシステム１３０と、ディスプレイ電力管理モジュール又はサブシステム１４０とを含む、プラットフォーム１００の電力管理のためのシステムを含む（それらのモジュール又はサブシステムは、複数の構成要素又は構成要素の機能を含んでよい。）。幾つかの実施形態では、ディスプレイ電力管理モジュール１４０は、画像の変化（スクリーン損傷）が存在する場合にのみ表示更新を提供する機能を含んでよい。

幾つかの実施形態では、コンピューティングプラットフォーム１００は、プラットフォーム電力管理ユニットモジュール１３０とディスプレイ電力管理モジュール１４０との間の協調１５０を提供する。幾つかの実施形態では、コンピューティングプラットフォーム１００は、表示更新が必要とされない場合に、コンピュータプラットフォームが低電力アクティブモード（ＩＩＭ）へ移行するか又はそのモードに留まることを可能にするよう、ディスプレイ電力管理のためのデータを利用する。

図２は、表示部分更新のためのシステムの実施形態の例示である。この例示において、システムは、特定のハードウェア２４０とともに、ユーザ空間２００及びカーネル空間２２０を含む。幾つかの実施形態では、ユーザ空間は、スクリーン画像に対する変更を反映する損傷データ２０５を生成するよう損傷拡張子（ＤＥｘ）２０４を有するＸサーバ２０２を含み、損傷拡張子は、システムのための損傷検出要素の少なくとも一部を提供する。幾つかの実施形態では、ユーザ空間は、グラフィクスドライバ（ＤＤＸ）２０６と、損傷データを受信する損傷モジュール（ＤＭ）２０８とを更に含み、損傷モジュール２０８は、ＳＰＵセットアップを開始し、スクリーン損傷通知を受信するようＤＥｘ２０４とのハンドシェイクを更に実行する。幾つかの実施形態では、ＤＥｘ２０４は、デカルト座標の形でルートウィンドウ（スクリーン全体）において２次元の変化が存在する場合に、損傷モジュール２０８へピクセル損傷を送信する。幾つかの実施形態では、損傷モジュール２０８は、データの妥当性をチェックし、１フレームの時間期間（通常、〜１６．６６ｍｓ）に損傷を累積する。幾つかの実施形態では、累積された損傷データは、長方形を表す４つのデータ点、すなわち、｛Ｘ１，Ｙ１，幅，高さ｝を有する。長方形の４辺は、後述される図３において示されるように、３つの点から導出され得る。

幾つかの実施形態では、フレーム時間の満了時に、ピクセル損傷データは、ＩＯＣＴＬ（入出力制御）インターフェースを介してディスプレイドライバ２２２（カーネル空間２２０において表される。）へ送信される。幾つかの実施形態では、ディスプレイドライバ２２２は、起動時にディスプレイパネル及び選択ピクセル送信器（ＳＰＴｘ）２４２を設定し、且つ、ピクセルデータ転送を同期させることに関与する。

幾つかの実施形態では、Ｖｂｌａｎｋインタラプトを受信すると、ディスプレイドライバ２２２は、フレームバッファに対するピクセル更新をチェックし、存在する場合は、次いで、ディスプレイドライバ２２２は、損傷領域ピクセルをパネル側ロジックへ送信するよう選択ピクセル送信器２４２を設定する。幾つかの実施形態では、この動作は、ホスト側での表示活動を完了し、ピクセルが正確に示されることを確かにすることは、パネル側ロジックの責任である。幾つかの実施形態では、ローカルのフレームバッファに対する更新がない（損傷がない）場合は、選択ピクセル送信器２４２は、何らかの新たなデータが遠隔のフレームバッファへ送信される必要があるまで、低電力モードへとディスプレイドライバ２２２によってパワーゲーティングされる。

幾つかの実施形態では、選択ピクセル受信器（ＳＰＲｘ）２４４と呼ばれるパネル側ロジックモジュールは、選択ピクセル送信器２４２によって提供されるピクセルを受け取り、遠隔のフレームバッファ２４６を新しいデータにより更新する。幾つかの実施形態では、タイミングコントローラ（ＴＣＯＮ）２４８は、夫々の新しいフレームの開始時に遠隔のフレームバッファを走査するよう動作し、その場合にピクセルは、表示のためにスクリーン２５０へ供給される。幾つかの実施形態では、タイミングコントローラ２４８は常にその内容を遠隔のフレームバッファ２４６からリフレッシュするので、ＳＰＵ技術は、遠隔のフレームバッファ２４６へ送信されるデータがない場合でさえ安定した画像を提供する。幾つかの実施形態では、ディスプレイの活動は、非活動期間が長いことによりプラットフォームがディスプレイから電力を外すよう動作するまで、存在する（例えば、スクリーンセーバ事象）。

図３は、表示部分更新の実施形態において使用されるスクリーン損傷長方形の例示である。幾つかの実施形態では、損傷長方形３００は、点（Ｘ１，Ｙ１）と損傷長方形の幅及び高さとによって定義されてよい。表されるように、損傷長方形は、そのようなデータによって定義される４つの角点を含み、角点は、（Ｘ１，Ｙ１）、（Ｘ１＋幅，Ｙ１）、（Ｘ１，Ｙ１＋高さ）、及び（Ｘ１＋幅，Ｙ１＋高さ）である。

図４は、表示部分更新を用いる装置又はシステムの実施形態による電力消費を説明するタイミング図である。幾つかの実施形態では、システムプラットフォームは、（１６．６６ミリ秒のフレームを有する）Ｖｂｌａｎｋインタラプト４１０に従ってフレームにおけるビデオデータ送信を提供してよい。メモリ及びディスプレイリンク活動４２０の従来動作によれば、データフレームに対する変化が全く又はほとんどない場合でさえ、相当の電力コストが存在する。幾つかの実施形態では、選択ピクセル更新システム４３０は、スクリーン画像に対する変更を含む損傷長方形のみを送信するディスプレイパイプラインの動作における低減により、電力消費４４０の節約を可能とする。

図５は、スクリーン損傷処理のためのプロセスの実施形態を説明するフローチャートである。幾つかの実施形態では、スクリーン初期化のためのプロセス５００は、ステップ５０５でスクリーン画像のためのスクリーン損傷リポートレベルを初期化し、ステップ５１０でスクリーン損傷のためのフラグ（Damage Init Frag）を偽（False）と設定する。ステップ５１５でシステムが選択ピクセル更新のためのサポートを提供する場合に、ステップ５２０でセマフォ・ミューテックス（相互排除オブジェクト）ロックが初期化され、ステップ５２５でスレッドが損傷処理のために生成される。

図６は、スクリーン損傷を扱うプロセスの実施形態を説明するフローチャートである。幾つかの実施形態では、損傷を扱う処理６００は、ミューテックスオブジェクトを破棄するステップ６０５と、スクリーン損傷のためのフラグ（Damage Init Frag）を偽（False）に設定するステップ６１０とを含む。ステップ６１５でセマフォが待機している場合は、ステップ６２０でセマフォは解放される。

図７は、部分スクリーン更新のためのプロセスの実施形態を説明するフローチャートである。幾つかの実施形態では、プロセスは、選択ピクセル更新スレッドを起動するステップ７００を含む。プロセスは、ルートウィンドウが存在するかどうかを決定するステップ７０２を更に含む。存在しない場合は、プロセスは休止し、ルートウィンドウがアクティブとなるまで再チェックする。ルートウィンドウが存在すると、損傷作成レジスタのチェック７０４がある。ステップ７０６でＳＰＵ削除フラグ（SPU Clean Flag）が、ＳＰＵ削除関数によって設定されるように、設定される場合に、ステップ７１８でセマフォオブジェクトが破棄され、プロセスは終了する。SPU Clean Flagが設定されない場合は、ステップ７０８で、セマフォが解放されるのを待つ。

同時に実行され得るプロセスにおいて、損傷通知関数７５０は、セマフォ待機フラグ（Semaphore Wait Flag）が設定されるかどうかを決定するステップ７５５を含む。設定される場合は、損傷情報のマージが存在し、関数は終了する。設定されない場合は、ステップ７６０でセマフォは選択ピクセル更新スレッド７０８へ解放され、関数は終了する。

ステップ７０８でセマフォが解放されると、ステップ７１０でタイマフラグ休止（Timer Flag Sleep）がフレーム長（例えば、１６ミリ秒）へ設定され、ステップ７１２で損傷長方形の座標（図３において示されるＸ、Ｙ、長さ、及び幅）を特定する決定がなされる。ＩＯＣＴＬ呼び出しがステップ７１４でカーネルに対してなされ、損傷領域はステップ７１６で削除される。次いで、プロセスは、SPU Clean Flagが設定されるかどうかの決定７０６へ戻り、ステップ７０８でセマフォが解放されるのを待つ。

図８は、部分スクリーン更新のためのディスプレイドライバ動作の実施形態を説明するフローチャートである。幾つかの実施形態では、ディスプレイドライバのためのプロセス８００は、ドライバを初期化し、ディスプレイエンジンを設定するステップ８０５と、フレームバッファにおいて損傷が存在するかどうかを決定するステップ８１０とを含む。損傷が存在しない場合は、プロセスは、ステップ８３０で、損傷が存在するまで休止する。損傷が存在する場合は、損傷領域長方形の更新８１５が行われる。ステップ８２０でＶｂｌａｎｋインタラプトが受信されない場合は、プロセスは、フレームバッファにおいて損傷が存在するかどうかを決定するステップ８１０へ戻る。Ｖｂｌａｎｋインタラプトが受信された場合は、フレームバッファから損傷サイズをフェッチするようＳＰＵ送信器を構成するステップ８２５と、ピクセルデータをパネルへ送信するステップ８３５とが行われる。

図９は、プラットフォーム電力管理のためのシステム、装置、又はプロセスの実施形態を説明するブロック図である。図９は、ＤＰＵ及びＳ０協調を利用するグラフィクス及びディスプレイパイプライン制御を含む装置又はシステムの実施形態を表す。Ａｐｐ−１ ９１０、Ａｐｐ−２ ９１２及びＡｐｐ−３ ９１４のようなアプリケーションは、そのようなアプリケーションのためのローカル・フレームバッファ（ＦＢ）９１６上にグラフィクス・テキスト及び画像をレンダリングし、また、アプリケーションは、そのようなデータをディスプレイドライバ９２０へ供給する。（Ｖｂｌａｎｋ信号における）各データフレームの開始時に、アプリケーションは、それらのローカル・フレームバッファのデータをメイン・フレームバッファ９２２上にコピー９６４する。メイン・フレームバッファ９２２にコピーされたデータは、ディスプレイパネルへの送信後にユーザにとって可視的である。動作において、ディスプレイコントローラ（ＤＣＴ）９４４は、ディスプレイ９４６へのビデオ（ピクセル）データ９６８の転送として示される、ディスプレイパネル９４６へのメイン・フレームバッファ９２２の内容の送信に関与する。この動作において、ソフトウェア又はハードウェアのいずれかにおいて実施される損傷検出（ＤＤ）要素９４２は、メイン・フレームバッファにおけるスクリーン更新を追跡し（スクリーン更新は、画像への損傷と呼ばれる。）、フレームバッファ９２２の変更された部分のみをディスプレイ９４６へ送信するようディスプレイコントローラとともに動作する。表されるように、ディスプレイ９４６は、ピクセルデータの送信をトリガするようＶｂｌａｎｋ（垂直ブランキングインターバル）９７０のインタラプトをディスプレイコントローラ９４４へ供給する。幾つかの実施形態では、ディスプレイコントローラは、Ｖｂｌａｎｋインタラプト９７２を電力管理ユニット９４０へ供給し、電力管理コントローラ９４０は、データをディスプレイドライバ９２０へ供給する。

幾つかの実施形態では、コンピューティングプラットフォーム９００は、ディスプレイコントローラ活動レジスタ又は他のメモリ要素９３２を有し、それは、損傷を有するスクリーンの部分（長方形）のための長方形要素と、アクティブなディスプレイコントローラの動作を示すビジーセクタとを含む。幾つかの実施形態では、コンピューティングプラットフォーム９００は、電力管理ユニット９４０から更新９７６を受信する電力レベル（ＩＩＭ）レジスタ又は他のメモリ要素９３０を更に有する。幾つかの実施形態では、ディスプレイドライバ９２０は、（ディスプレイコントローラ９４４及び損傷検出器９４２の動作を介する）ディスプレイの電力管理と、（電力管理ユニット９４０の動作を介する）プラットフォームの電力管理とを協調させるために、ディスプレイコントローラ活動レジスタ９３２及びＩＩＭレジスタ９３０にポーリングを行うよう動作する。

図１０は、電力管理システムの実施形態における活動レジスタの例示である。幾つかの実施形態では、活動レジスタ又は他のメモリ要素９３０（図９にも表される。）は、複数のフィールドを有し、それらのフィールドは、ＩＩＭ電力低下状態のイネーブルステータスのための第１フィールド１００２、アイドル期間のための第２フィールド１００４、ディスプレイドライバ（ＤＤ）応答のための第３フィールド１００６、及びディスプレイコントローラ電力（ＤＣＴ ＰＷＲ）のための第４フィールド１００８を含んでよい。

幾つかの実施形態では、ＤＰＵ及びＩＩＭ電力管理最適化の協調は、全体的なプラットフォーム電力管理を改善するために利用されてよい。幾つかの実施形態では、ディスプレイ電力管理をプラットフォーム電力管理インフラストラクチャと相互接続するために、装置又はシステムは、少なくとも２つのレジスタ又は他のメモリ要素を含む。幾つかの実施形態では、電力管理ユニット（ＰＭＵ）９４０のための第１のレジスタ又は他のメモリ要素（ＩＩＭレジスタ）９３０は、プラットフォーム電力管理決定をディスプレイドライバ９２０に示すために利用され、第２のレジスタ又は他のメモリ要素（ＤＣＴ）９３２は、ディスプレイコントローラ９４４が目下フレームを送信中（ビジーステータス）であるか否かをディスプレイコントローラ９４４が知らしめるために利用される。幾つかの実施形態では、ＤＣＴ活動レジスタ９３２はまた、ディスプレイコントローラ９４４がＶｂｌａｎｋインターバルの開始時にディスプレイ９４６へ送信するフレームバッファ長方形（Ｒｅｃｔ）を受信する。

幾つかの実施形態では、コンピューティングプラットフォームのための電力制御は、２つの方法において実施されてよい：プラットフォームはＩＩＭに入れる状態にあり、且つ、ディスプレイ管理決定は（１）Ｖｂｌａｎｋインターバルの開始時又は（２）Ｖｂｌａｎｋインターバル間で行われる。

（Ｉ）Ｖｂｌａｎｋの開始時のディスプレイ電力管理決定：幾つかの実施形態では、プラットフォームがＩＩＭ状態に入れる態勢にあるとき、電力管理ユニットは、プラットフォーム状態をＩＩＭレジスタ９３０を介してドライバへ示す。これは図９において表されており、図９において、ディスプレイドライバ９２０はＩＩＭレジスタ９３０を介して状態情報を受信する。電力管理ユニットは概して、ディスプレイドライバよりも速くプラットフォーム決定を行い、従って、イネーブルのたびにドライバへ送信されるインタラプト通知を有することは、プラットフォームに対して有意な性能影響を有しうる。幾つかの実施形態では、ディスプレイドライバ９２０は、それ自身の処理精度時間で（例えば、受信されるＶｂｌａｎｋインタラプト信号９７４に基づくＶｂｌａｎｋで）このレジスタを読み出すよう動作する。幾つかの実施形態では、ディスプレイドライバ９２０の挙動は、データ送信の期待される存続期間及びフレーム損傷に基づく。このために、“エネルギ採算（energy break-even）”（ＥＢＥ）時間は、ディスプレイパイプラインが、低電力モードに入るために費やされるエネルギ量（Ｅ_ｅｎｔ）及び低電力モードから出るために費やされるエネルギ量（Ｅ_ｅｘｉｔ）を埋め合わせるのに十分なエネルギ節約を達成するよう低電力モードのままであるべき最小時間として定義される。エネルギ採算時間は、次のように表される：

幾つかの実施形態では、損傷が存在し、且つ、期待されるアイドル存続期間（ＩＩＭレジスタ９３０に書き込まれている。）がディスプレイＥＢＥよりも長い場合に、ディスプレイドライバ９２０は、損傷長方形をＤＣＴ活動レジスタ９３２に設定し、電力管理ユニット９４０にディスプレイコントローラへの電力を外すよう知らしめるよう動作する（図１０において示されるＤＤ Ｒｅｓｐ１００６及びＤＣＴ ＰＷＲビット１００８）。ディスプレイドライバ９２０は、ＤＣＴ活動レジスタ９３２におけるビジービットをモニタすることができ、それがクリアされた後、ＤＣＴの電力を外すことができる。幾つかの実施形態では：
（１）損傷が存在せず、且つ、アイドル存続期間がＥＢＥ時間よりも長い場合に、ディスプレイドライバ９２０は、ビットをＤＤ Ｒｅｓｐ１００６及びＤＣＴ ＰＷＲ１００８に設定し、電力管理ユニット９４０は、フレーム自体においてディスプレイコントローラ９４４への電力を外す。

（２）期待されるアイドル存続期間がＥＢＥ時間よりも短い場合に、ＤＤ Ｒｅｓｐビット１００６は設定されず、且つ：
（ａ）スクリーン損傷が存在する場合は、ディスプレイドライバ９２０は、損傷部分をディスプレイへ送信するようＤＣＴレジスタ９３２において長方形を設定する。

（ｂ）スクリーン損傷がない場合は、長方形情報はＤＣＴレジスタ９３２において設定されない。幾つかの実施形態では、この挙動は通常、ディスプレイの低電力モードに入る時間が期待されるアイドル存続期間よりも長い場合に、続いて起こる。

（ＩＩ）Ｖｂｌａｎｋインターバル間のディスプレイ電力管理決定：幾つかの実施形態では、ディスプレイドライバ９２０がＩＩＭレジスタ９３０からプラットフォームＩＩＭ情報を読み出す場合に：
（１）期待されるアイドル存続期間がＥＢＥ時間よりも長く、且つ、損傷が存在する場合は、ディスプレイドライバ９２０は、現在の損傷長方形をＤＣＴ活動レジスタ９３２にポストし、ＤＤ Ｒｅｓｐビット１００６をＩＩＭレジスタ９３０に書き込むことによって電力管理ユニット９４０に知らせる。しかし、ディスプレイドライバ９２０はＤＣＴ ＰＷＲビット１００８を送信せず、従って、電力管理ユニット９４０は、現在のフレームにおいてディスプレイコントローラ９４４の電源オンをそのままにしておく。

（２）期待されるアイドル存続期間がＥＢＥ時間よりも長い場合に、損傷が存在するならば、ディスプレイドライバ９２０はＤＤ Ｒｅｓｐビット１００６を設定し、如何なる他の動作もとらない。

上記の（１）及び（２）のいずれの場合にも、任意に、次のＶｂｌａｎｋインタラプトを受信した後、プラットフォームがＩＩＭ状態にある場合は、電力管理ユニット９４０は、プロセッサのＣＰＵ（Central Processing Unit）を起動せずにディスプレイコントローラ９４４への電力を外すよう決定してよいが、電力管理ユニット９４０は、インタラプトの受信後に損傷が起こっていないと決定するために必要とされる。

（３）期待されるアイドル存続期間がＥＢＥ時間よりも短い場合は、動作はとられず、ＤＤ Ｒｅｓｐビット１００６は設定されない。

幾つかの実施形態では、Ｖｂｌａｎｋインターバル間で損傷データを取得するために、ディスプレイドライバとアプリケーションとの間のソフトウェアインターフェースに変更がなされる。幾つかの実施形態では、ディスプレイ機能は、ＩＩＭレジスタの読出時に、適切な応答動作がディスプレイパイプラインにおいて行われるように変更される。例えば、ＰＭＵファームウェア機能は、ＩＩＭポリシー決定をディスプレイドライバへ伝え、ＤＰＵドライバによって指示されるようにディスプレイコントローラのための電力及びクロックを管理するよう更新されてよい。

ディスプレイパネルに対するティア効果（tear effect）（複数のフレームからの情報が単一のフレームにおいて示される。）を低減する最適化として、アプリケーションがそれらのバッファデータをＶｂｌａｎｋ時のみにメイン・フレームバッファへコピーすべき特定のソフトウェアスタックにおいて、制約が存在する。幾つかの実施形態では、フレームバッファ損傷長方形がフレーム間にディスプレイコントローラへコミットされるよう求められる場合に、全ての未決のバッファコピーは、損傷コミットメントを達成するようこの時点で必要とされる。幾つかの実施形態では、コールバック機能メカニズムは、目下実行中である全てのアプリケーションから全ての未決のバッファコピーをフェッチするために利用されてよい。幾つかの実施形態では、未決のバッファコピーのフェッチングは、異なるバッファが異なるフレームにおいてコミットされ得るので、ユーザが見ることができるアーティファクトが存在しないことを確かにすることを含む。幾つかの実施形態では、ユーザが見ることができるアーティファクトが存在しないことを確かにすることがグラフィクスソフトウェアスタックに加えられる場合に、ディスプレイパイプラインのための更なる電力節約が可能である。

図１１は、電力管理の実施形態の動作を説明するタイミング図である。この図において、ディスプレイ及びシステム挙動が表される。図１１は、フレームが１６．６ミリ秒ごとに始まるよう表される典型的なディスプレイ活動１１１０のタイミングを含む。ＤＳＲ（Display Self-Refresh）（ディスプレイ・セルフリフレッシュ）を備える表示１１２０は、セルフリフレッシュ段階を設ける。ここで、ＤＳＲは、無活動の特定数の連続したフレームの後、ＤＣＴが電源を切断され、表示データがパネルへ送信されるところのディスプレイ電力管理のための旧（Ｇｅｎ−１）技術を参照する。ＤＳＲを備えるプラットフォーム活動１１３０は、Ｓ０１１３２からＩＩＭ１１３４状態へのプラットフォームの低減を表し、よって、電力消費の節約を可能にする。しかし、活動シナリオでは、ＤＳＲ期間に入ることを可能にするための無活動の設定された数の連続したフレームはめったに達成され得ず、よって、プラットフォームがＳ０状態のままである必要がある。

図１１は更に、Ｄ０１１４２（フルパワー活動表示状態）及びＤ０ｉｘ１１４０への電力低下（電力低下表示状態）での活動を表す、ＤＰＵを備えたディスプレイ活動１１４０のためのタイミングを表す。ＤＰＵは、損傷部分１１５２のような、スクリーン損傷活動１１５０において示される損傷領域のみを送信することによって、ＤＳＲへ機能強化を提供する。

次いで、図１１は、特定の、表示と無関係のプラットフォーム活動を含む、ＤＰＵを備えたプラットフォーム活動１１６０を表すタイミング図を提供する。しかし、図示されるように、移行１１６２のように、追加のデータの送信を必要とする損傷が存在していないので、データが送信されない期間にプラットフォームが起動し又は起動したままである状況が存在する。

幾つかの実施形態では、方法、装置、又はシステムは、ディスプレイ電力管理とプラットフォーム電力管理との間の協調により更なる電力低減を可能にするようＤＰＵ最適化１１７０を含む。表されるように、ＩＩＭ状態１１７２への前の移行に加えて、幾つかの実施形態では、方法、装置、又はシステムは、システムがＩＩＭ状態のままである期間を示す期間１１７４のような、電力低下状態への延長された移行又は新たな移行を提供する。幾つかの実施形態では、システムは、スクリーンデータの送信を必要とするスクリーン損傷が存在しないので、電力低下状態のままであってよく、プラットフォーム電力制御及びディスプレイ電力制御の協調により、システムは、Ｓ０電力状態への不必要な移行を行わない。

図１２は、ディスプレイドライバ電力管理モジュールの動作１２００の実施形態を説明するフローチャートである。幾つかの実施形態では、ディスプレイコントローラ及びディスプレイはステップ１２０２で起動されてよく、ＩＩＭ活動レジスタが読み出される（レジスタは周期的にポーリングされてよい。）。ステップ１２０６で、システムがＩＩＭへ移行することができないことをレジスタが示す場合は、動作は起こらず、システムは、次の時間周期にＩＩＭレジスタを読み出すステップ１２０４へ戻る。ステップ１２０６で、システムがＩＩＭへ移行することができる場合は、ステップ１２０８で、Ｖｂｌａｎｋインタラプトが受信されるかどうかが決定される。ここで：
（ａ）ステップ１２０８で、Ｖｂｌａｎｋインタラプトが受信され、且つ、ステップ１２１８で、エネルギ採算時間ＥＢＥが（ＩＩＭレジスタからの）期待されるアイドル存続期間よりも長い（低電力モードへ及びからの移行においてエネルギコストが存在することを示す。）場合は、ステップ１２２６で損傷長方形がディスプレイコントローラにおいて設定され、システムは、次の時間周期でＩＩＭレジスタを読み出すステップ１２０４へ戻る。ステップ１２０８で、ＥＢＥが期待されるアイドル存続期間よりも短く（低電力モードへ及びからの移行において潜在的なエネルギ節約が存在することを示す。）、且つ、ステップ１２２０で、スクリーン損傷が存在する場合は、ステップ１２２２で損傷長方形がディスプレイコントローラにおいて設定され、ステップ１２２４でＤＣＴ活動レジスタにおけるＤＤ応答及びＤＣＴ電力ビットが設定される。ステップ１２２０でスクリーン損傷が存在しない場合は、システムは、ＤＣＴ活動レジスタにおいてＤＤ応答及びＤＣＴ電力ビットを設定するステップ１２２４へ進む。

（ｂ）ステップ１２０８で、Ｖｂｌａｎｋインタラプトが受信されず、且つ、ステップ１２１８で、エネルギ採算時間ＥＢＥが期待されるアイドル存続期間よりも長い場合は、動作は起こらず、システムは、次の時間周期でＩＩＭレジスタを読み出すステップ１２０４へ戻る。ステップ１２１０で、ＥＢＥが期待されるアイドル存続期間よりも短く、且つ、ステップ１２１２で、スクリーン損傷が存在する場合は、ステップ１２１４で損傷長方形がディスプレイコントローラにおいて設定され、ステップ１２１６でＤＣＴ活動レジスタにおけるＤＤ応答ビットが設定される。ステップ１２１２でスクリーン損傷が存在しない場合は、システムは、ＤＣＴ活動レジスタにおいてＤＤ応答ビットを設定するステップ１２１６へ進む。

図１３は、電力管理ユニットモジュールの動作１３００の実施形態を説明するフローチャートである。幾つかの実施形態では、プラットフォームアイドル状態を推定することを含むプラットフォームの解析１３０２が行われる。ステップ１３０４で電力低下（ＩＩＭ）状態が可能でない場合は、動作は起こらず、システムはプラットフォームの解析へ戻る。ステップ１３０４で電力低下状態が可能である場合は、ステップ１３０６でＩＩＭレジスタはＩＩＭ値を設定される。ステップ１３０８でディスプレイドライバ（ＩＩＭレジスタのステータスを読み出すよう動作する。）からの応答がある場合は、ステップ１３１０で、ＩＩＭレジスタのＤＣＴ電力ビットが設定されるかどうかが決定される。設定される場合は、ステップ１３１２で、ＤＣＴ活動レジスタのビジービットの確認と、ディスプレイからの電力の除去とが行われる。ＩＩＭレジスタのＤＣＴ電力ビットがステップ１３１０で設定されない場合は、インタラプトが受信されるかどうかの決定１３１４によって示されるように、Ｖｂｌａｎｋインタラプトを待つ。Ｖｂｌａｎｋインタラプトを受信すると、システムがＩＩＭ状態にあるかどうかの決定１３１６が行われ、そうである場合は、ステップ１３１８でディスプレイコントローラへの電力が外される。システムがＩＩＭ状態にない場合は、プロセスは、プラットフォームを解析するステップ１３０２へ戻る。

図１４は、モバイルデバイス又は他のコンピューティングプラットフォームの実施形態を表す。この図では、本明細書と密接な関係にない特定の標準的且つよく知られている構成要素は図示されていない。幾つかの実施形態の下で、モバイルデバイス又は他のコンピューティングプラットフォーム（ここでは概してデバイスと呼ばれる。）１４００は、データの送信のためのインターコネクト若しくはクロスバー１４０５又は他の通信手段を有する。デバイス１４００は、情報を処理するためにインターコネクト１４０５と結合された１又はそれ以上のプロセッサ１４１０のような処理手段を有してよい。プロセッサ１４１０は、１又はそれ以上の物理プロセッサ及び１又はそれ以上の論理プロセッサを有してよい。インターコネクト１４０５は、簡単のために単一のインターコネクトとして表されているが、複数の異なるインターコネクト又はバスを表してよく、そのようなインターコネクトへの構成要素の接続は様々であってよい。図１４において示されるインターコネクト１４０５は、適切なブリッジ、アダプタ若しくはコントローラによって接続される如何なる１又はそれ以上の別個の物理バス、ポイント・ツー・ポイント接続、又はそれらの両方も表す抽象概念である。

幾つかの実施形態では、デバイス１４００は、プロセッサ１４１０によって実行される命令及び情報を記憶するメインメモリ及び他のメモリ（メモリバッファを含む。）１４１５としてランダムアクセスメモリ（ＲＡＭ）又は他の動的な記憶デバイス若しくは要素を更に有する。メモリ１４１５は、ビデオデータの記憶のための１又はそれ以上のフレームバッファを有してよい。メモリ１４１５はまた、データストリーム又はサブストリームのためのデータを記憶するために使用されてよい。ＲＡＭメモリは、メモリ内容のリフレッシュを必要とする動的ランダムアクセスメモリ（ＤＲＡＭ）と、内容をリフレッシュすることを要さないがコストが高い静的ランダムアクセスメモリ（ＳＲＡＭ）とを含む。ＤＲＡＭメモリは、信号を制御するようクロック信号を含む同期型動的ランダムアクセスメモリ（ＳＤＲＡＭ）と、拡張データ出力型動的ランダムアクセスメモリ（ＥＤＯ ＤＲＡＭ）とを含んでよい。デバイス１４００はまた、プロセッサ１４１０のための静的な情報及び命令を記憶する読出専用メモリ（ＲＯＭ）１４２５又は他の静的な記憶デバイスを有してよい。デバイス１４００は、ある要素の記憶のために、例えばフラッシュメモリを含む１又はそれ以上の不揮発性メモリ要素１４３０を有してよい。

更に、データ記憶装置１４２０が、情報及び命令を記憶するために、デバイス１４００のインターコネクト１４０５へ結合されてよい。データ記憶装置１４２０は、磁気ディスク、光ディスク及びその対応するドライブ、又は他のメモリデバイスを含んでよい。そのような要素は結合されてよく、あるいは、別個の構成要素であって、デバイス１４００の他の要素の部分を利用してよい。

幾つかの実施形態では、システムのメモリは、特定のレジスタ又は他の特別な目的のメモリ１４３５を含んでよい。幾つかの実施形態では、レジスタ１４３５は、図９及び１０において表される９３０のようなＩＩＭレジスタ１４３６と、図９において表されるレジスタ９３２のようなディスプレイコントローラ活動レジスタ１４３７とを含んでよい。

幾つかの実施形態では、デバイス１４００は、デバイスにおける電力の管理のための電力管理ユニット１４７０を更に有してよく、電力管理ユニット１４７０は、デバイスプラットフォームの電力管理に関連してＩＩＭレジスタ１４３６にアクセスしてよい。幾つかの実施形態では、デバイス１４００は、ディスプレイ１４４２と結合されたディスプレイコントローラ１４４０を更に有してよく、ディスプレイコントローラ１４４０は、ディスプレイコントローラ活動レジスタ１４３７にアクセスしてよい。幾つかの実施形態では、デバイス１４００は、ディスプレイコントローラ１４４０がディスプレイ１４４２へ能動的に更新を提供していない場合に低電力状態へのデバイスの移行を可能にするために、プラットフォーム電力制御をディスプレイ電力制御と協調させるよう動作する。幾つかの実施形態では、ディスプレイ１４４２は、ユーザに情報又はコンテンツを表示する液晶ディスプレイ（ＬＣＤ）又はその他のディスプレイ技術を有してよい。幾つかの環境では、ディスプレイ１４４２は、入力デバイスの少なくとも一部としても利用されるタッチスクリーンを有してよい。幾つかの環境では、ディスプレイ１４４２は、オーディオ情報を提供するスピーカのようなオーディオデバイスを有してよい。

更に、１又はそれ以上の送信器又は受信器１４４５がインターコネクト１４０５へ結合されてよい。幾つかの実施形態では、デバイス１４００は、データの受信又は送信のための１又はそれ以上のポート１４５０を有してよい。デバイス１４００は、無線信号によるデータの送信及び受信のための１又はそれ以上のアンテナ１４５５を更に有してよい。

デバイス１４００はまた、電力デバイス又はシステム１４６０を有してよく、それは、電力を供給又は生成するための電源、バッテリ、太陽電池、燃料電池、又は他のシステム若しくはデバイスを有してよい。電力デバイス又はシステム１４６０によって供給される電力は、デバイス１４００の要素へ必要とされるように分配されてよい。幾つかの実施形態では、電力管理ユニット１４７０は、プラットフォーム電力制御とディスプレイ電力制御との協調を通じて電力デバイス又はシステム１４６０からの電力の消費を制御するよう動作する。

上記において、説明のために、多数の具体的な詳細が、本発明の全体的な理解を提供するために挙げられている。しかし、当業者には明らかなように、本発明は、それらの具体的な詳細のいずれにもよらずに実施されてよい。他の事実において、よく知られている構造及びデバイスは、ブロック図形態において示される。表される構成要素間には中間構造物が存在する。ここで記載又は図示される構成要素は、図示又は記載されていない更なる入力又は出力を有してよい。

様々な実施形態は様々なプロセスを有してよい。それらのプロセスは、ハードウェア構成要素によって実施されてよく、あるいは、コンピュータプログラム又は機械により実行可能な命令において具現されてよい。コンピュータプログラム又は機械により実行可能な命令は、命令によりプログラミングされた汎用の又は特別な目的のプロセッサ又は論理回路にプロセスを実行させるために使用されてよい。代替的に、プロセスは、ハードウェア及びソフトウェアの組み合わせによって実施されてよい。

様々な実施形態の部分は、コンピュータプログラムプロダクトとして提供されてよく、コンピュータプログラムプロダクトは、特定の実施形態に従うプロセスを実施するよう１又はそれ以上のプロセッサによる実行のためにコンピュータ（又は他の電子機器）をプログラミングするために使用されるコンピュータプログラム命令を記憶したコンピュータ可読媒体を含んでよい。コンピュータ可読媒体は、磁気ディスク、光ディスク、コンパクトディスク読出専用メモリ（ＣＤ−ＲＯＭ）、及び光学磁気ディスク、読出専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、消去可能なプログラム可能読出専用メモリ（ＥＰＲＯＭ）、電気的消去可能なプログラム可能読出専用メモリ（ＥＥＰＲＯＭ）、磁気若しくは光学カード、フラッシュメモリ、又は電子命令を記憶するのに適した他のタイプのコンピュータ可読媒体を含んでよいが、それらに限られない。更に、実施形態は、コンピュータプログラムプロダクトとしてダウンロードされてもよく、このとき、プログラムは、遠隔のコンピュータから要求元のコンピュータへ転送されてよい。

多くの方法はそれらの最も基本的な形態において記載されているが、本発明の基本的な適用範囲から逸脱することなしに、プロセスは、方法のいずれかに付加され又は方法のいずれかから削除されてよく、情報は、記載されるメッセージのいずれかに付加され又はメッセージのいずれかから減じられてよい。当業者には明らかなように、多くの更なる変更及び改作がなされてよい。特定の実施形態は本発明を制限するために提供されるのではなく、それを説明するために提供される。本発明の実施形態の適用範囲は、先に与えられている具体例によって決定されるべきではなく、添付の特許請求の範囲によってのみ決定される。

要素“Ａ”が要素“Ｂ”へ又はと結合されると言われる場合に、要素Ａは要素Ｂへ直接結合されるか、又は、例えば要素Ｃを通じて、間接的に結合されてよい。明細書又は特許請求の範囲が、構成要素、特徴、構造、プロセス、又は特性Ａが構成要素、特徴、構造、プロセス、又は特性Ｂを“引き起こす”と述べる場合に、それは、“Ａ”が“Ｂ”の少なくとも部分的な原因であることを意味するが、“Ｂ”を引き起こすのを支援する少なくとも１の他の構成要素、特徴、構造、プロセス、又は特性が更に存在してもよい。明細書が、構成要素、特徴、構造、プロセス、又は特性は“含まれてよい”又は“含まれ得る”と示す場合に、その特定の構成要素、特徴、構造、プロセス、又は特性は含まれる必要がない。明細書又は特許請求の範囲が“１”又は“１つ”の要素に言及する場合に、これは、記載される要素がただ１つしか存在しないことを意味するわけではない。

実施形態は、本発明の実施又は例である。“実施形態”、“一実施形態”、“幾つかの実施形態”又は“他の実施形態”との明細書中の言及は、その実施形態に関連して記載される特定の特徴、構造又は特性が少なくとも幾つかの実施形態において含まれるが、必ずしも全ての実施形態に含まれるわけではないことを意味する。“実施形態”、“一実施形態”又は“幾つかの実施形態”の様々な出現は、必ずしも全て同じ実施形態に言及しているわけではない。当然に、本発明の例となる実施形態の上記の記載において、種々の特徴は時々、様々な発明態様の１又はそれ以上の理解を助け且つ本開示を簡素化するために、単一の実施形態、図、又は説明にまとめられる。しかし、このような開示法は、請求される発明が、各請求項において明示的に挙げられている以外の更なる特徴を必要とするとの意図を反映すると解されるべきではない。むしろ、添付の特許請求の範囲が反映するように、発明態様は、単一の先に開示されている全てに満たない実施形態にある。よって、特許請求の範囲はこれにより本開示に明示的に組み込まれ、各特許請求の範囲は本発明の別個の実施形態として自立している。

Claims (30)

1. フレームバッファからビデオディスプレイへピクセルデータを転送するディスプレイコントローラと、
   前記フレームバッファの更新を追跡し、前の画像から変更された前記ピクセルデータの部分を特定する検出部と
   を有し、
   前記ディスプレイコントローラは、特定された前記ピクセルデータの部分を前記ビデオディスプレイに供給する、
   装置。
2. 前記ピクセルデータの部分は、長方形のピクセルデータである、
   請求項１に記載の装置。
3. 前記ディスプレイコントローラは、前記前の画像から変更されていない前記ピクセルデータの少なくとも一部を供給することなしに部分的な更新データを前記ビデオディスプレイへ供給する、
   請求項１に記載の装置。
4. 当該装置のための電力管理を提供する電力管理ユニットを更に有し、
   前記電力管理ユニットは、前記ディスプレイコントローラが前記ビデオディスプレイのための保留中のビデオデータを有するかどうかに少なくとも部分的に基づき、当該装置を電力低下状態に移行すべきかどうかを決定する、
   請求項１に記載の装置。
5. 当該装置のための電力管理に関する情報を含む第１のメモリ部と、
   前記ディスプレイコントローラがデータを前記ビデオディスプレイへ転送するようスケジューリングされているかどうかに関する情報を含む第２のメモリ部と
   を更に有する請求項１に記載の装置。
6. 前記第１のメモリ部及び前記第２のメモリ部はレジスタである、
   請求項５に記載の装置。
7. 前記電力管理ユニットは、当該装置が電力低下状態に入れる態勢にあることをディスプレイドライバに示すよう前記第２のメモリ部を利用する、
   請求項５に記載の装置。
8. 前記電力管理ユニットは更に、前記電力低下状態へ移行することによって節約できるエネルギが、前記電力低下状態の内外に移行するために使用されるエネルギを埋め合わせるのに十分であるかどうかに少なくとも部分的に基づき、当該装置を前記電力低下状態に移行すべきかどうかを決定する、
   請求項４に記載の装置。
9. 前記電力低下状態は、中間にあるアイドルモード電力状態である、
   請求項４に記載の装置。
10. モバイルデバイスである請求項１に記載の装置。
11. 第１の画像のためのビデオデータの第１の組を第１のデータフレームについてビデオディスプレイへ送信するステップと、
    前記ビデオデータの第１の組のいずれかの部分が変更されたかどうかを決定するステップと、
    前記ビデオデータの部分が変更された場合は、変更された前記ビデオデータの部分を表すビデオデータの第２の組を生成するステップと、
    前記ビデオデータの第２の組を第２のデータフレームについて前記ビデオディスプレイへ送信するステップと
    を有する方法。
12. 前記ビデオディスプレイで該ビデオディスプレイのための第２の画像を生成するステップを更に有し、
    前記第２の画像は、前記ビデオデータの第２の組によって変更された前記第１の画像である、
    請求項１１に記載の方法。
13. 前記ビデオデータの第２の組は、前記第１のデータフレームから変化した前記第１の画像の長方形を有する、
    請求項１１に記載の方法。
14. 前記ビデオディスプレイのための保留中のビデオデータが存在するかどうかに少なくとも部分的に基づき、電力低下状態へ移行すべきかどうかを決定するステップ
    を更に有する請求項１１に記載の方法。
15. 第１のレジスタは、プラットフォーム電力管理に関する情報を含む、
    請求項１４に記載の方法。
16. 第２のレジスタは、前記ビデオディスプレイのために保留中のビデオデータが存在するかどうかを特定する情報を含み、
    前記電力低下状態へ移行すべきかどうかを決定するステップは、前記第２のレジスタから情報を読み出すことを含む、
    請求項１４に記載の方法。
17. 前記電力低下状態へ移行すべきかどうかを決定するステップは、前記電力低下状態へ移行することによって節約できるエネルギが、前記電力低下状態の内外に移行するために使用されるエネルギを埋め合わせるのに十分であるかどうかを決定することを更に含む、
    請求項１６に記載の方法。
18. 前記電力低下状態は、中間にあるアイドルモード電力状態である、
    請求項１１に記載の方法。
19. ビデオディスプレイと、
    前記ビデオディスプレイのためのディスプレイドライバと、
    前記ビデオディスプレイのためのピクセルデータを保持するフレームバッファを含む動的ランダムアクセスメモリと、
    前記フレームバッファから前記ビデオディスプレイへピクセルデータを転送するディスプレイコントローラと、
    前記フレームバッファの更新を追跡し、前の画像から変更された前記ピクセルデータの部分を特定する検出部と
    を有し、
    前記ディスプレイコントローラは、特定された前記ピクセルデータの部分を前記ビデオディスプレイに供給する、
    システム。
20. 前記ビデオディスプレイのためのピクセルデータを保持する遠隔フレームバッファ
    を更に有する請求項１９に記載のシステム。
21. 前記ピクセルデータの部分は、長方形のピクセルデータである、
    請求項１９に記載のシステム。
22. 前記ディスプレイコントローラは、前記前の画像から変更されていない前記ピクセルデータの少なくとも一部を供給することなしに部分的な更新データを前記ビデオディスプレイへ供給する、
    請求項１９に記載のシステム。
23. 前記ビデオディスプレイは、更新が前記画像に対してなされない場合に前記画像を留保するよう動作する、
    請求項２２に記載のシステム。
24. 当該システムのための電力管理を提供する電力管理ユニットを更に有し、
    前記電力管理ユニットは、前記ディスプレイコントローラが前記ビデオディスプレイのための保留中のビデオデータを有するかどうかに少なくとも部分的に基づき、当該システムを電力低下状態に移行すべきかどうかを決定する、
    請求項１９に記載のシステム。
25. 当該システムのための電力管理に関する情報を含む第１のメモリ部と、
    前記ディスプレイコントローラがデータを前記ビデオディスプレイへ転送するようスケジューリングされているかどうかに関する情報を含む第２のメモリ部と
    を更に有する請求項２４に記載のシステム。
26. 前記第１のメモリ部及び前記第２のメモリ部はレジスタである、
    請求項２５に記載のシステム。
27. 前記電力管理ユニットは、当該システムが電力低下状態に入る態勢にあることを前記ディスプレイドライバに示すよう前記第２のメモリ部を利用する、
    請求項２５に記載のシステム。
28. 前記電力管理ユニットは更に、前記電力低下状態へ移行することによって節約できるエネルギが、前記電力低下状態の内外に移行するために使用されるエネルギを埋め合わせるのに十分であるかどうかに少なくとも部分的に基づき、当該システムを前記電力低下状態に移行すべきかどうかを決定する、
    請求項２４に記載のシステム。
29. 前記電力低下状態は、中間にあるアイドルモード電力状態である、
    請求項１９に記載のシステム。
30. モバイルデバイスである請求項１９に記載のシステム。

Images