JP2013516711A - 電子デバイスにおける電力を制御するシステムおよび方法 - Google Patents

Abstract

ノード電力アーキテクチャ(NPA)システムを利用する方法であって、上記方法は、クライアントを作成したいという要求を受信するステップと、リソースが上記要求に適合するかどうかを判断するステップと、上記リソースが上記要求に適合するとき、クライアントハンドルを返信するステップとを含む。

Description

関連出願
本出願は、その内容が参照により完全に組み込まれる、2010年1月11日に出願されたSYSTEM AND METHOD OF CONTROLLING POWER IN AN ELECTRONIC DEVICEと題する米国仮特許出願第61/294,014号の優先権を主張する。

ポータブルコンピューティングデバイス(PCD)はユビキタスである。これらのデバイスは、セルラー電話、携帯情報端末(PDA)、ポータブルゲーム機、パームトップコンピュータ、および他のポータブル電子デバイスを含み得る。これらのデバイスの主要機能に加えて、多くは周辺機能を含む。たとえば、セルラー電話は、セルラー通話を行うという主要機能と、スチールカメラ、ビデオカメラ、全地球測位システム(GPS)ナビゲーション、ウェブブラウジング、電子メールの送信および受信、テキストメッセージの送信および受信、プッシュツートーク機能などの周辺機能とを含み得る。そのようなデバイスの機能が増加するにつれて、そのような機能をサポートするために必要とされる計算能力または処理能力も増加する。さらに、計算能力が増加するにつれて、計算能力を与える1つまたは複数のプロセッサを効果的に管理する必要が高まっている。

したがって、必要なものは、電子デバイスにおける電力を制御する改善された方法である。

図において、別段に規定されていない限り、様々な図を通して、同様の参照番号は同様の部分を指す。

閉位置におけるポータブルコンピューティングデバイス(PCD)の第1の態様の正面図である。 開位置におけるPCDの第1の態様の正面図である。 PCDの第2の態様のブロック図である。 処理システムのブロック図である。 ノード電力アーキテクチャ(NPA)システムの第1の態様のブロック図である。 ノード電力アーキテクチャ(NPA)システムの第2の態様のブロック図である。 ノード電力アーキテクチャ(NPA)システムの第3の態様のブロック図である。 ノード電力アーキテクチャ(NPA)システムの第4の態様のブロック図である。 NPAシステムを利用する方法を示すフローチャートである。 ノード電力アーキテクチャ(NPA)システムの第5の態様のブロック図である。 分散リソースを作成する方法を示すフローチャートである。 ローカルアグリゲーションを用いたリモートリソースを使用する方法を示すフローチャートである。 分散アグリゲーションを用いたリモートリソースを使用する方法を示すフローチャートである。 プロキシリソースを使用する方法を示すフローチャートである。 リモートインターフェース上でプロセッサ再起動を透過的に扱う方法を示すフローチャートである。

「例示的」という単語は、本明細書では、「例、事例、または例示の働きをすること」を意味するために使用する。「例示的」として本明細書で説明するいかなる態様も、必ずしも他の態様よりも好適または有利なものと解釈すべきではない。

本明細書では、「アプリケーション」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能なコンテンツを有するファイルをも含み得る。さらに、本明細書で言及する「アプリケーション」は、開く必要があり得るドキュメント、またはアクセスする必要がある他のデータファイルなど、本質的に実行可能でないファイルをも含み得る。

「コンテンツ」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能なコンテンツを有するファイルをも含み得る。さらに、本明細書で言及する「コンテンツ」は、開く必要があり得るドキュメント、またはアクセスする必要がある他のデータファイルなど、本質的に実行可能でないファイルをも含み得る。

本明細書で使用する「構成要素」、「データベース」、「モジュール」、「システム」などの用語は、コンピュータ関連のエンティティ、すなわち、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかを指すものとする。たとえば、構成要素は、プロセッサ上で動作されるプロセス、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラム、および/またはコンピュータであり得るが、これらに限定されない。例として、コンピューティングデバイス上で実行されるアプリケーションと、そのコンピューティングデバイスの両方が構成要素であり得る。1つまたは複数の構成要素がプロセスおよび/または実行スレッド内に常駐し得、1つの構成要素が1つのコンピュータ上に配置され、および/または2つ以上のコンピュータ間に分散され得る。さらに、これらの構成要素は、様々なデータ構造を記憶している様々なコンピュータ可読媒体から実行し得る。これらの構成要素は、1つまたは複数のデータパケット(たとえば、ローカルシステム、分散システム内の別の構成要素と対話する、および/またはインターネットなどのネットワーク上で信号を介して他のシステムと対話する、1つの構成要素からのデータ)を有する信号によるなど、ローカルプロセスおよび/またはリモートプロセスを介して通信し得る。

最初に図1および図2を参照すると、例示的なポータブルコンピューティングデバイス(PCD)が示されており、全体的に100と称される。図示のように、PCD100はハウジング102を含み得る。ハウジング102は、上側ハウジング部分104と下側ハウジング部分106とを含み得る。図1は、上側ハウジング部分104がディスプレイ108を含み得ることを示している。特定の態様では、ディスプレイ108はタッチスクリーンディスプレイであり得る。上側ハウジング部分104はトラックボール入力デバイス110をも含み得る。さらに、図1に示すように、上側ハウジング部分104は、電源投入ボタン112と電源切断ボタン114とを含み得る。図1に示すように、PCD100の上側ハウジング部分104は、複数のインジケータライト116とスピーカー118とを含み得る。各インジケータライト116は発光ダイオード(LED)であり得る。

特定の態様では、図2に示すように、上側ハウジング部分104は下側ハウジング部分106に対して可動である。詳細には、上側ハウジング部分104は、下側ハウジング部分106に対してスライド可能であり得る。図2に示すように、下側ハウジング部分106はマルチボタンキーボード120を含み得る。特定の態様では、マルチボタンキーボード120は標準QWERTYキーボードであり得る。下側ハウジング部分106に対して上側ハウジング部分104を動かすと、マルチボタンキーボード120があらわになり得る。図2はさらに、PCD100が下側ハウジング部分106上のリセットボタン122を含み得ることを示している。

図3を参照すると、ポータブルコンピューティングデバイス(PCD)の例示的な非限定的態様が示されており、全体的に320と称される。図示のように、PCD320は、マルチコアCPU324を含むオンチップシステム322を含む。マルチコアCPU324は、第0のコア325と、第1のコア326と、第Nのコア327とを含み得る。

図3に示すように、ディスプレイコントローラ328およびタッチスクリーンコントローラ330がマルチコアCPU324に結合される。次に、オンチップシステム322の外部のタッチスクリーンディスプレイ332が、ディスプレイコントローラ328とタッチスクリーンコントローラ330とに結合される。

図3はさらに、ビデオエンコーダ334、たとえば、位相反転線(PAL)エンコーダ、sequential couleur a memoire(SECAM)エンコーダ、または全米テレビジョン方式委員会(NTSC)エンコーダが、マルチコアCPU324に結合されることを示している。さらに、ビデオ増幅器336が、ビデオエンコーダ334とタッチスクリーンディスプレイ332とに結合される。また、ビデオポート338がビデオ増幅器336に結合される。図3に示すように、ユニバーサルシリアルバス(USB)コントローラ340がマルチコアCPU324に結合される。また、USBポート342がUSBコントローラ340に結合される。メモリ344および加入者識別モジュール(SIM)カード346もマルチコアCPU324に結合され得る。さらに、図3に示すように、デジタルカメラ348がマルチコアCPU324に結合され得る。例示的な一態様では、デジタルカメラ348は電荷結合デバイス(CCD)カメラまたは相補型金属酸化物半導体(CMOS)カメラである。

