コンピューティングデバイスのための動的低電力モード実装
態様は、使用されていないリソースと、許容できるシステムレイテンシと、動的動作条件(たとえば、温度)と、予想アイドル時間と、特定のデバイスの固有の電気的特性とに応じて、確実に機能し続けながら、選択されたリソースを低電力モードにすることによって、コンピューティングデバイスまたはマイクロプロセッサが、最も多くのシステム電力節約を与える低電力モードを判断することを可能にする。態様は、プロセッサがアイドル状態に入ったときに、どの低電力モードが有効であるかを判断することと、現在のデバイス条件が与えられたときに予想される電力節約によって有効な低電力モードをランク付けすることと、レイテンシ要件を満たしながら、どの有効な低電力モードが最も大きい電力節約を与えるかを判断することと、各リソースが入るべき特定の低電力モードを選択することとによって、コンピューティングデバイス内の様々なリソースについて低電力モードのセットからなる最適な低電力構成を判断するための機構を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、その内容全体が参照により本明細書に組み込まれる、2010年1月11日に出願された「Dynamic Low Power Mode Implementation For Computing Devices」と題する米国仮特許出願第61/294,055号の優先権の利益を主張する。
【背景技術】
【０００２】
ワイヤレス通信技術は、過去数年にわたって爆発的成長を経験してきた。この成長は、モバイル大衆に移動の自由を与え、有線通信システムへの束縛を断ち切る、ワイヤレスサービスによって加速された。サービス拡張の結果として、ワイヤレスサービスの流行は急速に成長し続けることが予想される。バッテリー寿命はモバイル電子デバイスの主要因であり、したがって、バッテリー電力の節約を可能にする方法およびデバイスが電子デバイス技術における重要な考慮事項である。
【発明の概要】
【課題を解決するための手段】
【０００３】
様々な態様は、コンピューティングデバイスのリソースにとって最適な、またはほぼ最適な低電力動作モードの組合せを選択するために、コンピューティングデバイス内のプロセッサによって使用または実装され得るデータおよび方法を提供する。様々な態様は、リソース構成要素が2つ以上のリソース電力モードを有することを可能にし、プロセッサが低電力またはスリープ状態に入ったときにシステム低電力モードを動的に構成するために、動作状態と動作条件とスリープサイクル特性と他のファクタとに基づいて、プロセッサが様々なリソースの各々について電力モードを選択することを可能にする。様々な態様は、実効レイテンシがすべてのアクティブタスクのシステム全体のレイテンシ要件を超えないであろう様々なリソースまたはリソースの組合せを識別するために、プロセッサがそれらのリソースの低電力モードおよびリソース低電力モードの組合せを評価することを可能にする。様々な態様は、プロセッサが、すべてのアクティブタスクのシステム全体のレイテンシ要件を満たしながら、電力節約を最大にするシステム低電力構成において実装すべきリソース低電力モードの組合せを選択し、あらかじめ定義された低電力構成のセットから選択する代わりに、動的に(すなわち、スリープサイクルの時間に)この選択を行うことを可能にする。様々な態様は、プロセッサが、現在の条件と動作状態とに対して最適化された最適低電力構成を判断するためにソルバープロセスによって使用されるルックアップテーブルを断続的に再計算することを可能にする。様々な態様は、プロセッサが、現在の状態と、アクティブなデバイスおよびアプリケーションと、予想されるスリープ持続時間とに好適な最適低電力構成を判断するために、コンピューティングデバイスの動作に関する統計的情報を利用することを可能にする。様々な態様は、プロセッサが、現在および過去の環境情報および使用情報に基づいて最適低電力構成を選択することを可能にする。
【０００４】
様々な態様は、コンピューティングデバイスにおける電力を温存するための方法を含み、方法は、リソースが使用されていないときリソースに関連するフラグビットを設定するステップであって、リソースが複数のリソースのうちの1つである、設定するステップと、プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得るリソースを識別するステップと、識別されたリソースの各々についてレイテンシ要件を登録するステップと、登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択するステップと、選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価するステップと、潜在的電力節約を最大にし、選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択するステップと、識別されたリソースの各々に対して選択された低電力モードの各々の入機能(enter function)を実行することによって低電力リソースモードの選択された組合せに入るステップとを含む。本態様方法では、低電力リソースモードの組合せを選択するステップが、様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行するステップを含み得る。本態様方法は、プロセッサがアイドル状態のままであることが予想される時間を判断するステップと、現在温度における単位時間当たりの潜在的電力節約×判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの潜在的電力節約を判断するステップとをさらに含み得る。本態様方法は、デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定するステップと、測定のためのリソースを選択するステップと、選択されたリソースを低電力リソースモードにするステップと、選択されたリソースが低電力リソースモードにある間、電流または電力需要を測定するステップと、低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップ、選択されたリソースを低電力リソースモードにするステップ、および選択されたリソースが低電力リソースモードにある間、電流または電力需要を測定するステップを繰り返すステップとをさらに含み得、潜在的電力節約を最大にする低電力リソースモードの組合せを選択するステップが、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する測定された電流または電力需要を使用するステップを含む。本態様方法は、異なる温度において請求項3に記載の動作を繰り返すステップと、各低電力リソースモードに関連する電流または電力需要の温度感度を判断するステップとをさらに含み得、潜在的電力節約を最大にする低電力リソースモードの組合せを選択するステップが、コンピューティングデバイスの温度を測定するステップと、測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の判断された温度感度を使用するステップとをさらに含む。本態様方法では、低電力モードにされ得る各リソースについて低電力リソースモードを評価するステップが、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成するステップを含み得、動作条件は温度値を含み得る。本態様方法は、コンピューティングデバイス上で動作条件に関する統計を収集するステップと、収集された動作条件統計に基づいて低電力モード選択データテーブルを更新するステップとをさらに含み得る。本態様方法では、動作条件は、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択され得る。本態様方法は、コンピューティングデバイスが外部電力に接続されているかどうかを判断するステップであって、コンピューティングデバイスが外部電力に接続されているとき、動作条件統計に基づいて低電力モード選択データテーブルを更新するステップが達成される、判断するステップをさらに含み得る。
【０００５】
様々な態様はまた、上記の態様方法の機能を実行するための手段を含むコンピューティングデバイスを含む。
【０００６】
様々な態様はまた、メモリバッファとメモリバッファに結合されたプロセッサとを含むコンピューティングデバイスにおける電力を温存するための装置を含み、プロセッサは、上記の態様方法の動作を実行するためのプロセッサ実行可能命令で構成される。
【０００７】
様々な態様はまた、上記の態様方法の動作を含む、コンピューティングデバイスにおける電力を温存するための動作をプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を記憶した非一時的記憶媒体を含む。
【０００８】
本明細書に組み込まれ、本明細書の一部をなす添付の図面は、本発明の例示的な実施形態を示し、上記の概略的な説明および下記の発明を実施するための形態とともに、本発明の特徴を説明するのに役立つ。
【図面の簡単な説明】
【０００９】
【図１】一態様における2つの低電力モードのうちの1つに入るようにプログラミングノードによって制御されるリソースの図である。
【図２】一態様による、共用リソースが、低電力モードに入るそれの能力を登録する方法のプロセスフロー図である。
【図３】一態様による、共有リソースが低電力モードを出る方法のプロセスフロー図である。
【図４】一態様による、低電力モードを選択し、低電力モードに入るための方法のプロセスフロー図である。
【図５】低電力モードを選択し、低電力モードに入るための態様方法を示すプログラミングノードおよびリソース図である。
【図６】低電力モードを選択し、低電力モードに入るための別の態様方法を示すプログラミングノードおよびリソース図である。
【図７】最適低電力モードを選択するための態様方法のプロセスフロー図である。
【図８Ａ】予想アイドル時間に基づいて最適低電力モードを選択するための態様方法を示す3つの代替低電力モードの電力節約対アイドル時間のグラフである。
【図８Ｂ】予想アイドル時間に基づいて最適低電力モードを選択するための態様方法を示す3つの代替低電力モードの電力節約対アイドル時間のグラフである。
【図９Ａ】最適低電力モードを選択するための代替態様方法のプロセスフロー図である。
【図９Ｂ】最適低電力モードを選択するための代替態様方法のプロセスフロー図である。
【図１０】最適低電力モードを選択するための代替態様方法のプロセスフロー図である。
【図１１】コンピューティングデバイスが外部電力に接続されているかどうかに基づいて、最適低電力モードを選択するか、または低電力モード選択テーブルを更新するための代替態様方法のプロセスフロー図である。
【図１２】モバイルデバイスによって収集された統計に基づいてリソースの電力節約パラメータを更新するための態様方法のプロセスフロー図である。
【図１３】モバイルデバイスが、様々な低電力モードによって達成される電力節約に関する統計、ならびにアイドルモード電力節約に影響を及ぼす割込みおよびタイマーの分配に関する統計を収集し得る態様方法のプロセスフロー図である。
【図１４】モバイルデバイスが、各低電力リソースモードによって達成される測定された電力節約を収集し得る態様方法のプロセスフロー図である。
【図１５】一態様において使用するのに好適なモバイルデバイスの構成要素ブロック図である。
【発明を実施するための形態】
【００１０】
様々な態様について添付の図面を参照しながら詳細に説明する。可能な場合はいつでも、同じまたは同様の部分を指すために図面全体にわたって同じ参照番号を使用する。特定の例および実装形態になされる言及は、説明のためであり、本発明の範囲または特許請求の範囲を限定するものではない。
【００１１】
「例示的」という単語は、本明細書では、例、事例、または例示の働きをすることを意味するために使用する。本明細書に「例示的」と記載されたいかなる実施形態も、必ずしも他の実装形態よりも好ましいまたは有利であると解釈されるべきではない。
【００１２】
「モバイルデバイス」および「コンピューティングデバイス」という用語は、本明細書では、セルラー電話と、個人情報端末(PDA)と、パームトップコンピュータと、ワイヤレス電子メール受信機(たとえば、Blackberry(登録商標)およびTreo(登録商標)デバイス)と、マルチメディアインターネット対応セルラー電話(たとえば、Blackberry Storm(登録商標))と、Global Positioning System(GPS)受信機と、ワイヤレスゲームコントローラと、プログラマブルプロセッサを含み、電力節約方法が有益になるようにバッテリー電力の下で動作する同様のパーソナル電子デバイスとのうちのいずれか1つまたはすべてを指すために互換的に使用する。
【００１３】
本明細書で使用する「リソース」という用語は、多種多様な回路(たとえば、ポート、クロック、バス、発振器など)と、構成要素(たとえば、メモリ)と、信号(たとえば、クロック信号)と、コンピューティングデバイス上で実行されるプロセッサおよびクライアントをサポートするために使用される電圧(たとえば、電圧レール)とのうちのいずれかを指すために本明細書で使用する。
【００１４】
ワイヤレスデバイスのバッテリー寿命を最大にすることは、重要な設計基準である。バッテリー寿命を増加させることで、より長い時間ユーザがワイヤレスデバイスを用いてより多くのことを行うことを可能にすることによって、ユーザのエクスペリエンスを最大にする。しかしながら、ユーザのエクスペリエンスを真に最大にするために、デバイスの機能または信頼性を改変しないように電力節約ストラテジが実装されるべきである。したがって、機能を改変しない効率的で効果的な電力節約方式を設計することは、モバイルおよびワイヤレスデバイスプロバイダにとって重要な目的である。
【００１５】
バッテリー寿命を最大にするために、たいていのモバイルブロードキャスト受信機は、プロセッサがアイドル状態にあるときなど、可能な場合はいつでも、1つまたは複数のプロセッサおよびデバイスリソースを低電力状態にするように構成される。デバイスリソースを低電力状態にすることは、一般に、プロセッサがアクティブにタスクを処理していないときはいつでも、および/またはアイドル状態にあるときはいつでも様々なデバイスリソースをオフにすることからなる。プロセッサがタスクを処理していないときおよび/またはアイドル状態にあるときに、オフにされるか、あるいは1つまたは複数の低電力および/またはアイドル状態にされることが可能であるリソースを、本明細書では低電力リソース、またはLPRと呼ぶ。ワイヤレスモデムプロセッサおよびアプリケーションプロセッサを有し得るスマートフォンなど、マルチプロセッサデバイスでは、低電力モードを実装する動作は、独立して、または協調して各プロセッサによって達成され得る。
【００１６】
モバイルコンピューティングデバイスは、一般に、水晶発振器、電圧レール、1つまたは複数のメモリユニット、通信バスなど、デバイスプロセッサが使用するいくつかのリソースを含む。コンピューティングデバイスが一層複雑になっているので、デバイスプロセッサによって使用または管理されるリソースの数は毎年増加している。たとえば、多くのモバイルコンピューティングデバイスは、現在、複数の水晶発振器と、複数の電圧レールと、複数のメモリとを含み、それらの各々は独立して制御され得る。したがって、電力を温存するために、コンピューティングデバイスプロセッサがオフにし得るかまたは低電力モードにし得る多くの異なるリソースがある。また、コンピューティングデバイスは、様々なデバイスリソースを使用し、異なるタスクを実行する(したがって、同時にアイドル状態でないことがある)複数のプロセッサを有し得る。これらの理由のために、低電力モードにされるべきリソースを選択するときに、ある程度の制御の実行が行使されなければならない。低電力モードにすべきリソースを選定することは「スリープ問題」として知られている。
【００１７】
概して、プロセッサが安定アイドル状態に入ったときなど、プロセッサがリソースをもはや必要としないとき、プロセッサは、低電力リソースのエネルギー消費のニーズをオフにするか、無効化するか、アイドリングするか、または場合によっては低減し得る。プロセッサが「起動する」(たとえば、別のプロセスを実行するためにアイドル状態を出る)とき、リソースは、オンに戻され、再有効化され、および/または許容できる動作状態に戻されなければならない。しかしながら、各低電力リソースは、異なる電力消費レベルとレイテンシ特性(すなわち、リソースを完全電力モードに戻すために必要とされる時間)とを有し得、そのような特性は、温度および動作状態とともに変化し得る。すなわち、各リソースは、それらの様々な低電力モードで異なる電力量を消費し得、電源切断状態、アイドル状態および/または低電力状態に入り、それを出るために異なる時間量を必要とし得、そのような状態に入り、それを出るときに異なる電力量を消費し得る。明快のために、リソースの各々にとって利用可能な様々な低電力モードを、本明細書では、低電力リソースモードまたはLPRMと呼ぶ。
【００１８】
リソースをそれの要求される動作状態に戻すために必要とされる電力が、プロセッサアイドル状態の推定された持続時間の間リソースを低電力モードにすることによって節約される電力よりも大きい場合、ワイヤレスデバイスのバッテリー寿命は、プロセッサがアイドル状態のときはいつでもリソースをオフにし、および/またはリソースを低電力状態にするだけでは、最大にされないことがある。したがって、どの低電力リソースがオフにされ、および/または低電力モードにされるべきか、ならびに各リソースがなるべき特定の低電力モードを判断するスリープ問題は、一般に、レイテンシ、電力節約可能性、電力消費および相互依存性などの各リソースの低電力モード特性とともに、そのプロセッサ状態ならびに他のデバイスプロセッサの状態の分析を必要とする。また、リソース低電力モード特性は、温度などの動作条件によって影響を及ぼされ得、したがって、そのような条件も評価されるべきである。
【００１９】
上記で説明したように、各リソースは、リソースがなり得る低電力モードまたはLPRMのセットを有し得る。各リソースの各低電力リソースモードは、それのレイテンシ、電力節約可能性、遷移電力消費、低電力モード入基準(mode entrance criteria)、モード出基準(mode exit criteria)およびリソース相互依存に関して特徴づけられ得、それらの一部または全部は、温度および他の動作条件とともに変動し得る。リソースは、その各々が、異なる電力節約特性および待ち時間(latency time)を有し得る2つ以上の低電力リソースモードを有し得る。たとえば、リソースについての1つの低電力リソースモードは、そのリソースを完全に無効化し得る(たとえば、電力を遮断する)が、第2の低電力リソースモードは、リソースの機能または周期動作の低減に関与し得る。各低電力リソースモードは、単位時間ごとに異なる電力節約を行うこと、そのモードに入り、それを出るために異なる時間量(すなわち、異なるレイテンシ要件)を必要とすることなど、異なる動作特性を有し得る。たとえば、揮発性メモリチップは、以下の2つの低電力リソースモード、すなわち、最小電力量を消費するが、動作状態に戻るためにより大きい時間(すなわち、より大きいレイテンシ)を必要とするディープ電源切断モード(deep power-down mode)と、ある程度のバッテリー電力を消費し続けるが、より低いレイテンシを有する(すなわち、それは極めて迅速に完全機能状態に戻ることができる)自己リフレッシュモード(self-refresh mode)とを有し得る。さらに、各低電力リソースモードによって与えられる電力節約は、温度および予想アイドル時間などの動作条件に依存し得る。したがって、いくつかの態様では、低リソース電力モードは、予想される電力節約を、現在温度における単位時間当たりの潜在的電力節約に、判断された予想アイドル時間を乗算した積として計算し得る。他の態様では、予想される電力節約は、温度と予想アイドル時間と他の変数との別の関数として判断され得る。
【００２０】
上述のように、リソースを低電力モードにし、プロセッサの起動時にリソースを通常モードに回復することは、しばしば、達成するのに電力と時間(すなわち、レイテンシ)の両方がかかる何らかの作業を必要とする。低電力リソースモードに入るのに必要な追加の電力および時間は、システムがアイドル状態のままである時間量が短すぎる場合、実際の電力節約を生じないことがある。言い換えれば、リソースを低電力リソースモードにし、リソースを完全動作に戻す際に消費される電力は、リソースが低電力モードにあった短い時間中に節約された電力よりも多くなり得る。したがって、特定の低電力リソースモードに入る利益は、プロセッサがアイドル状態のままであり得る予想される時間に依存し得る。この時間を、本明細書では「予想アイドル時間」と呼ぶ。
【００２１】
リソースを低電力リソースモードにすることによって節約され得る電力量は、動作モードの特性、および必要とされるリソースの特性に基づいて、ならびにリソースがそのモードのままである時間量に基づいて変動する。たとえば、メモリチップを自己リフレッシュ低電力モードにすることは、自己リフレッシュプロセスに関連する電力を消費し、ならびにチップへの電力の可用性を必要とし得る。したがって、特定の低電力リソースモードでの利用可能な電力節約は、所与のスリープサイクルにおいて実装すべき低電力リソースモードの組合せを決定するために、複数の低電力リソースモードの中から選択する際に考慮すべき重要な特性である。
【００２２】
上述のように、リソースを特定の低電力リソースモードにすることによって節約され得る電力量も、温度など、環境ファクタおよび動作ファクタに依存し得る。温度はデバイス内の電気抵抗に影響を及ぼす。したがって、(低電力構成が事前に展開されるときに仮定されなければならない)室温における各リソースの異なる低電力リソースモードに関連する電力節約は、デバイスがはるかに低温になる場(たとえば、アラスカ州の冬の間)にあるか高温になる場(たとえば、テキサス州の夏の間)にあるかで異なり得る。したがって、現実の条件での異なる低電力構成(すなわち、低電力リソースモードの選択されたセット)の電力節約は、現実の最適低電力モードが、事前に予期され得るものとは異なることを意味し得る。デバイスの温度は事前に知られ得ないので、この重要な特性は、低電力モードを編成および選択するための従来の方法を使用して、利用可能な低電力リソースのための低電力リソースモードの組合せを選択するために使用され得ない。
【００２３】
電力を節約することが、電子デバイスのための低電力モードを構成する際の重要な目的であるが、デバイスが低電力モードに入った後に適切に動作し続けることを確実にすることも考慮されるべきである。したがって、各低電力リソースモードに関連するレイテンシの考慮も重要である。上述のように、低電力リソースモードに入り、それを出て、リソースを通常動作モードに戻すために、ある時間量が必要とされる。この待ち時間は予想アイドル時間未満であるべきであり、さもなければ低電力モードはほとんど無益になる。より有意には、低電力リソースモードまたは低電力リソースモードの選択された組合せを出ることに関連するレイテンシは、1つまたは複数のリソースが低電力モードにあるときにその1つまたは複数のリソースを要求し得るクライアントまたはプロセッサの最大許容システムレイテンシよりも小さくなければならない。特定の低電力リソースモード、または低電力リソースモードの組合せを出ることに関連するレイテンシがシステムの許容できるレイテンシを超えた場合、特定のシステム低電力構成は、機能エラーにつながるか、または何らかの無関係な技術が間違って機能することになるので、許容できないことがある。
【００２４】
レイテンシ要件がスリープ問題における重要な考慮事項である状況の例は、ユニバーサルシリアルバス(USB)コネクタがモバイルデバイスに接続されているときである。USBプロトコルは、一般に極めて短いレイテンシ要件を有し、ホストがそのレイテンシ内にリソース要求への応答を受信しない場合、ホストは、デバイスが故障していると結論し得る。したがって、現在の動作構成がUSBデバイスへの接続を含むとき、出レイテンシ(exit latency)がUSBレイテンシ要件よりも大きい、リソースの低電力リソースモードまたは低電力リソースモードの組合せに入れられるべきではない。
【００２５】
レイテンシおよび動作条件に加えて、リソースの低電力モードは、他のリソースおよび/または条件にも依存し得る。そのようなリソース相互依存性考慮事項を、本明細書では概して「依存性」と呼ぶ。これらの依存性は、相互依存し得る(すなわち、別のリソースが利用可能のままである場合のみ、そのモードが有効化され得る)か、排他的であり得る(すなわち、特定の他のリソースが低電力モードまたは高電力モードにある場合、そのモードに入ることができない)か、または直交であり得る(すなわち、それらのモードは、互いとの関係を有さず、独立して有効化され得る)。また、低電力モード依存性は、「静的」または「動的」のいずれかであるとして分類され得る。静的依存性は、リソースが、特定の低電力モード動作を実装することさえも考慮し得る前に満たされなければならない条件を定義するものである。動的依存性は、他方では、1つのモードがシステム中の別のモードと併せて実装され得るときのみに生じ、それは、一般にランタイムにおいてのみ判断できる。
【００２６】
静的依存性はある程度の確度で予期され得るが、動的依存性は前もって判断するのが難しい。さらに、構成要素および/またはリソースの数が増加するにつれて、動的依存性は指数関数的により複雑になる。現代のワイヤレスデバイスが、複雑さを増し続け、より多くの構成要素およびリソースを含むにつれて、低電力モードの動的依存性を効果的に管理することはますます重要になる。
【００２７】
したがって、リソースをアイドリングおよび/または無効化することによってバッテリー寿命を温存するようにデバイスを構成することは、電力節約の様々な低電力モード特性、様々なリソースのレイテンシおよび相互依存性、ならびに同時に実行され得るクライアントとプロセッサとアプリケーションとの要件を平衡させるために、リソースの異なる低電力リソースモードの中から選択することに関与する。この選択プロセスは、特にコンピューティングデバイスの複雑さが増加する際に考慮され得る変数および置換の数に起因する(古典的な「ナップザック」問題に類似している)計算量的に困難なタスクである。
【００２８】
現在、プロセッサおよび電子デバイスのための低電力モードは、優先度と予測可能な特性との静的セットに基づいて開発者によって事前に構成される。低電力構成の1つまたは数個のセットは、開発中にプロセッサまたはシステムにハードコーディングされ得る。低電力モードのセットからの1つの低電力構成の選択は、現在、ハードコーディングされたif-then/else決定ツリープログラミングによって制御される。複数のあらかじめ定義されたシステム低電力モードが与えられたとき、動作クライアントが「投票(voting)」によってそれらの様々なリソース要件または動作条件を示すことを可能にすることによって、プロセッサは、様々なあらかじめ定義されたモードの中から選択し得る。クライアント投票の結果は、1つまたは複数の低電力モードを明示的に無効化することになり得る。
【００２９】
いくつかのあらかじめ定義されたシステム低電力モードの中から実装すべき1つのシステム低電力モードを選択するための既知のプロセスは、温度と予想アイドル時間とレイテンシ要件とを考慮し得る。しかしながら、そのような既知の方法はすべて、低電力モードにされ得るリソースの組合せを予期することによっていくつかの随意のシステムモードをあらかじめ定義し、それらの可能性のある相互依存性を評価し、それらのレイテンシを合計し、そのようなモードに入り得るときにシステム要件および制限を予期するように、システム、プロセッサまたはアプリケーション開発者に要求する。プロセッサおよびデバイスが比較的単純だったときには、低電力モード条件を予期し、選択が行われ得るシステムモードのセットをあらかじめ定義するプロセスが可能だったが、システムおよびプロセッサの複雑さが将来増加するにつれて、この設計問題が極めて困難になることが予期される。
【００３０】
コンピューティングデバイスにおけるシステム低電力モードを開発し、実装するための今日の方法は、デバイスの電流、ランタイム、動作条件(たとえば、温度)、レイテンシ要件または依存性を考慮に入れないことがある。さらに、そのような構成要素の動作状態が事前に予測され得ないので、低電力構成の現在の実装形態は、特定のデバイス構成にチューニングされず、各特定のクライアントの低電力リソースモードの各々の動的レイテンシ要件に明示的に対処しないことがある。したがって、低電力モードを開発し、実装する現在の方法は、一般に、事前に行われ得る推定に基づいてあらかじめ設定された数のシステム低電力構成(たとえば、アイドルモード、スリープモード、ディープスリープモードなど)を構成することと、開発者によって定義された選択基準に基づいて、システムを、システム低電力モードのうちの最良のシステム低電力モードにすることとを必要とする。今日の方法は、低電力リソースの各々ならびにプロセッサを、電力節約を十分に最大にする状態にする低電力リソースモードの組合せから構成されるリアルタイム低電力構成を動的に生成しないことがある。
【００３１】
前の世代のデバイスでは、プロセッサと対話し得る異なるリソースおよびクライアントの数が限定されおり、少数の異なる動作状態を予期することができたので、事前に低電力モードを構成することが妥当だった。しかしながら、現代の電子デバイスは、複数のプロセッサと多数のリソースと同時クライアントとに関与し、一層高度になっており、プロセッサにハードコーディングされ得る最適低電力モードを定義することがもはや可能でないことがある。さらに、if-then/else決定ツリープログラミングを使用する、前に定義されたシステム低電力モードの選択は、ほぼ2nに従ってスケーリングし、「n」は、その判断に関与するリソースおよびクライアントの数である。結果として、開発者は、事前にハードコーディングされ得る低電力構成のサブセットで妥協しなければならず、その低電力構成のサブセットは、すべてでないとしても、一部の動作状態では次善であり得る。開発者に次善の低電力構成を採用するように要求することにより、最適低電力モードが特定の動作条件について定義および実装され得る場合に通常ならば達成可能であろう電力節約よりも少ない電力節約を達成する電子デバイスになる。
【００３２】
低電力構成の現在のプログラミングの動作制限に加えて、システム低電力モードおよび/または構成のセット(たとえば、アイドル、スリープ、ディープスリープ)を事前に定義し、そのモードをプロセッサまたはアプリケーションにハードコーディングする作業は、著しい開発者作業を含む。さらに、低電力モードの高度セットをハードコーディングすることは、所与の時間にリソースの各々がなり得る様々な動作状態に対処せず、システム中のすべての構成要素の全体的な電力消費レベルと動作状態とに動的に応答することができるわけではない。システム低電力モードの定義はコード駆動型であり、データ駆動型ではないので、デバイス構成に行われる小さい変更、およびリソース低電力モードのセットに行われる小さい変更は、コード変更がデバイスエラーを生じないことを確認するために広範に再テストすることを必要とする。したがって、低電力モードを実装するための現在の方法は、製品の生産工程中に行われ得るデバイス構成(たとえば、構成要素、ソフトウェアなど)の変更に対応することができない。
【００３３】
これらおよび他の問題に対処するために、様々な態様は、個々の低電力リソースの各々ならびにプロセッサをシステム全体にわたる電力節約を十分に最大にする動作状態にするように、複数の低電力リソースから選択された低電力リソースモードの組合せから構成されるシステム低電力構成を動的に生成することを実現する。現在達成可能な電力節約のレベルに微調整され得る多数の低電力構成を提供するために、より多くの最適低電力構成選択がリアルタイムでプロセッサによって行われ得るように、様々な態様は、スリープ問題をデバイスプロセッサのために簡略化することを可能にする方法を提供する。様々な態様は、構成要素開発者が、それらの構成要素の各々について、使用中のリソースのタイプ、許容され得るワーストケースレイテンシ、動的動作条件(たとえば、温度)、予想アイドル時間、および構成要素レイテンシなど、様々なファクタを考慮に入れる様々な低電力リソースモードを定義することを可能にする。また、各リソースについて定義される低電力リソースモードは、静的依存性と動的依存性とを定義し得る。次いで、デバイスプロセッサは、ランタイムに、低電力リソースモードの組合せを動的に選択し得る。一態様では、デバイスプロセッサは、システム中の他のプロセッサおよび構成要素の要件を含む現在の動作要件を満たしながら、電力節約および/または動作速度を最大にするシステム低電力構成またはスリープ状態を生じる低電力モードの組合せを計算および選択し得る。
【００３４】
様々な態様はまた、無効化され得るリソース、ならびにデバイス低電力構成中にオンのままであるべきリソースを識別することによって、デバイスが1つまたは複数の低電力リソースモードを選択することを可能にする。様々な態様は、かなりのクライアント対話と余分のプロセッサアクションとを必要とすることなく機能的信頼性をサポートしながら、プロセッサがアイドル状態になるときにリソースにとって最適な、またはほぼ最適な低電力リソースモードのセットを選択するために、コンピューティングデバイス内のプロセッサによって使用され得るデータおよび方法を提供する。本態様は、プロセッサが、使用中のリソースと、許容され得るワーストケースレイテンシと、動的動作条件(たとえば、温度)と、予想アイドル時間と、低電力モードに入り、それを出るために必要とされる時間と、特定の電子デバイスの固有の電気的特性とに応じて、確実に機能し続けながら、最も多くのシステム電力節約を与えるシステム低電力構成を判断することを可能にする。
【００３５】
様々な態様は、プロセッサがアイドル状態に入ったときに、リソースの低電力リソースモードのいずれが有効であるかを判断することと、現在のデバイス状態を与えられたときに予想される電力節約によって有効な低電力リソースモードをランク付けすることと、レイテンシ要件を満たしながら、有効な低電力リソースモードのいずれが最も大きい電力節約を与えるかを判断することと、各リソースが入るべき特定の低電力リソースモードを選択することとによって、コンピューティングデバイス内の様々なリソースについて低電力リソースモードのセットからなる最適システム低電力構成を判断するための機構を提供する。そうすることによって、様々な態様は、固定のあらかじめ定義されたシステム低電力構成の概念を除去し、それにより、開発者が各リソースに別々に対処することを可能にすることによって開発者の問題を簡略化し、プロセッサがアイドル状態に入ったとき、プロセッサが、実装されるべき低電力リソースモードのセットを選択することを可能にすることによってスリープ問題をランタイムにシフトする。これは、低電力モードの実装が動作データによって駆動されることを可能にし、デバイスがどのように使用され、動作するかについて知ることによって、システム低電力モードを自己最適化する能力をプロセッサに与える。典型的な実装形態において、現在の方法に比較してより大きい電力節約を与えることに加えて、様々な態様はまた、電子デバイスの開発を簡略化する。
【００３６】
明快のために、また「低電力モード」と「低電力リソース」との間のあいまいさを除外するために、各低電力リソースが複数の低電力モードを有することができることを理解されたい。複数の低電力リソースは、所与のアイドル状態でアクティブにされ、有効化され、非アクティブにされ、および/または無効化され得る。したがって、全体的な「システム低電力構成」は、現在の動作状態および条件に基づいて低電力モードに入るために利用可能なリソースの各々についての低電力モードの選択によって定義される。また、(以下で説明するように)レイテンシ制限およびリソース依存性により、最適システム低電力構成は、アイドリングするために利用可能な複数のリソースのすべてのリソースを低電力モードにすることに関与しないことがあることに留意されたい。したがって、最適システム低電力構成の選択は、レイテンシ、統計的可用性および他の理由のために、ある動作状態のままでなければならないいくつかのリソースを識別し得る。
【００３７】
様々な態様はまた、プロセッサによって使用され、したがって、単に、もはや使用されていないときに無効化され得ないそれらのリソースについて低電力リソースモードを定義することを可能にする。システムが適切に機能するために、プロセッサによって使用されるリソースは、制御された方式で有効化および無効化される必要がある。この要件が与えられれば、そのようなリソースがもはや使用されていない後にそれらを無効化することは、リソースが無効化され得るアイドル状態にプロセッサが入るまで、延期されなければならない。システム低電力構成またはモードに入るプロセスは、低電力状態に入ることと呼ばれる。
【００３８】
様々な態様は、低電力モードマスク(「LPMマスク」)内のフラグビットを有効化することによって、リソースが低電力状態に入ることが可能なときをリソースが示すことを可能にし、低電力モードマスクは、プロセッサがアイドル状態に入ったとき、システム低電力構成で実装すべきLPRMの適切な組合せを選択するためにプロセッサによって使用され得る。リソースが使用されているとき、リソースはLPMマスク中のフラグビットを無効化し得る。様々な態様では、LPMマスク内のビットを有効化および無効化することは、さらに以下で説明するように、アプリケーションプログラミングインターフェース(API)を呼び得るプロセッサ従属リソースプログラミングノード内のドライバ関数によって達成され得る。したがって、プロセッサがアイドル状態に入ることが可能である瞬間に、どのリソースが低電力モードにされることが可能であるかを判断するために、LPMマスクはアクセスされ得る。
【００３９】
上記で説明したように、リソースがもはや使用されておらず、プロセッサがアイドル状態に入っているとき、リソースは、リソースの低電力リソースモードのうちの1つなどの低電力モードにされ得る。しかしながら、リソースがもはや使用されておらず、プロセッサがアイドル状態に入っているということだけが、リソースを低電力モードにするための常に十分な根拠であるわけではない。さらに、様々なタイプの低電力リソースモードをサポートするリソースについて、プロセッサは、現在の動作条件(たとえば、温度)と、予想アイドル時間内に達成され得る総電力節約に対処することと、現在のクライアントおよび他のプロセッサのレイテンシ要件と、様々な他のファクタとに基づいて、代替低電力リソースモードの中から選択を行わなければならない。様々な態様では、各評価される低電力リソースモードの潜在的電力節約が、(低電力モード定義中に含まれ得るファクタである)現在温度における単位時間当たりの潜在的電力節約に、判断された予想アイドル時間を乗算することによって判断され得るように、特定のリソースについての特定の低電力リソースモードの電力節約は、温度と時間とに依存し得る。さらに、低電力モード選択はまた、特定の電子デバイス特性と、デバイスソフトウェア実装形態と、アイドル条件での予想時間と、クロックスピードなどのデバイス状態とを含む他の変数を考慮に入れるべきである。
【００４０】
プロセッサがアイドル状態に入る準備ができているときなど、プロセッサがシステム低電力構成に入る準備ができているとき、低電力タスクは、低電力状態にされ得るリソースを識別するためにLPMマスクにアクセスし、所与の動的システム状態(たとえば、現在アクティブなクライアント、必要とされるレイテンシ、予想アイドル時間、および温度)に基づいて、それらのリソースについて入るべき適切な低電力リソースモードを判断し得る。プロセッサがこの判断を達成することを可能にするために、各リソースは、所与の状態の場合に実装されるべき低電力リソースモードの最適なセットを選択することに必要な情報を指定する低電力リソースモード特性データを定義し得る。この指定された情報は、リソースのために利用可能な各低電力リソースモードのリストと、時間に応じた、または単位時間当たりの各低電力リソースモードについての潜在的電力節約と、各低電力リソースモードについてのレイテンシ特性(すなわち、低電力モードを出るための時間)と、潜在的電力節約への温度の効果と、依存性(すなわち、そのクライアントの他のリソースとの相互依存性)と、各リソースについて最適な低電力リソースモードを選択することに関係し得る他の情報とを含み得る。そのような情報は、様々な方法およびデータ構造でリソースについて指定され得、それのCコード例を以下に記載する。
typedef struct
{
/*この低電力リソースの名前、たとえば「apps core voltage」。*/
const char *resource_name;
/*このリソースが入ることができる低電力モードの数。*/
uint32_t mode_count;
/*このリソースが入ることができる低電力モードのリスト。*/
LPM_Resource_Mode *modes;
} LPM_Resource;
【００４１】
この定義では、リソースデータの大半は、リソース低電力モード定義内に含まれる。リソースについての低電力モードの定義は、以下のようにCコードで書き込まれ得る。
typedef uint32_t (*LPRM_PowerSavingsFcn)
(uint32_t duration_us, int32_t temp_c);
typedef struct
{
uint32_t enter;
uint32_t exit;
}
sleep_latency_type;
typedef uint32_t (*sleep_power_func)(uint32_t duration_us, int32_t temp_c);
typedef struct LPRM
{
/*この低電力モードの名前(たとえば「minimization」)。*/
const char *mode_name;
/*モードの特性について説明する関数。*/
LPRM_PowerSavingsFcn power_savings;
LPRM_LatencyFcn latency;
/*モードの実際のセットアップとティアダウンとを実装する関数。*/
LPRM_EnterFcn enter;
LPRM_ExitFcn exit;
/*このモードが起こるように大部分が有効化されるLRR。*/
uint32_t lpr_dependency_count;
const char *lpr_dependencies;
/*このモードが選択された場合に入ることができないLPR。*/
uint32_t lpr_exclusion_count;
const char *lpr_exclusions;
/*このポイントの後のいくつかの予約済みブックキーピングフィールド- 0に初期化する。*/
}
LPM_Resource_Mode.
【００４２】
上記のCコードは、一般的な場合について書き込まれる。電圧レールリソースの特定の場合について低電力モードを定義するための例示的なCコードが、以下に提示されている。水晶発振器(CXO)リソース低電力モードについてのCコード定義の例を以下に記載する。この例では、プロセッサは、水晶発振器リソースを低電力モードで動作させるための2つのオプション、すなわち、クロックツリー電力を節約するが、依然として発振器を動作させる電力を消費するゲートモードと、クロックツリー電力および発振器電力を節約するが、この低電力モードを出た後に著しいウォームアップ時間を必要とする(すなわち、比較的長いレイテンシを有する)遮断モードとをサポートする。
const char *cxo_gated_deps[] = {"lpr://cxo"};
LPM_Resource_Mode cxo_gated =
{
.mode_name = "gated"; /*ゲート制御されるものは、LPR中にある*/
.power_savings = cxo_gated_power; /*データに基づく*/
.latency = cxo_gated_latency; /*データに基づく*/
.enter = cxo_gated_enter; /*mpmドライバを呼ぶ*/
.exit = cxo_gated_exit; /*mpmドライバクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(cxo_gated_deps);
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
}
const char *cxo_stdn_deps[] = {"lpr://cxo"};
LPM_Resource_Mode cxo_shutdown =
{
.mode_name = "shutdown";
.power_savings = cxo_stdn_power; /*データに基づく*/
.latency = cxo_stdn_latency; /*データに基づく*/
.enter = cxo_stdn_enter; /*異なるmpmを呼ぶ*/
.exit = cxo_stdn_exit; /*mpmクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(cxo_stdn_deps); /*ゲート制御と同じ*/
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
}
LPM_Resource_Mode *cxo_modes[] = {&cxo_gated, &cxo_shutdown};
LPM_Resource cxo =
{
.resource_name = "CXO";
LPM_MODE_ARRAY(cxo_modes);
};
//起動時:
sleep_define_lpr(&cxo);
//CXOモードは現在/sleep/lprに登録され、起動は無効化される。
//次に、制御NPAノードは、どのようにそれらを有効化することができるか。
//起動:
client = npa_create_sync_client("/sleep/lpr", "/xo/cxo", NPA_CLIENT_REQUIRED);
npa_query_type q;
q.reference = "lpr://cxo";
npa_query_by_client(client, SLEEP_QUERY_LPRM_BITMASK, &q);
uint32 bitmask = q.value;
//有効化する:
npa_issue_required_request(client, bitmask)
//無効化する:
npa_complete_request(client)
【００４３】
ノード電力アーキテクチャ(NPA)ノードを制御することに関係する例示的なコードの部分、およびNPAノードまたはNPA方法への他の言及は、本明細書では例示のためにすぎないことに留意されたい。様々な態様は、NPAノードを介してリソースを有効化および無効化することを達成すること、またはノード電力アーキテクチャを使用することに限定されない。したがって、特に特許請求の範囲にそのように記載されていない限り、特許請求の範囲は、NPAノードまたはNPAプロセスを必要とすると解釈されるべきではない。
【００４４】
電圧源(Vdd)について低電力モードを定義するのに適したCコードの別の例が、以下に提示されている。この例では、プロセッサは、そのコード中で「dig」および「mem」と呼ばれる、デジタル論理およびメモリ回路のために制御されるVddを供給する2つのシステムレベル電圧レールを有する。電圧レールを低電力モードにすることは、低電力モードを出たときにリソースをオンラインに戻すことに関連するレイテンシペナルティを必要とする。2つのリソースが並列に「ウォームアップ」され得るので、一方の電圧レールが低電力モードにされた場合、他方の電圧レールもさらなるレイテンシペナルティを受けることなく低電力モードにされ得るために、これらの2つの電圧レールの制御は結合される。この相互依存性を扱うために、以下のコードは、単一のリソースについて3つの低電力モード「system Vdd」、すなわち、digおよびmem最小化と、mem専用最小化と、dig専用最小化とを定義する。
const char *dig_mem_deps[] = {"lpr://vdd_dig", "lpr://vdd_mem"};
LPM_Resource_Mode dig_mem =
{
.mode_name = "Dig/Mem Min";
.power_savings = dig_mem_power;
.latency = dig_mem_latency; /*これは、ほぼdig_latencyまたはmem_latencyと等価である。それらはこれを共有し得る。*/
.enter = dig_mem_enter; /*mpmドライバを呼ぶ*/
.exit = dig_mem_exit; /*mpmドライバクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(dig_mem_deps);
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
const char *mem_deps[] = {"lpr://vdd_mem"};
LPM_Resource_Mode mem_min =
{
.mode_name = "Mem Min";
.power_savings = mem_power;
.latency = mem_latency;
.enter = mem_enter; /*mpmドライバを呼ぶ*/
.exit = mem_exit; /*mpmドライバクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(mem_deps);
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
}
const char *dig_deps[] = {"lpr://vdd_dig"};
LPM_Resource_Mode dig_min =
{
.mode_name = "Dig Min";
.power_savings = dig_power;
.latency = dig_latency;
.enter = dig_enter; /*mpmドライバを呼ぶ*/
.exit = dig_exit; /*mpmドライバクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(dig_deps);
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
}
LPM_Resource_Mode *sys_vdds_modes[] = {mem_dig, mem_min, dig_min};
LPM_Resource sys_vdds =
{
.resource_name = "System Vdds";
LPM_MODE_ARRAY(sys_vdds_modes);
};
//起動時:
sleep_define_lpr(&sys_vdds);
//モードは、現在/sleep/lprに登録され、起動は無効化される。
//次に、制御NPAノードは、どのようにそれらを有効化することができるか。
//起動:
dig_client = npa_create_sync_client("/sleep/lpr", "/rail/vdd_dig", NPA_CLIENT_REQUIRED);
mem_client = npa_create_sync_client("/sleep/lpr", "/rail/vdd_mem", NPA_CLIENT_REQUIRED);
npa_query_type q;
q.reference = "lpr://vdd_dig";
npa_query_by_client(dig_client, SLEEP_QUERY_LPRM_BITMASK, &q);
uint32 dig_bitmask = q.value;
q.reference = "lpr://vdd_mem";
npa_query_by_client(mem_client, SLEEP_QUERY_LPRM_BITMASK, &q);
uint32 mem_bitmask = q.value;
npa_issue_required_request(mem_client, mem_bitmask);
//現時点で、「Mem Min」モードのみが有効
npa_issue_required_request(dig_client, dig_bitmask);
//現時点で、すべての3つのモードが有効
npa_complete_request(mem_client)
//現時点で、「Dig Min」モードのみが有効
npa_complete_request(dig_client)
//どのモードも有効でない状態に戻る
【００４５】
上記で例示し、説明した動的低電力リソース登録機構は、低電力リソースとモードとのセットが動的に拡張されることを可能にする。この能力は、リソースのためでない低電力動作状態であるが、同様の方法で扱われる場合、電力動作の低減を可能にすることができる「仮想低電力モード」を可能にすることを含む。そのような仮想低電力モードの例は、リフレッシュを必要とするであろう新しいコンテンツが生成されないので、プロセッサがアイドル状態に入ったとき、ディスプレイリフレッシュプロセスを中断することを含む。したがって、他の動作およびデバイス構成要素は、構成要素がそれ自体リソースでなくても、電力消費の低減を可能にするための様々な態様を使用して管理され得る。
【００４６】
様々な態様では、プロセッサがアイドル状態に入ることが可能なとき、低電力タスクは、所与のスリープサイクルの間にシステム低電力構成の一部として、様々なリソースについてどの低電力モードに入るべきかを判断するために「ソルバー」プロセスを実行し得る。そのような場合、アイドル状態に入るべき時間であるときに評価されるべきスリープタスクが使用するために、異なるリソースについての低電力モード、およびそれらの低電力モードの特性が収集される必要があり得る。一態様では、これは、ノード電力アーキテクチャ(NPA)において、「/sleep/lpr」NPAノードを介して実装され得る。「/sleep/lpr」への要求は、低電力リソースモードを有効化するビットマスクの形態で行われ得る。様々な態様では、開発者は、低電力リソースモード(およびそれのリソース低電力モードビットマスク)を「/sleep/lpr」NPAノードに登録するsleep_define_lpr()関数を介して、低電力リソースモードを登録し得る。様々な態様では、「/sleep/lpr」NPAノードは、それらが有効化/無効化することに関係するリソース低電力リソースモードを表すビットマスクについて、任意の時間に問い合わせられ得る。また、NPAリソースは、正しい「ビットマスク」をもつ「/sleep/lpr」への要求を行うことによって、それらのリソース低電力リソースモードがアイドル時間に有効化されることを要求することができる。次いで、スリープソルバーは、低電力リソースモードのリストと、現在有効化されている低電力リソースモードのマスクとについて、アイドル時間に「/sleep/lpr」に問い合わせることができる。
【００４７】
上記で説明したように、様々な態様では、プロセッサがアイドル状態に入ることが可能なとき、低電力タスクは、様々なリソースについてどの低電力リソースモードに入られなければならないかを判断するために「ソルバー」プロセスを実行し得る。これの例は図1に示され、図1には、ノード電力アーキテクチャ(NPA)2内のプロセス(すなわち、ノード)が、水晶発振器4などのリソースについて2つの利用可能な低電力モード6、8のうちのどちらに入り得るかをどのように判断するかを示す。図1に示す例では、水晶発振器リソース4は、2つの代替低電力モード、すなわちゲート動作状態6と完全遮断8とを有する。低電力モードにされる資格がある様々なリソースの各々について低電力モードの最適なセットを選択することは、資格があるリソースの各々について利用可能なモードのうちの1つを選択することに関与する。一態様では、低電力リソースモードの「入」機能を呼ぶことによって、選択された低電力リソースモードの各々に入り得る。低電力リソースモードの入機能が呼ばれると、リソースは、それの選択された低電力リソースモードによって定義された電力節約状態にされ得る。プロセッサがアイドル状態である間、プロセッサは割込み待ち(WFI)プロセスおよび/またはアイドルプロセスを実行し得る。起動イベントが行われるまで、プロセッサおよび選択されたリソースはこの状態のままであり得る。起動イベントが行われたとき、各選択されたリソースについて、リソースを所望の動作状態(たとえば、通常または完全電力状態)に戻すために、関連する「出」機能が呼ばれ得る。
【００４８】
様々な態様を実装するためのプロセスが図2〜図4に示されている。図2を参照すると、態様方法10では、ブロック12においてクライアントがリソースをリリースしたのでリソースがもはや使用されていないとき、ブロック14において、上記に記載した例に示すような動作を実装することなどによって、LPMマスク中で低電力リソースモードフラグを有効化する。この時点で、リソースは、それが低電力リソースモードにされるために利用可能であることを示している。起動イベントが行われ、クライアントがリソースへのアクセスを要求したとき、図3に示す方法16が実装され得る。ブロック18においてクライアントがリソースを要求したとき、ブロック20において、上記に記載した例に示すような動作を実装することなどによって、LPMマスク中でそのリソースの低電力リソースモードフラグを無効化する。次いで、ブロック22において、上述のように関連する「出」機能を達成することなどによって、リソースを再活動化する。
【００４９】
図4に、プロセッサが、特定のアイドルおよび低電力状態で実装するための最適システム低電力構成(すなわち、低電力リソースモードの最適セット)を識別し得る態様方法24を示す。ブロック26において、プロセッサを低電力状態にするためにアイドルおよび/またはスリープタスクを開始したとき、プロセッサは、リソース低電力リソースモードフラグについて低電力リソースマスクを検査することによって低電力リソースモードにされ得るそれらのリソースを識別する。ブロック28において、プロセッサは、低電力リソースモードにされ得るリソースを識別するために、低電力リソースモードフラグについてLPMマスクを検査する。ブロック30において、プロセッサは、システム上で実行しているアクティブなクライアント、タスク、またはサブシステムのレイテンシ要件を検査する。たとえば、プロセッサは、クライアントについて定義されたデータ構造にアクセスし、その情報を使用して、レイテンシバジェットを判断し得る。レイテンシバジェットは、システムがシステム低電力状態からの起動中に適応することができる総レイテンシを定義し得る。
【００５０】
一態様では、レイテンシバジェットは、すべての同時プロセッサおよびクライアントにとって許容できるすべてのレイテンシの最小値、またはワーストケースレイテンシ、または最も厳しいレイテンシとして定義され得る。たとえば、ホストがUSBとの通信を開始するときはいつでも、ホストに接続されたUSBリソースは1ミリ秒内に応答することが要求される。この例では、ホストのレイテンシ要件は、1ミリ秒である。したがって、システムがアイドル状態のとき、プロセッサは、オンに戻すために1ミリ秒以上を必要とするリソース、またはリソースの組合せをオフにしないことがある。これは、所与の時間に、ホストが、システムをオンに戻すために割込みを発行し、要求されたタスクを扱うことが可能な動作状態に戻るように、リソースに要求し得るからである。すなわち、システムは、ホストが割込みを発行したときに、出るために全体で1ミリ秒以上を必要としない低電力リソースモードを実装することに限定される。将来、USBがホストから切断された場合、USBがもはや実行されているタスクでないので、1ミリ秒の応答時間はもはや必要とされない。この状況では、より高いレイテンシ要件でずっと実行していた何らかの他のタスクがあり得るので、ワーストケースレイテンシは、何らかの他の値(たとえば、5ミリ秒)に変更することができる。したがって、様々な態様では、レイテンシ要件は、システム低電力モード構成が現在の動作状態要件に基づいて判断され得るように、そのときに評価され得るシステム状態に応じた動的プロパティであり得る。さらに、低電力リソースモード自体は、それら自体のレイテンシ要件、ならびに相互依存レイテンシを有し得る。したがって、いくつかの状況では、入るために利用可能なすべての低電力リソースモードに入ることができるわけではない。これは、いくつかの低電力リソースモードに入ることが、現在の動作状態のワーストケースレイテンシ要件に違反するシステム全体のレイテンシを生じ得るからである。
【００５１】
図4に戻ると、ブロック32において、プロセッサは、様々な低電力リソースモードについてのモードのアイドル入待ち時間およびアイドル出待ち時間についてリソース定義データを検査する。ブロック34において、プロセッサは、予想アイドル時間(すなわち、現在の条件および動作状態を与えられたときに、プロセッサが、起動イベントまでにアイドル状態のままであることを予想される持続時間)を判断する。ブロック36において、プロセッサは、現在温度と他のセンサ値とを記憶しているデータレジスタにアクセスすることなどによって、現在の状態の条件を判断する。ブロック28〜36において収集された現在の状態と低電力リソースモードデータとを使用して、ブロック38において、プロセッサは、最適低電力構成を識別するために「ソルバー」機能を実行する。ソルバー機能は、許容できる最適低電力構成を識別するのに必要な様々な考慮事項を平衡させるためのいくつかの異なる手法を使用し得、そのいくつかの例について、図7〜図10を参照しながら以下で説明する。ブロック28〜38のうちの1つまたは複数の一部として、プロセッサは、各低電力リソースモードおよび低電力リソースモードの各組合せについて、現在温度(および他の動作条件)における単位時間当たりの潜在的電力節約×予想アイドル時間を計算することなどによって、予想され得る潜在的電力節約を計算し、ブロック38において、ソルバープロセスの一部としてこの値を使用する。最適低電力構成が識別されると、1つまたは複数の低電力リソースモードは、各リソース、タスクおよび/またはサブシステムについて選択され、ブロック40において、プロセッサは、関連する入機能を各選択された低電力リソースモードに実行させることなどによってその低電力構成に入る。システムは、タイマ割り込みなどの起動イベントが行われるまで、このアイドル状態および/または低電力状態のままである。起動イベントまたは割込みが行われたとき、ブロック42において、プロセッサおよび関連するリソースは、低電力リソースモード中のリソースの各々について、それらのリソースをそれらの通常動作状態に戻す一連の出機能を実行することなどによってアイドル状態を出る。
【００５２】
様々な態様では、ブロック42において、直接探索(quarry)されるタイマーサブシステムに関連する既知の起動イベントがある。様々な態様はまた、クライアントが、起動イベントがある時間量内に行われると考えることを「暗示する」ことを可能にする起動リソースを含み得る。様々な態様では、システムは、リソースおよび/またはプロセッサが、どのくらい長く所与のスリープ状態のままである可能性があるかを予測および/または制御する機構を含み得る。これらの態様では、プロセッサは、リソースがどのくらい長くスリープ状態にあると予想することができるかを制御するために、いくつかのイベントを延期し得る。様々な態様では、リソースが起動させられるハード起動ポイントがあり得る。様々な態様では、システムは、予想される起動時間フレームを判断するためにリソースからの「暗示」を使用し得る。様々な態様は、最も効率的な起動時間を推定するために、プロセッサによって使用され得る予測アルゴリズムを実装し得る。様々な態様は、予想される起動時間を判断するために、ハード制限と暗示と学習機構との組合せを使用し得る。様々な態様は、予想される起動時間を使用して、判断された予想される起動時間まで様々なリソースが低電力リソースモードにされた場合、どのくらいの電力が節約されるかを判断し得る。次いで、そのような予想される電力節約は、差し迫ったスリープサイクルのためにシステム低電力モード構成で実装するために、低電力モードにすべき特定のリソースを選択する(すなわち、低電力リソースモードを選択する)プロセスにおいて使用され得る。
【００５３】
様々な態様は、電力機能を判断するために、電力節約の和と、リソースを停止させ、再び動作させることのエネルギーコストの両方を使用し得る。様々な態様は、もしあれば、どのリソースが低電力リソースモードにされるべきかを判断するために電力機能を使用し得る。様々な態様はまた、実装された低電力リソースモードの様々な組合せによって与えられる潜在的システム低電力構成の各々に関連する純電力節約を判断するために、電力機能を使用し得る。様々な態様は、計算された時間フレームにわたって節約され、様々なリソースを低電力リソースモードにし、それらを動作モードに戻すために必要とされる業務量だけオフセットされる電力量として純電力節約を計算し得る。様々な態様では、純電力節約は、傾きMとオフセットBとをもつ予想アイドル時間Xを有する単純な線形多項式モジュールを使用する関数によって計算され得、計算される電力節約は、MX+Bである。様々な態様は、構成可能なシステムパラメータに記憶された値に基づいて定期的に純電力節約を計算し得る。
【００５４】
様々な態様では、純電力節約は各リソースについて作表され得る。すなわち、様々な態様は、利用可能な低電力リソースモードの各々に関連する様々な純電力節約を含んでいるテーブルを事前計算し得る。様々な態様はまた、オンザフライで、連続的に、または定期的に、構成可能なシステムパラメータに記憶された値に従って、作表されたリストを生成し得る。様々な態様では、決定間の境界は、テーブルに記憶され、どの潜在的システム低電力構成が現在のシステムニーズおよび動作状態に最も適しているかに関して決定するときに参照され得る。たとえば、システムは、時間に基づいていくつかの好適な低電力構成を示す情報(たとえば、X時間までのモードAの選好、次いでY時間までのモードBの選好、次いでモードAおよびBの選好)を記憶し得る。
【００５５】
様々な態様では、依存性について検査するプロセスが、最適システム低電力モード構成を定義するために低電力リソースモードが選択されるレベルまでプッシュダウンされ得るので、LPMフラグは、明示的にリソースを支配することに制限されない。たとえば、リソース「A」が2つの低電力リソースモード「1」および「2」を有すると仮定する。モード「1」と「2」の両方が同じリソースのものであるので、それらは、そのリソースが低電力リソースモードにされ得ることを示す共通のLPMマスクビットを共有し得る。したがって、この例では、モード「1」および「2」は両方ともLPMマスク内のビット「A」に依存し、ビット「A」は、リソースのためのNPAリソースドライバによって制御される。しかしながら、モード「2」は、モード「1」の特殊な形態であり得、リソース「A」がスリープ状態になることが可能である(すなわち、いかなるクライアントまたはプロセッサによっても使用されない)ことと、リソース「B」もスリープ状態になることが可能であることの両方に対する依存性を有するという点で、さらなる複雑化があり得る。言い換えれば、リソース「A」の低電力リソースモード「2」は、リソース「B」も低電力モードにされることに依存し得る。したがって、この例では、モード「2」は、リソース「A」と「B」の両方のLPMマスクビットに依存する。したがって、この例では、LPMフラグは、モード「2」の依存性によりリソースを明示的に支配しない。
【００５６】
静的依存性と動的依存性とを示すために、クロックドライバリソースと何らかの他の種々のハードウェアリソースとに電力を供給する電圧調整器リソースの例について考える。電圧調整器は、2つの動作モード、すなわち、通常電力と低電力(すなわち、それの低電力リソースモード)とを有し得る。電圧調整器を低電力状態にすることは、電圧調整器によって消費されるエネルギーオーバーヘッド量を低減し得、全体的により低いシステム電力需要を生じる。しかしながら、それの低電力モードで許されるよりも多くの電力が電圧調整器から引き出される場合、電圧調整器は機能せず、デバイスハードウェアに潜在的に損傷を与え得る。たとえば、クロックドライバは、電圧調整器がそれの低電力モードで供給することができるよりも多くの電力を消費し得る。この場合、電圧調整器は、クロックドライバに対する1つの静的依存性を有し(すなわち、クロックは、オフにされることが可能でなければならない)、他の種々のハードウェアに対する別の静的依存性を有し得る(すなわち、その種々のハードウェアは、オフにされなければならない)。さらに、電圧調整器は、クロックドライバがオンのままである限り、電圧調整器から引き出される電力が大きすぎて、それが低電力モードに入ることができないという動的依存性を有し得る。クロックドライバがオフにされるとすぐに、電圧調整器に対する負荷がなくなり、低電力モードに入ることが可能になる。したがって、クロックドライバの電源切断モードは、電圧調整器の低電力リソースモードの動的依存性である。
【００５７】
上記で説明したように、静的依存性はある程度の確度で予期され得るが、動的依存性は前もって判断するのが難しい。さらに、構成要素および/またはリソースの数が増加するにつれて、動的依存性は指数関数的により複雑になる。様々な態様では、様々な動的依存性を管理するために、ソルバープロセスが使用される。様々な態様では、様々な動的依存性を管理するために、アイドルタスクが使用される。
【００５８】
様々な態様の動作が、プログラミングノードおよびリソースグラフ図を示す図5に示されている。図5は、3つのクライアント50、52、54がアクティブであり、3つのリソース、具体的には、メモリ70、クロック発振器78および電圧レール76が、低電力リソースモードに応じられる動作状態を示す。この図では、処理ノード58、69、70、72、74、76、および78は、システムがアイドルタスク60を実行することによって低電力リソースモードに入る準備ができているときに横断されるプロセスを表す。投票のためにクライアント50、52、54をポーリングする代わりに、低電力構成に基づいてシステムを低電力状態にするために、そのプロセスは削除され、ノード図を横断するスリープクライアント64と交換される。この図では、(メモリを使用していた)クライアント1 50は、ノード70への矢印によって示されるように、メモリをリリースし、LPMマスクにおいて適切な低電力リソースモード有効化ビットを設定する。同様に、クライアント2 52は、ノード74および76への矢印によって示されるように、電圧レールリソースとクロックとをリリースし得、LPMマスクにおいて適切な低電力リソースモード有効化ビットを設定する。クライアント3 54が、ノード69への矢印によって示されるようにプロセッサをリリースするとき、プロセッサは、低電力モードソルバー66プロセスを実行する前にLPMマスクを検査し、システムレイテンシを検査し、予想アイドル時間を検査することによって、アイドルタスク60を実行し得る。グラフ全体が横断された後、スリープクライアント64は低電力リソースモード「入」機能を呼び出し、アクティブな低電力リソースモードのセットが、所与の現在の動的条件に基づいてリソースについて選択され得る。
【００５９】
図6に、別の態様方法の場合の同様のプロセスノードおよびリソースグラフを示す。この態様方法は、スリープタイムラインからプロセッサグラフ横断を削除するさらなる利益を与える。図6に示すように、(図5中の矢印48によって示される)プロセッサ依存性は、プロセッサのリソースが低電力リソースモードマスクと直接対話するために特殊なAPIを使用することを可能にすることによって、プロセスノードグラフから省略され得る。図6はまた、(図5に示す)LMPマスク80が、システム低電力状態の場合のLPMマスク90と、アイドル低電力状態の場合のLPMマスク92と、低電力状態の場合のLPMマスク94とによって交換され得ることを示す。この態様では、低電力リソースモードにされることに応じられるリソース(たとえば、メモリ70、クロック発振器78、および電圧レール76)は、システム低電力状態の場合のLPMマスク90においてLPM有効化(ビット)および/またはLPM無効化(ビット)を直接設定し得る。クライアント3 54が、ノード69への矢印によって示されるようにプロセッサをリリースするとき、プロセッサは、アイドル低電力状態の場合のLPMマスク92を検査し、システムレイテンシを検査し、予想アイドル時間を検査することによってアイドルタスク60を実行し得る。アイドルタスク60の低電力リソースモード「入」機能86が呼び出され、アクティブな低電力リソースモードのセットが、低電力状態の場合のLPMマスク94を介して所与の現在の動的条件について選択され得る。
【００６０】
例示的な態様では、低電力リソースモードは、一連のビットベクトルとして実装され得る。たとえば、システム低電力状態(すなわち、リソース使用状況と、クライアント経路コンテキストの外部のクライアントとによる現在アクティブな低電力状態)と、アイドル低電力状態(すなわち、レイテンシおよび予想アイドル時間など、アイドルタスクにおいて発見される動的システム条件による現在アクティブな低電力モード状態)と、(たとえば、不揮発性アイテムまたは同様のものを介して)条件をデバッグ/提示することと、各コアプロセッサノード依存性についての1ビットとのためのビットベクトルがあり得る。各ビットのデフォルト状態は、無効化された低電力リソースモードであり得る。図5または図6に示すノードグラフを通過することによってリソース使用状況要件を設定するクライアントは、低電力ビットのいずれかを有効化させ得、それにより、特定のリソースが低電力リソースモードにされることを可能にする。一態様では、アイドルタスクは、インターモード依存性とレイテンシと予想アイドル時間と温度とを含む、他のファクタに関するデータを収集し、それ自体のビットマスクを設定し得る。この態様では、図に示されていないが、最終LPMマスク設定は、システムおよびアイドルマスクのビット単位の追加を介して判断され得る。
【００６１】
様々な態様では、いくつかの機構は、現在の動作状態および条件に基づいてリソース低電力リソースモードの最適なセットを識別するために、低電力リソースモード選択ソルバー中で使用され得る。一般論的に、低電力リソースモードの最適なセットを選択する問題は、組合せ最適化においてよく知られている問題である「ナップザック問題」の一形態である。ナップザック問題に対する様々な既知のアルゴリズムまたはヒューリスティック解は、低電力リソースモード選択ソルバーにおいて実装され得る。そのような方法は、if/then/else論理ツリーアルゴリズムと、テーブルルックアップアルゴリズムと、異なるリソースの代替低電力リソースモードの代替並べ替えおよび組合せを通して系統的に動作する比較方法とに関与し得る。
【００６２】
例として、図7に、様々なリソースと代替低電力リソースモードとを通して動作することによって低電力リソースモードの最適なセットを選択するための態様方法38aを示す。方法38aは、図4を参照しながら上記で説明した方法24の一部として達成され得、したがって、潜在的電力節約と出待ち時間と依存性とを含む低電力リソースモード特性およびビットマップは、すでにアクセスされたと仮定され得る。現在のアイドル状態の時間に、低電力リソースモードにされ得るリソースのすべての低電力リソースモードのすべてを評価するために、プロセッサは、ブロック100において、LPMフラグが有効化される各リソースを増分的に選択し、次いで、ブロック102において、選択されたリソースについて各低電力リソースモードを増分的に選択する。LPMマスクにおいて設定されたフラグが検査される方法は、実装形態に応じて、様々なリソースの相互依存性に応じて変わり得る。一実装形態では、プロセッサはLPMマスクにおけるフラグを検査し得、そのビットが設定されていない場合には、そのリソースについての低電力リソースモードのいずれについても考慮しないことがある。たとえば、プロセッサが、リソース「A」低電力リソースモードのすべてが、「A」ビットを設定するように要求することを知っている場合、ボックス100において、プロセッサは、「A」ビットについて検査することができ、そのビットが設定されていない場合には、そのリソースのための低電力リソースモードのいずれについても考慮しないことがある。しかしながら、選択されたリソースのためのいくつかの低電力リソースモードは、さらなるリソースビットもそれの依存性に応じて設定される(または設定されない)ことを要求し得るので、ブロック102において、プロセッサは、依然としてLPMマスクを検査する必要があり得る。したがって、一態様では、ブロック102において選択されたリソースについて特定の低電力リソースモードを選択する前に、プロセッサは、低電力リソースモードによって要求された他のリソースLPMフラグも、要求された値に設定されるかどうかを検査し得る。
【００６３】
仮想リソースとともに使用するのに適用可能であり得るような、さらなる態様では、リソースが低電力リソースモードにされることに応じられるかどうかの判断は、他のリソースのために設定されているLPMフラグに依存し得る。たとえば、低電力リソースモード「3」および「4」が定義される仮想リソース「C」が存在する場合、低電力モード「3」の可用性がリソース「A」のためのLPMマスクビットに依存することがあり得るが、低電力モード「4」の可用性は、リソース「B」のためのLPMマスクビットに依存するであろう。したがってこの例では、リソース「C」、がリソース「A」および「B」の状態に応じて低電力モード「3」または「4」のうちの1つになる仮想リソースであるので、仮想リソース「C」を低電力モードにする可用性は、明示的にリソース「C」のためのLPMマスクビットに依存する。したがって、一態様では、ブロック100とブロック102の両方において、プロセッサは、LPMマスクビットについて考えることによって、評価のためのリソースを選択する。
【００６４】
判断ブロック104において、プロセッサは、低電力リソースモードが現在のシステムレイテンシ要件に適合することになるかどうかを判断するために、選択されたリソース低電力リソースモードレイテンシを(上記で説明したステップ30において判断された)レイテンシバジェットと比較する。選択されたリソースの選択された低電力リソースモードの出レイテンシが、レイテンシバジェットを超えた場合(すなわち、判断ステップ104=「いいえ」)、判断ブロック112において、プロセッサは、選択されたリソースについて別の低電力リソースモードがあるかどうかを判断する。他方では、選択されたリソースの選択された低電力リソースモードの出レイテンシが、レイテンシバジェット内である場合(すなわち、判断ステップ104=「はい」)、ステップ106において、プロセッサは、新しい純節約(すなわち、評価されている低電力モードを含む低電力構成の場合の推定される電力節約)を取得するために、選択された低電力リソースモードに関連する電力節約を、選択されたモードの場合の電力節約に加算する。言い換えれば、評価されている特定のリソース低電力リソースモードを含む、低電力リソースモードのセットによって与えられることになる純電力節約を判断するために、選択された低電力リソースモードの予想される電力節約は、すでに評価された他のリソース低電力リソースモードの電力節約に加算され得る。一態様では、各低電力リソースモードの場合の予想される電力節約は、現在温度(および/または他の動作条件)における単位時間当たりの(または時間に応じた)潜在的電力節約×予想アイドル時間の積、または何らかの関数として判断され得る。判断ブロック108において、選択されたリソース低電力リソースモードを含めることが、より大きい電力節約を生じるかどうかを判断するために、プロセッサは、ブロック106において取得された和を、低電力リソースモードの前に選択された最良のセットの総電力節約と比較する。選択されたリソース低電力リソースモードを含む組合せが、より大きい電力節約を生じる場合(すなわち、判断ブロック108=「はい」)、ブロック110において、コンピューティングデバイスは、低電力リソースモードの選択されたセット中に、そのリソースについて選択された低電力リソースモードを含める。
【００６５】
選択されたリソース低電力リソースモードを含む組合せが、より小さい電力節約を生じる場合(すなわち、判断ブロック108=「いいえ」)、判断ブロック112において、プロセッサは、選択されたリソースについて別の低電力リソースモードがあるかどうかを判断する。選択されたリソースに関連する別の低電力リソースモードがある場合(すなわち、判断ブロック112=「はい」)、プロセッサはブロック102に戻って、評価のために次の低電力リソースモードを選択する。選択されたリソースの低電力リソースモードすべてが評価された場合(すなわち、判断ブロック112=「いいえ」)、判断ブロック114において、プロセッサは、低電力リソースモードにされ得る別のリソースがあるかどうかを判断する。評価されるべき別のリソースがある場合(すなわち、判断ブロック114=「はい」)、プロセッサはブロック100に戻って、評価のための次のリソースを選択する。リソースすべてが評価されると(すなわち、判断ブロック114=「いいえ」)、アルゴリズムは、実装すべき低電力リソースモードの最適なセットを識別すべきであったので、図4およびブロック40を参照しながら上記で説明したように、低電力リソースモードの選択されたセットを実装することに進む。
【００６６】
図7に示すアルゴリズムなどの組合せ計算アルゴリズムは、所与の動作条件の場合の低電力リソースモードの最適なセットを識別することが可能であり得るが、そのような計算は、特に予想アイドル時間が数ミリ秒のみであり得、リソースの数が多いときには、実装するには計算量的に難しすぎることがある。したがって、様々な態様では、ナップザック問題に対する近似解および事前に判断され得る解が実装され得る。スリープサイクルに先だってプロセッサによって判断され得る解決策の例は、テーブルルックアップ方法を使用する解決策である。テーブルルックアップ方法では、様々な低電力リソースモードのパフォーマンスは、予想アイドル時間と、温度と、現在のシステム構成と、他のパラメータとに関して、ランタイムにプロセッサによって計算され得る(すなわち、開発者によって事前に定義されないことがある)。これらの計算の結果は、スリープサイクルの時間に低電力リソースモードのほぼ最適なセットを迅速に識別するために、プロセッサによって使用され得るテーブルまたはグラフの形態で与えられ得る。
【００６７】
図8Aに、電力節約対予想アイドル時間に関してプロットされた動作低電力構成の3つの代替セット120、122、124の1次元グラフを示す。グラフが明らかにするように、3つの代替低電力構成は、予想アイドル時間の異なる範囲において異なる相対電力節約を生じ得る。図8Aは、代替低電力構成120が、初めに(たとえば、アイドル時間の開始から矢印126によって示される時間まで)負の電力節約を生じるが、時間的に後では正の電力節約を生じることを示している。したがって、プロセッサスリープサイクルの開始と矢印126によって示される時間との間で、低電力構成122および124のみが、要素128によって示される電力節約を生じる。図8Aはまた、スリープサイクルの開始と矢印126によって示される時間との間の期間において、低電力構成122が低電力構成124よりも大きい電力節約を与えるであろうことを示している。矢印126と矢印130との間の時間から、3つの低電力構成すべてが正の電力節約を生じ、低電力構成122が最も多くの電力節約可能性を与え、124および120がそれぞれ、その後に続くであろう。これは要素132によって示され、要素132は、低電力構成122が124よりも高い電力節約を有し、次に、124は120よりも高い電力節約を有することを示す。矢印130と矢印136との間の時間フレームにおいて、3つの低電力構成すべてが正の電力節約を生じ、3つの代替形態は、要素134によって示されるように、122、120および124の順に電力節約可能性を与える。矢印136によって示される時間の後に、3つの代替形態は、要素138によって示されるように、120、122および124の順に電力節約可能性を有する。
【００６８】
図8Aに示す態様では、プロセッサは、予想アイドル時間をルックアップ値として使用して代替低電力構成の優先順位を判断することができる。図8Aは2次元グラフ(すなわち、電力節約対予想アイドル時間)で本態様を示しているが、本態様方法は、温度、レイテンシなどのパラメータを含む多次元グラフを用いて実装され得る。一態様では、プロセッサは、複数のパラメータに基づいて、ほぼ最適な低電力構成、または構成の優先順位を識別するために、既知の3次元グラフ化解析アルゴリズムを利用し得る。この場合も、そのようなグラフ化は、ランタイムにおいてプロセッサによって実行され得、開発者によって事前に定義されないことがある。
【００６９】
事前計算により、ルックアッププロセスにおいて必要とされる業務は減少するが、転移点の数は、(異なるリソースの数に連結される)異なる低電力モードの数と、次元(すなわち、最適システム低電力モード構成を選択する際に使用されるパラメータ)の数とともに増加する。そのような場合、そのようなルックアップテーブルを記憶するのに必要なスペースは法外になり得る。したがって、さらなる態様では、追跡される必要がある個別領域の数を低減するためにルックアップテーブルの異なる領域を統合するために、ヒューリスティックが使用され、それにより、ルックアップテーブルのサイズを低減し得る。図8Bに、低電力構成のランク付けされた順序が、入力パラメータのいくつかの領域(たとえば、矢印126と矢印136との間の領域)において、1つまたは2つの(140によって示される)代替ランク付けリストの形態で提示され得る例示的な態様を示す。図8Bは、異なる領域を統合することが、いくつかのセットの条件の場合に次善の結果を生成し得ることを示している。たとえば、矢印126と矢印136との間の時間領域において、矢印126に最も近いエリアのための最適結果は、矢印136に近いエリアのための最適結果とは異なる。これらの次善の結果の影響を緩和するために、様々な態様では、プロセッサは、不正確なランキングを比較的興味のない領域に配置し得る。領域が、まれに経験される条件(たとえば、温度極値)を表す場合、その領域は興味のないものとして分類され得る。様々な態様では、プロセッサは、非最適ランキングでエラーを評価し、そのエラーが最小であるか、または何らかの設定されたしきい値を下回ると判断することによって、その次善の結果が許容できると判断し得る。そのようなヒューリスティックルールの開発は、ランタイムにおいてプロセッサによって実行され得、開発者によって事前に定義されないことがある。
【００７０】
本態様の拡張として、プロセッサは、デバイスがどの条件を最も頻繁に経験するかに関する統計を収集し、以下でより十分に説明するように、ルックアップテーブルを再計算して、そのテーブルを、特定のコンピューティングデバイスが最も頻繁に経験する条件にカスタマイズし得る。たとえば、アラスカ州で使用されるセルラー電話は、サハラ砂漠で使用されるセルラー電話に比較して、それのテーブルスペースのより多くを低温温度領域に割り振るルックアップテーブルを計算し得る。本態様は、各コンピューティングデバイスが、環境(すなわち、温度)と測定される使用パターン(たとえば、予想アイドル時間)の両方に関して、それの典型的な条件に最適化される低電力構成決定を行うことを可能にする。
【００７１】
図9Aは、上記で説明したソルバープロセスのためのテーブルルックアップ方法を実装するための態様方法38bを示している。方法38bでは、ブロック150において、プロセッサは(図4を参照しながら上記で説明したように)ブロック28〜36において判断されたパラメータを使用して、低電力構成を選択する。上述のように、一態様では、このテーブルルックアッププロセスは、3Dマッピング解析アルゴリズムの使用に関与し得る。最適低電力構成が識別されると、ステップ40において、プロセッサは、上記で説明したように選択されたモードに入る。
【００７２】
図9Bは、さらなる評価のために代替構成のランク付けされたリストを生じるテーブルルックアップ方法を実装するための代替態様方法38cを示している。方法38cでは、ブロック152において、プロセッサは(上記で説明したように)ブロック28〜36において判断されたパラメータを使用して、潜在的電力節約に基づいて代替低電力構成のランク付けされたリストを取得する。ブロック154において、プロセッサは、評価のために最高ランクの代替低電力構成を選択する。判断ブロック156において、プロセッサは、選択された構成のモード出レイテンシが最大許容システムレイテンシ未満であるかどうかを判断する。選択された低電力構成のレイテンシがシステム要件を満たす場合(すなわち、判断ブロック156=「はい」)、ステップ40において、プロセッサは、上記で説明したように選択されたモードに入る。選択された低電力構成のレイテンシがシステムレイテンシ要件を満たさない場合(すなわち、判断ブロック156=「いいえ」)、プロセッサは、評価のために次の低電力構成を選択する。許容できない低電力構成がすべて排除されるまで、あるいはシステムレイテンシ要件を満たす1つまたは複数の低電力構成が識別されるまで、このプロセスは続き得る。低電力構成のすべてが排除されるか、または満足な低電力構成が識別されない場合、プロセッサは、利用可能な予想される電力節約と、動作要件と、上記で説明した他のファクタとに基づいて、それが低電力構成に入るべきなのか、または動作状態のままであるべきなのかについての判断を行い得る。
【００７３】
上記で説明したテーブルルックアップソルバー手法は、システム低電力構成を排除し、比較的迅速に計算され得る1つまたは複数の最適低電力構成を識別するためのフレキシブルなデータ駆動型手法を提供することができる。しかしながら、いくつかの状況では、この手法は、それが事前に行われる計算に基づくために、すべての動作状態および条件において最適低電力構成を識別することが可能でないことがある。図10は、予想アイドル時間に応じて、組合せ計算アルゴリズム方法とテーブルルックアップ方法の両方を利用するために実装され得る代替態様方法38dを示している。判断ブロック160において、プロセッサは、最適な構成、またはより高速なテーブルルックアップ方法が実装されるべきかどうかを直接判断するために必要とされる計算時間を補うために、予想アイドル時間が十分に長くなる(すなわち、所定のしきい値よりも長くなる)かどうかを判断する。プロセッサが、予想アイドル時間がしきい値を超え、したがってより厳密なソルバーアルゴリズムを完了するために必要とされる余分の計算時間を補うと判断した場合(すなわち、判断ブロック160=「はい」)、ブロック40において、プロセッサは、実装すべき最適低電力構成を判断するために、図7を参照しながら上記で説明したアルゴリズムを実行する。一方、プロセッサが、予想アイドル時間がしきい値未満であると判断した場合(すなわち、判断ブロック160=「いいえ」)、プロセッサは、図9Aまたは図9Bを参照しながら上記で説明したテーブルルックアップ方法を実行する。このようにして、コンピューティングデバイスは、プロセッサがアイドル状態のままであることを予想される時間に応じて、両方のソルバー方法の利益を有することができる。
【００７４】
一態様では、コンピューティングデバイスは、そのコンピューティングデバイスの動作に関して収集された統計的情報を利用するために、様々な状態および条件の場合の最適低電力構成を判断するためのソルバーにおいて使用されるルックアップテーブルを時々再計算し得る。ルックアップテーブルの特徴を周期的に再計算することによって、本態様は、将来の低電力構成によって達成される潜在的電力節約をより良く最適化するために、コンピューティングデバイスがそれの現在および過去の動作から学習することを可能にする。ルックアップテーブルを計算するために、コンピューティングデバイスは、様々な動作条件(たとえば、異なる温度条件ならびに異なるクライアントおよびアプリケーション状態)の各々と、異なるリソースおよびリソース低電力モードの各々とについて、達成可能な相対電力節約を評価するように構成され得る。そのような計算は、図7を参照しながら上記で説明した計算と同様であり得、いくつかの異なるシステム構成ならびに温度および他の動作条件値についてプロセッサによって実行され得る。
【００７５】
様々な態様では、コンピューティングデバイスプロセッサは、バックグラウンドタスクとしてルックアップテーブルを計算するように構成され得る。すなわち、その計算は、かなりの量の処理を含む可能性があるので、プロセッサがより高い優先度の動作を実行することに関与しないときにその計算が実行されるように構成され得る。たとえば、1つまたは複数のプロセッサが通常ならばアイドル状態にあるであろうとき、コンピューティングデバイスはその計算を実行するように構成され得る。そのような計算がかなりの電力を消費する可能性があるので、コンピューティングデバイスが外部電力に接続されているとき(たとえば、バッテリーを充電するとき)のみ、したがって、電力節約が動作優先事項でなく、電力消費が問題でないとき、デバイスはこれらの計算を実行するようにさらに構成され得る。
【００７６】
図11は、コンピューティングデバイスが外部電力に接続されているとき、ルックアップテーブルを計算するための態様方法178を示している。方法178では、判断ブロック180において、プロセッサがアイドル状態に入ったとき、プロセッサは、デバイスが外部電力に接続されているかどうかを判断する。プロセッサが、デバイスが外部電力に接続されていないと判断した場合(すなわち、判断ブロック180=「いいえ」)、ブロック40において、最適低電力構成を識別し、低電力構成を構成する低電力リソースモードのセットに入るために、プロセッサは、図4および図9Aを参照しながら上記で説明したプロセスを実行する。プロセッサが、デバイスが外部電力に接続されていると判断した場合(すなわち、判断ブロック180=「はい」)、プロセッサは、ルックアップテーブルを更新するために必要とされる計算を実行する。ブロック182において、プロセッサは、最適低電力構成を計算するための特定の動作状態および条件を選択する。ブロック184において、プロセッサは、評価のために第1のリソースを選択し、ブロック186において、選択されたリソースのための第1の低電力リソースモードを選択する。ブロック188において、プロセッサは、選択された低電力リソースモードのレイテンシを使用して、選択されたモードを含む低電力構成の総リソースレイテンシを判断する。ブロック190において、プロセッサは、新しいモード電力節約を取得するために、選択された低電力リソースモードに関連する電力節約を、低電力モードの選択されたセットに関連する電力節約に加算する。
【００７７】
判断ブロック192において、プロセッサは、新しいモード電力節約が前に選択された低電力構成の節約を超えるかどうかを判断する。選択された低電力リソースモードが電力節約の増加を生じた場合(すなわち、判断ブロック192=「はい」)、ブロック194において、プロセッサは、仮低電力構成において、選択された低電力リソースモードを使用する。その後、または選択された低電力リソースモードが電力節約の増加を生じない場合(すなわち、判断ブロック192=「いいえ」)、判断ブロック196において、プロセッサは、選択されたリソースに関連する別の低電力リソースモードがあるかどうかを判断する。そのリソースに関連する別の低電力リソースモードがある場合(すなわち、判断ブロック196=「はい」)、プロセッサはブロック186に戻って、選択されたリソースのための次の低電力リソースモードを選択する。選択されたリソースのための低電力リソースモードすべてが評価された場合(すなわち、判断ブロック196=「いいえ」)、判断ブロック198において、プロセッサは、現在の選択された条件の場合に評価されるべき別のリソースがあるかどうかを判断する。
【００７８】
プロセッサが、評価されるべき別のリソースがあると判断した場合(すなわち、判断ブロック198=「はい」)、プロセッサはブロック184に戻って、評価のための次のリソースを選択する。プロセッサが、リソースすべてが現在選択された条件について評価されたと判断した場合(すなわち、判断ブロック198=「いいえ」)、プロセッサは、ブロック190において、判断された潜在的節約の値と、ブロック188において、判断された様々な低電力リソースモードのレイテンシとを含む、予想低電力構成を用いて選択テーブルを更新する。その後、判断ブロック202において、プロセッサは、評価されるべき別の条件があるかどうかを判断する。プロセッサが、評価されるべき別の条件があると判断した場合(すなわち、判断ブロック202=「はい」)、プロセッサはブロック182に戻って、評価されるべき次の条件を選択する。すべての条件が評価され、それに応じてルックアップテーブルが更新されると(すなわち、判断ブロック202=「いいえ」)、ブロック204において、プロセッサは、(外部電力に接続されていることを含む)現在の条件に適した通常のアイドルプロセスを続ける。
【００７９】
さらなる態様では、プロセッサは、最適低電力構成を判断するために使用されるパラメータを調整するために、動作統計に注目するように構成され得る。図12に示すように、態様方法210では、ブロック212において、プロセッサは、実装された低電力構成と、低電力構成を判断する際に使用される推定アイドル時間と、低電力構成の開始時間とに留意する。プロセッサが低電力構成を出た(すなわち、起動した)とき、ブロック214において、プロセッサは、プロセッサが低電力構成を出た時間と、要求されたリソースと、プロセッサまたはクライアントが、起動イベントを促したリソースを要求することとに留意する。ブロック216において、プロセッサは、ブロック214において取得された情報を使用して、特定のリソース、プロセッサ、クライアント、および/または低電力構成の場合のリソースアイドル時間に関する統計を計算または改良する。そのような統計は、補正ファクタを生成するなど、予想アイドル時間推定がどのくらい正確である傾向があるかに対処し、起動イベントを開始する特定のプロセッサまたはクライアントを識別し、特定の低電力構成のアイドル時間特性を識別し得る。ブロック218において、プロセッサは、レイテンシ、予想アイドル時間推定値、またはブロック216において計算された統計の使用に基づいて調整された電力節約のための確率または補正ファクタを用いて、リソース低電力リソースモードデータパラメータを更新する。本態様では、コンピューティングデバイスの典型的な動作に関して広範囲にわたる統計が収集され得、得られた情報は、ソルバーモジュールが最も適切な低電力構成をより良く判断することを可能にするために使用される。このようにして、低電力リソースモードおよび/または低電力構成を実装することによって節約され得る電力をさらに最適化するために、コンピューティングデバイスは、それの典型的な使用および動作条件に適応し得る。
【００８０】
様々な態様では、リソースパラメータおよびプロセッサ動作状態に基づいて、通常ならば選択されるであろう構成よりも平均して大きい電力節約を生じる低電力構成を選択するために、プロセッサは、異なるプロセッサの通常の機能に関する統計を使用することが可能であり得る。所与のアイドル期間の間、プロセッサAが(共有)リソースSまたは(ローカル)リソースLのいずれかのための低電力モードから選定することができるが、両方の低電力モードに入ることを認めない(すなわち、この特定のアイドル期間の間、それらのモードは機能的に相互排他的である)動的レイテンシ要件を有する例を参照すれば、これは明確化され得る。絶対的には、リソースSは、リソースSを低電力状態にすることによってより多くの電力を節約するであろうが、プロセッサAのアイドル時間中にプロセッサBがリソースSを必要とする確率が0ではない。リソースSがプロセッサBによってどのくらい長く使用されるかに応じて、プロセッサAのための最適低電力状態は、理論上、節約する電力はより少なくても、リソースLのための低電力リソースモードに入ることになり得る。これを考慮するために、プロセッサAはアイドル状態であるが、プロセッサBはアイドル状態でないことを仮定すれば、リソースSのための電力モデルは、それが全体的にアイドル状態になる確率だけディレーティングされ得る。すなわち、リソースSのための電力モデル計算がpower_model(idle, temp)である代わりに、その計算はE[power_model(idle, temp)|Proc A idle]になり得る。様々な態様では、期待値計算のための確率分布は、命令によって、プロファイリングによって静的に定義されるか、または実際の使用統計を収集することによって、ランタイムに経験的に判断されるかのいずれかであり得る。
【００８１】
低電力構成の実装および実施に関連する、条件、パフォーマンス、持続時間および、他の特性に関する統計的情報を収集するための学習アルゴリズムを適用するプロセスは、概して、低電力構成の電力節約パフォーマンスが、特定のコンピューティングデバイスの特性、ならびに特定のユーザの使用パターンに対して最適化されることを可能にするために適用され得る。そのような学習を達成するために、プロセッサは、モード選択方法、リソースパフォーマンス値を調整するために、場合によっては、デバイス動作を監視することから取得される情報を反映するためにソルバーにおいて実装されるアルゴリズムを調整するために、低電力モード動作から取得される様々なデータを使用して統計的解析アルゴリズムを実行し得る。
【００８２】
図13に示すさらなる態様方法220では、プロセッサは、モード選択が実際のデバイス電力消費特性に基づくために、様々な低電力構成によって達成される実際の電力節約に関する統計を収集するように構成され得る。ブロック222において、プロセッサは、入るべき特定の低電力構成と、デバイス温度と、予想アイドル時間と、アイドル状態の開始の時間とに留意する。ブロック224において、プロセッサは、それが選択された低電力構成に入ったとき、システムを通して実際の電力消耗を測定および記憶する。この測定は、低電力状態の開始時に、アイドルサイクル全体にわたって、またはアイドル状態を出るプロセスの一部としてなど、アイドルサイクルの最後に行われ得る。ステップ226において、プロセッサは、低電力状態の最後における割込み発射および/またはタイマー発射に留意する。ブロック228において、プロセッサは、ブロック222〜226において収集された情報に基づいて、現在温度における特定の低電力構成において達成される実際の電力節約を反映するために、リソース低電力リソースモードデータパラメータおよび/または低電力リソースモード選択テーブルを更新する。ブロック230において、プロセッサは、割込み発射およびタイマー発射の分配に関する統計を計算または更新し、ブロック232において、この情報を使用して低電力リソースモード選択テーブルを更新する。このようにして、構成および動作条件データに基づいて最適低電力構成を選択するためにプロセッサによって使用されるパラメータは、実際のデバイスパフォーマンスに基づいて改良され得る。様々な低電力リソースモードにおいて達成可能な電力節約は、温度と、生産工程と、寿命と、特定の構成要素の構成と、事前に予期されないことがある多くの他のファクタとに応じて変動し得る。さらに、本態様は、プロセッサが、実際の使用に基づいてアイドル動作構成を選択するために使用される計算または低電力リソースモード選択テーブルを改良することを可能にする。したがって、コンピューティングデバイスが一般に低温温度を経験する(たとえば、コンピューティングデバイスの所有者がアラスカ州に住んでいる)場合、低電力リソースモード選択テーブルは、デバイスが他の場所で経験し得る温度の完全潜在的範囲をカバーしようと試みるのではなく、コンピューティングデバイスが一般に経験する温度範囲内でより大きいグラニュラリティを与えるように改良され得る。したがって、本態様方法は、プロセッサが、そのときの、その動作の条件下のデバイスの実際のパフォーマンス特性に基づいて最適低電力構成を判断することを可能にする。
【００８３】
図14に示すさらなる態様方法240では、プロセッサは、各モードを選択的に実装し、電流または電力需要の生じた変化を測定することによって、各低電力リソースモード(すなわち、各リソースの各低電力モード)の電力節約特性を測定し得る。各低電力リソースモードによって達成される実際の電力節約を測定することによって、コンピューティングデバイスは、最適なシステム低電力モード構成を選択するために有用な統計を収集することができる。構成変更およびデバイス寿命が、特定の低電力リソースモードによって達成される電力節約に影響を及ぼすことがあるので、本方法は、デバイスが製造されてから変化し得た現在の動作構成および条件に基づいて、コンピューティングデバイスがシステム低電力構成決定を行うことを可能にする。また、様々な低電力リソースモードの電力節約可能性の温度感度に関する情報を取得または更新するために、異なる温度においてそのような測定が実行され得る。
【００８４】
図14を参照すると、方法240では、ブロック241において、コンピューティングデバイスプロセッサが、それが既知の安定状態にあり、測定を行うことを助長する動作条件にあると判断したとき、プロセッサは、デバイス内に含まれるセンサを使用して、デバイス温度と電流または電力需要とを測定する。このブロックにおいて、プロセッサは、各低電力リソースモードを用いて達成可能な電力節約に影響を及ぼし得る他の動作条件を測定し得る。ブロック242において、プロセッサは、測定のために、低電力モードを有するリソースを選択する。ブロック243において、プロセッサは、選択されたリソースを、それの低電力リソースモードのうちの選択された低電力リソースモードにする。次いで、ブロック244において、プロセッサは、実装された低電力リソースモードの場合のシステム電流または電力需要を測定する。ブロック245において、プロセッサは、選択されたリソースを選択された低電力リソースモードにすることによって達成される電力節約を計算する。これは、ブロック241において測定された初期電力から、ブロック244において測定された電力を減算することによって達成され得る。判断ブロック246において、プロセッサは、測定すべき別のリソースがあるかどうかを判断する。そうであれば(すなわち、判断ブロック246=「はい」)、プロセッサはブロック242に戻って、測定のための次のリソースを選択する。リソースすべてが選択され、対応する低電力リソースモード電力節約が測定されると(すなわち、判断ブロック246=「いいえ」)、ブロック247において、プロセッサは、測定された電力節約を使用して、低電力モード選択テーブルを更新する。更新された低電力モード選択テーブルは、プロセッサがスリープサイクルに入る次の時にシステム低電力モード構成を選択するために使用され得る。一態様では、特にシステム温度が前の測定プロセスとは異なることにプロセッサが気づいたとき、方法240は周期的に繰り返され得る。異なる温度において低電力リソースモードの各々によって達成される電力節約を測定することによって、プロセッサは、曲線の当てはめアルゴリズムなどのよく知られている算術分析を通して、各低電力リソースモードの電力節約可能性の温度感度を計算または推定することができる。次いで、そのような温度感
度は、システム低電力モード構成において実装されるべき低電力リソースモードを選択するプロセスにおいて使用され得る。
【００８５】
様々な態様は、さらなるバッテリー電力を単に節約すること以上に、ユーザおよび開発者にいくつかの有用な利益を与える。1つの利益として、様々なリソースの低電力リソースモードおよびそれらの定義は、大部分は、モードを実装するコードとは無関係である。関係するドライバ呼出しは、「入」機能および「出」機能内に含められ得、したがって、低電力リソースモードは影響を受けない。ソルバープロセス(すなわち、上記で説明した方法26中のブロック38)は、各低電力リソースモードについての電力およびレイテンシデータなどのハードデータと、現在の動作状態に存在する動的制限(たとえば、レイテンシ要件)および動作条件とに基づいて、いつ低電力リソースモードに入るべきか、またはいつそれから出るべきかを判断することに対処し得る。したがって、開発者は、好適な低電力リソースモードをデバイスにハードコーディングするために、そのようなパラメータの組合せを予期することを試みる必要はない。
【００８６】
上記で説明した態様の別の利益は、コンピューティングデバイスが、システムモードの事前構成されたかまたはあらかじめ定義されたセットから単一の定義された低電力リソースモードを選択するように要求されないが、現在の動作状態、リソース、動作条件、推定されたスリープサイクル、デバイス構成などに基づいて、システムのための低電力構成を動的に実装するために低電力リソースモードの組合せを選択することができることである。これは、前の既知の電力管理システムが、あらかじめ定義された低電力構成のセット(たとえば、モード1、モード2、またはモード3のうちの1つ)から選択するように構成されるので有利であるが、上記で説明した態様は、デバイスが、低電力モードに入ることに応じられる各リソースについて1つまたは複数の低電力リソースモードを動的に選択することを可能にし、現在の条件および状態に最も良く適したシステム低電力構成を実装するためにはるかに大きいフレキシビリティを与える。たとえば、特定のプロセッサが、リソースA、BおよびCの低電力リソースモードをそれぞれ有する3つのリソースA、BおよびCを有すると仮定する。Aの低電力リソースモードはレイテンシ.4msを有し得、Bの低電力リソースモードはレイテンシ.5msを有し得、Cの低電力リソースモードはレイテンシ.6msを有し得るなど、低電力リソースモードは異なるレイテンシを有し得る。システムに対して1ミリ秒のレイテンシ要件(たとえば、1msのワーストケース許容レイテンシ)があるようにUSBクライアントがアクティブである場合、選択された低電力モードの組合せがワーストケースレイテンシ要件を満たす限り、リソースA、BおよびCの低電力モードは、互いから独立して有効化または無効化され得る。たとえば、プロセッサがアイドル状態になり、リソースA、BおよびCがすべて有効化された場合、システムは、Aの低電力リソースモード(レイテンシ.4ms)、Bの低電力リソースモード(レイテンシ.5ms)、Cの低電力リソースモード(レイテンシ.6ms)、AおよびBのモード(レイテンシ.9ms)、またはAおよびCのモード(レイテンシ1ms)を選ぶことができる。したがって、様々な態様では、ソルバータスクは、1msのワーストケースレイテンシトレランスを仮定すれば、最も多くの電力を節約する低電力リソースモ
ードの最も良好なセットを選び得る。
【００８７】
さらに、典型的な電力管理システムは、クライアントが非アクティブモードとアクティブモードとを有し、レイテンシトレランスが現在のパフォーマンス状態に依存することを要求する。上記で説明した様々な態様では、クライアント機構は、「アクティブ」または「非アクティブ」ではなく、「存在する」または「存在しない」とすることができる。すなわち、様々な態様では、様々な低電力リソースモードは、動作状態(たとえば、アクティブまたは非アクティブ)に基づいて選択されるのではなく、可能な状態を排除するために進行され得る。さらに、様々な態様は、クライアントが、様々なリソースのための低電力リソースモードを作成、登録および/または無視することを可能にし、多数の可能なシステム低電力構成を可能にするために低電力リソースモードの組合せを動的に選択することを可能にする。これは、システムクライアントがデバイスの低電力状態をさらに制御し、微調整することを可能にする。
【００８８】
上記で説明した態様の別の利益は、コンピューティングデバイスプロセッサがシステムクライアントの様々な動作モードに気づく必要がないということである。様々な態様では、クライアントは、それらのレイテンシトレランスのみを直接サブミットし得る。したがって、プロセッサは、各クライアントの動作状態に関連する様々な詳細に関して知る必要がない。プロセッサは、クライアントの登録されたレイテンシトレランスを知り、報告されたレイテンシトレランスに基づいて低電力リソースモードに入るべき低電力リソースを選択するだけでよい。様々な態様では、トレランスおよび低電力モードの設定は、個別エンティティによってなされ得る。たとえば、USBクライアントは、レイテンシトレランを設定し得るが、必ずしも低電力モードを設定しないことがある。各低電力リソースモードは、レイテンシ考慮事項から完全に独立している所与のスリープサイクル上で、それらのモードに入り得るかどうかを示すシグナリング機構のセットを有し得る。
【００８９】
さらなる利益として、一態様では、クライアントが、それらがどのくらい長くスリープ状態にあると予想するかを指定することを可能にするために、新しいNPAプログラミングノードが与えられ得る。たとえば、クライアントが、それらが(71時間までの)「X」マイクロ秒以内の間スリープ状態にある(すなわち、プロセッサまたはリソースを利用しない)と予想することを指定することを可能にするために、NPAプログラミングノード「/core/processor/wakeup」が与えられ得る。そのようなプログラミング能力は、プロセッサアイドル状態および低電力構成との適合性について、クライアントアプリケーションの開発を簡略化し得る。
【００９０】
さらなる態様では、アイドル状態に入り得るときに同じまたは同様の動作条件(たとえば、動作状態、温度、およびレイテンシ制限)が存在するとき、ソルバーアルゴリズムを再実行する必要なしに、最適低電力構成が再利用され得るように、図7を参照しながら上記で説明したようなソルバー計算の結果はメモリ中にキャッシュされ得る。このようにして、プロセッサは、最適な、またはほぼ最適な電力節約を依然として達成しながら、ソルバーアルゴリズムを実行するプロセスをスキップすることによってアイドル状態に迅速に入ることができる。さらなる態様では、キャッシュされた最適低電力構成が、条件および状態の統計的に判断された範囲にリンクされ得るように、動作状態および条件は統計的に分析され得る。
【００９１】
様々な態様での使用に好適な典型的なモバイルデバイス250は、図15に示す構成要素を共有する。たとえば、例示的なモバイル受信機デバイス250は、内部メモリ252とディスプレイ253とスピーカー259とに結合されたプロセッサ251を含み得る。さらに、モバイルデバイス250は、プロセッサ251に結合されたモバイルマルチメディア受信機256に接続される、電磁放射を送信および受信するためのアンテナ254を有し得る。いくつかの態様では、モバイルマルチメディア受信機256は、受信機256の動作を制御し、デバイスプロセッサ251と通信するために、デジタル信号プロセッサ(DSP)などの内部プロセッサ258を含み得る。モバイルデバイスは、一般に、ユーザ入力を受け取るためのキーパッド256または小型キーボードおよびメニュー選択ボタンまたはロッカースイッチ257をも含む。
【００９２】
プロセッサ251は、本明細書で説明する様々な態様の機能を含む、様々な機能を実行するようにプロセッサ実行可能ソフトウェア命令(アプリケーション)によって構成され得る任意のプログラマブルマイクロプロセッサ、マイクロコンピュータあるいは1つまたは複数の多重プロセッサチップであり得る。また、様々な態様の機能は、DSP実行可能命令で構成された受信機256内のDSPプロセッサ258において実装され得る。一般に、ソフトウェアアプリケーションおよびプロセッサ実行可能命令は、アクセスされ、プロセッサ251にロードされる前に内部メモリ252に記憶され得る。いくつかのモバイルデバイスでは、プロセッサ251は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含み得る。一部のモバイルデバイスでは、セキュアなメモリは、プロセッサ251に結合された別個のメモリチップ中にあり得る。多くのモバイルデバイス250では、内部メモリ252は、揮発性メモリ、またはフラッシュメモリなどの不揮発性メモリ、あるいは両方の混合であり得る。本明細書では、メモリへの一般的言及は、内部メモリ252と、モバイルデバイスに接続されるリムーバブルメモリと、プロセッサ251自体の内のメモリとを含む、プロセッサ251によってアクセス可能なすべてのメモリを指す。
【００９３】
上記の方法の説明およびプロセスフロー図は、単に説明のための例として提供したものであり、様々な態様のステップを提示された順序で実行しなければならないことを要求または暗示するものではない。当業者なら諒解するように、上記の態様におけるステップの順序は、どんな順序でも実行され得る。「その後」、「次いで」、「次に」などの単語は、ステップの順序を限定するものではなく、これらの単語は、単に、読者に方法の説明を案内するために使用される。さらに、たとえば、冠詞「a」、「an」または「the」を使用する単数形の請求項要素への言及は、その要素を単数形に限定するものと解釈すべきではない。
【００９４】
本明細書で開示した態様に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈すべきではない。
【００９５】
本明細書で開示した態様に関して説明した様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、マルチメディアブロードキャスト受信機チップ内のDSP、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、あるいは本明細書で説明した機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。代替的に、いくつかのステップまたは方法は、所与の機能に固有の回路によって実行され得る。
【００９６】
1つまたは複数の例示的な態様では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装した場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。本明細書で開示した方法またはアルゴリズムのステップは、コンピュータ可読媒体上に常駐し得る、実行されるプロセッサ実行可能なソフトウェアモジュールで実施され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく、例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスク記憶装置、磁気ディスク記憶デバイスまたは他の磁気記憶デバイス、あるいは命令またはデータ構造の形態で所望のプログラムコードを搬送または記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フレキシブルディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。さらに、方法またはアルゴリズムの動作は、コンピュータプログラム製品
に組み込まれ得る、機械可読媒体および/またはコンピュータ可読媒体上のコードおよび/または命令の1つまたは任意の組合せ、あるいはそのセットとして常駐し得る。
【００９７】
開示した実施形態の上記の説明は、当業者が本発明を製作または使用できるように提供したものである。これらの実施形態に対する様々な変更は、当業者には容易に明らかとなり、本明細書で定義された一般的な原理は、本発明の趣旨または範囲から逸脱することなく他の実施形態に適用され得る。したがって、本発明は、本明細書で示した実施形態に限定されるものではなく、以下の特許請求の範囲ならびに本明細書で開示した原理および新規の特徴に合致する最も広い範囲を与えられるべきである。
【符号の説明】
【００９８】
2 ノード電力アーキテクチャ
2 NPA
4 水晶発振器
4 水晶発振器リソース
6 ゲート動作状態
8 完全遮断
24 態様方法
24 方法
38a 態様方法
38a 方法
38b 態様方法
38b 方法
38c 代替態様方法
38c 方法
38d 代替態様方法
50 クライアント
52 クライアント
54 クライアント
58 処理ノード
60 アイドルタスク
69 処理ノード
69 ノード
70 メモリ
70 処理ノード
70 ノード
72 処理ノード
72 ノード
74 処理ノード
74 ノード
76 電圧レール
76 処理ノード
76 ノード
78 クロック発振器
78 処理ノード
80 LMPマスク
86 低電力リソースモード「入」機能
90 LMPマスク
92 LMPマスク
94 LMPマスク
120 低電力構成
122 低電力構成
124 低電力構成
220 態様方法
240 態様方法
250 受信機デバイス
250 モバイルデバイス
251 プロセッサ
251 デバイスプロセッサ
252 内部メモリ
253 ディスプレイ
256 受信機
256 キーパッド
256 モバイルマルチメディア受信機
257 ロッカースイッチ
258 内部プロセッサ
258 DSPプロセッサ
259 スピーカー
【技術分野】
【０００１】
関連出願
本出願は、その内容全体が参照により本明細書に組み込まれる、2010年1月11日に出願された「Dynamic Low Power Mode Implementation For Computing Devices」と題する米国仮特許出願第61/294,055号の優先権の利益を主張する。
【背景技術】
【０００２】
ワイヤレス通信技術は、過去数年にわたって爆発的成長を経験してきた。この成長は、モバイル大衆に移動の自由を与え、有線通信システムへの束縛を断ち切る、ワイヤレスサービスによって加速された。サービス拡張の結果として、ワイヤレスサービスの流行は急速に成長し続けることが予想される。バッテリー寿命はモバイル電子デバイスの主要因であり、したがって、バッテリー電力の節約を可能にする方法およびデバイスが電子デバイス技術における重要な考慮事項である。
【発明の概要】
【課題を解決するための手段】
【０００３】
様々な態様は、コンピューティングデバイスのリソースにとって最適な、またはほぼ最適な低電力動作モードの組合せを選択するために、コンピューティングデバイス内のプロセッサによって使用または実装され得るデータおよび方法を提供する。様々な態様は、リソース構成要素が2つ以上のリソース電力モードを有することを可能にし、プロセッサが低電力またはスリープ状態に入ったときにシステム低電力モードを動的に構成するために、動作状態と動作条件とスリープサイクル特性と他のファクタとに基づいて、プロセッサが様々なリソースの各々について電力モードを選択することを可能にする。様々な態様は、実効レイテンシがすべてのアクティブタスクのシステム全体のレイテンシ要件を超えないであろう様々なリソースまたはリソースの組合せを識別するために、プロセッサがそれらのリソースの低電力モードおよびリソース低電力モードの組合せを評価することを可能にする。様々な態様は、プロセッサが、すべてのアクティブタスクのシステム全体のレイテンシ要件を満たしながら、電力節約を最大にするシステム低電力構成において実装すべきリソース低電力モードの組合せを選択し、あらかじめ定義された低電力構成のセットから選択する代わりに、動的に(すなわち、スリープサイクルの時間に)この選択を行うことを可能にする。様々な態様は、プロセッサが、現在の条件と動作状態とに対して最適化された最適低電力構成を判断するためにソルバープロセスによって使用されるルックアップテーブルを断続的に再計算することを可能にする。様々な態様は、プロセッサが、現在の状態と、アクティブなデバイスおよびアプリケーションと、予想されるスリープ持続時間とに好適な最適低電力構成を判断するために、コンピューティングデバイスの動作に関する統計的情報を利用することを可能にする。様々な態様は、プロセッサが、現在および過去の環境情報および使用情報に基づいて最適低電力構成を選択することを可能にする。
【０００４】
様々な態様は、コンピューティングデバイスにおける電力を温存するための方法を含み、方法は、リソースが使用されていないときリソースに関連するフラグビットを設定するステップであって、リソースが複数のリソースのうちの1つである、設定するステップと、プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得るリソースを識別するステップと、識別されたリソースの各々についてレイテンシ要件を登録するステップと、登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択するステップと、選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価するステップと、潜在的電力節約を最大にし、選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択するステップと、識別されたリソースの各々に対して選択された低電力モードの各々の入機能(enter function)を実行することによって低電力リソースモードの選択された組合せに入るステップとを含む。本態様方法では、低電力リソースモードの組合せを選択するステップが、様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行するステップを含み得る。本態様方法は、プロセッサがアイドル状態のままであることが予想される時間を判断するステップと、現在温度における単位時間当たりの潜在的電力節約×判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの潜在的電力節約を判断するステップとをさらに含み得る。本態様方法は、デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定するステップと、測定のためのリソースを選択するステップと、選択されたリソースを低電力リソースモードにするステップと、選択されたリソースが低電力リソースモードにある間、電流または電力需要を測定するステップと、低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップ、選択されたリソースを低電力リソースモードにするステップ、および選択されたリソースが低電力リソースモードにある間、電流または電力需要を測定するステップを繰り返すステップとをさらに含み得、潜在的電力節約を最大にする低電力リソースモードの組合せを選択するステップが、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する測定された電流または電力需要を使用するステップを含む。本態様方法は、異なる温度において請求項3に記載の動作を繰り返すステップと、各低電力リソースモードに関連する電流または電力需要の温度感度を判断するステップとをさらに含み得、潜在的電力節約を最大にする低電力リソースモードの組合せを選択するステップが、コンピューティングデバイスの温度を測定するステップと、測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の判断された温度感度を使用するステップとをさらに含む。本態様方法では、低電力モードにされ得る各リソースについて低電力リソースモードを評価するステップが、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成するステップを含み得、動作条件は温度値を含み得る。本態様方法は、コンピューティングデバイス上で動作条件に関する統計を収集するステップと、収集された動作条件統計に基づいて低電力モード選択データテーブルを更新するステップとをさらに含み得る。本態様方法では、動作条件は、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択され得る。本態様方法は、コンピューティングデバイスが外部電力に接続されているかどうかを判断するステップであって、コンピューティングデバイスが外部電力に接続されているとき、動作条件統計に基づいて低電力モード選択データテーブルを更新するステップが達成される、判断するステップをさらに含み得る。
【０００５】
様々な態様はまた、上記の態様方法の機能を実行するための手段を含むコンピューティングデバイスを含む。
【０００６】
様々な態様はまた、メモリバッファとメモリバッファに結合されたプロセッサとを含むコンピューティングデバイスにおける電力を温存するための装置を含み、プロセッサは、上記の態様方法の動作を実行するためのプロセッサ実行可能命令で構成される。
【０００７】
様々な態様はまた、上記の態様方法の動作を含む、コンピューティングデバイスにおける電力を温存するための動作をプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を記憶した非一時的記憶媒体を含む。
【０００８】
本明細書に組み込まれ、本明細書の一部をなす添付の図面は、本発明の例示的な実施形態を示し、上記の概略的な説明および下記の発明を実施するための形態とともに、本発明の特徴を説明するのに役立つ。
【図面の簡単な説明】
【０００９】
【図１】一態様における2つの低電力モードのうちの1つに入るようにプログラミングノードによって制御されるリソースの図である。
【図２】一態様による、共用リソースが、低電力モードに入るそれの能力を登録する方法のプロセスフロー図である。
【図３】一態様による、共有リソースが低電力モードを出る方法のプロセスフロー図である。
【図４】一態様による、低電力モードを選択し、低電力モードに入るための方法のプロセスフロー図である。
【図５】低電力モードを選択し、低電力モードに入るための態様方法を示すプログラミングノードおよびリソース図である。
【図６】低電力モードを選択し、低電力モードに入るための別の態様方法を示すプログラミングノードおよびリソース図である。
【図７】最適低電力モードを選択するための態様方法のプロセスフロー図である。
【図８Ａ】予想アイドル時間に基づいて最適低電力モードを選択するための態様方法を示す3つの代替低電力モードの電力節約対アイドル時間のグラフである。
【図８Ｂ】予想アイドル時間に基づいて最適低電力モードを選択するための態様方法を示す3つの代替低電力モードの電力節約対アイドル時間のグラフである。
【図９Ａ】最適低電力モードを選択するための代替態様方法のプロセスフロー図である。
【図９Ｂ】最適低電力モードを選択するための代替態様方法のプロセスフロー図である。
【図１０】最適低電力モードを選択するための代替態様方法のプロセスフロー図である。
【図１１】コンピューティングデバイスが外部電力に接続されているかどうかに基づいて、最適低電力モードを選択するか、または低電力モード選択テーブルを更新するための代替態様方法のプロセスフロー図である。
【図１２】モバイルデバイスによって収集された統計に基づいてリソースの電力節約パラメータを更新するための態様方法のプロセスフロー図である。
【図１３】モバイルデバイスが、様々な低電力モードによって達成される電力節約に関する統計、ならびにアイドルモード電力節約に影響を及ぼす割込みおよびタイマーの分配に関する統計を収集し得る態様方法のプロセスフロー図である。
【図１４】モバイルデバイスが、各低電力リソースモードによって達成される測定された電力節約を収集し得る態様方法のプロセスフロー図である。
【図１５】一態様において使用するのに好適なモバイルデバイスの構成要素ブロック図である。
【発明を実施するための形態】
【００１０】
様々な態様について添付の図面を参照しながら詳細に説明する。可能な場合はいつでも、同じまたは同様の部分を指すために図面全体にわたって同じ参照番号を使用する。特定の例および実装形態になされる言及は、説明のためであり、本発明の範囲または特許請求の範囲を限定するものではない。
【００１１】
「例示的」という単語は、本明細書では、例、事例、または例示の働きをすることを意味するために使用する。本明細書に「例示的」と記載されたいかなる実施形態も、必ずしも他の実装形態よりも好ましいまたは有利であると解釈されるべきではない。
【００１２】
「モバイルデバイス」および「コンピューティングデバイス」という用語は、本明細書では、セルラー電話と、個人情報端末(PDA)と、パームトップコンピュータと、ワイヤレス電子メール受信機(たとえば、Blackberry(登録商標)およびTreo(登録商標)デバイス)と、マルチメディアインターネット対応セルラー電話(たとえば、Blackberry Storm(登録商標))と、Global Positioning System(GPS)受信機と、ワイヤレスゲームコントローラと、プログラマブルプロセッサを含み、電力節約方法が有益になるようにバッテリー電力の下で動作する同様のパーソナル電子デバイスとのうちのいずれか1つまたはすべてを指すために互換的に使用する。
【００１３】
本明細書で使用する「リソース」という用語は、多種多様な回路(たとえば、ポート、クロック、バス、発振器など)と、構成要素(たとえば、メモリ)と、信号(たとえば、クロック信号)と、コンピューティングデバイス上で実行されるプロセッサおよびクライアントをサポートするために使用される電圧(たとえば、電圧レール)とのうちのいずれかを指すために本明細書で使用する。
【００１４】
ワイヤレスデバイスのバッテリー寿命を最大にすることは、重要な設計基準である。バッテリー寿命を増加させることで、より長い時間ユーザがワイヤレスデバイスを用いてより多くのことを行うことを可能にすることによって、ユーザのエクスペリエンスを最大にする。しかしながら、ユーザのエクスペリエンスを真に最大にするために、デバイスの機能または信頼性を改変しないように電力節約ストラテジが実装されるべきである。したがって、機能を改変しない効率的で効果的な電力節約方式を設計することは、モバイルおよびワイヤレスデバイスプロバイダにとって重要な目的である。
【００１５】
バッテリー寿命を最大にするために、たいていのモバイルブロードキャスト受信機は、プロセッサがアイドル状態にあるときなど、可能な場合はいつでも、1つまたは複数のプロセッサおよびデバイスリソースを低電力状態にするように構成される。デバイスリソースを低電力状態にすることは、一般に、プロセッサがアクティブにタスクを処理していないときはいつでも、および/またはアイドル状態にあるときはいつでも様々なデバイスリソースをオフにすることからなる。プロセッサがタスクを処理していないときおよび/またはアイドル状態にあるときに、オフにされるか、あるいは1つまたは複数の低電力および/またはアイドル状態にされることが可能であるリソースを、本明細書では低電力リソース、またはLPRと呼ぶ。ワイヤレスモデムプロセッサおよびアプリケーションプロセッサを有し得るスマートフォンなど、マルチプロセッサデバイスでは、低電力モードを実装する動作は、独立して、または協調して各プロセッサによって達成され得る。
【００１６】
モバイルコンピューティングデバイスは、一般に、水晶発振器、電圧レール、1つまたは複数のメモリユニット、通信バスなど、デバイスプロセッサが使用するいくつかのリソースを含む。コンピューティングデバイスが一層複雑になっているので、デバイスプロセッサによって使用または管理されるリソースの数は毎年増加している。たとえば、多くのモバイルコンピューティングデバイスは、現在、複数の水晶発振器と、複数の電圧レールと、複数のメモリとを含み、それらの各々は独立して制御され得る。したがって、電力を温存するために、コンピューティングデバイスプロセッサがオフにし得るかまたは低電力モードにし得る多くの異なるリソースがある。また、コンピューティングデバイスは、様々なデバイスリソースを使用し、異なるタスクを実行する(したがって、同時にアイドル状態でないことがある)複数のプロセッサを有し得る。これらの理由のために、低電力モードにされるべきリソースを選択するときに、ある程度の制御の実行が行使されなければならない。低電力モードにすべきリソースを選定することは「スリープ問題」として知られている。
【００１７】
概して、プロセッサが安定アイドル状態に入ったときなど、プロセッサがリソースをもはや必要としないとき、プロセッサは、低電力リソースのエネルギー消費のニーズをオフにするか、無効化するか、アイドリングするか、または場合によっては低減し得る。プロセッサが「起動する」(たとえば、別のプロセスを実行するためにアイドル状態を出る)とき、リソースは、オンに戻され、再有効化され、および/または許容できる動作状態に戻されなければならない。しかしながら、各低電力リソースは、異なる電力消費レベルとレイテンシ特性(すなわち、リソースを完全電力モードに戻すために必要とされる時間)とを有し得、そのような特性は、温度および動作状態とともに変化し得る。すなわち、各リソースは、それらの様々な低電力モードで異なる電力量を消費し得、電源切断状態、アイドル状態および/または低電力状態に入り、それを出るために異なる時間量を必要とし得、そのような状態に入り、それを出るときに異なる電力量を消費し得る。明快のために、リソースの各々にとって利用可能な様々な低電力モードを、本明細書では、低電力リソースモードまたはLPRMと呼ぶ。
【００１８】
リソースをそれの要求される動作状態に戻すために必要とされる電力が、プロセッサアイドル状態の推定された持続時間の間リソースを低電力モードにすることによって節約される電力よりも大きい場合、ワイヤレスデバイスのバッテリー寿命は、プロセッサがアイドル状態のときはいつでもリソースをオフにし、および/またはリソースを低電力状態にするだけでは、最大にされないことがある。したがって、どの低電力リソースがオフにされ、および/または低電力モードにされるべきか、ならびに各リソースがなるべき特定の低電力モードを判断するスリープ問題は、一般に、レイテンシ、電力節約可能性、電力消費および相互依存性などの各リソースの低電力モード特性とともに、そのプロセッサ状態ならびに他のデバイスプロセッサの状態の分析を必要とする。また、リソース低電力モード特性は、温度などの動作条件によって影響を及ぼされ得、したがって、そのような条件も評価されるべきである。
【００１９】
上記で説明したように、各リソースは、リソースがなり得る低電力モードまたはLPRMのセットを有し得る。各リソースの各低電力リソースモードは、それのレイテンシ、電力節約可能性、遷移電力消費、低電力モード入基準(mode entrance criteria)、モード出基準(mode exit criteria)およびリソース相互依存に関して特徴づけられ得、それらの一部または全部は、温度および他の動作条件とともに変動し得る。リソースは、その各々が、異なる電力節約特性および待ち時間(latency time)を有し得る2つ以上の低電力リソースモードを有し得る。たとえば、リソースについての1つの低電力リソースモードは、そのリソースを完全に無効化し得る(たとえば、電力を遮断する)が、第2の低電力リソースモードは、リソースの機能または周期動作の低減に関与し得る。各低電力リソースモードは、単位時間ごとに異なる電力節約を行うこと、そのモードに入り、それを出るために異なる時間量(すなわち、異なるレイテンシ要件)を必要とすることなど、異なる動作特性を有し得る。たとえば、揮発性メモリチップは、以下の2つの低電力リソースモード、すなわち、最小電力量を消費するが、動作状態に戻るためにより大きい時間(すなわち、より大きいレイテンシ)を必要とするディープ電源切断モード(deep power-down mode)と、ある程度のバッテリー電力を消費し続けるが、より低いレイテンシを有する(すなわち、それは極めて迅速に完全機能状態に戻ることができる)自己リフレッシュモード(self-refresh mode)とを有し得る。さらに、各低電力リソースモードによって与えられる電力節約は、温度および予想アイドル時間などの動作条件に依存し得る。したがって、いくつかの態様では、低リソース電力モードは、予想される電力節約を、現在温度における単位時間当たりの潜在的電力節約に、判断された予想アイドル時間を乗算した積として計算し得る。他の態様では、予想される電力節約は、温度と予想アイドル時間と他の変数との別の関数として判断され得る。
【００２０】
上述のように、リソースを低電力モードにし、プロセッサの起動時にリソースを通常モードに回復することは、しばしば、達成するのに電力と時間(すなわち、レイテンシ)の両方がかかる何らかの作業を必要とする。低電力リソースモードに入るのに必要な追加の電力および時間は、システムがアイドル状態のままである時間量が短すぎる場合、実際の電力節約を生じないことがある。言い換えれば、リソースを低電力リソースモードにし、リソースを完全動作に戻す際に消費される電力は、リソースが低電力モードにあった短い時間中に節約された電力よりも多くなり得る。したがって、特定の低電力リソースモードに入る利益は、プロセッサがアイドル状態のままであり得る予想される時間に依存し得る。この時間を、本明細書では「予想アイドル時間」と呼ぶ。
【００２１】
リソースを低電力リソースモードにすることによって節約され得る電力量は、動作モードの特性、および必要とされるリソースの特性に基づいて、ならびにリソースがそのモードのままである時間量に基づいて変動する。たとえば、メモリチップを自己リフレッシュ低電力モードにすることは、自己リフレッシュプロセスに関連する電力を消費し、ならびにチップへの電力の可用性を必要とし得る。したがって、特定の低電力リソースモードでの利用可能な電力節約は、所与のスリープサイクルにおいて実装すべき低電力リソースモードの組合せを決定するために、複数の低電力リソースモードの中から選択する際に考慮すべき重要な特性である。
【００２２】
上述のように、リソースを特定の低電力リソースモードにすることによって節約され得る電力量も、温度など、環境ファクタおよび動作ファクタに依存し得る。温度はデバイス内の電気抵抗に影響を及ぼす。したがって、(低電力構成が事前に展開されるときに仮定されなければならない)室温における各リソースの異なる低電力リソースモードに関連する電力節約は、デバイスがはるかに低温になる場(たとえば、アラスカ州の冬の間)にあるか高温になる場(たとえば、テキサス州の夏の間)にあるかで異なり得る。したがって、現実の条件での異なる低電力構成(すなわち、低電力リソースモードの選択されたセット)の電力節約は、現実の最適低電力モードが、事前に予期され得るものとは異なることを意味し得る。デバイスの温度は事前に知られ得ないので、この重要な特性は、低電力モードを編成および選択するための従来の方法を使用して、利用可能な低電力リソースのための低電力リソースモードの組合せを選択するために使用され得ない。
【００２３】
電力を節約することが、電子デバイスのための低電力モードを構成する際の重要な目的であるが、デバイスが低電力モードに入った後に適切に動作し続けることを確実にすることも考慮されるべきである。したがって、各低電力リソースモードに関連するレイテンシの考慮も重要である。上述のように、低電力リソースモードに入り、それを出て、リソースを通常動作モードに戻すために、ある時間量が必要とされる。この待ち時間は予想アイドル時間未満であるべきであり、さもなければ低電力モードはほとんど無益になる。より有意には、低電力リソースモードまたは低電力リソースモードの選択された組合せを出ることに関連するレイテンシは、1つまたは複数のリソースが低電力モードにあるときにその1つまたは複数のリソースを要求し得るクライアントまたはプロセッサの最大許容システムレイテンシよりも小さくなければならない。特定の低電力リソースモード、または低電力リソースモードの組合せを出ることに関連するレイテンシがシステムの許容できるレイテンシを超えた場合、特定のシステム低電力構成は、機能エラーにつながるか、または何らかの無関係な技術が間違って機能することになるので、許容できないことがある。
【００２４】
レイテンシ要件がスリープ問題における重要な考慮事項である状況の例は、ユニバーサルシリアルバス(USB)コネクタがモバイルデバイスに接続されているときである。USBプロトコルは、一般に極めて短いレイテンシ要件を有し、ホストがそのレイテンシ内にリソース要求への応答を受信しない場合、ホストは、デバイスが故障していると結論し得る。したがって、現在の動作構成がUSBデバイスへの接続を含むとき、出レイテンシ(exit latency)がUSBレイテンシ要件よりも大きい、リソースの低電力リソースモードまたは低電力リソースモードの組合せに入れられるべきではない。
【００２５】
レイテンシおよび動作条件に加えて、リソースの低電力モードは、他のリソースおよび/または条件にも依存し得る。そのようなリソース相互依存性考慮事項を、本明細書では概して「依存性」と呼ぶ。これらの依存性は、相互依存し得る(すなわち、別のリソースが利用可能のままである場合のみ、そのモードが有効化され得る)か、排他的であり得る(すなわち、特定の他のリソースが低電力モードまたは高電力モードにある場合、そのモードに入ることができない)か、または直交であり得る(すなわち、それらのモードは、互いとの関係を有さず、独立して有効化され得る)。また、低電力モード依存性は、「静的」または「動的」のいずれかであるとして分類され得る。静的依存性は、リソースが、特定の低電力モード動作を実装することさえも考慮し得る前に満たされなければならない条件を定義するものである。動的依存性は、他方では、1つのモードがシステム中の別のモードと併せて実装され得るときのみに生じ、それは、一般にランタイムにおいてのみ判断できる。
【００２６】
静的依存性はある程度の確度で予期され得るが、動的依存性は前もって判断するのが難しい。さらに、構成要素および/またはリソースの数が増加するにつれて、動的依存性は指数関数的により複雑になる。現代のワイヤレスデバイスが、複雑さを増し続け、より多くの構成要素およびリソースを含むにつれて、低電力モードの動的依存性を効果的に管理することはますます重要になる。
【００２７】
したがって、リソースをアイドリングおよび/または無効化することによってバッテリー寿命を温存するようにデバイスを構成することは、電力節約の様々な低電力モード特性、様々なリソースのレイテンシおよび相互依存性、ならびに同時に実行され得るクライアントとプロセッサとアプリケーションとの要件を平衡させるために、リソースの異なる低電力リソースモードの中から選択することに関与する。この選択プロセスは、特にコンピューティングデバイスの複雑さが増加する際に考慮され得る変数および置換の数に起因する(古典的な「ナップザック」問題に類似している)計算量的に困難なタスクである。
【００２８】
現在、プロセッサおよび電子デバイスのための低電力モードは、優先度と予測可能な特性との静的セットに基づいて開発者によって事前に構成される。低電力構成の1つまたは数個のセットは、開発中にプロセッサまたはシステムにハードコーディングされ得る。低電力モードのセットからの1つの低電力構成の選択は、現在、ハードコーディングされたif-then/else決定ツリープログラミングによって制御される。複数のあらかじめ定義されたシステム低電力モードが与えられたとき、動作クライアントが「投票(voting)」によってそれらの様々なリソース要件または動作条件を示すことを可能にすることによって、プロセッサは、様々なあらかじめ定義されたモードの中から選択し得る。クライアント投票の結果は、1つまたは複数の低電力モードを明示的に無効化することになり得る。
【００２９】
いくつかのあらかじめ定義されたシステム低電力モードの中から実装すべき1つのシステム低電力モードを選択するための既知のプロセスは、温度と予想アイドル時間とレイテンシ要件とを考慮し得る。しかしながら、そのような既知の方法はすべて、低電力モードにされ得るリソースの組合せを予期することによっていくつかの随意のシステムモードをあらかじめ定義し、それらの可能性のある相互依存性を評価し、それらのレイテンシを合計し、そのようなモードに入り得るときにシステム要件および制限を予期するように、システム、プロセッサまたはアプリケーション開発者に要求する。プロセッサおよびデバイスが比較的単純だったときには、低電力モード条件を予期し、選択が行われ得るシステムモードのセットをあらかじめ定義するプロセスが可能だったが、システムおよびプロセッサの複雑さが将来増加するにつれて、この設計問題が極めて困難になることが予期される。
【００３０】
コンピューティングデバイスにおけるシステム低電力モードを開発し、実装するための今日の方法は、デバイスの電流、ランタイム、動作条件(たとえば、温度)、レイテンシ要件または依存性を考慮に入れないことがある。さらに、そのような構成要素の動作状態が事前に予測され得ないので、低電力構成の現在の実装形態は、特定のデバイス構成にチューニングされず、各特定のクライアントの低電力リソースモードの各々の動的レイテンシ要件に明示的に対処しないことがある。したがって、低電力モードを開発し、実装する現在の方法は、一般に、事前に行われ得る推定に基づいてあらかじめ設定された数のシステム低電力構成(たとえば、アイドルモード、スリープモード、ディープスリープモードなど)を構成することと、開発者によって定義された選択基準に基づいて、システムを、システム低電力モードのうちの最良のシステム低電力モードにすることとを必要とする。今日の方法は、低電力リソースの各々ならびにプロセッサを、電力節約を十分に最大にする状態にする低電力リソースモードの組合せから構成されるリアルタイム低電力構成を動的に生成しないことがある。
【００３１】
前の世代のデバイスでは、プロセッサと対話し得る異なるリソースおよびクライアントの数が限定されおり、少数の異なる動作状態を予期することができたので、事前に低電力モードを構成することが妥当だった。しかしながら、現代の電子デバイスは、複数のプロセッサと多数のリソースと同時クライアントとに関与し、一層高度になっており、プロセッサにハードコーディングされ得る最適低電力モードを定義することがもはや可能でないことがある。さらに、if-then/else決定ツリープログラミングを使用する、前に定義されたシステム低電力モードの選択は、ほぼ2nに従ってスケーリングし、「n」は、その判断に関与するリソースおよびクライアントの数である。結果として、開発者は、事前にハードコーディングされ得る低電力構成のサブセットで妥協しなければならず、その低電力構成のサブセットは、すべてでないとしても、一部の動作状態では次善であり得る。開発者に次善の低電力構成を採用するように要求することにより、最適低電力モードが特定の動作条件について定義および実装され得る場合に通常ならば達成可能であろう電力節約よりも少ない電力節約を達成する電子デバイスになる。
【００３２】
低電力構成の現在のプログラミングの動作制限に加えて、システム低電力モードおよび/または構成のセット(たとえば、アイドル、スリープ、ディープスリープ)を事前に定義し、そのモードをプロセッサまたはアプリケーションにハードコーディングする作業は、著しい開発者作業を含む。さらに、低電力モードの高度セットをハードコーディングすることは、所与の時間にリソースの各々がなり得る様々な動作状態に対処せず、システム中のすべての構成要素の全体的な電力消費レベルと動作状態とに動的に応答することができるわけではない。システム低電力モードの定義はコード駆動型であり、データ駆動型ではないので、デバイス構成に行われる小さい変更、およびリソース低電力モードのセットに行われる小さい変更は、コード変更がデバイスエラーを生じないことを確認するために広範に再テストすることを必要とする。したがって、低電力モードを実装するための現在の方法は、製品の生産工程中に行われ得るデバイス構成(たとえば、構成要素、ソフトウェアなど)の変更に対応することができない。
【００３３】
これらおよび他の問題に対処するために、様々な態様は、個々の低電力リソースの各々ならびにプロセッサをシステム全体にわたる電力節約を十分に最大にする動作状態にするように、複数の低電力リソースから選択された低電力リソースモードの組合せから構成されるシステム低電力構成を動的に生成することを実現する。現在達成可能な電力節約のレベルに微調整され得る多数の低電力構成を提供するために、より多くの最適低電力構成選択がリアルタイムでプロセッサによって行われ得るように、様々な態様は、スリープ問題をデバイスプロセッサのために簡略化することを可能にする方法を提供する。様々な態様は、構成要素開発者が、それらの構成要素の各々について、使用中のリソースのタイプ、許容され得るワーストケースレイテンシ、動的動作条件(たとえば、温度)、予想アイドル時間、および構成要素レイテンシなど、様々なファクタを考慮に入れる様々な低電力リソースモードを定義することを可能にする。また、各リソースについて定義される低電力リソースモードは、静的依存性と動的依存性とを定義し得る。次いで、デバイスプロセッサは、ランタイムに、低電力リソースモードの組合せを動的に選択し得る。一態様では、デバイスプロセッサは、システム中の他のプロセッサおよび構成要素の要件を含む現在の動作要件を満たしながら、電力節約および/または動作速度を最大にするシステム低電力構成またはスリープ状態を生じる低電力モードの組合せを計算および選択し得る。
【００３４】
様々な態様はまた、無効化され得るリソース、ならびにデバイス低電力構成中にオンのままであるべきリソースを識別することによって、デバイスが1つまたは複数の低電力リソースモードを選択することを可能にする。様々な態様は、かなりのクライアント対話と余分のプロセッサアクションとを必要とすることなく機能的信頼性をサポートしながら、プロセッサがアイドル状態になるときにリソースにとって最適な、またはほぼ最適な低電力リソースモードのセットを選択するために、コンピューティングデバイス内のプロセッサによって使用され得るデータおよび方法を提供する。本態様は、プロセッサが、使用中のリソースと、許容され得るワーストケースレイテンシと、動的動作条件(たとえば、温度)と、予想アイドル時間と、低電力モードに入り、それを出るために必要とされる時間と、特定の電子デバイスの固有の電気的特性とに応じて、確実に機能し続けながら、最も多くのシステム電力節約を与えるシステム低電力構成を判断することを可能にする。
【００３５】
様々な態様は、プロセッサがアイドル状態に入ったときに、リソースの低電力リソースモードのいずれが有効であるかを判断することと、現在のデバイス状態を与えられたときに予想される電力節約によって有効な低電力リソースモードをランク付けすることと、レイテンシ要件を満たしながら、有効な低電力リソースモードのいずれが最も大きい電力節約を与えるかを判断することと、各リソースが入るべき特定の低電力リソースモードを選択することとによって、コンピューティングデバイス内の様々なリソースについて低電力リソースモードのセットからなる最適システム低電力構成を判断するための機構を提供する。そうすることによって、様々な態様は、固定のあらかじめ定義されたシステム低電力構成の概念を除去し、それにより、開発者が各リソースに別々に対処することを可能にすることによって開発者の問題を簡略化し、プロセッサがアイドル状態に入ったとき、プロセッサが、実装されるべき低電力リソースモードのセットを選択することを可能にすることによってスリープ問題をランタイムにシフトする。これは、低電力モードの実装が動作データによって駆動されることを可能にし、デバイスがどのように使用され、動作するかについて知ることによって、システム低電力モードを自己最適化する能力をプロセッサに与える。典型的な実装形態において、現在の方法に比較してより大きい電力節約を与えることに加えて、様々な態様はまた、電子デバイスの開発を簡略化する。
【００３６】
明快のために、また「低電力モード」と「低電力リソース」との間のあいまいさを除外するために、各低電力リソースが複数の低電力モードを有することができることを理解されたい。複数の低電力リソースは、所与のアイドル状態でアクティブにされ、有効化され、非アクティブにされ、および/または無効化され得る。したがって、全体的な「システム低電力構成」は、現在の動作状態および条件に基づいて低電力モードに入るために利用可能なリソースの各々についての低電力モードの選択によって定義される。また、(以下で説明するように)レイテンシ制限およびリソース依存性により、最適システム低電力構成は、アイドリングするために利用可能な複数のリソースのすべてのリソースを低電力モードにすることに関与しないことがあることに留意されたい。したがって、最適システム低電力構成の選択は、レイテンシ、統計的可用性および他の理由のために、ある動作状態のままでなければならないいくつかのリソースを識別し得る。
【００３７】
様々な態様はまた、プロセッサによって使用され、したがって、単に、もはや使用されていないときに無効化され得ないそれらのリソースについて低電力リソースモードを定義することを可能にする。システムが適切に機能するために、プロセッサによって使用されるリソースは、制御された方式で有効化および無効化される必要がある。この要件が与えられれば、そのようなリソースがもはや使用されていない後にそれらを無効化することは、リソースが無効化され得るアイドル状態にプロセッサが入るまで、延期されなければならない。システム低電力構成またはモードに入るプロセスは、低電力状態に入ることと呼ばれる。
【００３８】
様々な態様は、低電力モードマスク(「LPMマスク」)内のフラグビットを有効化することによって、リソースが低電力状態に入ることが可能なときをリソースが示すことを可能にし、低電力モードマスクは、プロセッサがアイドル状態に入ったとき、システム低電力構成で実装すべきLPRMの適切な組合せを選択するためにプロセッサによって使用され得る。リソースが使用されているとき、リソースはLPMマスク中のフラグビットを無効化し得る。様々な態様では、LPMマスク内のビットを有効化および無効化することは、さらに以下で説明するように、アプリケーションプログラミングインターフェース(API)を呼び得るプロセッサ従属リソースプログラミングノード内のドライバ関数によって達成され得る。したがって、プロセッサがアイドル状態に入ることが可能である瞬間に、どのリソースが低電力モードにされることが可能であるかを判断するために、LPMマスクはアクセスされ得る。
【００３９】
上記で説明したように、リソースがもはや使用されておらず、プロセッサがアイドル状態に入っているとき、リソースは、リソースの低電力リソースモードのうちの1つなどの低電力モードにされ得る。しかしながら、リソースがもはや使用されておらず、プロセッサがアイドル状態に入っているということだけが、リソースを低電力モードにするための常に十分な根拠であるわけではない。さらに、様々なタイプの低電力リソースモードをサポートするリソースについて、プロセッサは、現在の動作条件(たとえば、温度)と、予想アイドル時間内に達成され得る総電力節約に対処することと、現在のクライアントおよび他のプロセッサのレイテンシ要件と、様々な他のファクタとに基づいて、代替低電力リソースモードの中から選択を行わなければならない。様々な態様では、各評価される低電力リソースモードの潜在的電力節約が、(低電力モード定義中に含まれ得るファクタである)現在温度における単位時間当たりの潜在的電力節約に、判断された予想アイドル時間を乗算することによって判断され得るように、特定のリソースについての特定の低電力リソースモードの電力節約は、温度と時間とに依存し得る。さらに、低電力モード選択はまた、特定の電子デバイス特性と、デバイスソフトウェア実装形態と、アイドル条件での予想時間と、クロックスピードなどのデバイス状態とを含む他の変数を考慮に入れるべきである。
【００４０】
プロセッサがアイドル状態に入る準備ができているときなど、プロセッサがシステム低電力構成に入る準備ができているとき、低電力タスクは、低電力状態にされ得るリソースを識別するためにLPMマスクにアクセスし、所与の動的システム状態(たとえば、現在アクティブなクライアント、必要とされるレイテンシ、予想アイドル時間、および温度)に基づいて、それらのリソースについて入るべき適切な低電力リソースモードを判断し得る。プロセッサがこの判断を達成することを可能にするために、各リソースは、所与の状態の場合に実装されるべき低電力リソースモードの最適なセットを選択することに必要な情報を指定する低電力リソースモード特性データを定義し得る。この指定された情報は、リソースのために利用可能な各低電力リソースモードのリストと、時間に応じた、または単位時間当たりの各低電力リソースモードについての潜在的電力節約と、各低電力リソースモードについてのレイテンシ特性(すなわち、低電力モードを出るための時間)と、潜在的電力節約への温度の効果と、依存性(すなわち、そのクライアントの他のリソースとの相互依存性)と、各リソースについて最適な低電力リソースモードを選択することに関係し得る他の情報とを含み得る。そのような情報は、様々な方法およびデータ構造でリソースについて指定され得、それのCコード例を以下に記載する。
typedef struct
{
/*この低電力リソースの名前、たとえば「apps core voltage」。*/
const char *resource_name;
/*このリソースが入ることができる低電力モードの数。*/
uint32_t mode_count;
/*このリソースが入ることができる低電力モードのリスト。*/
LPM_Resource_Mode *modes;
} LPM_Resource;
【００４１】
この定義では、リソースデータの大半は、リソース低電力モード定義内に含まれる。リソースについての低電力モードの定義は、以下のようにCコードで書き込まれ得る。
typedef uint32_t (*LPRM_PowerSavingsFcn)
(uint32_t duration_us, int32_t temp_c);
typedef struct
{
uint32_t enter;
uint32_t exit;
}
sleep_latency_type;
typedef uint32_t (*sleep_power_func)(uint32_t duration_us, int32_t temp_c);
typedef struct LPRM
{
/*この低電力モードの名前(たとえば「minimization」)。*/
const char *mode_name;
/*モードの特性について説明する関数。*/
LPRM_PowerSavingsFcn power_savings;
LPRM_LatencyFcn latency;
/*モードの実際のセットアップとティアダウンとを実装する関数。*/
LPRM_EnterFcn enter;
LPRM_ExitFcn exit;
/*このモードが起こるように大部分が有効化されるLRR。*/
uint32_t lpr_dependency_count;
const char *lpr_dependencies;
/*このモードが選択された場合に入ることができないLPR。*/
uint32_t lpr_exclusion_count;
const char *lpr_exclusions;
/*このポイントの後のいくつかの予約済みブックキーピングフィールド- 0に初期化する。*/
}
LPM_Resource_Mode.
【００４２】
上記のCコードは、一般的な場合について書き込まれる。電圧レールリソースの特定の場合について低電力モードを定義するための例示的なCコードが、以下に提示されている。水晶発振器(CXO)リソース低電力モードについてのCコード定義の例を以下に記載する。この例では、プロセッサは、水晶発振器リソースを低電力モードで動作させるための2つのオプション、すなわち、クロックツリー電力を節約するが、依然として発振器を動作させる電力を消費するゲートモードと、クロックツリー電力および発振器電力を節約するが、この低電力モードを出た後に著しいウォームアップ時間を必要とする(すなわち、比較的長いレイテンシを有する)遮断モードとをサポートする。
const char *cxo_gated_deps[] = {"lpr://cxo"};
LPM_Resource_Mode cxo_gated =
{
.mode_name = "gated"; /*ゲート制御されるものは、LPR中にある*/
.power_savings = cxo_gated_power; /*データに基づく*/
.latency = cxo_gated_latency; /*データに基づく*/
.enter = cxo_gated_enter; /*mpmドライバを呼ぶ*/
.exit = cxo_gated_exit; /*mpmドライバクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(cxo_gated_deps);
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
}
const char *cxo_stdn_deps[] = {"lpr://cxo"};
LPM_Resource_Mode cxo_shutdown =
{
.mode_name = "shutdown";
.power_savings = cxo_stdn_power; /*データに基づく*/
.latency = cxo_stdn_latency; /*データに基づく*/
.enter = cxo_stdn_enter; /*異なるmpmを呼ぶ*/
.exit = cxo_stdn_exit; /*mpmクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(cxo_stdn_deps); /*ゲート制御と同じ*/
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
}
LPM_Resource_Mode *cxo_modes[] = {&cxo_gated, &cxo_shutdown};
LPM_Resource cxo =
{
.resource_name = "CXO";
LPM_MODE_ARRAY(cxo_modes);
};
//起動時:
sleep_define_lpr(&cxo);
//CXOモードは現在/sleep/lprに登録され、起動は無効化される。
//次に、制御NPAノードは、どのようにそれらを有効化することができるか。
//起動:
client = npa_create_sync_client("/sleep/lpr", "/xo/cxo", NPA_CLIENT_REQUIRED);
npa_query_type q;
q.reference = "lpr://cxo";
npa_query_by_client(client, SLEEP_QUERY_LPRM_BITMASK, &q);
uint32 bitmask = q.value;
//有効化する:
npa_issue_required_request(client, bitmask)
//無効化する:
npa_complete_request(client)
【００４３】
ノード電力アーキテクチャ(NPA)ノードを制御することに関係する例示的なコードの部分、およびNPAノードまたはNPA方法への他の言及は、本明細書では例示のためにすぎないことに留意されたい。様々な態様は、NPAノードを介してリソースを有効化および無効化することを達成すること、またはノード電力アーキテクチャを使用することに限定されない。したがって、特に特許請求の範囲にそのように記載されていない限り、特許請求の範囲は、NPAノードまたはNPAプロセスを必要とすると解釈されるべきではない。
【００４４】
電圧源(Vdd)について低電力モードを定義するのに適したCコードの別の例が、以下に提示されている。この例では、プロセッサは、そのコード中で「dig」および「mem」と呼ばれる、デジタル論理およびメモリ回路のために制御されるVddを供給する2つのシステムレベル電圧レールを有する。電圧レールを低電力モードにすることは、低電力モードを出たときにリソースをオンラインに戻すことに関連するレイテンシペナルティを必要とする。2つのリソースが並列に「ウォームアップ」され得るので、一方の電圧レールが低電力モードにされた場合、他方の電圧レールもさらなるレイテンシペナルティを受けることなく低電力モードにされ得るために、これらの2つの電圧レールの制御は結合される。この相互依存性を扱うために、以下のコードは、単一のリソースについて3つの低電力モード「system Vdd」、すなわち、digおよびmem最小化と、mem専用最小化と、dig専用最小化とを定義する。
const char *dig_mem_deps[] = {"lpr://vdd_dig", "lpr://vdd_mem"};
LPM_Resource_Mode dig_mem =
{
.mode_name = "Dig/Mem Min";
.power_savings = dig_mem_power;
.latency = dig_mem_latency; /*これは、ほぼdig_latencyまたはmem_latencyと等価である。それらはこれを共有し得る。*/
.enter = dig_mem_enter; /*mpmドライバを呼ぶ*/
.exit = dig_mem_exit; /*mpmドライバクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(dig_mem_deps);
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
const char *mem_deps[] = {"lpr://vdd_mem"};
LPM_Resource_Mode mem_min =
{
.mode_name = "Mem Min";
.power_savings = mem_power;
.latency = mem_latency;
.enter = mem_enter; /*mpmドライバを呼ぶ*/
.exit = mem_exit; /*mpmドライバクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(mem_deps);
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
}
const char *dig_deps[] = {"lpr://vdd_dig"};
LPM_Resource_Mode dig_min =
{
.mode_name = "Dig Min";
.power_savings = dig_power;
.latency = dig_latency;
.enter = dig_enter; /*mpmドライバを呼ぶ*/
.exit = dig_exit; /*mpmドライバクリーンアップを呼ぶ*/
LPRM_DEPENDENCY_ARRAY(dig_deps);
LPRM_EMPTY_ARRAY(); /*このモードには排除がない*/
}
LPM_Resource_Mode *sys_vdds_modes[] = {mem_dig, mem_min, dig_min};
LPM_Resource sys_vdds =
{
.resource_name = "System Vdds";
LPM_MODE_ARRAY(sys_vdds_modes);
};
//起動時:
sleep_define_lpr(&sys_vdds);
//モードは、現在/sleep/lprに登録され、起動は無効化される。
//次に、制御NPAノードは、どのようにそれらを有効化することができるか。
//起動:
dig_client = npa_create_sync_client("/sleep/lpr", "/rail/vdd_dig", NPA_CLIENT_REQUIRED);
mem_client = npa_create_sync_client("/sleep/lpr", "/rail/vdd_mem", NPA_CLIENT_REQUIRED);
npa_query_type q;
q.reference = "lpr://vdd_dig";
npa_query_by_client(dig_client, SLEEP_QUERY_LPRM_BITMASK, &q);
uint32 dig_bitmask = q.value;
q.reference = "lpr://vdd_mem";
npa_query_by_client(mem_client, SLEEP_QUERY_LPRM_BITMASK, &q);
uint32 mem_bitmask = q.value;
npa_issue_required_request(mem_client, mem_bitmask);
//現時点で、「Mem Min」モードのみが有効
npa_issue_required_request(dig_client, dig_bitmask);
//現時点で、すべての3つのモードが有効
npa_complete_request(mem_client)
//現時点で、「Dig Min」モードのみが有効
npa_complete_request(dig_client)
//どのモードも有効でない状態に戻る
【００４５】
上記で例示し、説明した動的低電力リソース登録機構は、低電力リソースとモードとのセットが動的に拡張されることを可能にする。この能力は、リソースのためでない低電力動作状態であるが、同様の方法で扱われる場合、電力動作の低減を可能にすることができる「仮想低電力モード」を可能にすることを含む。そのような仮想低電力モードの例は、リフレッシュを必要とするであろう新しいコンテンツが生成されないので、プロセッサがアイドル状態に入ったとき、ディスプレイリフレッシュプロセスを中断することを含む。したがって、他の動作およびデバイス構成要素は、構成要素がそれ自体リソースでなくても、電力消費の低減を可能にするための様々な態様を使用して管理され得る。
【００４６】
様々な態様では、プロセッサがアイドル状態に入ることが可能なとき、低電力タスクは、所与のスリープサイクルの間にシステム低電力構成の一部として、様々なリソースについてどの低電力モードに入るべきかを判断するために「ソルバー」プロセスを実行し得る。そのような場合、アイドル状態に入るべき時間であるときに評価されるべきスリープタスクが使用するために、異なるリソースについての低電力モード、およびそれらの低電力モードの特性が収集される必要があり得る。一態様では、これは、ノード電力アーキテクチャ(NPA)において、「/sleep/lpr」NPAノードを介して実装され得る。「/sleep/lpr」への要求は、低電力リソースモードを有効化するビットマスクの形態で行われ得る。様々な態様では、開発者は、低電力リソースモード(およびそれのリソース低電力モードビットマスク)を「/sleep/lpr」NPAノードに登録するsleep_define_lpr()関数を介して、低電力リソースモードを登録し得る。様々な態様では、「/sleep/lpr」NPAノードは、それらが有効化/無効化することに関係するリソース低電力リソースモードを表すビットマスクについて、任意の時間に問い合わせられ得る。また、NPAリソースは、正しい「ビットマスク」をもつ「/sleep/lpr」への要求を行うことによって、それらのリソース低電力リソースモードがアイドル時間に有効化されることを要求することができる。次いで、スリープソルバーは、低電力リソースモードのリストと、現在有効化されている低電力リソースモードのマスクとについて、アイドル時間に「/sleep/lpr」に問い合わせることができる。
【００４７】
上記で説明したように、様々な態様では、プロセッサがアイドル状態に入ることが可能なとき、低電力タスクは、様々なリソースについてどの低電力リソースモードに入られなければならないかを判断するために「ソルバー」プロセスを実行し得る。これの例は図1に示され、図1には、ノード電力アーキテクチャ(NPA)2内のプロセス(すなわち、ノード)が、水晶発振器4などのリソースについて2つの利用可能な低電力モード6、8のうちのどちらに入り得るかをどのように判断するかを示す。図1に示す例では、水晶発振器リソース4は、2つの代替低電力モード、すなわちゲート動作状態6と完全遮断8とを有する。低電力モードにされる資格がある様々なリソースの各々について低電力モードの最適なセットを選択することは、資格があるリソースの各々について利用可能なモードのうちの1つを選択することに関与する。一態様では、低電力リソースモードの「入」機能を呼ぶことによって、選択された低電力リソースモードの各々に入り得る。低電力リソースモードの入機能が呼ばれると、リソースは、それの選択された低電力リソースモードによって定義された電力節約状態にされ得る。プロセッサがアイドル状態である間、プロセッサは割込み待ち(WFI)プロセスおよび/またはアイドルプロセスを実行し得る。起動イベントが行われるまで、プロセッサおよび選択されたリソースはこの状態のままであり得る。起動イベントが行われたとき、各選択されたリソースについて、リソースを所望の動作状態(たとえば、通常または完全電力状態)に戻すために、関連する「出」機能が呼ばれ得る。
【００４８】
様々な態様を実装するためのプロセスが図2〜図4に示されている。図2を参照すると、態様方法10では、ブロック12においてクライアントがリソースをリリースしたのでリソースがもはや使用されていないとき、ブロック14において、上記に記載した例に示すような動作を実装することなどによって、LPMマスク中で低電力リソースモードフラグを有効化する。この時点で、リソースは、それが低電力リソースモードにされるために利用可能であることを示している。起動イベントが行われ、クライアントがリソースへのアクセスを要求したとき、図3に示す方法16が実装され得る。ブロック18においてクライアントがリソースを要求したとき、ブロック20において、上記に記載した例に示すような動作を実装することなどによって、LPMマスク中でそのリソースの低電力リソースモードフラグを無効化する。次いで、ブロック22において、上述のように関連する「出」機能を達成することなどによって、リソースを再活動化する。
【００４９】
図4に、プロセッサが、特定のアイドルおよび低電力状態で実装するための最適システム低電力構成(すなわち、低電力リソースモードの最適セット)を識別し得る態様方法24を示す。ブロック26において、プロセッサを低電力状態にするためにアイドルおよび/またはスリープタスクを開始したとき、プロセッサは、リソース低電力リソースモードフラグについて低電力リソースマスクを検査することによって低電力リソースモードにされ得るそれらのリソースを識別する。ブロック28において、プロセッサは、低電力リソースモードにされ得るリソースを識別するために、低電力リソースモードフラグについてLPMマスクを検査する。ブロック30において、プロセッサは、システム上で実行しているアクティブなクライアント、タスク、またはサブシステムのレイテンシ要件を検査する。たとえば、プロセッサは、クライアントについて定義されたデータ構造にアクセスし、その情報を使用して、レイテンシバジェットを判断し得る。レイテンシバジェットは、システムがシステム低電力状態からの起動中に適応することができる総レイテンシを定義し得る。
【００５０】
一態様では、レイテンシバジェットは、すべての同時プロセッサおよびクライアントにとって許容できるすべてのレイテンシの最小値、またはワーストケースレイテンシ、または最も厳しいレイテンシとして定義され得る。たとえば、ホストがUSBとの通信を開始するときはいつでも、ホストに接続されたUSBリソースは1ミリ秒内に応答することが要求される。この例では、ホストのレイテンシ要件は、1ミリ秒である。したがって、システムがアイドル状態のとき、プロセッサは、オンに戻すために1ミリ秒以上を必要とするリソース、またはリソースの組合せをオフにしないことがある。これは、所与の時間に、ホストが、システムをオンに戻すために割込みを発行し、要求されたタスクを扱うことが可能な動作状態に戻るように、リソースに要求し得るからである。すなわち、システムは、ホストが割込みを発行したときに、出るために全体で1ミリ秒以上を必要としない低電力リソースモードを実装することに限定される。将来、USBがホストから切断された場合、USBがもはや実行されているタスクでないので、1ミリ秒の応答時間はもはや必要とされない。この状況では、より高いレイテンシ要件でずっと実行していた何らかの他のタスクがあり得るので、ワーストケースレイテンシは、何らかの他の値(たとえば、5ミリ秒)に変更することができる。したがって、様々な態様では、レイテンシ要件は、システム低電力モード構成が現在の動作状態要件に基づいて判断され得るように、そのときに評価され得るシステム状態に応じた動的プロパティであり得る。さらに、低電力リソースモード自体は、それら自体のレイテンシ要件、ならびに相互依存レイテンシを有し得る。したがって、いくつかの状況では、入るために利用可能なすべての低電力リソースモードに入ることができるわけではない。これは、いくつかの低電力リソースモードに入ることが、現在の動作状態のワーストケースレイテンシ要件に違反するシステム全体のレイテンシを生じ得るからである。
【００５１】
図4に戻ると、ブロック32において、プロセッサは、様々な低電力リソースモードについてのモードのアイドル入待ち時間およびアイドル出待ち時間についてリソース定義データを検査する。ブロック34において、プロセッサは、予想アイドル時間(すなわち、現在の条件および動作状態を与えられたときに、プロセッサが、起動イベントまでにアイドル状態のままであることを予想される持続時間)を判断する。ブロック36において、プロセッサは、現在温度と他のセンサ値とを記憶しているデータレジスタにアクセスすることなどによって、現在の状態の条件を判断する。ブロック28〜36において収集された現在の状態と低電力リソースモードデータとを使用して、ブロック38において、プロセッサは、最適低電力構成を識別するために「ソルバー」機能を実行する。ソルバー機能は、許容できる最適低電力構成を識別するのに必要な様々な考慮事項を平衡させるためのいくつかの異なる手法を使用し得、そのいくつかの例について、図7〜図10を参照しながら以下で説明する。ブロック28〜38のうちの1つまたは複数の一部として、プロセッサは、各低電力リソースモードおよび低電力リソースモードの各組合せについて、現在温度(および他の動作条件)における単位時間当たりの潜在的電力節約×予想アイドル時間を計算することなどによって、予想され得る潜在的電力節約を計算し、ブロック38において、ソルバープロセスの一部としてこの値を使用する。最適低電力構成が識別されると、1つまたは複数の低電力リソースモードは、各リソース、タスクおよび/またはサブシステムについて選択され、ブロック40において、プロセッサは、関連する入機能を各選択された低電力リソースモードに実行させることなどによってその低電力構成に入る。システムは、タイマ割り込みなどの起動イベントが行われるまで、このアイドル状態および/または低電力状態のままである。起動イベントまたは割込みが行われたとき、ブロック42において、プロセッサおよび関連するリソースは、低電力リソースモード中のリソースの各々について、それらのリソースをそれらの通常動作状態に戻す一連の出機能を実行することなどによってアイドル状態を出る。
【００５２】
様々な態様では、ブロック42において、直接探索(quarry)されるタイマーサブシステムに関連する既知の起動イベントがある。様々な態様はまた、クライアントが、起動イベントがある時間量内に行われると考えることを「暗示する」ことを可能にする起動リソースを含み得る。様々な態様では、システムは、リソースおよび/またはプロセッサが、どのくらい長く所与のスリープ状態のままである可能性があるかを予測および/または制御する機構を含み得る。これらの態様では、プロセッサは、リソースがどのくらい長くスリープ状態にあると予想することができるかを制御するために、いくつかのイベントを延期し得る。様々な態様では、リソースが起動させられるハード起動ポイントがあり得る。様々な態様では、システムは、予想される起動時間フレームを判断するためにリソースからの「暗示」を使用し得る。様々な態様は、最も効率的な起動時間を推定するために、プロセッサによって使用され得る予測アルゴリズムを実装し得る。様々な態様は、予想される起動時間を判断するために、ハード制限と暗示と学習機構との組合せを使用し得る。様々な態様は、予想される起動時間を使用して、判断された予想される起動時間まで様々なリソースが低電力リソースモードにされた場合、どのくらいの電力が節約されるかを判断し得る。次いで、そのような予想される電力節約は、差し迫ったスリープサイクルのためにシステム低電力モード構成で実装するために、低電力モードにすべき特定のリソースを選択する(すなわち、低電力リソースモードを選択する)プロセスにおいて使用され得る。
【００５３】
様々な態様は、電力機能を判断するために、電力節約の和と、リソースを停止させ、再び動作させることのエネルギーコストの両方を使用し得る。様々な態様は、もしあれば、どのリソースが低電力リソースモードにされるべきかを判断するために電力機能を使用し得る。様々な態様はまた、実装された低電力リソースモードの様々な組合せによって与えられる潜在的システム低電力構成の各々に関連する純電力節約を判断するために、電力機能を使用し得る。様々な態様は、計算された時間フレームにわたって節約され、様々なリソースを低電力リソースモードにし、それらを動作モードに戻すために必要とされる業務量だけオフセットされる電力量として純電力節約を計算し得る。様々な態様では、純電力節約は、傾きMとオフセットBとをもつ予想アイドル時間Xを有する単純な線形多項式モジュールを使用する関数によって計算され得、計算される電力節約は、MX+Bである。様々な態様は、構成可能なシステムパラメータに記憶された値に基づいて定期的に純電力節約を計算し得る。
【００５４】
様々な態様では、純電力節約は各リソースについて作表され得る。すなわち、様々な態様は、利用可能な低電力リソースモードの各々に関連する様々な純電力節約を含んでいるテーブルを事前計算し得る。様々な態様はまた、オンザフライで、連続的に、または定期的に、構成可能なシステムパラメータに記憶された値に従って、作表されたリストを生成し得る。様々な態様では、決定間の境界は、テーブルに記憶され、どの潜在的システム低電力構成が現在のシステムニーズおよび動作状態に最も適しているかに関して決定するときに参照され得る。たとえば、システムは、時間に基づいていくつかの好適な低電力構成を示す情報(たとえば、X時間までのモードAの選好、次いでY時間までのモードBの選好、次いでモードAおよびBの選好)を記憶し得る。
【００５５】
様々な態様では、依存性について検査するプロセスが、最適システム低電力モード構成を定義するために低電力リソースモードが選択されるレベルまでプッシュダウンされ得るので、LPMフラグは、明示的にリソースを支配することに制限されない。たとえば、リソース「A」が2つの低電力リソースモード「1」および「2」を有すると仮定する。モード「1」と「2」の両方が同じリソースのものであるので、それらは、そのリソースが低電力リソースモードにされ得ることを示す共通のLPMマスクビットを共有し得る。したがって、この例では、モード「1」および「2」は両方ともLPMマスク内のビット「A」に依存し、ビット「A」は、リソースのためのNPAリソースドライバによって制御される。しかしながら、モード「2」は、モード「1」の特殊な形態であり得、リソース「A」がスリープ状態になることが可能である(すなわち、いかなるクライアントまたはプロセッサによっても使用されない)ことと、リソース「B」もスリープ状態になることが可能であることの両方に対する依存性を有するという点で、さらなる複雑化があり得る。言い換えれば、リソース「A」の低電力リソースモード「2」は、リソース「B」も低電力モードにされることに依存し得る。したがって、この例では、モード「2」は、リソース「A」と「B」の両方のLPMマスクビットに依存する。したがって、この例では、LPMフラグは、モード「2」の依存性によりリソースを明示的に支配しない。
【００５６】
静的依存性と動的依存性とを示すために、クロックドライバリソースと何らかの他の種々のハードウェアリソースとに電力を供給する電圧調整器リソースの例について考える。電圧調整器は、2つの動作モード、すなわち、通常電力と低電力(すなわち、それの低電力リソースモード)とを有し得る。電圧調整器を低電力状態にすることは、電圧調整器によって消費されるエネルギーオーバーヘッド量を低減し得、全体的により低いシステム電力需要を生じる。しかしながら、それの低電力モードで許されるよりも多くの電力が電圧調整器から引き出される場合、電圧調整器は機能せず、デバイスハードウェアに潜在的に損傷を与え得る。たとえば、クロックドライバは、電圧調整器がそれの低電力モードで供給することができるよりも多くの電力を消費し得る。この場合、電圧調整器は、クロックドライバに対する1つの静的依存性を有し(すなわち、クロックは、オフにされることが可能でなければならない)、他の種々のハードウェアに対する別の静的依存性を有し得る(すなわち、その種々のハードウェアは、オフにされなければならない)。さらに、電圧調整器は、クロックドライバがオンのままである限り、電圧調整器から引き出される電力が大きすぎて、それが低電力モードに入ることができないという動的依存性を有し得る。クロックドライバがオフにされるとすぐに、電圧調整器に対する負荷がなくなり、低電力モードに入ることが可能になる。したがって、クロックドライバの電源切断モードは、電圧調整器の低電力リソースモードの動的依存性である。
【００５７】
上記で説明したように、静的依存性はある程度の確度で予期され得るが、動的依存性は前もって判断するのが難しい。さらに、構成要素および/またはリソースの数が増加するにつれて、動的依存性は指数関数的により複雑になる。様々な態様では、様々な動的依存性を管理するために、ソルバープロセスが使用される。様々な態様では、様々な動的依存性を管理するために、アイドルタスクが使用される。
【００５８】
様々な態様の動作が、プログラミングノードおよびリソースグラフ図を示す図5に示されている。図5は、3つのクライアント50、52、54がアクティブであり、3つのリソース、具体的には、メモリ70、クロック発振器78および電圧レール76が、低電力リソースモードに応じられる動作状態を示す。この図では、処理ノード58、69、70、72、74、76、および78は、システムがアイドルタスク60を実行することによって低電力リソースモードに入る準備ができているときに横断されるプロセスを表す。投票のためにクライアント50、52、54をポーリングする代わりに、低電力構成に基づいてシステムを低電力状態にするために、そのプロセスは削除され、ノード図を横断するスリープクライアント64と交換される。この図では、(メモリを使用していた)クライアント1 50は、ノード70への矢印によって示されるように、メモリをリリースし、LPMマスクにおいて適切な低電力リソースモード有効化ビットを設定する。同様に、クライアント2 52は、ノード74および76への矢印によって示されるように、電圧レールリソースとクロックとをリリースし得、LPMマスクにおいて適切な低電力リソースモード有効化ビットを設定する。クライアント3 54が、ノード69への矢印によって示されるようにプロセッサをリリースするとき、プロセッサは、低電力モードソルバー66プロセスを実行する前にLPMマスクを検査し、システムレイテンシを検査し、予想アイドル時間を検査することによって、アイドルタスク60を実行し得る。グラフ全体が横断された後、スリープクライアント64は低電力リソースモード「入」機能を呼び出し、アクティブな低電力リソースモードのセットが、所与の現在の動的条件に基づいてリソースについて選択され得る。
【００５９】
図6に、別の態様方法の場合の同様のプロセスノードおよびリソースグラフを示す。この態様方法は、スリープタイムラインからプロセッサグラフ横断を削除するさらなる利益を与える。図6に示すように、(図5中の矢印48によって示される)プロセッサ依存性は、プロセッサのリソースが低電力リソースモードマスクと直接対話するために特殊なAPIを使用することを可能にすることによって、プロセスノードグラフから省略され得る。図6はまた、(図5に示す)LMPマスク80が、システム低電力状態の場合のLPMマスク90と、アイドル低電力状態の場合のLPMマスク92と、低電力状態の場合のLPMマスク94とによって交換され得ることを示す。この態様では、低電力リソースモードにされることに応じられるリソース(たとえば、メモリ70、クロック発振器78、および電圧レール76)は、システム低電力状態の場合のLPMマスク90においてLPM有効化(ビット)および/またはLPM無効化(ビット)を直接設定し得る。クライアント3 54が、ノード69への矢印によって示されるようにプロセッサをリリースするとき、プロセッサは、アイドル低電力状態の場合のLPMマスク92を検査し、システムレイテンシを検査し、予想アイドル時間を検査することによってアイドルタスク60を実行し得る。アイドルタスク60の低電力リソースモード「入」機能86が呼び出され、アクティブな低電力リソースモードのセットが、低電力状態の場合のLPMマスク94を介して所与の現在の動的条件について選択され得る。
【００６０】
例示的な態様では、低電力リソースモードは、一連のビットベクトルとして実装され得る。たとえば、システム低電力状態(すなわち、リソース使用状況と、クライアント経路コンテキストの外部のクライアントとによる現在アクティブな低電力状態)と、アイドル低電力状態(すなわち、レイテンシおよび予想アイドル時間など、アイドルタスクにおいて発見される動的システム条件による現在アクティブな低電力モード状態)と、(たとえば、不揮発性アイテムまたは同様のものを介して)条件をデバッグ/提示することと、各コアプロセッサノード依存性についての1ビットとのためのビットベクトルがあり得る。各ビットのデフォルト状態は、無効化された低電力リソースモードであり得る。図5または図6に示すノードグラフを通過することによってリソース使用状況要件を設定するクライアントは、低電力ビットのいずれかを有効化させ得、それにより、特定のリソースが低電力リソースモードにされることを可能にする。一態様では、アイドルタスクは、インターモード依存性とレイテンシと予想アイドル時間と温度とを含む、他のファクタに関するデータを収集し、それ自体のビットマスクを設定し得る。この態様では、図に示されていないが、最終LPMマスク設定は、システムおよびアイドルマスクのビット単位の追加を介して判断され得る。
【００６１】
様々な態様では、いくつかの機構は、現在の動作状態および条件に基づいてリソース低電力リソースモードの最適なセットを識別するために、低電力リソースモード選択ソルバー中で使用され得る。一般論的に、低電力リソースモードの最適なセットを選択する問題は、組合せ最適化においてよく知られている問題である「ナップザック問題」の一形態である。ナップザック問題に対する様々な既知のアルゴリズムまたはヒューリスティック解は、低電力リソースモード選択ソルバーにおいて実装され得る。そのような方法は、if/then/else論理ツリーアルゴリズムと、テーブルルックアップアルゴリズムと、異なるリソースの代替低電力リソースモードの代替並べ替えおよび組合せを通して系統的に動作する比較方法とに関与し得る。
【００６２】
例として、図7に、様々なリソースと代替低電力リソースモードとを通して動作することによって低電力リソースモードの最適なセットを選択するための態様方法38aを示す。方法38aは、図4を参照しながら上記で説明した方法24の一部として達成され得、したがって、潜在的電力節約と出待ち時間と依存性とを含む低電力リソースモード特性およびビットマップは、すでにアクセスされたと仮定され得る。現在のアイドル状態の時間に、低電力リソースモードにされ得るリソースのすべての低電力リソースモードのすべてを評価するために、プロセッサは、ブロック100において、LPMフラグが有効化される各リソースを増分的に選択し、次いで、ブロック102において、選択されたリソースについて各低電力リソースモードを増分的に選択する。LPMマスクにおいて設定されたフラグが検査される方法は、実装形態に応じて、様々なリソースの相互依存性に応じて変わり得る。一実装形態では、プロセッサはLPMマスクにおけるフラグを検査し得、そのビットが設定されていない場合には、そのリソースについての低電力リソースモードのいずれについても考慮しないことがある。たとえば、プロセッサが、リソース「A」低電力リソースモードのすべてが、「A」ビットを設定するように要求することを知っている場合、ボックス100において、プロセッサは、「A」ビットについて検査することができ、そのビットが設定されていない場合には、そのリソースのための低電力リソースモードのいずれについても考慮しないことがある。しかしながら、選択されたリソースのためのいくつかの低電力リソースモードは、さらなるリソースビットもそれの依存性に応じて設定される(または設定されない)ことを要求し得るので、ブロック102において、プロセッサは、依然としてLPMマスクを検査する必要があり得る。したがって、一態様では、ブロック102において選択されたリソースについて特定の低電力リソースモードを選択する前に、プロセッサは、低電力リソースモードによって要求された他のリソースLPMフラグも、要求された値に設定されるかどうかを検査し得る。
【００６３】
仮想リソースとともに使用するのに適用可能であり得るような、さらなる態様では、リソースが低電力リソースモードにされることに応じられるかどうかの判断は、他のリソースのために設定されているLPMフラグに依存し得る。たとえば、低電力リソースモード「3」および「4」が定義される仮想リソース「C」が存在する場合、低電力モード「3」の可用性がリソース「A」のためのLPMマスクビットに依存することがあり得るが、低電力モード「4」の可用性は、リソース「B」のためのLPMマスクビットに依存するであろう。したがってこの例では、リソース「C」、がリソース「A」および「B」の状態に応じて低電力モード「3」または「4」のうちの1つになる仮想リソースであるので、仮想リソース「C」を低電力モードにする可用性は、明示的にリソース「C」のためのLPMマスクビットに依存する。したがって、一態様では、ブロック100とブロック102の両方において、プロセッサは、LPMマスクビットについて考えることによって、評価のためのリソースを選択する。
【００６４】
判断ブロック104において、プロセッサは、低電力リソースモードが現在のシステムレイテンシ要件に適合することになるかどうかを判断するために、選択されたリソース低電力リソースモードレイテンシを(上記で説明したステップ30において判断された)レイテンシバジェットと比較する。選択されたリソースの選択された低電力リソースモードの出レイテンシが、レイテンシバジェットを超えた場合(すなわち、判断ステップ104=「いいえ」)、判断ブロック112において、プロセッサは、選択されたリソースについて別の低電力リソースモードがあるかどうかを判断する。他方では、選択されたリソースの選択された低電力リソースモードの出レイテンシが、レイテンシバジェット内である場合(すなわち、判断ステップ104=「はい」)、ステップ106において、プロセッサは、新しい純節約(すなわち、評価されている低電力モードを含む低電力構成の場合の推定される電力節約)を取得するために、選択された低電力リソースモードに関連する電力節約を、選択されたモードの場合の電力節約に加算する。言い換えれば、評価されている特定のリソース低電力リソースモードを含む、低電力リソースモードのセットによって与えられることになる純電力節約を判断するために、選択された低電力リソースモードの予想される電力節約は、すでに評価された他のリソース低電力リソースモードの電力節約に加算され得る。一態様では、各低電力リソースモードの場合の予想される電力節約は、現在温度(および/または他の動作条件)における単位時間当たりの(または時間に応じた)潜在的電力節約×予想アイドル時間の積、または何らかの関数として判断され得る。判断ブロック108において、選択されたリソース低電力リソースモードを含めることが、より大きい電力節約を生じるかどうかを判断するために、プロセッサは、ブロック106において取得された和を、低電力リソースモードの前に選択された最良のセットの総電力節約と比較する。選択されたリソース低電力リソースモードを含む組合せが、より大きい電力節約を生じる場合(すなわち、判断ブロック108=「はい」)、ブロック110において、コンピューティングデバイスは、低電力リソースモードの選択されたセット中に、そのリソースについて選択された低電力リソースモードを含める。
【００６５】
選択されたリソース低電力リソースモードを含む組合せが、より小さい電力節約を生じる場合(すなわち、判断ブロック108=「いいえ」)、判断ブロック112において、プロセッサは、選択されたリソースについて別の低電力リソースモードがあるかどうかを判断する。選択されたリソースに関連する別の低電力リソースモードがある場合(すなわち、判断ブロック112=「はい」)、プロセッサはブロック102に戻って、評価のために次の低電力リソースモードを選択する。選択されたリソースの低電力リソースモードすべてが評価された場合(すなわち、判断ブロック112=「いいえ」)、判断ブロック114において、プロセッサは、低電力リソースモードにされ得る別のリソースがあるかどうかを判断する。評価されるべき別のリソースがある場合(すなわち、判断ブロック114=「はい」)、プロセッサはブロック100に戻って、評価のための次のリソースを選択する。リソースすべてが評価されると(すなわち、判断ブロック114=「いいえ」)、アルゴリズムは、実装すべき低電力リソースモードの最適なセットを識別すべきであったので、図4およびブロック40を参照しながら上記で説明したように、低電力リソースモードの選択されたセットを実装することに進む。
【００６６】
図7に示すアルゴリズムなどの組合せ計算アルゴリズムは、所与の動作条件の場合の低電力リソースモードの最適なセットを識別することが可能であり得るが、そのような計算は、特に予想アイドル時間が数ミリ秒のみであり得、リソースの数が多いときには、実装するには計算量的に難しすぎることがある。したがって、様々な態様では、ナップザック問題に対する近似解および事前に判断され得る解が実装され得る。スリープサイクルに先だってプロセッサによって判断され得る解決策の例は、テーブルルックアップ方法を使用する解決策である。テーブルルックアップ方法では、様々な低電力リソースモードのパフォーマンスは、予想アイドル時間と、温度と、現在のシステム構成と、他のパラメータとに関して、ランタイムにプロセッサによって計算され得る(すなわち、開発者によって事前に定義されないことがある)。これらの計算の結果は、スリープサイクルの時間に低電力リソースモードのほぼ最適なセットを迅速に識別するために、プロセッサによって使用され得るテーブルまたはグラフの形態で与えられ得る。
【００６７】
図8Aに、電力節約対予想アイドル時間に関してプロットされた動作低電力構成の3つの代替セット120、122、124の1次元グラフを示す。グラフが明らかにするように、3つの代替低電力構成は、予想アイドル時間の異なる範囲において異なる相対電力節約を生じ得る。図8Aは、代替低電力構成120が、初めに(たとえば、アイドル時間の開始から矢印126によって示される時間まで)負の電力節約を生じるが、時間的に後では正の電力節約を生じることを示している。したがって、プロセッサスリープサイクルの開始と矢印126によって示される時間との間で、低電力構成122および124のみが、要素128によって示される電力節約を生じる。図8Aはまた、スリープサイクルの開始と矢印126によって示される時間との間の期間において、低電力構成122が低電力構成124よりも大きい電力節約を与えるであろうことを示している。矢印126と矢印130との間の時間から、3つの低電力構成すべてが正の電力節約を生じ、低電力構成122が最も多くの電力節約可能性を与え、124および120がそれぞれ、その後に続くであろう。これは要素132によって示され、要素132は、低電力構成122が124よりも高い電力節約を有し、次に、124は120よりも高い電力節約を有することを示す。矢印130と矢印136との間の時間フレームにおいて、3つの低電力構成すべてが正の電力節約を生じ、3つの代替形態は、要素134によって示されるように、122、120および124の順に電力節約可能性を与える。矢印136によって示される時間の後に、3つの代替形態は、要素138によって示されるように、120、122および124の順に電力節約可能性を有する。
【００６８】
図8Aに示す態様では、プロセッサは、予想アイドル時間をルックアップ値として使用して代替低電力構成の優先順位を判断することができる。図8Aは2次元グラフ(すなわち、電力節約対予想アイドル時間)で本態様を示しているが、本態様方法は、温度、レイテンシなどのパラメータを含む多次元グラフを用いて実装され得る。一態様では、プロセッサは、複数のパラメータに基づいて、ほぼ最適な低電力構成、または構成の優先順位を識別するために、既知の3次元グラフ化解析アルゴリズムを利用し得る。この場合も、そのようなグラフ化は、ランタイムにおいてプロセッサによって実行され得、開発者によって事前に定義されないことがある。
【００６９】
事前計算により、ルックアッププロセスにおいて必要とされる業務は減少するが、転移点の数は、(異なるリソースの数に連結される)異なる低電力モードの数と、次元(すなわち、最適システム低電力モード構成を選択する際に使用されるパラメータ)の数とともに増加する。そのような場合、そのようなルックアップテーブルを記憶するのに必要なスペースは法外になり得る。したがって、さらなる態様では、追跡される必要がある個別領域の数を低減するためにルックアップテーブルの異なる領域を統合するために、ヒューリスティックが使用され、それにより、ルックアップテーブルのサイズを低減し得る。図8Bに、低電力構成のランク付けされた順序が、入力パラメータのいくつかの領域(たとえば、矢印126と矢印136との間の領域)において、1つまたは2つの(140によって示される)代替ランク付けリストの形態で提示され得る例示的な態様を示す。図8Bは、異なる領域を統合することが、いくつかのセットの条件の場合に次善の結果を生成し得ることを示している。たとえば、矢印126と矢印136との間の時間領域において、矢印126に最も近いエリアのための最適結果は、矢印136に近いエリアのための最適結果とは異なる。これらの次善の結果の影響を緩和するために、様々な態様では、プロセッサは、不正確なランキングを比較的興味のない領域に配置し得る。領域が、まれに経験される条件(たとえば、温度極値)を表す場合、その領域は興味のないものとして分類され得る。様々な態様では、プロセッサは、非最適ランキングでエラーを評価し、そのエラーが最小であるか、または何らかの設定されたしきい値を下回ると判断することによって、その次善の結果が許容できると判断し得る。そのようなヒューリスティックルールの開発は、ランタイムにおいてプロセッサによって実行され得、開発者によって事前に定義されないことがある。
【００７０】
本態様の拡張として、プロセッサは、デバイスがどの条件を最も頻繁に経験するかに関する統計を収集し、以下でより十分に説明するように、ルックアップテーブルを再計算して、そのテーブルを、特定のコンピューティングデバイスが最も頻繁に経験する条件にカスタマイズし得る。たとえば、アラスカ州で使用されるセルラー電話は、サハラ砂漠で使用されるセルラー電話に比較して、それのテーブルスペースのより多くを低温温度領域に割り振るルックアップテーブルを計算し得る。本態様は、各コンピューティングデバイスが、環境(すなわち、温度)と測定される使用パターン(たとえば、予想アイドル時間)の両方に関して、それの典型的な条件に最適化される低電力構成決定を行うことを可能にする。
【００７１】
図9Aは、上記で説明したソルバープロセスのためのテーブルルックアップ方法を実装するための態様方法38bを示している。方法38bでは、ブロック150において、プロセッサは(図4を参照しながら上記で説明したように)ブロック28〜36において判断されたパラメータを使用して、低電力構成を選択する。上述のように、一態様では、このテーブルルックアッププロセスは、3Dマッピング解析アルゴリズムの使用に関与し得る。最適低電力構成が識別されると、ステップ40において、プロセッサは、上記で説明したように選択されたモードに入る。
【００７２】
図9Bは、さらなる評価のために代替構成のランク付けされたリストを生じるテーブルルックアップ方法を実装するための代替態様方法38cを示している。方法38cでは、ブロック152において、プロセッサは(上記で説明したように)ブロック28〜36において判断されたパラメータを使用して、潜在的電力節約に基づいて代替低電力構成のランク付けされたリストを取得する。ブロック154において、プロセッサは、評価のために最高ランクの代替低電力構成を選択する。判断ブロック156において、プロセッサは、選択された構成のモード出レイテンシが最大許容システムレイテンシ未満であるかどうかを判断する。選択された低電力構成のレイテンシがシステム要件を満たす場合(すなわち、判断ブロック156=「はい」)、ステップ40において、プロセッサは、上記で説明したように選択されたモードに入る。選択された低電力構成のレイテンシがシステムレイテンシ要件を満たさない場合(すなわち、判断ブロック156=「いいえ」)、プロセッサは、評価のために次の低電力構成を選択する。許容できない低電力構成がすべて排除されるまで、あるいはシステムレイテンシ要件を満たす1つまたは複数の低電力構成が識別されるまで、このプロセスは続き得る。低電力構成のすべてが排除されるか、または満足な低電力構成が識別されない場合、プロセッサは、利用可能な予想される電力節約と、動作要件と、上記で説明した他のファクタとに基づいて、それが低電力構成に入るべきなのか、または動作状態のままであるべきなのかについての判断を行い得る。
【００７３】
上記で説明したテーブルルックアップソルバー手法は、システム低電力構成を排除し、比較的迅速に計算され得る1つまたは複数の最適低電力構成を識別するためのフレキシブルなデータ駆動型手法を提供することができる。しかしながら、いくつかの状況では、この手法は、それが事前に行われる計算に基づくために、すべての動作状態および条件において最適低電力構成を識別することが可能でないことがある。図10は、予想アイドル時間に応じて、組合せ計算アルゴリズム方法とテーブルルックアップ方法の両方を利用するために実装され得る代替態様方法38dを示している。判断ブロック160において、プロセッサは、最適な構成、またはより高速なテーブルルックアップ方法が実装されるべきかどうかを直接判断するために必要とされる計算時間を補うために、予想アイドル時間が十分に長くなる(すなわち、所定のしきい値よりも長くなる)かどうかを判断する。プロセッサが、予想アイドル時間がしきい値を超え、したがってより厳密なソルバーアルゴリズムを完了するために必要とされる余分の計算時間を補うと判断した場合(すなわち、判断ブロック160=「はい」)、ブロック40において、プロセッサは、実装すべき最適低電力構成を判断するために、図7を参照しながら上記で説明したアルゴリズムを実行する。一方、プロセッサが、予想アイドル時間がしきい値未満であると判断した場合(すなわち、判断ブロック160=「いいえ」)、プロセッサは、図9Aまたは図9Bを参照しながら上記で説明したテーブルルックアップ方法を実行する。このようにして、コンピューティングデバイスは、プロセッサがアイドル状態のままであることを予想される時間に応じて、両方のソルバー方法の利益を有することができる。
【００７４】
一態様では、コンピューティングデバイスは、そのコンピューティングデバイスの動作に関して収集された統計的情報を利用するために、様々な状態および条件の場合の最適低電力構成を判断するためのソルバーにおいて使用されるルックアップテーブルを時々再計算し得る。ルックアップテーブルの特徴を周期的に再計算することによって、本態様は、将来の低電力構成によって達成される潜在的電力節約をより良く最適化するために、コンピューティングデバイスがそれの現在および過去の動作から学習することを可能にする。ルックアップテーブルを計算するために、コンピューティングデバイスは、様々な動作条件(たとえば、異なる温度条件ならびに異なるクライアントおよびアプリケーション状態)の各々と、異なるリソースおよびリソース低電力モードの各々とについて、達成可能な相対電力節約を評価するように構成され得る。そのような計算は、図7を参照しながら上記で説明した計算と同様であり得、いくつかの異なるシステム構成ならびに温度および他の動作条件値についてプロセッサによって実行され得る。
【００７５】
様々な態様では、コンピューティングデバイスプロセッサは、バックグラウンドタスクとしてルックアップテーブルを計算するように構成され得る。すなわち、その計算は、かなりの量の処理を含む可能性があるので、プロセッサがより高い優先度の動作を実行することに関与しないときにその計算が実行されるように構成され得る。たとえば、1つまたは複数のプロセッサが通常ならばアイドル状態にあるであろうとき、コンピューティングデバイスはその計算を実行するように構成され得る。そのような計算がかなりの電力を消費する可能性があるので、コンピューティングデバイスが外部電力に接続されているとき(たとえば、バッテリーを充電するとき)のみ、したがって、電力節約が動作優先事項でなく、電力消費が問題でないとき、デバイスはこれらの計算を実行するようにさらに構成され得る。
【００７６】
図11は、コンピューティングデバイスが外部電力に接続されているとき、ルックアップテーブルを計算するための態様方法178を示している。方法178では、判断ブロック180において、プロセッサがアイドル状態に入ったとき、プロセッサは、デバイスが外部電力に接続されているかどうかを判断する。プロセッサが、デバイスが外部電力に接続されていないと判断した場合(すなわち、判断ブロック180=「いいえ」)、ブロック40において、最適低電力構成を識別し、低電力構成を構成する低電力リソースモードのセットに入るために、プロセッサは、図4および図9Aを参照しながら上記で説明したプロセスを実行する。プロセッサが、デバイスが外部電力に接続されていると判断した場合(すなわち、判断ブロック180=「はい」)、プロセッサは、ルックアップテーブルを更新するために必要とされる計算を実行する。ブロック182において、プロセッサは、最適低電力構成を計算するための特定の動作状態および条件を選択する。ブロック184において、プロセッサは、評価のために第1のリソースを選択し、ブロック186において、選択されたリソースのための第1の低電力リソースモードを選択する。ブロック188において、プロセッサは、選択された低電力リソースモードのレイテンシを使用して、選択されたモードを含む低電力構成の総リソースレイテンシを判断する。ブロック190において、プロセッサは、新しいモード電力節約を取得するために、選択された低電力リソースモードに関連する電力節約を、低電力モードの選択されたセットに関連する電力節約に加算する。
【００７７】
判断ブロック192において、プロセッサは、新しいモード電力節約が前に選択された低電力構成の節約を超えるかどうかを判断する。選択された低電力リソースモードが電力節約の増加を生じた場合(すなわち、判断ブロック192=「はい」)、ブロック194において、プロセッサは、仮低電力構成において、選択された低電力リソースモードを使用する。その後、または選択された低電力リソースモードが電力節約の増加を生じない場合(すなわち、判断ブロック192=「いいえ」)、判断ブロック196において、プロセッサは、選択されたリソースに関連する別の低電力リソースモードがあるかどうかを判断する。そのリソースに関連する別の低電力リソースモードがある場合(すなわち、判断ブロック196=「はい」)、プロセッサはブロック186に戻って、選択されたリソースのための次の低電力リソースモードを選択する。選択されたリソースのための低電力リソースモードすべてが評価された場合(すなわち、判断ブロック196=「いいえ」)、判断ブロック198において、プロセッサは、現在の選択された条件の場合に評価されるべき別のリソースがあるかどうかを判断する。
【００７８】
プロセッサが、評価されるべき別のリソースがあると判断した場合(すなわち、判断ブロック198=「はい」)、プロセッサはブロック184に戻って、評価のための次のリソースを選択する。プロセッサが、リソースすべてが現在選択された条件について評価されたと判断した場合(すなわち、判断ブロック198=「いいえ」)、プロセッサは、ブロック190において、判断された潜在的節約の値と、ブロック188において、判断された様々な低電力リソースモードのレイテンシとを含む、予想低電力構成を用いて選択テーブルを更新する。その後、判断ブロック202において、プロセッサは、評価されるべき別の条件があるかどうかを判断する。プロセッサが、評価されるべき別の条件があると判断した場合(すなわち、判断ブロック202=「はい」)、プロセッサはブロック182に戻って、評価されるべき次の条件を選択する。すべての条件が評価され、それに応じてルックアップテーブルが更新されると(すなわち、判断ブロック202=「いいえ」)、ブロック204において、プロセッサは、(外部電力に接続されていることを含む)現在の条件に適した通常のアイドルプロセスを続ける。
【００７９】
さらなる態様では、プロセッサは、最適低電力構成を判断するために使用されるパラメータを調整するために、動作統計に注目するように構成され得る。図12に示すように、態様方法210では、ブロック212において、プロセッサは、実装された低電力構成と、低電力構成を判断する際に使用される推定アイドル時間と、低電力構成の開始時間とに留意する。プロセッサが低電力構成を出た(すなわち、起動した)とき、ブロック214において、プロセッサは、プロセッサが低電力構成を出た時間と、要求されたリソースと、プロセッサまたはクライアントが、起動イベントを促したリソースを要求することとに留意する。ブロック216において、プロセッサは、ブロック214において取得された情報を使用して、特定のリソース、プロセッサ、クライアント、および/または低電力構成の場合のリソースアイドル時間に関する統計を計算または改良する。そのような統計は、補正ファクタを生成するなど、予想アイドル時間推定がどのくらい正確である傾向があるかに対処し、起動イベントを開始する特定のプロセッサまたはクライアントを識別し、特定の低電力構成のアイドル時間特性を識別し得る。ブロック218において、プロセッサは、レイテンシ、予想アイドル時間推定値、またはブロック216において計算された統計の使用に基づいて調整された電力節約のための確率または補正ファクタを用いて、リソース低電力リソースモードデータパラメータを更新する。本態様では、コンピューティングデバイスの典型的な動作に関して広範囲にわたる統計が収集され得、得られた情報は、ソルバーモジュールが最も適切な低電力構成をより良く判断することを可能にするために使用される。このようにして、低電力リソースモードおよび/または低電力構成を実装することによって節約され得る電力をさらに最適化するために、コンピューティングデバイスは、それの典型的な使用および動作条件に適応し得る。
【００８０】
様々な態様では、リソースパラメータおよびプロセッサ動作状態に基づいて、通常ならば選択されるであろう構成よりも平均して大きい電力節約を生じる低電力構成を選択するために、プロセッサは、異なるプロセッサの通常の機能に関する統計を使用することが可能であり得る。所与のアイドル期間の間、プロセッサAが(共有)リソースSまたは(ローカル)リソースLのいずれかのための低電力モードから選定することができるが、両方の低電力モードに入ることを認めない(すなわち、この特定のアイドル期間の間、それらのモードは機能的に相互排他的である)動的レイテンシ要件を有する例を参照すれば、これは明確化され得る。絶対的には、リソースSは、リソースSを低電力状態にすることによってより多くの電力を節約するであろうが、プロセッサAのアイドル時間中にプロセッサBがリソースSを必要とする確率が0ではない。リソースSがプロセッサBによってどのくらい長く使用されるかに応じて、プロセッサAのための最適低電力状態は、理論上、節約する電力はより少なくても、リソースLのための低電力リソースモードに入ることになり得る。これを考慮するために、プロセッサAはアイドル状態であるが、プロセッサBはアイドル状態でないことを仮定すれば、リソースSのための電力モデルは、それが全体的にアイドル状態になる確率だけディレーティングされ得る。すなわち、リソースSのための電力モデル計算がpower_model(idle, temp)である代わりに、その計算はE[power_model(idle, temp)|Proc A idle]になり得る。様々な態様では、期待値計算のための確率分布は、命令によって、プロファイリングによって静的に定義されるか、または実際の使用統計を収集することによって、ランタイムに経験的に判断されるかのいずれかであり得る。
【００８１】
低電力構成の実装および実施に関連する、条件、パフォーマンス、持続時間および、他の特性に関する統計的情報を収集するための学習アルゴリズムを適用するプロセスは、概して、低電力構成の電力節約パフォーマンスが、特定のコンピューティングデバイスの特性、ならびに特定のユーザの使用パターンに対して最適化されることを可能にするために適用され得る。そのような学習を達成するために、プロセッサは、モード選択方法、リソースパフォーマンス値を調整するために、場合によっては、デバイス動作を監視することから取得される情報を反映するためにソルバーにおいて実装されるアルゴリズムを調整するために、低電力モード動作から取得される様々なデータを使用して統計的解析アルゴリズムを実行し得る。
【００８２】
図13に示すさらなる態様方法220では、プロセッサは、モード選択が実際のデバイス電力消費特性に基づくために、様々な低電力構成によって達成される実際の電力節約に関する統計を収集するように構成され得る。ブロック222において、プロセッサは、入るべき特定の低電力構成と、デバイス温度と、予想アイドル時間と、アイドル状態の開始の時間とに留意する。ブロック224において、プロセッサは、それが選択された低電力構成に入ったとき、システムを通して実際の電力消耗を測定および記憶する。この測定は、低電力状態の開始時に、アイドルサイクル全体にわたって、またはアイドル状態を出るプロセスの一部としてなど、アイドルサイクルの最後に行われ得る。ステップ226において、プロセッサは、低電力状態の最後における割込み発射および/またはタイマー発射に留意する。ブロック228において、プロセッサは、ブロック222〜226において収集された情報に基づいて、現在温度における特定の低電力構成において達成される実際の電力節約を反映するために、リソース低電力リソースモードデータパラメータおよび/または低電力リソースモード選択テーブルを更新する。ブロック230において、プロセッサは、割込み発射およびタイマー発射の分配に関する統計を計算または更新し、ブロック232において、この情報を使用して低電力リソースモード選択テーブルを更新する。このようにして、構成および動作条件データに基づいて最適低電力構成を選択するためにプロセッサによって使用されるパラメータは、実際のデバイスパフォーマンスに基づいて改良され得る。様々な低電力リソースモードにおいて達成可能な電力節約は、温度と、生産工程と、寿命と、特定の構成要素の構成と、事前に予期されないことがある多くの他のファクタとに応じて変動し得る。さらに、本態様は、プロセッサが、実際の使用に基づいてアイドル動作構成を選択するために使用される計算または低電力リソースモード選択テーブルを改良することを可能にする。したがって、コンピューティングデバイスが一般に低温温度を経験する(たとえば、コンピューティングデバイスの所有者がアラスカ州に住んでいる)場合、低電力リソースモード選択テーブルは、デバイスが他の場所で経験し得る温度の完全潜在的範囲をカバーしようと試みるのではなく、コンピューティングデバイスが一般に経験する温度範囲内でより大きいグラニュラリティを与えるように改良され得る。したがって、本態様方法は、プロセッサが、そのときの、その動作の条件下のデバイスの実際のパフォーマンス特性に基づいて最適低電力構成を判断することを可能にする。
【００８３】
図14に示すさらなる態様方法240では、プロセッサは、各モードを選択的に実装し、電流または電力需要の生じた変化を測定することによって、各低電力リソースモード(すなわち、各リソースの各低電力モード)の電力節約特性を測定し得る。各低電力リソースモードによって達成される実際の電力節約を測定することによって、コンピューティングデバイスは、最適なシステム低電力モード構成を選択するために有用な統計を収集することができる。構成変更およびデバイス寿命が、特定の低電力リソースモードによって達成される電力節約に影響を及ぼすことがあるので、本方法は、デバイスが製造されてから変化し得た現在の動作構成および条件に基づいて、コンピューティングデバイスがシステム低電力構成決定を行うことを可能にする。また、様々な低電力リソースモードの電力節約可能性の温度感度に関する情報を取得または更新するために、異なる温度においてそのような測定が実行され得る。
【００８４】
図14を参照すると、方法240では、ブロック241において、コンピューティングデバイスプロセッサが、それが既知の安定状態にあり、測定を行うことを助長する動作条件にあると判断したとき、プロセッサは、デバイス内に含まれるセンサを使用して、デバイス温度と電流または電力需要とを測定する。このブロックにおいて、プロセッサは、各低電力リソースモードを用いて達成可能な電力節約に影響を及ぼし得る他の動作条件を測定し得る。ブロック242において、プロセッサは、測定のために、低電力モードを有するリソースを選択する。ブロック243において、プロセッサは、選択されたリソースを、それの低電力リソースモードのうちの選択された低電力リソースモードにする。次いで、ブロック244において、プロセッサは、実装された低電力リソースモードの場合のシステム電流または電力需要を測定する。ブロック245において、プロセッサは、選択されたリソースを選択された低電力リソースモードにすることによって達成される電力節約を計算する。これは、ブロック241において測定された初期電力から、ブロック244において測定された電力を減算することによって達成され得る。判断ブロック246において、プロセッサは、測定すべき別のリソースがあるかどうかを判断する。そうであれば(すなわち、判断ブロック246=「はい」)、プロセッサはブロック242に戻って、測定のための次のリソースを選択する。リソースすべてが選択され、対応する低電力リソースモード電力節約が測定されると(すなわち、判断ブロック246=「いいえ」)、ブロック247において、プロセッサは、測定された電力節約を使用して、低電力モード選択テーブルを更新する。更新された低電力モード選択テーブルは、プロセッサがスリープサイクルに入る次の時にシステム低電力モード構成を選択するために使用され得る。一態様では、特にシステム温度が前の測定プロセスとは異なることにプロセッサが気づいたとき、方法240は周期的に繰り返され得る。異なる温度において低電力リソースモードの各々によって達成される電力節約を測定することによって、プロセッサは、曲線の当てはめアルゴリズムなどのよく知られている算術分析を通して、各低電力リソースモードの電力節約可能性の温度感度を計算または推定することができる。次いで、そのような温度感
度は、システム低電力モード構成において実装されるべき低電力リソースモードを選択するプロセスにおいて使用され得る。
【００８５】
様々な態様は、さらなるバッテリー電力を単に節約すること以上に、ユーザおよび開発者にいくつかの有用な利益を与える。1つの利益として、様々なリソースの低電力リソースモードおよびそれらの定義は、大部分は、モードを実装するコードとは無関係である。関係するドライバ呼出しは、「入」機能および「出」機能内に含められ得、したがって、低電力リソースモードは影響を受けない。ソルバープロセス(すなわち、上記で説明した方法26中のブロック38)は、各低電力リソースモードについての電力およびレイテンシデータなどのハードデータと、現在の動作状態に存在する動的制限(たとえば、レイテンシ要件)および動作条件とに基づいて、いつ低電力リソースモードに入るべきか、またはいつそれから出るべきかを判断することに対処し得る。したがって、開発者は、好適な低電力リソースモードをデバイスにハードコーディングするために、そのようなパラメータの組合せを予期することを試みる必要はない。
【００８６】
上記で説明した態様の別の利益は、コンピューティングデバイスが、システムモードの事前構成されたかまたはあらかじめ定義されたセットから単一の定義された低電力リソースモードを選択するように要求されないが、現在の動作状態、リソース、動作条件、推定されたスリープサイクル、デバイス構成などに基づいて、システムのための低電力構成を動的に実装するために低電力リソースモードの組合せを選択することができることである。これは、前の既知の電力管理システムが、あらかじめ定義された低電力構成のセット(たとえば、モード1、モード2、またはモード3のうちの1つ)から選択するように構成されるので有利であるが、上記で説明した態様は、デバイスが、低電力モードに入ることに応じられる各リソースについて1つまたは複数の低電力リソースモードを動的に選択することを可能にし、現在の条件および状態に最も良く適したシステム低電力構成を実装するためにはるかに大きいフレキシビリティを与える。たとえば、特定のプロセッサが、リソースA、BおよびCの低電力リソースモードをそれぞれ有する3つのリソースA、BおよびCを有すると仮定する。Aの低電力リソースモードはレイテンシ.4msを有し得、Bの低電力リソースモードはレイテンシ.5msを有し得、Cの低電力リソースモードはレイテンシ.6msを有し得るなど、低電力リソースモードは異なるレイテンシを有し得る。システムに対して1ミリ秒のレイテンシ要件(たとえば、1msのワーストケース許容レイテンシ)があるようにUSBクライアントがアクティブである場合、選択された低電力モードの組合せがワーストケースレイテンシ要件を満たす限り、リソースA、BおよびCの低電力モードは、互いから独立して有効化または無効化され得る。たとえば、プロセッサがアイドル状態になり、リソースA、BおよびCがすべて有効化された場合、システムは、Aの低電力リソースモード(レイテンシ.4ms)、Bの低電力リソースモード(レイテンシ.5ms)、Cの低電力リソースモード(レイテンシ.6ms)、AおよびBのモード(レイテンシ.9ms)、またはAおよびCのモード(レイテンシ1ms)を選ぶことができる。したがって、様々な態様では、ソルバータスクは、1msのワーストケースレイテンシトレランスを仮定すれば、最も多くの電力を節約する低電力リソースモ
ードの最も良好なセットを選び得る。
【００８７】
さらに、典型的な電力管理システムは、クライアントが非アクティブモードとアクティブモードとを有し、レイテンシトレランスが現在のパフォーマンス状態に依存することを要求する。上記で説明した様々な態様では、クライアント機構は、「アクティブ」または「非アクティブ」ではなく、「存在する」または「存在しない」とすることができる。すなわち、様々な態様では、様々な低電力リソースモードは、動作状態(たとえば、アクティブまたは非アクティブ)に基づいて選択されるのではなく、可能な状態を排除するために進行され得る。さらに、様々な態様は、クライアントが、様々なリソースのための低電力リソースモードを作成、登録および/または無視することを可能にし、多数の可能なシステム低電力構成を可能にするために低電力リソースモードの組合せを動的に選択することを可能にする。これは、システムクライアントがデバイスの低電力状態をさらに制御し、微調整することを可能にする。
【００８８】
上記で説明した態様の別の利益は、コンピューティングデバイスプロセッサがシステムクライアントの様々な動作モードに気づく必要がないということである。様々な態様では、クライアントは、それらのレイテンシトレランスのみを直接サブミットし得る。したがって、プロセッサは、各クライアントの動作状態に関連する様々な詳細に関して知る必要がない。プロセッサは、クライアントの登録されたレイテンシトレランスを知り、報告されたレイテンシトレランスに基づいて低電力リソースモードに入るべき低電力リソースを選択するだけでよい。様々な態様では、トレランスおよび低電力モードの設定は、個別エンティティによってなされ得る。たとえば、USBクライアントは、レイテンシトレランを設定し得るが、必ずしも低電力モードを設定しないことがある。各低電力リソースモードは、レイテンシ考慮事項から完全に独立している所与のスリープサイクル上で、それらのモードに入り得るかどうかを示すシグナリング機構のセットを有し得る。
【００８９】
さらなる利益として、一態様では、クライアントが、それらがどのくらい長くスリープ状態にあると予想するかを指定することを可能にするために、新しいNPAプログラミングノードが与えられ得る。たとえば、クライアントが、それらが(71時間までの)「X」マイクロ秒以内の間スリープ状態にある(すなわち、プロセッサまたはリソースを利用しない)と予想することを指定することを可能にするために、NPAプログラミングノード「/core/processor/wakeup」が与えられ得る。そのようなプログラミング能力は、プロセッサアイドル状態および低電力構成との適合性について、クライアントアプリケーションの開発を簡略化し得る。
【００９０】
さらなる態様では、アイドル状態に入り得るときに同じまたは同様の動作条件(たとえば、動作状態、温度、およびレイテンシ制限)が存在するとき、ソルバーアルゴリズムを再実行する必要なしに、最適低電力構成が再利用され得るように、図7を参照しながら上記で説明したようなソルバー計算の結果はメモリ中にキャッシュされ得る。このようにして、プロセッサは、最適な、またはほぼ最適な電力節約を依然として達成しながら、ソルバーアルゴリズムを実行するプロセスをスキップすることによってアイドル状態に迅速に入ることができる。さらなる態様では、キャッシュされた最適低電力構成が、条件および状態の統計的に判断された範囲にリンクされ得るように、動作状態および条件は統計的に分析され得る。
【００９１】
様々な態様での使用に好適な典型的なモバイルデバイス250は、図15に示す構成要素を共有する。たとえば、例示的なモバイル受信機デバイス250は、内部メモリ252とディスプレイ253とスピーカー259とに結合されたプロセッサ251を含み得る。さらに、モバイルデバイス250は、プロセッサ251に結合されたモバイルマルチメディア受信機256に接続される、電磁放射を送信および受信するためのアンテナ254を有し得る。いくつかの態様では、モバイルマルチメディア受信機256は、受信機256の動作を制御し、デバイスプロセッサ251と通信するために、デジタル信号プロセッサ(DSP)などの内部プロセッサ258を含み得る。モバイルデバイスは、一般に、ユーザ入力を受け取るためのキーパッド256または小型キーボードおよびメニュー選択ボタンまたはロッカースイッチ257をも含む。
【００９２】
プロセッサ251は、本明細書で説明する様々な態様の機能を含む、様々な機能を実行するようにプロセッサ実行可能ソフトウェア命令(アプリケーション)によって構成され得る任意のプログラマブルマイクロプロセッサ、マイクロコンピュータあるいは1つまたは複数の多重プロセッサチップであり得る。また、様々な態様の機能は、DSP実行可能命令で構成された受信機256内のDSPプロセッサ258において実装され得る。一般に、ソフトウェアアプリケーションおよびプロセッサ実行可能命令は、アクセスされ、プロセッサ251にロードされる前に内部メモリ252に記憶され得る。いくつかのモバイルデバイスでは、プロセッサ251は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含み得る。一部のモバイルデバイスでは、セキュアなメモリは、プロセッサ251に結合された別個のメモリチップ中にあり得る。多くのモバイルデバイス250では、内部メモリ252は、揮発性メモリ、またはフラッシュメモリなどの不揮発性メモリ、あるいは両方の混合であり得る。本明細書では、メモリへの一般的言及は、内部メモリ252と、モバイルデバイスに接続されるリムーバブルメモリと、プロセッサ251自体の内のメモリとを含む、プロセッサ251によってアクセス可能なすべてのメモリを指す。
【００９３】
上記の方法の説明およびプロセスフロー図は、単に説明のための例として提供したものであり、様々な態様のステップを提示された順序で実行しなければならないことを要求または暗示するものではない。当業者なら諒解するように、上記の態様におけるステップの順序は、どんな順序でも実行され得る。「その後」、「次いで」、「次に」などの単語は、ステップの順序を限定するものではなく、これらの単語は、単に、読者に方法の説明を案内するために使用される。さらに、たとえば、冠詞「a」、「an」または「the」を使用する単数形の請求項要素への言及は、その要素を単数形に限定するものと解釈すべきではない。
【００９４】
本明細書で開示した態様に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈すべきではない。
【００９５】
本明細書で開示した態様に関して説明した様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、マルチメディアブロードキャスト受信機チップ内のDSP、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、あるいは本明細書で説明した機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。代替的に、いくつかのステップまたは方法は、所与の機能に固有の回路によって実行され得る。
【００９６】
1つまたは複数の例示的な態様では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装した場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。本明細書で開示した方法またはアルゴリズムのステップは、コンピュータ可読媒体上に常駐し得る、実行されるプロセッサ実行可能なソフトウェアモジュールで実施され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく、例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスク記憶装置、磁気ディスク記憶デバイスまたは他の磁気記憶デバイス、あるいは命令またはデータ構造の形態で所望のプログラムコードを搬送または記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フレキシブルディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。さらに、方法またはアルゴリズムの動作は、コンピュータプログラム製品
に組み込まれ得る、機械可読媒体および/またはコンピュータ可読媒体上のコードおよび/または命令の1つまたは任意の組合せ、あるいはそのセットとして常駐し得る。
【００９７】
開示した実施形態の上記の説明は、当業者が本発明を製作または使用できるように提供したものである。これらの実施形態に対する様々な変更は、当業者には容易に明らかとなり、本明細書で定義された一般的な原理は、本発明の趣旨または範囲から逸脱することなく他の実施形態に適用され得る。したがって、本発明は、本明細書で示した実施形態に限定されるものではなく、以下の特許請求の範囲ならびに本明細書で開示した原理および新規の特徴に合致する最も広い範囲を与えられるべきである。
【符号の説明】
【００９８】
2 ノード電力アーキテクチャ
2 NPA
4 水晶発振器
4 水晶発振器リソース
6 ゲート動作状態
8 完全遮断
24 態様方法
24 方法
38a 態様方法
38a 方法
38b 態様方法
38b 方法
38c 代替態様方法
38c 方法
38d 代替態様方法
50 クライアント
52 クライアント
54 クライアント
58 処理ノード
60 アイドルタスク
69 処理ノード
69 ノード
70 メモリ
70 処理ノード
70 ノード
72 処理ノード
72 ノード
74 処理ノード
74 ノード
76 電圧レール
76 処理ノード
76 ノード
78 クロック発振器
78 処理ノード
80 LMPマスク
86 低電力リソースモード「入」機能
90 LMPマスク
92 LMPマスク
94 LMPマスク
120 低電力構成
122 低電力構成
124 低電力構成
220 態様方法
240 態様方法
250 受信機デバイス
250 モバイルデバイス
251 プロセッサ
251 デバイスプロセッサ
252 内部メモリ
253 ディスプレイ
256 受信機
256 キーパッド
256 モバイルマルチメディア受信機
257 ロッカースイッチ
258 内部プロセッサ
258 DSPプロセッサ
259 スピーカー
【特許請求の範囲】
【請求項１】
コンピューティングデバイスにおける電力を温存するための方法であって、
リソースが使用されていないとき前記リソースに関連するフラグビットを設定するステップであって、前記リソースが複数のリソースのうちの1つである、設定するステップと、
プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得る前記リソースを識別するステップと、
前記識別されたリソースの各々についてレイテンシ要件を登録するステップと、
前記登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択するステップと、
前記選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、前記コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価するステップと、
潜在的電力節約を最大にし、前記選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択するステップと、
前記識別されたリソースの各々に対して前記選択された低電力モードの各々の入機能を実行することによって低電力リソースモードの前記選択された組合せに入るステップと
を含む、方法。
【請求項２】
低電力リソースモードの組合せを選択するステップが、前記様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行するステップを含む、請求項1に記載の方法。
【請求項３】
前記プロセッサがアイドル状態のままであることが予想される時間を判断するステップと、
現在温度における単位時間当たりの潜在的電力節約×前記判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの前記潜在的電力節約を判断するステップと
をさらに含む、請求項1に記載の方法。
【請求項４】
前記デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定するステップと、
測定のためのリソースを選択するステップと、
前記選択されたリソースを低電力リソースモードにするステップと、
前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップと、
低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップと、前記選択されたリソースを低電力リソースモードにするステップと、前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップとを繰り返すステップと
をさらに含み、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択するステップが、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する前記測定された電流または電力需要を使用するステップを含む、請求項1に記載の方法。
【請求項５】
異なる温度において請求項3に記載の動作を繰り返すステップと、
各低電力リソースモードに関連する電流または電力需要の温度感度を判断するステップと
をさらに含み、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択するステップが、
前記コンピューティングデバイスの温度を測定するステップと、
前記測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の前記判断された温度感度を使用するステップと
をさらに含む、請求項4に記載の方法。
【請求項６】
低電力モードにされ得る各リソースについて低電力リソースモードを評価するステップが、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成するステップを含む、請求項1に記載の方法。
【請求項７】
前記動作条件が温度値を含む、請求項6に記載の方法。
【請求項８】
前記コンピューティングデバイス上で動作条件に関する統計を収集するステップと、
前記収集された動作条件統計に基づいて前記低電力モード選択データテーブルを更新するステップと
をさらに含む、請求項6に記載の方法。
【請求項９】
前記動作条件が、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択される、請求項8に記載の方法。
【請求項１０】
前記コンピューティングデバイスが外部電力に接続されているかどうかを判断するステップであって、前記コンピューティングデバイスが外部電力に接続されているとき、前記動作条件統計に基づいて前記低電力モード選択データテーブルを更新するステップが達成される、判断するステップをさらに含む、請求項8に記載の方法。
【請求項１１】
少なくとも1つのプロセッサを有するコンピューティングデバイスであって、
リソースが使用されていないとき前記リソースに関連するフラグビットを設定するための手段であって、前記リソースが複数のリソースのうちの1つである、設定するための手段と、
プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得る前記リソースを識別するための手段と、
前記識別されたリソースの各々についてレイテンシ要件を登録するための手段と、
前記登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択するための手段と、
前記選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、前記コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価するための手段と、
潜在的電力節約を最大にし、前記選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択するための手段と、
前記識別されたリソースの各々に対して前記選択された低電力モードの各々の入機能を実行することによって低電力リソースモードの前記選択された組合せに入るための手段と
を含む、コンピューティングデバイス。
【請求項１２】
低電力リソースモードの組合せを選択するための手段が、前記様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行するための手段を含む、請求項11に記載のコンピューティングデバイス。
【請求項１３】
前記プロセッサがアイドル状態のままであることが予想される時間を判断するための手段と、
現在温度における単位時間当たりの潜在的電力節約×前記判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの前記潜在的電力節約を判断するための手段と
をさらに含む、請求項11に記載のコンピューティングデバイス。
【請求項１４】
前記デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定するための手段と、
測定のためのリソースを選択するための手段と、
前記選択されたリソースを低電力リソースモードにするための手段と、
前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するための手段と、
低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップと、前記選択されたリソースを低電力リソースモードにするステップと、前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップとを繰り返すための手段と
をさらに含み、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択するための手段が、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する前記測定された電流または電力需要を使用するための手段を含む、請求項11に記載のコンピューティングデバイス。
【請求項１５】
異なる温度において請求項3に記載の動作を繰り返すための手段と、
各低電力リソースモードに関連する電流または電力需要の温度感度を判断するための手段と
をさらに含み、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択するための手段が、
前記コンピューティングデバイスの温度を測定するための手段と、
前記測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の前記判断された温度感度を使用するための手段と
をさらに含む、請求項14に記載のコンピューティングデバイス。
【請求項１６】
低電力モードにされ得る各リソースについて低電力リソースモードを評価するための手段が、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成するための手段を含む、請求項11に記載のコンピューティングデバイス。
【請求項１７】
前記動作条件が温度値を含む、請求項16に記載のコンピューティングデバイス。
【請求項１８】
前記コンピューティングデバイス上で動作条件に関する統計を収集するための手段と、
前記収集された動作条件統計に基づいて前記低電力モード選択データテーブルを更新するための手段と
をさらに含む、請求項16に記載のコンピューティングデバイス。
【請求項１９】
前記動作条件が、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択される、請求項18に記載のコンピューティングデバイス。
【請求項２０】
前記コンピューティングデバイスが外部電力に接続されているかどうかを判断するための手段であって、前記コンピューティングデバイスが外部電力に接続されているとき、前記動作条件統計に基づいて前記低電力モード選択データテーブルを更新するための手段が達成される、判断するための手段をさらに含む、請求項18に記載のコンピューティングデバイス。
【請求項２１】
コンピューティングデバイスにおける電力を温存するための装置であって、
メモリバッファと、
前記メモリバッファに結合されたプロセッサと
を含み、前記プロセッサは、
リソースが使用されていないとき前記リソースに関連するフラグビットを設定することであって、前記リソースが複数のリソースのうちの1つである、設定することと、
プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得る前記リソースを識別することと、
前記識別されたリソースの各々についてレイテンシ要件を登録することと、
前記登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択することと、
前記選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、前記コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価することと、
潜在的電力節約を最大にし、前記選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択することと、
前記識別されたリソースの各々に対して前記選択された低電力モードの各々の入機能を実行することによって低電力リソースモードの前記選択された組合せに入ることと
を含む動作を実行するためのプロセッサ実行可能命令で構成された、装置。
【請求項２２】
前記プロセッサはさらに、低電力リソースモードの組合せを選択することが、前記様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行することを含むようなプロセッサ実行可能命令で構成された、請求項21に記載の装置。
【請求項２３】
前記プロセッサは、
前記プロセッサがアイドル状態のままであることが予想される時間を判断することと、
現在温度における単位時間当たりの潜在的電力節約×前記判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの前記潜在的電力節約を判断することと
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成された、請求項21に記載の装置。
【請求項２４】
前記プロセッサは、
前記デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定することと、
測定のためのリソースを選択することと、
前記選択されたリソースを低電力リソースモードにすることと、
前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定することと、
低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップと、前記選択されたリソースを低電力リソースモードにするステップと、前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップとを繰り返すことと
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成され、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択することが、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する前記測定された電流または電力需要を使用することを含む、請求項21に記載の装置。
【請求項２５】
前記プロセッサは、
異なる温度において請求項3に記載の動作を繰り返すことと、
各低電力リソースモードに関連する電流または電力需要の温度感度を判断することと
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成され、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択することが、
前記コンピューティングデバイスの温度を測定することと、
前記測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の前記判断された温度感度を使用することと
を含む、請求項24に記載の装置。
【請求項２６】
前記プロセッサは、低電力モードにされ得る各リソースについて低電力リソースモードを評価することが、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成することを含むようなプロセッサ実行可能命令で構成された、請求項21に記載の装置。
【請求項２７】
前記プロセッサは、前記動作条件が温度値を含むようなプロセッサ実行可能命令で構成された、請求項26に記載の装置。
【請求項２８】
前記プロセッサは、
前記コンピューティングデバイス上で動作条件に関する統計を収集することと、
前記収集された動作条件統計に基づいて前記低電力モード選択データテーブルを更新することと
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成された、請求項26に記載の装置。
【請求項２９】
前記プロセッサは、前記動作条件が、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択されるようなプロセッサ実行可能命令で構成された、請求項28に記載の装置。
【請求項３０】
前記プロセッサは、
前記コンピューティングデバイスが外部電力に接続されているかどうかを判断することであって、前記コンピューティングデバイスが外部電力に接続されているとき、前記動作条件統計に基づいて前記低電力モード選択データテーブルを更新するステップが達成される、判断すること
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成された、請求項28に記載の装置。
【請求項３１】
コンピューティングデバイスにおける電力を温存するための動作をプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を記録したプロセッサ読み取り可能な記録媒体であって、前記動作は、
リソースが使用されていないとき前記リソースに関連するフラグビットを設定することであって、前記リソースが複数のリソースのうちの1つである、設定することと、
プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得る前記リソースを識別することと、
前記識別されたリソースの各々についてレイテンシ要件を登録することと、
前記登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択することと、
前記選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、前記コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価することと、
潜在的電力節約を最大にし、前記選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択することと、
前記識別されたリソースの各々に対して前記選択された低電力モードの各々の入機能を実行することによって低電力リソースモードの前記選択された組合せに入ることと
を含む、記録媒体。
【請求項３２】
前記記憶されたプロセッサ実行可能ソフトウェア命令は、低電力リソースモードの組合せを選択することが、前記様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行することを含むような動作をプロセッサに実行させるように構成された、請求項31に記載の記録媒体。
【請求項３３】
前記記憶されたプロセッサ実行可能命令は、
前記プロセッサがアイドル状態のままであることが予想される時間を判断することと、
現在温度における単位時間当たりの潜在的電力節約×前記判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの前記潜在的電力節約を判断することと
をさらに含む動作をプロセッサに実行させるように構成された、請求項31に記載の記録媒体。
【請求項３４】
前記記憶されたプロセッサ実行可能命令は、
前記デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定することと、
測定のためのリソースを選択することと、
前記選択されたリソースを低電力リソースモードにすることと、
前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定することと、
低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップと、前記選択されたリソースを低電力リソースモードにするステップと、前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップとを繰り返すことと
をさらに含む動作をプロセッサに実行させるように構成され、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択することが、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する前記測定された電流または電力需要を使用することを含む、請求項31に記載の記録媒体。
【請求項３５】
前記記憶されたプロセッサ実行可能命令は、
異なる温度において請求項3に記載の動作を繰り返すことと、
各低電力リソースモードに関連する電流または電力需要の温度感度を判断することと
をさらに含む動作をプロセッサに実行させるように構成され、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択することが、
前記コンピューティングデバイスの温度を測定することと、
前記測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の前記判断された温度感度を使用することと
を含む、請求項34に記載の記録媒体。
【請求項３６】
前記記憶されたプロセッサ実行可能命令は、低電力モードにされ得る各リソースについて低電力リソースモードを評価することが、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成することを含むような動作をプロセッサに実行させるように構成された、請求項31に記載の記録媒体。
【請求項３７】
前記記憶されたプロセッサ実行可能命令は、前記動作条件が温度値を含むような動作をプロセッサに実行させるように構成された、請求項36に記載の記録媒体。
【請求項３８】
前記記憶されたプロセッサ実行可能命令は、
前記コンピューティングデバイス上で動作条件に関する統計を収集することと、
前記収集された動作条件統計に基づいて前記低電力モード選択データテーブルを更新することと
をさらに含む動作をプロセッサに実行させるように構成された、請求項36に記載の記録媒体。
【請求項３９】
前記記憶されたプロセッサ実行可能命令は、前記動作条件が、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択されるような動作をプロセッサに実行させるように構成された、請求項38に記載の記録媒体。
【請求項４０】
前記記憶されたプロセッサ実行可能命令は、
前記コンピューティングデバイスが外部電力に接続されているかどうかを判断することであって、前記コンピューティングデバイスが外部電力に接続されているとき、前記動作条件統計に基づいて前記低電力モード選択データテーブルを更新することが達成される、判断すること
をさらに含む動作をプロセッサに実行させるように構成された、請求項38に記載の記録媒体。
【請求項１】
コンピューティングデバイスにおける電力を温存するための方法であって、
リソースが使用されていないとき前記リソースに関連するフラグビットを設定するステップであって、前記リソースが複数のリソースのうちの1つである、設定するステップと、
プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得る前記リソースを識別するステップと、
前記識別されたリソースの各々についてレイテンシ要件を登録するステップと、
前記登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択するステップと、
前記選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、前記コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価するステップと、
潜在的電力節約を最大にし、前記選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択するステップと、
前記識別されたリソースの各々に対して前記選択された低電力モードの各々の入機能を実行することによって低電力リソースモードの前記選択された組合せに入るステップと
を含む、方法。
【請求項２】
低電力リソースモードの組合せを選択するステップが、前記様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行するステップを含む、請求項1に記載の方法。
【請求項３】
前記プロセッサがアイドル状態のままであることが予想される時間を判断するステップと、
現在温度における単位時間当たりの潜在的電力節約×前記判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの前記潜在的電力節約を判断するステップと
をさらに含む、請求項1に記載の方法。
【請求項４】
前記デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定するステップと、
測定のためのリソースを選択するステップと、
前記選択されたリソースを低電力リソースモードにするステップと、
前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップと、
低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップと、前記選択されたリソースを低電力リソースモードにするステップと、前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップとを繰り返すステップと
をさらに含み、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択するステップが、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する前記測定された電流または電力需要を使用するステップを含む、請求項1に記載の方法。
【請求項５】
異なる温度において請求項3に記載の動作を繰り返すステップと、
各低電力リソースモードに関連する電流または電力需要の温度感度を判断するステップと
をさらに含み、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択するステップが、
前記コンピューティングデバイスの温度を測定するステップと、
前記測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の前記判断された温度感度を使用するステップと
をさらに含む、請求項4に記載の方法。
【請求項６】
低電力モードにされ得る各リソースについて低電力リソースモードを評価するステップが、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成するステップを含む、請求項1に記載の方法。
【請求項７】
前記動作条件が温度値を含む、請求項6に記載の方法。
【請求項８】
前記コンピューティングデバイス上で動作条件に関する統計を収集するステップと、
前記収集された動作条件統計に基づいて前記低電力モード選択データテーブルを更新するステップと
をさらに含む、請求項6に記載の方法。
【請求項９】
前記動作条件が、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択される、請求項8に記載の方法。
【請求項１０】
前記コンピューティングデバイスが外部電力に接続されているかどうかを判断するステップであって、前記コンピューティングデバイスが外部電力に接続されているとき、前記動作条件統計に基づいて前記低電力モード選択データテーブルを更新するステップが達成される、判断するステップをさらに含む、請求項8に記載の方法。
【請求項１１】
少なくとも1つのプロセッサを有するコンピューティングデバイスであって、
リソースが使用されていないとき前記リソースに関連するフラグビットを設定するための手段であって、前記リソースが複数のリソースのうちの1つである、設定するための手段と、
プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得る前記リソースを識別するための手段と、
前記識別されたリソースの各々についてレイテンシ要件を登録するための手段と、
前記登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択するための手段と、
前記選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、前記コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価するための手段と、
潜在的電力節約を最大にし、前記選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択するための手段と、
前記識別されたリソースの各々に対して前記選択された低電力モードの各々の入機能を実行することによって低電力リソースモードの前記選択された組合せに入るための手段と
を含む、コンピューティングデバイス。
【請求項１２】
低電力リソースモードの組合せを選択するための手段が、前記様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行するための手段を含む、請求項11に記載のコンピューティングデバイス。
【請求項１３】
前記プロセッサがアイドル状態のままであることが予想される時間を判断するための手段と、
現在温度における単位時間当たりの潜在的電力節約×前記判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの前記潜在的電力節約を判断するための手段と
をさらに含む、請求項11に記載のコンピューティングデバイス。
【請求項１４】
前記デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定するための手段と、
測定のためのリソースを選択するための手段と、
前記選択されたリソースを低電力リソースモードにするための手段と、
前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するための手段と、
低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップと、前記選択されたリソースを低電力リソースモードにするステップと、前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップとを繰り返すための手段と
をさらに含み、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択するための手段が、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する前記測定された電流または電力需要を使用するための手段を含む、請求項11に記載のコンピューティングデバイス。
【請求項１５】
異なる温度において請求項3に記載の動作を繰り返すための手段と、
各低電力リソースモードに関連する電流または電力需要の温度感度を判断するための手段と
をさらに含み、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択するための手段が、
前記コンピューティングデバイスの温度を測定するための手段と、
前記測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の前記判断された温度感度を使用するための手段と
をさらに含む、請求項14に記載のコンピューティングデバイス。
【請求項１６】
低電力モードにされ得る各リソースについて低電力リソースモードを評価するための手段が、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成するための手段を含む、請求項11に記載のコンピューティングデバイス。
【請求項１７】
前記動作条件が温度値を含む、請求項16に記載のコンピューティングデバイス。
【請求項１８】
前記コンピューティングデバイス上で動作条件に関する統計を収集するための手段と、
前記収集された動作条件統計に基づいて前記低電力モード選択データテーブルを更新するための手段と
をさらに含む、請求項16に記載のコンピューティングデバイス。
【請求項１９】
前記動作条件が、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択される、請求項18に記載のコンピューティングデバイス。
【請求項２０】
前記コンピューティングデバイスが外部電力に接続されているかどうかを判断するための手段であって、前記コンピューティングデバイスが外部電力に接続されているとき、前記動作条件統計に基づいて前記低電力モード選択データテーブルを更新するための手段が達成される、判断するための手段をさらに含む、請求項18に記載のコンピューティングデバイス。
【請求項２１】
コンピューティングデバイスにおける電力を温存するための装置であって、
メモリバッファと、
前記メモリバッファに結合されたプロセッサと
を含み、前記プロセッサは、
リソースが使用されていないとき前記リソースに関連するフラグビットを設定することであって、前記リソースが複数のリソースのうちの1つである、設定することと、
プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得る前記リソースを識別することと、
前記識別されたリソースの各々についてレイテンシ要件を登録することと、
前記登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択することと、
前記選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、前記コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価することと、
潜在的電力節約を最大にし、前記選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択することと、
前記識別されたリソースの各々に対して前記選択された低電力モードの各々の入機能を実行することによって低電力リソースモードの前記選択された組合せに入ることと
を含む動作を実行するためのプロセッサ実行可能命令で構成された、装置。
【請求項２２】
前記プロセッサはさらに、低電力リソースモードの組合せを選択することが、前記様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行することを含むようなプロセッサ実行可能命令で構成された、請求項21に記載の装置。
【請求項２３】
前記プロセッサは、
前記プロセッサがアイドル状態のままであることが予想される時間を判断することと、
現在温度における単位時間当たりの潜在的電力節約×前記判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの前記潜在的電力節約を判断することと
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成された、請求項21に記載の装置。
【請求項２４】
前記プロセッサは、
前記デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定することと、
測定のためのリソースを選択することと、
前記選択されたリソースを低電力リソースモードにすることと、
前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定することと、
低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップと、前記選択されたリソースを低電力リソースモードにするステップと、前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップとを繰り返すことと
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成され、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択することが、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する前記測定された電流または電力需要を使用することを含む、請求項21に記載の装置。
【請求項２５】
前記プロセッサは、
異なる温度において請求項3に記載の動作を繰り返すことと、
各低電力リソースモードに関連する電流または電力需要の温度感度を判断することと
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成され、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択することが、
前記コンピューティングデバイスの温度を測定することと、
前記測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の前記判断された温度感度を使用することと
を含む、請求項24に記載の装置。
【請求項２６】
前記プロセッサは、低電力モードにされ得る各リソースについて低電力リソースモードを評価することが、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成することを含むようなプロセッサ実行可能命令で構成された、請求項21に記載の装置。
【請求項２７】
前記プロセッサは、前記動作条件が温度値を含むようなプロセッサ実行可能命令で構成された、請求項26に記載の装置。
【請求項２８】
前記プロセッサは、
前記コンピューティングデバイス上で動作条件に関する統計を収集することと、
前記収集された動作条件統計に基づいて前記低電力モード選択データテーブルを更新することと
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成された、請求項26に記載の装置。
【請求項２９】
前記プロセッサは、前記動作条件が、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択されるようなプロセッサ実行可能命令で構成された、請求項28に記載の装置。
【請求項３０】
前記プロセッサは、
前記コンピューティングデバイスが外部電力に接続されているかどうかを判断することであって、前記コンピューティングデバイスが外部電力に接続されているとき、前記動作条件統計に基づいて前記低電力モード選択データテーブルを更新するステップが達成される、判断すること
をさらに含む動作を実行するためのプロセッサ実行可能命令で構成された、請求項28に記載の装置。
【請求項３１】
コンピューティングデバイスにおける電力を温存するための動作をプロセッサに実行させるように構成されたプロセッサ実行可能ソフトウェア命令を記録したプロセッサ読み取り可能な記録媒体であって、前記動作は、
リソースが使用されていないとき前記リソースに関連するフラグビットを設定することであって、前記リソースが複数のリソースのうちの1つである、設定することと、
プロセッサがアイドル状態に入ることが可能であるとき、フラグビット設定に基づいて低電力モードにされ得る前記リソースを識別することと、
前記識別されたリソースの各々についてレイテンシ要件を登録することと、
前記登録されたレイテンシ要件から最も厳しいレイテンシ要件を選択することと、
前記選択された最も厳しいレイテンシトレランスを超える複合レイテンシ要件を有する、低電力リソースモード、または低電力リソースモードの組合せを除去するために、前記コンピューティングデバイス上で、低電力モードにされ得る各リソースについて低電力モードを評価することと、
潜在的電力節約を最大にし、前記選択されたワーストケースレイテンシ要件以下である総レイテンシ要件を有する、低電力リソースモードの組合せを選択することと、
前記識別されたリソースの各々に対して前記選択された低電力モードの各々の入機能を実行することによって低電力リソースモードの前記選択された組合せに入ることと
を含む、記録媒体。
【請求項３２】
前記記憶されたプロセッサ実行可能ソフトウェア命令は、低電力リソースモードの組合せを選択することが、前記様々な低電力モードおよびリソースのためのナップザック問題解決アルゴリズムを実行することを含むような動作をプロセッサに実行させるように構成された、請求項31に記載の記録媒体。
【請求項３３】
前記記憶されたプロセッサ実行可能命令は、
前記プロセッサがアイドル状態のままであることが予想される時間を判断することと、
現在温度における単位時間当たりの潜在的電力節約×前記判断された予想アイドル時間に基づいて、各評価された低電力リソースモードの前記潜在的電力節約を判断することと
をさらに含む動作をプロセッサに実行させるように構成された、請求項31に記載の記録媒体。
【請求項３４】
前記記憶されたプロセッサ実行可能命令は、
前記デバイスが既知の安定状態にあるとき、温度と電流とを測定するか、または温度と電力需要とを測定することと、
測定のためのリソースを選択することと、
前記選択されたリソースを低電力リソースモードにすることと、
前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定することと、
低電力リソースモードを有するすべてのリソースについて低電力リソースモード中の電流または電力需要が測定されるまで、次のリソースを選択するステップと、前記選択されたリソースを低電力リソースモードにするステップと、前記選択されたリソースが前記低電力リソースモードにある間、電流または電力需要を測定するステップとを繰り返すことと
をさらに含む動作をプロセッサに実行させるように構成され、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択することが、低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する前記測定された電流または電力需要を使用することを含む、請求項31に記載の記録媒体。
【請求項３５】
前記記憶されたプロセッサ実行可能命令は、
異なる温度において請求項3に記載の動作を繰り返すことと、
各低電力リソースモードに関連する電流または電力需要の温度感度を判断することと
をさらに含む動作をプロセッサに実行させるように構成され、
潜在的電力節約を最大にする低電力リソースモードの組合せを選択することが、
前記コンピューティングデバイスの温度を測定することと、
前記測定されたコンピューティングデバイス温度において低電力リソースモードの組合せの潜在的電力節約を判断するために、各低電力リソースモードに関連する電流または電力需要の前記判断された温度感度を使用することと
を含む、請求項34に記載の記録媒体。
【請求項３６】
前記記憶されたプロセッサ実行可能命令は、低電力モードにされ得る各リソースについて低電力リソースモードを評価することが、潜在的電力節約と、推定アイドル時間と、動作条件とを使用して、低電力モード選択データテーブルを使用するテーブルルックアッププロセスを達成することを含むような動作をプロセッサに実行させるように構成された、請求項31に記載の記録媒体。
【請求項３７】
前記記憶されたプロセッサ実行可能命令は、前記動作条件が温度値を含むような動作をプロセッサに実行させるように構成された、請求項36に記載の記録媒体。
【請求項３８】
前記記憶されたプロセッサ実行可能命令は、
前記コンピューティングデバイス上で動作条件に関する統計を収集することと、
前記収集された動作条件統計に基づいて前記低電力モード選択データテーブルを更新することと
をさらに含む動作をプロセッサに実行させるように構成された、請求項36に記載の記録媒体。
【請求項３９】
前記記憶されたプロセッサ実行可能命令は、前記動作条件が、温度と、特定の低電力リソースモードの電力消費と、様々な動作状態において経験されるアイドル時間と、典型的なデバイス使用パターンとを含むグループから選択されるような動作をプロセッサに実行させるように構成された、請求項38に記載の記録媒体。
【請求項４０】
前記記憶されたプロセッサ実行可能命令は、
前記コンピューティングデバイスが外部電力に接続されているかどうかを判断することであって、前記コンピューティングデバイスが外部電力に接続されているとき、前記動作条件統計に基づいて前記低電力モード選択データテーブルを更新することが達成される、判断すること
をさらに含む動作をプロセッサに実行させるように構成された、請求項38に記載の記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図９Ａ】
【図９Ｂ】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図９Ａ】
【図９Ｂ】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公表番号】特表２０１３−５１６０２５（Ｐ２０１３−５１６０２５Ａ）
【公表日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願番号】特願２０１２−５４７３４２（Ｐ２０１２−５４７３４２）
【出願日】平成２３年１月１０日（２０１１．１．１０）
【国際出願番号】ＰＣＴ／ＵＳ２０１１／０２０７１０
【国際公開番号】ＷＯ２０１１／０８５３３０
【国際公開日】平成２３年７月１４日（２０１１．７．１４）
【出願人】（５０７３６４８３８）クアルコム，インコーポレイテッド (446)
【Ｆターム（参考）】
【公表日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願日】平成２３年１月１０日（２０１１．１．１０）
【国際出願番号】ＰＣＴ／ＵＳ２０１１／０２０７１０
【国際公開番号】ＷＯ２０１１／０８５３３０
【国際公開日】平成２３年７月１４日（２０１１．７．１４）
【出願人】（５０７３６４８３８）クアルコム，インコーポレイテッド (446)
【Ｆターム（参考）】
[ Back to top ]