図3にさらに示すように、ステレオオーディオコーデック350がマルチコアCPU324に結合され得る。さらに、オーディオ増幅器352がステレオオーディオコーデック350に結合され得る。例示的な一態様では、第1のステレオスピーカー354および第2のステレオスピーカー356がオーディオ増幅器352に結合される。図3は、マイクロフォン増幅器358もステレオオーディオコーデック350に結合され得ることを示している。さらに、マイクロフォン360がマイクロフォン増幅器358に結合され得る。特定の態様では、周波数変調(FM)ラジオチューナー362がステレオオーディオコーデック350に結合され得る。また、FMアンテナ364がFMラジオチューナー362に結合される。さらに、ステレオヘッドフォン366がステレオオーディオコーデック350に結合され得る。

図3はさらに、無線周波数(RF)トランシーバ368がマルチコアCPU324に結合され得ることを示している。RFスイッチ370が、RFトランシーバ368とRFアンテナ372とに結合され得る。図3に示すように、キーパッド374がマルチコアCPU324に結合され得る。また、マイクロフォン付きモノヘッドセット376がマルチコアCPU324に結合され得る。さらに、バイブレータデバイス378がマルチコアCPU324に結合され得る。図3はまた、電源380がオンチップシステム322に結合され得ることを示している。特定の態様では、電源380は、電力を必要とするPCD320の様々な構成要素に電力を供給する直流電流(DC)電源である。さらに、特定の態様では、電源は、再充電可能なDC電池、または交流電流(AC)電源に接続されたAC-DC変換器から得られるDC電源である。

図3はさらに、PCD320が、データネットワーク、たとえば、ローカルエリアネットワーク、パーソナルエリアネットワーク、または他のネットワークにアクセスするために使用され得るネットワークカード388をも含み得ることを示している。ネットワークカード388は、Bluetooth(登録商標)ネットワークカード、WiFiネットワークカード、パーソナルエリアネットワーク(PAN)カード、パーソナルエリアネットワーク超低電力技術(PeANUT)ネットワークカード、または当技術分野でよく知られている他のネットワークカードであり得る。さらに、ネットワークカード388はチップに組み込まれ得、すなわち、ネットワークカード388は、チップ中で完全なソリューションであることがあり、別個のネットワークカード388でないことがある。

図3に示すように、タッチスクリーンディスプレイ332、ビデオポート338、USBポート342、カメラ348、第1のステレオスピーカー354、第2のステレオスピーカー356、マイクロフォン360、FMアンテナ364、ステレオヘッドフォン366、RFスイッチ370、RFアンテナ372、キーパッド374、モノヘッドセット376、バイブレータ378、および電源380はオンチップシステム322の外部にある。

特定の態様では、本明細書で説明する方法ステップのうちの1つまたは複数がコンピュータプログラム命令としてメモリ344に記憶され得る。これらの命令は、本明細書で説明する方法を実行するためにマルチコアCPU324によって実行され得る。さらに、マルチコアCPU324、メモリ344、またはそれらの組合せは、中央処理ユニット内のデータをサンプリングするために、本明細書で説明する方法ステップのうちの1つまたは複数を実行するための手段として働き得る。

図4を参照すると、処理システムが示されており、全体的に400と称される。特定の態様では、処理システム400は、図3に関連して上記で説明したPCD320に組み込まれ得る。図示のように、処理システム400は、マルチコア中央処理ユニット(CPU)402と、マルチコアCPU402に接続されたメモリ404とを含み得る。マルチコアCPU402は、第0のコア410と、第1のコア412と、第Nのコア414とを含み得る。第0のコア410は、その上で実行される第0の動的クロックおよび電圧スケーリング(dynamic clock and voltage scaling)(DCVS)アルゴリズム416を含み得る。第1のコア412は、その上で実行される第1のDCVSアルゴリズム417を含み得る。さらに、第Nのコア414は、その上で実行される第NのDCVSアルゴリズム418を含み得る。特定の態様では、各DCVSアルゴリズム416、417、418は、それぞれのコア412、414、416上で独立して実行され得る。

その上、図示のように、メモリ404は、その上に記憶されたオペレーティングシステム420を含み得る。オペレーティングシステム420はスケジューラ422を含み得、スケジューラ422は、第1の実行キュー424と、第2の実行キュー426と、第Nの実行キュー428とを含み得る。メモリ404は、その上に記憶された第1のアプリケーション430と、第2のアプリケーション432と、第Nのアプリケーション434とをも含み得る。

特定の態様では、アプリケーション430、432、434は、マルチコアCPU402内のコア410、412、414において処理されるように、1つまたは複数のタスク436をオペレーティングシステム420に送り得る。タスク436は、単独のタスク、スレッド、またはそれらの組合せとして処理または実行され得る。さらに、スケジューラ422は、タスク、スレッド、またはそれらの組合せをマルチコアCPU402内での実行のためにスケジュールし得る。さらに、スケジューラ422は、タスク、スレッド、またはそれらの組合せを実行キュー424、426、428に入れ得る。コア410、412、414は、たとえば、コア410、412、414におけるそれらのタスクおよびスレッドの処理または実行のためにオペレーティングシステム420によって、命令されたように、実行キュー424、426、428からタスク、スレッド、またはそれらの組合せを取り出し得る。

図4は、メモリ404が、その上に記憶されたコントローラ440を含み得ることをも示している。コントローラ440は、オペレーティングシステム420とマルチコアCPU402とに接続され得る。詳細には、コントローラ440は、オペレーティングシステム420内のスケジューラ422に接続され得る。本明細書で説明するように、コントローラ440は、コア410、412、414上の作業負荷を監視し得、コントローラ440は、以下で説明するようにコア410、412、414からデータをサンプリングし得る。

特定の態様では、コントローラ440はソフトウェアプログラムであり得る。ただし、代替態様では、コントローラ440は、メモリ404の外部にあるハードウェアコントローラであり得る。いずれの場合も、コントローラ440、メモリ404、コア410、412、414、またはそれらの任意の組合せは、コア410、412、414からデータをサンプリングするために、本明細書で説明する方法ステップのうちの1つまたは複数を実行するための手段として働き得る。

図5を参照すると、ノード電力アーキテクチャ(NPA)システムが示されており、全体的に500と称される。NPAシステム500は、第1のクライアント502と、第2のクライアント504と、第Nのクライアント506とを含み得る。さらに、NPAシステム500は、第1のクライアント502と第2のクライアント504とに接続された第1のリソース510を含み得る。第2のリソース512が第Nのクライアント506に接続され得る。

さらに、図5に示すように、NPAシステム500は、第1のリソース510に接続された第3のリソース514を含み得る。第4のリソース516が、第1のリソース510と第2のリソース512とに接続され得る。その上、第Nのリソース518が、第3のリソース514と第4のリソース516とに接続され得る。図5はさらに、イベントハンドラ520が第1のリソース510に接続され得ることを示している。イベントハンドラ520は、第1のリソース510から1つまたは複数のイベント522を受信し得る。

特定の態様では、各リソース510、512、514、516、518は、中央処理ユニット、コア、モデム、クロック、バスなどであり得る。各クライアント502、504、506はソフトウェアアプリケーションであり得る。代替として、各クライアント502、504、506は、ソフトウェアアプリケーションまたはソフトウェアアプリケーションのインスタンスを表し得る。

図5に示す接続性が、例示的なものであり、NPAシステム500の範囲を限定するものではないことが諒解され得る。さらに、任意の数のクライアントおよび任意の数のリソースがシステム500中に含まれ得ることが諒解され得る。また、クライアントおよびリソースは、図5に示されていない多数の方法で相互接続され得る。

特定の態様では、図5に示すように、NPAシステム500は、コードではなく有向非巡回グラフ構造として示され得る。さらに、NPAシステム500は、リソース間のディペンデンシを明示的にし、NPAシステム500の構成要素を暗黙的に文書化し得る。さらに、NPAシステム500は、新しいハードウェア(HW)へのリソースおよびクライアントの移植を容易にし得る。特定の態様では、クライアント502、504、506は、直接使用される任意のリソースに要求を発行し得る。リソースからリソースに間接的要求が発行され得る。

また、NPAシステム500は、オン、オフ、またはレベルを越えて作業要求を向上させ得る。さらに、NPAシステム500では、クライアント、リソース、またはそれらの組合せによって暗示およびデッドラインを発行することが可能になり得る。暗示は、命令毎秒、たとえば、百万命令毎秒(MIPS)で表される、クライアントまたはリソースの特定の作業負荷要件を示し得る。代替的に、作業負荷要件は、周波数、たとえば、キロヘルツ値(kHz)、メガヘルツ(MHz)値、ギガヘルツ(GHz)値などとして表され得る。別の態様では、作業負荷要件は、データ転送レート、たとえば、キロビット毎秒(KB/S)、メガビット毎秒(MB/S)、ギガビット毎秒(GB/S)、またはそれらの組合せとして表され得る。さらに、作業負荷要件は、上記で説明した任意の組合せとして表され得る。特定の作業負荷要件に関連するデッドラインは、特定の作業負荷がいつ完了しなければならないかを示し得る。

図5に示すNPAシステム500は、さらに、リソース要求とは別の電力最適化を行う。たとえば、NPAシステム500は、クライアント要求を変更する必要なしに電力を最適化するために、暗示、持続時間、デッドライン、またはそれらの組合せを利用し得る。

NPAシステム500は、リソース状態変化の通知のためのイベント機構、すなわち、イベントハンドラ520を含み得る。イベントハンドラ520により、ソフトウェアプログラムは、リソースがイネーブル、ディスエィブル、オーバーサブスクライブなどになったときにそれらのリソースに反応することが可能になり得る。さらに、イベントハンドラ520により、リソース利用の動的プロファイリングが可能になり得る。NPAシステム500は分散システムと見なされ得るので、これにより、追加のリソースをNPAシステム500に動的に追加することが可能になり得る。さらに、リソース定義とは別に電力最適化が実行され得る。

特定の態様では、リソース510、512、514、516、518は、NPAシステム500中のノードであり得る。クライアント502、504、506はエッジであり得る。各リソース510、512、514、516、518は、必要に応じて、それらに接続された他のリソース510、512、514、516、518に要求を伝搬し得る。特に、各リソース510、512、514、516、518は、外部要求が発行されるのと同様にして、クライアント502、504、506を介して従属リソース510、512、514、516、518に要求を発行し得る。より詳細には、リソース510、512、514、516、518の観点からすると、外部クライアント502、504、506が要求を発行すること、または別のリソース510、512、514、516、518が要求を発行することの間には差異がないことがある。特定の態様では、リソース510、512、514、516、518が動的に追加され得る。さらに、クライアント502、504、506およびイベントハンドラ520が動的に追加され、削除され得る。

特定の態様では、リソース510、512、514、516、518は、クライアント502、504、506がそれに対して作業要求を発行し得るエンティティであり得る。すべてのリソース要求および更新はロギングされ得る。その上、リソース510、512、514、516、518は、様々なクライアント要求を満たすことと、電力消費を最適化することとを担当し得る。特定の態様では、クライアント要求を満たすための正しいレベル、すなわち、作業負荷を判断することを担当する関数は、ユーザ定義され、オーバーライドされ得る。ハードウェア(HW)および他のリソースディペンデンシを更新することを担当する関数はユーザ定義可能であり得る。

NPAシステム500では、すべてのリソース510、512、514、516、518が名前によって識別され得る。さらに、NPAシステム500を使用すると、クライアント502、504、506とリソース510、512、514、516、518との間のコンパイル時間リンケージがない。詳細には、クライアント502、504、506が作成されるときにストリングルックアップが解決され得る。さらに、要求時間オーバーヘッドがない。各リソース510、512、514、516、518は複数の名前、すなわち、エイリアスを有し得、各リソース510、512、514、516、518は、それ自体の単位、たとえば、MIPS、MHz、MB/Sなどを定義し得、定義された単位で作業要求が行われる。

NPAシステム500を示すリソースグラフ、図5は、極めて動的であり、必ずしも図5に示すように見えるわけではない。NPAシステム500を表すリソースグラフは、リソースおよびクライアントが設置されたデバイスの初期化中に構築される。クライアントおよびイベントハンドラは動的に追加され得、リソースに対してクライアント要求が発行され得る。リソースは、新しいリソース状態を計算するために複数の同時要求をアグリゲートし得る。その上、リソースは、新しいリソース状態を満たすために、必要に応じてディペンデンシ要求を更新し、取り消し得る。

図6に、600と称される、NPAシステムの別の態様を示す。図示のように、NPAシステム600は、第2のノード604に接続された第1のノード602を含む。第1のノード602は第1のリソース610を含む。第2のノード604は、第2のリソース612と、第3のリソース614と、第4のリソース616とを含む。図示のように、クライアント620が第1のノード602に接続される。特定の態様では、第1のリソース610は、第1のエイリアス622と第2のエイリアス624とを含み得る。

特定の態様では、ノード602、604は、1つまたは複数のリソース610、612、614、616の集合であり得る。2つ以上のリソースをもつノードは、複合ノード、たとえば、第2のノード604と呼ばれる。複合ノードの一例は、結合されたCPUおよびバスクロックを含み得る。同じドライバ関数がCPUとバスリソースの両方によって共有され得る。一方のクロックを更新することにより、他方のクロックが暗黙的に更新され得る。

リソース610、612、614、616は、命名されたインターフェースであり得る。命名規則は、ファイルシステムと同様であり得、たとえば、/clk/cpu、/bus/arbiterなどであり得る。リソース610、612、614、616は、物理リソース、たとえば、クロック、電圧レールなどを表し得る。リソース610、612、614、616は、論理リソース、たとえば、CPU、バスなどをも表し得る。リソース610、612、614、616は、サブシステム使用事例、たとえば、バスフローをも表し得る。さらに、リソース610、612、614、616は、制御信号、たとえば、DCVSイネーブルなどを提示し得る。

論理リソースの一例はCPUレイテンシリソースを含み得る。そのような場合、クライアントが、特定のレイテンシ要件をもつ要求を発行し得る。スリープタスクでは、その制約を使用して、いくつかの低電力モードを許可するかまたは許可しないことがある。スリープ状態が実装されると、または新しいハードウェアが低電力モード(LPM)遷移時間を変更すると、低電力モードがイネーブルにされ得、または潜在的な障害事例が回避され得る。そのような場合、LPM挙動のいかなる変更も、すべての登録されたクライアントに対して透過的であり得る。

本明細書で述べるように、同じリソースが2つ以上の名前、すなわち、シムリンクまたはエイリアスを有し得る。これにより、仮想リソースを確立し得る。そのような場合、そのリソースのために複数のハードウェア(HW)非依存の名前が作成され得る。たとえば、1つのリソースが「/power/cpu」および「/power/C2」と命名され得る。これらの名前は互いにリンクされ得、リンクはリソース定義に依存せずに定義され得る。特定の態様では、リソースは、リンクが作成されるより前に存在していなければならず、リンクはクライアント作成時間に解決され得る。さらに、要求時間オーバーヘッドが生じないことがある。

仮想リソースの使用により、若干のハードウェア抽象化が行われ得る。言い換えれば、クライアントは、どのレールが特定のCPUに電力供給するかを知っている必要がなく、クライアントは、クライアントがどのCPU上で動作しているかを知っている必要がない。

特定の態様では、ノード602、604は、すべての集められたリソース610、612、614、616のディペンデンシを管理し得る。その上、複合ノード604中の各リソース612、614、616は、同じドライバ関数、ディペンデンシ、NPAロック、またはそれらの組合せを共有し得る。また、特定の態様では、複合ノード604中の各リソース612、614、616に対する更新または要求がアトミックに処理され得る。ドライバおよび更新関数は、複合ノード604中のすべてのリソース612、614、616の状態にアクセスし得る。各ノード602、604は、名前またはエイリアスによって識別され得、各ノード名はディペンデンシを識別するために使用され得る。

ノード602、604は、名前、(カスタム関数であり得る)ドライバ関数、1つまたは複数の属性、ユーザデータ、ディペンデンシアレイ、リソース定義アレイ、またはそれらの任意の組合せを含む、構造のセットを介して定義され得る。ディペンデンシアレイは、ディペンデンシの名前とディペンデンシクライアントタイプとを含み得る。リソース定義アレイは、リソース名、最大値、1つまたは複数のリソース属性、ライブラリからのプラグイン(たとえば、更新関数)、ユーザデータ、またはそれらの組合せを与えられ得、それらを含み得る。

ノード作成関数は、ノード定義構造、初期リソース状態アレイ、随意のノード作成イベント、またはそれらの組合せを利用し得る。ノードディペンデンシのすべてが存在した後、ノード作成関数は、1つまたは複数のリソースを作成し得、そのリソースをリソースグラフに追加する。さらに、ノード作成関数は、ディペンデンシに関してクライアントを作成し得、ノード作成関数は、初期値を用いてドライバ関数を呼び出し得る。特定の態様では、ノードのためのすべてのディペンデンシが存在するまで、ノードは作成されないことがある。ノードが完全に構築されると、クライアントは通知を受け得る。

特定の態様では、NPAシステムを表すリソースグラフが分散的に構築され得る。いかなる技術も、それ自体のリソースを定義し、そのリソースをグラフに追加し得る。ノードは任意の順序で定義され得る。

図7に、700と称される、NPAシステムの第3の態様を示す。図示のように、NPAシステム700はリソース702を含み得る。リソース702は、すべてのアクティブに登録されたクライアントの集合を含み得る。その集合は、第1のクライアント704と、第2のクライアント706と、第3のクライアント708とを含むリストであり得る。クライアント704、706、708は、リソース702に関連付けられ、互いに関連付けられないことがある。クライアント704、706、708は、リソース702に作業要求を発行するために使用され得る。その上、クライアント704、706、708は同期または非同期であり得る。特定の態様では、同期クライアントは、要求が完了するまで復帰しないことがある。非同期クライアントは、直ちに復帰し、要求が完了したときにユーザコールバックを呼び出し得る。

作業要求は作業モデルを含み得る。作業モデルは、登録作業負荷、インパルス作業負荷、等時性作業負荷(isochronous workload)、パルス作業負荷、ベストエフォート作業負荷、スケジュール作業負荷などを含み得る。

さらに、リソース702は、随意のクライアント作成およびクライアント破棄関数を介してクライアントをさらにカスタマイズし得る。リソース702は、クライアントのuser_dataフィールドを使用して、任意の余分なデータを各クライアントに追加し得る。このデータは、作業負荷統計のキャッシング、クライアント識別、データベースアクセスなどのために使用され得る。

登録作業負荷は、作業負荷を完了するための1つまたは複数の要件、たとえば、特定のCPU周波数を示し得る作業負荷を含み得る。インパルス作業負荷は、よく知られている開始点を有する作業負荷であって、ただし、よく知られている終了を有さず、よく知られている負荷を有しない作業負荷を含み得る。等時性作業負荷は、実質的に一定の持続時間に実質的に一定の間隔で生じる作業負荷であり得る。パルス作業負荷は、一定のレベルで開始する作業負荷であって、固定の時間間隔で自動的に停止する作業負荷を含み得る。さらに、ベストエフォート作業負荷は、実行され得る作業であって、ただし、パフォーマンスクリティカルではなく、任意に延期され得る作業があるという暗示を含み得る。スケジュール作業負荷は、ある量の作業が将来の定義された時点に必要となるという通知を含む作業負荷であり得る。各タイプの作業負荷は、実行される前にそれのタイプを示し得、リソースは、たとえば、動的クロックおよび電圧スケーリング(DCVS)アルゴリズムを改変することによって、その作業負荷を効果的かつ効率的に実行するために、作業負荷タイプを利用し得る。

特定の態様では、各クライアント704、706、708は名前によって識別され得る。各クライアント名は情報提供の目的で使用され得る。さらに、特定の態様では、ユーザは、不透明なクライアントハンドル710を介してクライアントにアクセスし得る。クライアント要求は、ハードウェア(HW)フィードバック、たとえば、CPUアイドル時間、バス監視などから、およびソフトウェア(SW)アプリケーションから導出され得る。ユーザは、リソース702に要求を発行するために、クライアント704、706、708をリソース702に登録し得る。クライアント登録は実行時に起こり得、リソース702は複数のクライアント要求タイプをサポートし得る。各クライアントタイプは潜在的に異なるインターフェースであり、いくつかのデフォルトクライアントタイプが定義され得る。

次に図8を参照すると、NPAシステムの第4の態様が示されており、800と称される。図示のように、NPAシステム800はリソース802を含み得る。リソース802は、すべての登録されたイベントハンドラの集合を含み得る。登録されたイベントハンドラの集合は、リストであり得、第1のイベントハンドラ804と、第2のイベントハンドラ806と、第3のイベントハンドラ808とを含み得る。イベントハンドラ802、804、806は、リソース802に関連付けられるが、互いに関連付けられないことがある。

図示のように、リソース802は、イベントハンドラ804、806、808のリストを含み得る。クライアントはイベントハンドラ804、806、808を登録し得る。ただし、イベントハンドラ804、806、808は、必ずしもクライアントに関連付けられるわけではないことがある。ユーザは、不透明なイベントハンドラハンドル810を介してイベントハンドラ804、806、808にアクセスし得る。

特定の態様では、各イベントハンドラ804、806、808は、ハイウォーターマーク、ローウォーターマーク、またはそれらの組合せの登録を行い得、ウォーターマークはヘッドルームとして表され得る。イベントは、たとえば、プロファイリング目的で、リソース状態の変化を含み得る。その上、イベントは、リソース負荷を監視するために、またはリソース状態の変化から他のアクションをトリガするために、使用され得る。これは、リソースがオーバーサブスクライブされたときに作業負荷を低減するために、またはリソースがなくなったときに随意の関数をディスエィブルにするために、使用され得る。

特定の態様では、あらゆる公衆NPA呼が共通のログファイルにロギングされ得る。ログは、名前、すなわち、人間が読み取れるストリングを使用し得る。ストリングの構文解析は別個のスレッドで起こり得る。

次に図9を参照すると、NPAシステムを利用する方法が示されており、全体的に900と称される。図示のように、ステップ902において開始し、ユーザ、すなわち、ソフトウェアアプリケーションが、クライアント作成関数を使用してリソースのための特定のタイプのクライアントを作成し得る。クライアント作成関数は、リソース名、クライアント名、クライアント作業モデル、またはそれらの組合せという引数を含み得る。ステップ904において、リソースは、クライアントを作成したいという要求を受信した後、クライアントのためのクライアントハンドルを返信し得る。クライアントは、ハンドルが実際に作成されたと判断するために、戻り値を検査すべきである。たとえば、適合しない作業モデル、リソースにおける利用可能性の欠如などにより、ハンドルが作成されない場合、方法900は終了し得、ユーザは、別のリソースのためのクライアントを作成することを試み得る。

ステップ906において、ユーザは、ハンドルを使用してリソースに作業要求を発行し得る。作業は、リソース状態、たとえば、オン、オフ、レベル、およびその状態が必要とされる持続時間を含む。作業要求パラメータは知られていることも知られていないこともある。知られているパラメータはリソースに対する要件である。知られていないパラメータはリソースによって暗示され、変更され得る。

可能な場合、リソースは、知られている作業パラメータとともに作業要求を受け取らなければならない。クライアントは、要求が満たされない場合に通知を受信するために、イベントハンドラに登録し得る。知られていない作業パラメータおよび暗示された作業パラメータは、電力消費を最適化するための機会をリソースに与え得る。可能な場合、クライアントは、電力最適化の機会を最大化するために、パラメータを知られていないままにするか、または暗示されたままにすべきである。

また、作業要求は作業モデルを含み得る。作業モデルは、登録作業負荷、インパルス作業負荷、等時性作業負荷、パルス作業負荷、ベストエフォート作業負荷、スケジュール作業負荷などを含み得る。作業モデルが、リソースにとって意味をなさないか、または特定のリソースに適合しない場合、リソースは、その作業モデルをサポートしないことがある。したがって、リソースが特定の作業モデルをサポートしない場合、作業要求は、ステップ902においてクライアントが作成されるときに機能しないことがある。特定の態様では、必要に応じて他の作業モデルが定義され得、後方互換性のある様式で新しい作業モデルが追加され得る。

ステップ908に移動して、要求は2つの段階でアトミックに処理され得、すなわち、更新関数が実行され、ドライバ関数が実行される。詳細には、ステップ910において、新しいリソース状態を判断するために新しい要求を任意の未解決のクライアント要求とアグリゲートするために更新関数が実行され得る。言い換えれば、様々な作業モデルの同時クライアント要求があるとすれば、更新関数は、リソース状態を計算するためにリソースによって呼び出され得る。たとえば、あるクライアントが少なくとも200MIPSを必要とし、別のクライアントが少なくとも350MIPSを必要とする場合、更新関数は、両方のクライアントを満たすために新しいリソース状態が少なくとも350MIPSであるべきであると判断し得る。別の態様では、それらのクライアント要件は加算され得、550MIPSが新しいリソース状態であり得る。更新関数は、動的であるプラグインと見なされ得、すなわち、更新関数はオーバーライドされ得る。たとえば、更新関数は、リソースのクライアントを変更することなしに電力消費を最適化するためにオーバーライドされ得る。更新関数はまた、立ち上げの状況またはデバッグの状況においてリソースを強制的にオン状態にするためにオーバーライドされ得る。

特定の態様では、更新関数は、リソースと要求側クライアントとを引数として使用し得る。さらに、現在のアクティブなクライアント要求および保留中のクライアント要求が更新関数にとって利用可能である。更新関数は所望の状態を返信し得、更新関数によって計算された所望の状態はハードウェア(HW)によってサポートされないことがある。必要に応じてドライバ関数が所望の状態を量子化し得る。

次に、ステップ912において、ドライバ関数が実行され得る。ドライバ関数は、更新関数によって計算された新しいリソース状態をリソースに適用する。したがって、ドライバ関数は、管理されたリソースを更新し、従属リソースに1つまたは複数の要求を発行する。ターゲットディペンデンシはドライバ関数においてキャプチャされ得る。さらに、ドライバ関数は、クライアントインターフェースまたは更新関数を変更することなしにターゲットごとに異なり得る。

ドライバ関数は、リソースと所望の状態とを引数として利用し得る。詳細には、ドライバ関数は、所望の状態をMIPSで計算し、CPUクロックに対する周波数要求とバスに対する帯域幅(BW)要求とを導出し得る。ドライバ関数は、以下で説明するようにディペンデンシに要求を発行し得る。ディペンデンシは状態の関数であり得る。さらに、ディペンデンシは、リソース定義アレイの一部であるディペンデンシアレイからインデックス付けされ得る。ドライバ関数はハードウェア(HW)にも要求を発行し得る。ただし、リソースが論理リソースである場合、これらの要求は必要でないことがある。さらに、ドライバ関数は、リソースとリソースのディペンデンシとに関連する実際の状態セットを返信し得る。

ステップ914において、ドライバ関数は、必要に応じて他の従属リソースにディペンデンシ要求を発行する。たとえば、リソースが新しい状態を適用することができない場合、リソースは、利用可能な場合は、リソースに関連するノードにおいてリソースに接続された別のリソースにクライアント要求を受け渡し得る。ステップ916において、リソースは、1つまたは複数のトリガイベントをイベントハンドラに出力し得る。トリガイベントはリソース状態の関数であり得る。トリガイベントは、リソース負荷を監視するために、またはリソース状態の変化から他のアクションをトリガするために、使用され得る。たとえば、トリガイベントは、リソースがオーバーサブスクライブされたときに作業負荷を低減するために、またはリソースがなくなったときに随意の関数をディスエィブルにするために、使用され得る。

ステップ918に移動して、リソースは、ユーザによってリソースが必要とされなくなるまで、ユーザによって利用され得る。ステップ920において、ユーザが要求発行をもはや必要としなくなると、ユーザは、クライアントハンドルを破棄したいという要求を送信し得、リソースはクライアントハンドルを破棄し得る。次いで、方法900は終了し得る。ユーザがクライアントハンドルを破棄することなしに要求を取り消し得ることが諒解され得る。これにより、クライアントハンドルを再利用することが可能になり得る。

図10に、全体的に1000と称される、NPAシステムの第5の態様を示す。図示のように、システム1000は、カーネル空間1002とユーザ空間1004とを含み得る。NPAカーネルドライバ1006が、カーネル空間1002とユーザ空間1004との間のインターフェースを与え得る。図10に示すように、カーネル空間1002は、NPAカーネルドライバ1006に接続され得るカーネル空間NPAクライアントアプリケーションプログラミングインターフェース(API)1010を含み得る。さらに、カーネル空間1002は、NPAカーネルドライバ1006に接続されたカーネル空間NPAイベントAPI1012を含み得る。カーネル空間NPAリソース定義API1014が、カーネル空間NPAクライアントAPI1010とカーネル空間NPAイベントAPI1012とに接続される。

図10に示すように、NPAシステム1000のユーザ空間1004は、NPAカーネルドライバ1006に接続されたユーザ空間NPAクライアントAPI1020を含み得る。その上、ユーザ空間NPAイベントAPI1022がNPAカーネルドライバ1006に接続され得る。

特定の態様では、カーネル空間中の任意の要素がNPA関数へのフルアクセスを有し得る。たとえば、カーネル空間中の任意の要素は、任意のリソースに対して要求を発行し、イベントを受信し得る。さらに、カーネル空間中の任意の要素はリソースを作成し得る。別の態様では、ユーザ空間NPAクライアントAPI1020はカーネル空間NPAクライアントAPI1010の複製であり得、ユーザ空間NPAイベントAPI1022はカーネル空間NPAイベントAPI1012の複製であり得る。ユーザ空間中の要素は、要求を発行し、イベントを受信し得るが、明示的にエクスポートされたリソースに対してのみそれらを行い得る。ただし、ユーザ空間中の要素はリソースを作成しないことがある。

特定の態様では、ユーザ空間NPAクライアントAPI1020は、NPAカーネルドライバ1006を通してカーネル空間NPAクライアントAPI1010に要求を発行し得る。カーネル空間NPAクライアントAPI1010は、その要求をカーネル空間NPAリソース定義API1014に受け渡し得る。カーネル空間NPAリソース定義API1014は、カーネル空間NPAイベントAPI1012にイベントを返信し得る。次いで、カーネル空間NPAイベントAPI1012は、そのイベントをNPAカーネルドライバ1006を通してユーザ空間NPAイベントAPI1022に受け渡し得る。

NPAカーネルドライバ1006は、特定のオペレーションシステム(OS)で動作するように構成され得る。さらに、NPAカーネルドライバ1006は、NPA APIをカーネルドライバモデル上にマッピングするユーザ空間ライブラリを与え得る。NPAカーネルドライバ1006の上にあるユーザ空間API1020、1022は、OSから独立して動作するように構成され得る。リソースオーサーが、リソースへのユーザ空間アクセスを可能にするためにカーネルドライバコードを書き込む必要がないことがある。

NPAリソースグラフがプロセッサローカルであり得、すなわち、各プロセッサまたはアドレス空間が、それ自体のリソースグラフを定義し得ることが諒解され得る。ただし、複数のプロセッサにわたって共有され得るいくつかのリソースがある。これらの共有リソースは、1つのプロセッサ、たとえば、モデム上で制御され得る。代替的に、これらの共有リソースは、共通のリソースマネージャ、たとえば、リソース電力マネージャ(RPM)によって制御され得る。クライアントは、リソースがローカルであるのか分散されているのかを知らないことがある。

特定の態様では、分散リソースは、要求を処理するために別のプロセッサ上のリソースによるアクションを必要とする任意のリソースであり得る。リモートリソースは、別のプロセッサ上のリソースの状態から独立したローカル状態を維持する分散リソースであり得る。さらに、プロキシリソースは、その状態が別のプロセッサ上のリソースの状態を追跡する、分散リソースであり得る。別のプロセッサ上のリソース(resource on another processor)(ROAP)は、分散リソースがアクセスをそれに対して分散しているリソースであり得る。ROAPは、ROAPが分散様式でアクセスされていることを知らないことがある。

ローカルアグリゲーションを用いた分散リソースは、すべての要求をローカルでアグリゲートする分散リソースであって、アグリゲートされた要求をROAPに発行する分散リソースであり得る。ローカルアグリゲーションを用いた分散リソースは、ROAP上で1つのクライアントのみを必要とする。リモートアグリゲーションを用いた分散リソースは、他のプロセッサ上でのアグリゲーションのために各要求を別個にROAPに転送する分散リソースであり得る。リモートアグリゲーションを用いた分散リソースは、ローカルクライアントごとにROAP上で1つのクライアントを必要とする。特定の態様では、様々な分散使用事例は、クライアント作成、クライアント破棄、要求発行、イベント登録、リソース利用可能、および状態問合せという、NPA関数のうちの1つまたは複数がリモートインターフェースによってエクスポートされることを必要とし得る。

図11に、分散リソースを作成する方法を示す。本方法は全体的に1100と称され得る。方法1100は、ステップ1102において、リモートリソースを定義したいという要求で開始し得る。その要求はリモートプロトコルに対して行われ得る。ステップ1104において、リモートプロトコルは、ROAPが利用可能であるかどうかを判断するためにリソース利用可能関数を呼び出し得る。ステップ1106において、リソース利用可能関数は、リモートインターフェースに対してリソース利用可能イベントをトリガし得る。ステップ1108において、ROAPが利用可能であるかどうかを判断するためにnpaリソース利用可能関数をROAPに呼び出させるために、リソース利用可能イベントはリモートインターフェースを通してROAPに送信され得る。ROAPが利用可能である場合、ステップ1110において、ROAPは、リソース利用可能イベントを生成するためにnpaリソース利用可能コールバック関数を呼び出し得、ステップ1112において、リソース利用可能イベントはリモートインターフェースに送信され得る。次いで、ステップ1114において、リモートインターフェースは、リモートプロトコルにリソース利用可能コールバックを発行し得る。次いで、ステップ1116において、リモートプロトコルは、ノードを定義するためにnpaノード定義関数を呼び出し得る。

次に図12を参照すると、ローカルアグリゲーションを用いたリモートリソースを使用する方法が示されており、全体的に1200と称される。図示のように、方法1200は、ステップ1202において、クライアントを作成したいという要求で開始し得る。クライアントを作成したいという要求により、リモートリソースは、ステップ1204において更新関数を呼び出し、ステップ1206においてドライバ関数を呼び出し得る。

ステップ1208において、ノード定義関数が呼び出され得る。これにより、ステップ1210において、リモートリソースはドライバ関数を呼び出し得る。呼び出されると、ドライバ関数は、ステップ1212において、クライアント作成イベントをトリガし得る。クライアント作成イベントは、リモートインターフェースを通してROAPに受け渡され得る。ステップ1214において、ROAPはリモートリソースにハンドルを返信し得る。その後、ステップ1216において、ノード定義が完了し得る。ステップ1218において、リモートリソースは、クライアントに代わって、ROAPに作業要求を発行し得る。ステップ1220において、ROAPは、作業が完了するまで作業を実行し得る。

図13に、リモートアグリゲーションを用いたリモートリソースを使用する方法を示す。本方法は全体的に1300と称され得る。ステップ1302において、クライアントを作成したいという要求がリモートリソースにサブミットされ得る。ステップ1304において、リモートリソースはクライアント作成関数を呼び出し得る。ステップ1306において、クライアント作成関数はクライアント作成イベントをトリガし得、クライアント作成イベントはリモートインターフェースを介してROAPに送信され得る。ステップ1308において、ROAPは、リモートインターフェースを通してリモートリソースにハンドルを送信し得る。ステップ1310において、リモートリソースはハンドルをクライアントに受け渡し得る。

ステップ1312に移動して、クライアントはリモートリソースに作業要求を発行し得る。ステップ1314において、リモートリソースは更新関数を呼び出し得る。さらに、ステップ1316において、リモートリソースはドライバ関数を呼び出し得る。その後、ステップ1318において、リモートリソースはROAPに作業要求を発行し得る。ステップ1320において、ROAPは、必要に応じて作業を実行し、作業をリモートリソースに受け渡し得る。ステップ1322において、リモートリソースは作業をクライアントに送信し得る。

ステップ1324において、クライアントは、クライアントハンドルを破棄したいという要求をリモートリソースに発行し得る。ステップ1326において、リモートリソースはクライアントハンドル破棄関数を呼び出し得る。次いで、ステップ1328において、リモートリソースは、ROAPにクライアント破棄イベントを出力し得る。ステップ1330において、ROAPは、クライアントが破棄されたことを示すイベントをリモートリソースに返信し得る。次いで、リモートリソースは、クライアントハンドルが破棄されたことを示す指示をクライアントに送信し得る。

図14を参照すると、プロキシリソースを使用する方法が示されており、全体的に1400と称される。ステップ1402において、ユーザがプロキシリソースにイベント作成を発行し得る。ステップ1404において、プロキシリソースはイベント作成関数を呼び出し得る。ステップ1406において、プロキシリソースは、リモートインターフェースを通してROAPに変更イベント作成を発行し得る。ステップ1408において、ROAPは応答を発行し、その応答はリモートインターフェースを介してプロキシリソースに返信され得る。ステップ1410において、プロキシリソースは応答をユーザに送り得る。

ステップ1412において、ROAPは、リモートインターフェースを介してプロキシリソースにイベントコールバックを発行する。ステップ1414において、プロキシリソースは、イベントコールバックに応答してnpaリソース状態割当て関数を呼び出し得る。次いで、ステップ1416において、プロキシリソースは、ユーザに1つまたは複数のトリガイベントを発行し得る。

ステップ1418に移動して、ユーザはプロキシリソースにイベント破棄を発行し得る。ステップ1420において、プロキシリソースは、変更イベント破棄をトリガし得るイベント破棄関数を呼び出し得、ステップ1422において、変更イベント破棄はリモートインターフェースを介してROAPに送信され得る。ステップ1424において、ROAPは、変更イベント破棄に対する応答をリモートインターフェースを通してプロキシリソースに送信し得る。ステップ1426において、プロキシリソースは応答をユーザに受け渡し得る。

図15に、全体的に1500と称される、リモートインターフェース上でプロセッサ再起動を透過的に扱う方法を示す。ステップ1502において開始し、ROAP、この場合モデムが、リモートインターフェースにモデム再起動を発行し得る。ステップ1504において、リモートインターフェースは分散リソースにリソースロックを発行する。

ステップ1506において、ROAPは、再起動が完了したことをリモートインターフェースに示し得る。次いで、ステップ1508において、リモートインターフェースは分散リソースにリソースリセットを発行し得る。次に、ステップ1510において、分散リソースはクライアント再同期関数を呼び出し得る。次いで、ステップ1512において、分散リソースは、リモートインターフェースを介してROAPにクライアント作成要求を発行し得る。ステップ1512において、分散リソースは、リモートインターフェースを介してROAPに作業要求を発行し得る。次いで、方法1500は終了し得る。

特定の態様では、各リソースは、それがリモートでアクセスされるべきかどうかを定義し得る。リソースが、リモートでアクセスされ得ることを定義しない場合、リモートクライアントおよびリモートイベントは作成されないことがある。さらに、リモートコマンドプロトコルはトランスポートアグノスティックであり得る。同じコマンドが複数のプロセッサ間トランスポートで、さらには同時に使用され得る。特に、同じコマンドプロトコルが、ユーザ空間とカーネル空間との間で、ならびにリモートアクセスのために使用され得る。

本明細書で説明した方法ステップは、必ずしも説明した順序で実行される必要がないことを理解されたい。さらに、「その後」、「次いで」、「次に」などの単語は、ステップの順序を限定するものではない。これらの単語は、単に、読者に方法ステップの説明を案内するために使用される。さらに、本明細書で説明した方法は、ポータブルコンピューティングデバイス(PCD)上で実行可能であるものとして説明されている。PCDは、携帯電話デバイス、携帯情報端末デバイス、スマートブックコンピューティングデバイス、ネットブックコンピューティングデバイス、ラップトップコンピューティングデバイス、デスクトップコンピューティングデバイス、またはそれらの組合せであり得る。

本明細書で説明する構成を用いて、本システムおよび方法は、動的リソースの要求を定義し、行うための共通のソフトウェアソリューションを作成し得る。さらに、本システムおよび方法は、クライアントの影響を最小にしてクライアントサービス品質(QoS)要件を満たしながら、ネイティブに同時要求を扱い、電力最適化を可能にし得る。さらに、本システムおよび方法は、最適化目的でのリソース利用のソフトウェア(SW)およびハードウェア(HW)フィードバックを可能にし得る。本明細書で開示するシステムおよび方法を使用して、リソースディペンデンシがコードとしてではなくデータとして表され得る。さらに、リソース状態の変化からアクションがトリガされ得る。さらに、本システムおよび方法は、システム定義およびリソース利用の可視性を実質的に改善し、ビルド時間および統合問題を実質的に改善し得る。

特定の態様では、リソース名はリソースグラフにわたって一意であるべきである。リソースは、/bus/… ; [ahb|axi|…]、/clk/… ; [tcxo|cpu |…]、/core/… ; [cpu|gfx|…]、/pwr/… ; [c1|c2|…]など、トップレベルとともにファイルシステムメタファーを使用して命名され得る。別の態様では、クライアント名は、情報提供の目的で使用され得、一意である必要がない。複数の技術によって作成されたクライアントのために、システム/サブシステム[/サブシステム]/使用事例、たとえば、modem/cdma/srch/idleという規則が使用され得る。他のリソースによって作成されたクライアントは、作成リソースにちなんで命名され得る。

別の特定の態様では、NPA構造は実行時に動的に作成され得る。断片化を防ぎ、割振りコストを最小限に抑えるために、固定サイズメモリプールアロケータが使用され得る。プールは、ユーザ割振りメモリを用いて初期化され得る。さらに、プールは場合によってはヒープ割振りを介して拡張され得るが、ヒープサポートは必要とされない。その上、プールに追加されたメモリは解放されないことがある。

デバッギング目的で、すべてのクライアント作業要求およびリソース状態変化は共通のログにおいてキャプチャされ得る。詳細には、クライアントおよびリソースは、読みやすさの改善のために名前によってロギングされ得る。アクティブなクライアントリストがリソース利用に対する洞察を与え得る。デバッギング中に、リソースを強制的に知られている状態にするために、リソースのための更新関数は動的にオーバーライドされ得る。これにより、初期立上げ段階中に電力管理を延期し、バグハント中に電力管理を分離し得る。さらに、アクティブなクライアントおよびリソース状態は、実行時にプログラム的に、または停止されている間に他のユーティリティを介して、取り出され得る。

特定の態様では、コンパイル時間結合が最小限に抑えられ得る。クライアント/リソース結合は名前のルックアップを介して達成され得、ルックアップは初期化時間に解決され得る。その上、クライアントは動的に割り振られ得、クライアントの固定計数ベースのセットがないことがある。クライアントは、ハンドル、すなわち、不透明な構造ポインタを介してアクセスされ得る。また、クライアントによる、実際のクライアントデータ構造の可視性がないことがある。

本明細書で説明するNPAシステムは、ディペンデンシを定義するための機構を与え得る。その上、NPAシステムは、ディペンデンシ順序で初期化を順序付けながら、定義の任意の順序を可能にし得る。サブシステムはそれらのディペンデンシを所有し得るが、サブシステムはまた、NPA型インターフェースを採用する必要なしに、NPAディペンデンシ管理を使用して初期化を順序付け得る。包括的に採用された場合、サブシステム始動は任意の順序で行われ得る。これにより、始動の保守を実質的に低減し、始動シーケンスのロバストネスおよび可視性を実質的に高め得る。また、これは、マルチコアプロセッサ上で始動シーケンスを自動的に並列化するように拡張され得る。

特定の態様では、リソースは、リソースがどの他のリソースに依存するかを明示的に記載し得る。クライアントおよび非リソースは、必要とされるリソースが存在するとき、イベント、たとえば、コールバック/信号の登録を行い得る。さらに、定義および作成がロギングされ得る。サブシステムは、他のサブシステムが初期化ディペンデンシを表すことを可能にするために、およびNPAシステムがシステム始動を適切に順序付けることを可能にするために、論理/initリソースを定義し得る。サブシステムがNPA型要求インターフェースをサポートするという要件はない。しかしながら、サブシステムは、今度は、サブシステム自体のディペンデンシのためにNPAディペンデンシ管理および初期化順序付けを活用し得る。

1つまたは複数の例示的な態様では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装した場合、機能は、1つまたは複数の命令またはコードとして、機械可読媒体、すなわちコンピュータ可読媒体などのコンピュータプログラム製品上に記憶されるか、あるいはコンピュータプログラム製品を介して送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく、例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスク記憶装置ストレージ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは命令またはデータ構造の形態で所望のプログラムコードを搬送または記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を含み得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フレキシブルディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

選択された態様について詳細に図示および説明したが、以下の特許請求の範囲によって規定されるように、本発明の趣旨および範囲から逸脱することなく様々な置換および改変を本明細書で行い得ることを理解されたい。

100 ポータブルコンピューティングデバイス(PCD)
102 ハウジング
104 上側ハウジング部分
106 下側ハウジング部分
108 ディスプレイ
110 トラックボール入力デバイス
112 電源投入ボタン
114 電源切断ボタン
116 インジケータライト
118 スピーカー
120 マルチボタンキーボード
122 リセットボタン
320 ポータブルコンピューティングデバイス(PCD)
322 オンチップシステム
324 マルチコアCPU
325 第0のコア
326 第1のコア
327 第Nのコア
328 ディスプレイコントローラ
330 タッチスクリーンコントローラ
332 タッチスクリーンディスプレイ
334 ビデオエンコーダ
336 ビデオ増幅器
338 ビデオポート
340 ユニバーサルシリアルバス(USB)コントローラ
342 USBポート
344 メモリ
346 加入者識別モジュール(SIM)カード
348 デジタルカメラ
350 ステレオオーディオコーデック
352 オーディオ増幅器
354 第1のステレオスピーカー
356 第2のステレオスピーカー
358 マイクロフォン増幅器
360 マイクロフォン
362 周波数変調(FM)ラジオチューナー
364 FMアンテナ
366 ステレオヘッドフォン
368 RFトランシーバ
370 RFスイッチ
372 RFアンテナ
374 キーパッド
376 マイクロフォン付きモノヘッドセット
378 バイブレータデバイス
380 電源
388 ネットワークカード
400 処理システム
402 マルチコア中央処理ユニット(CPU)
404 メモリ
410 第0のコア
412 第1のコア
414 第Nのコア
416 第0の動的クロックおよび電圧スケーリング(DCVS)アルゴリズム
417 第1のDCVSアルゴリズム
418 第NのDCVSアルゴリズム
420 オペレーティングシステム
422 スケジューラ
424 第1の実行キュー
426 第2の実行キュー
428 第Nの実行キュー
430 第1のアプリケーション
432 第2のアプリケーション
434 第Nのアプリケーション
436 タスク
440 コントローラ
500 NPAシステム
502 第1のクライアント
504 第2のクライアント
506 第Nのクライアント
510 第1のリソース
512 第2のリソース
514 第3のリソース
516 第4のリソース
518 第Nのリソース
520 イベントハンドラ
600 NPAシステム
602 第1のノード
604 第2のノード
610 第1のリソース
612 第2のリソース
614 第3のリソース
616 第4のリソース
620 クライアント
622 第1のエイリアス
624 第2のエイリアス
700 NPAシステム
702 リソース
704 第1のクライアント
706 第2のクライアント
708 第3のクライアント
710 クライアントハンドル
800 NPAシステム
802 リソース
804 第1のイベントハンドラ
806 第2のイベントハンドラ
808 第3のイベントハンドラ
810 イベントハンドラハンドル
1000 システム
1000 NPAシステム
1002 カーネル空間
1004 ユーザ空間
1006 NPAカーネルドライバ
1010 カーネル空間NPAクライアントアプリケーションプログラミングインターフェース(API)
1012 カーネル空間NPAイベントAPI
1014 カーネル空間NPAリソース定義API
1020 ユーザ空間NPAクライアントAPI
1022 ユーザ空間NPAイベントAPI

Claims (40)

1. ノード電力アーキテクチャ(NPA)システムを利用する方法であって、前記方法は、
   クライアントを作成したいという要求を受信するステップと、
   リソースが前記要求に適合するかどうかを判断するステップと、
   前記リソースが前記要求に適合するとき、クライアントハンドルを返信するステップと
   を含む、方法。
2. 前記要求が作業モデルを含む、請求項1に記載の方法。
3. 前記作業モデルが、登録作業負荷、インパルス作業負荷、等時性作業負荷、パルス作業負荷、ベストエフォート作業負荷、スケジュール作業負荷、またはそれらの組合せを含む、請求項2に記載の方法。
4. 新しい作業要求を受信するステップ
   をさらに含む、請求項1に記載の方法。
5. 新しい作業要求を任意の保留作業要求とアグリゲートするステップと、
   前記新しい作業要求と前記保留作業要求とに基づいてリソース状態を判断するステップと
   をさらに含む、請求項4に記載の方法。
6. 前記リソース状態を前記リソースに適用するステップと、
   前記作業要求を実行するステップと
   をさらに含む、請求項5に記載の方法。
7. 前記クライアントハンドルを破棄したいという要求を受信するステップ
   をさらに含む、請求項6に記載の方法。
8. 前記クライアントハンドルを破棄するステップ
   をさらに含む、請求項7に記載の方法。
9. 前記リソースが前記作業要求を実行することができない場合、従属リソースにディペンデンシ要求を発行するステップ
   をさらに含む、請求項1に記載の方法。
10. 従属リソースが利用不可能である場合、トリガイベントを出力するステップ
    をさらに含む、請求項9に記載の方法。
11. クライアントを作成したいという要求を受信するための手段と、
    リソースが前記要求に適合するかどうかを判断するための手段と、
    前記リソースが前記要求に適合するとき、クライアントハンドルを返信するための手段と
    を含む、デバイス。
12. 前記要求が作業モデルを含む、請求項11に記載のデバイス。
13. 前記作業モデルが、登録作業負荷、インパルス作業負荷、等時性作業負荷、パルス作業負荷、ベストエフォート作業負荷、スケジュール作業負荷、またはそれらの組合せを含む、請求項12に記載のデバイス。
14. 新しい作業要求を受信するための手段
    をさらに含む、請求項11に記載のデバイス。
15. 新しい作業要求を任意の保留作業要求とアグリゲートするための手段と、
    前記新しい作業要求と前記保留作業要求とに基づいてリソース状態を判断するための手段と
    をさらに含む、請求項14に記載のデバイス。
16. 前記リソース状態を前記リソースに適用するための手段と、
    前記作業要求を実行するための手段と
    をさらに含む、請求項15に記載のデバイス。
17. 前記クライアントハンドルを破棄したいという要求を受信するための手段
    をさらに含む、請求項16に記載のデバイス。
18. 前記クライアントハンドルを破棄するための手段
    をさらに含む、請求項17に記載のデバイス。
19. 前記リソースが前記作業要求を実行することができない場合、従属リソースにディペンデンシ要求を発行するための手段
    をさらに含む、請求項11に記載のデバイス。
20. 従属リソースが利用不可能である場合、トリガイベントを出力するための手段
    をさらに含む、請求項19に記載のデバイス。
21. プロセッサであって、前記プロセッサは、
    クライアントを作成したいという要求を受信することと、
    リソースが前記要求に適合するかどうかを判断することと、
    前記リソースが前記要求に適合するとき、クライアントハンドルを返信することと
    を行うように動作可能である、プロセッサ
    を含む、デバイス。
22. 前記要求が作業モデルを含む、請求項21に記載のデバイス。
23. 前記作業モデルが、登録作業負荷、インパルス作業負荷、等時性作業負荷、パルス作業負荷、ベストエフォート作業負荷、スケジュール作業負荷、またはそれらの組合せを含む、請求項22に記載のデバイス。
24. 前記プロセッサが、
    新しい作業要求を受信すること
    を行うようにさらに動作可能である、請求項21に記載のデバイス。
25. 前記プロセッサが、
    新しい作業要求を任意の保留作業要求とアグリゲートすることと、
    前記新しい作業要求と前記保留作業要求とに基づいてリソース状態を判断することと
    を行うようにさらに動作可能である、請求項24に記載のデバイス。
26. 前記プロセッサが、
    前記リソース状態を前記リソースに適用することと、
    前記作業要求を実行することと
    を行うようにさらに動作可能である、請求項25に記載のデバイス。
27. 前記プロセッサが、
    前記クライアントハンドルを破棄したいという要求を受信すること
    を行うようにさらに動作可能である、請求項26に記載のデバイス。
28. 前記プロセッサが、
    前記クライアントハンドルを破棄すること
    を行うようにさらに動作可能である、請求項27に記載のデバイス。
29. 前記プロセッサは、
    前記リソースが前記作業要求を実行することができない場合、従属リソースにディペンデンシ要求を発行すること
    を行うようにさらに動作可能である、請求項21に記載のデバイス。
30. 前記プロセッサは、
    従属リソースが利用不可能である場合、トリガイベントを出力すること
    を行うようにさらに動作可能である、請求項29に記載のデバイス。
31. プロセッサにより実行可能な命令を記録するプロセッサ読み取り可能な記録媒体において、
    クライアントを作成したいという要求を受信するための少なくとも1つの命令と、
    リソースが前記要求に適合するかどうかを判断するための少なくとも1つの命令と、
    前記リソースが前記要求に適合するとき、クライアントハンドルを返信するための少なくとも1つの命令と
    を記録する、記録媒体。
32. 前記要求が作業モデルを含む、請求項31に記載の記録媒体。
33. 前記作業モデルが、登録作業負荷、インパルス作業負荷、等時性作業負荷、パルス作業負荷、ベストエフォート作業負荷、スケジュール作業負荷、またはそれらの組合せを含む、請求項32に記載の記録媒体。
34. 新しい作業要求を受信するための少なくとも1つの命令
    をさらに記録する、請求項31に記載の記録媒体。
35. 新しい作業要求を任意の保留作業要求とアグリゲートするための少なくとも1つの命令と、
    前記新しい作業要求と前記保留作業要求とに基づいてリソース状態を判断するための少なくとも1つの命令と
    をさらに記録する、請求項34に記載の記録媒体。
36. 前記リソース状態を前記リソースに適用するための少なくとも1つの命令と、
    前記作業要求を実行するための少なくとも1つの命令と
    をさらに記録する、請求項35に記載の記録媒体。
37. 前記クライアントハンドルを破棄したいという要求を受信するための少なくとも1つの命令
    をさらに記録する、請求項36に記載の記録媒体。
38. 前記クライアントハンドルを破棄するための少なくとも1つの命令
    をさらに記録する、請求項37に記載の記録媒体。
39. 前記リソースが前記作業要求を実行することができない場合、従属リソースにディペンデンシ要求を発行するための少なくとも1つの命令
    をさらに記録する、請求項31に記載の記録媒体。
40. 従属リソースが利用不可能である場合、トリガイベントを出力するための少なくとも1つの命令
    をさらに記録する、請求項39に記載の記録媒体。

Images