Method and system for managing resources within a portable computing device

A method and system for managing requests to resources among processors of a portable computing device (“PCD”) includes each master processor identifying a plurality of resources of the PCD in a storage device, such as a message RAM. This message RAM is part of the PCD. A master processor may identify desired states for the plurality of resources in the message RAM. Then, the master processor may generate an alert that the plurality of resources and desired states for resources have been set in the message RAM. After receiving the alert, a controller may determine if one or more previous requests have been processed to completion. If so, then the controller may review the contents of the message RAM to identify the plurality of resources and to identify the desired states of the resources. If appropriate, the controller may pass the desired states to the plurality of resources.

DESCRIPTION OF THE RELATED ART

Portable computing devices (“PCDs”) are becoming necessities for people on personal and professional levels. These devices may include cellular telephones, portable digital assistants (“PDAs”), portable game consoles, palmtop computers, and other portable electronic devices.

PCDs typically have complex and compact electronic packaging that is generally made of multiple processing units that include central processing units, digital signal processors, and the like. Conventional PCD's currently use a remote procedure call (“RPC”) protocol as understood by one of ordinary skill the art. The RPC protocol manages resource requests among different processing units within a PCD. One problem with the RPC protocol is that the protocol is often very slow for managing resource requests among multiple processing units within a PCD. Another problem with the RPC protocol is that the protocol may not efficiently support low-level power states that are critical for PCDs to conserve battery power.

Accordingly, what is needed in the art is a method and system for more efficiently managing resource requests among multiple processing units within a PCD while achieving increased energy conservation. There is also a need in the art for an interprocessor communication protocol that increases the speed in which requests among processing units may be handled.

SUMMARY

A method and system for managing requests to resources among processors of a portable computing device (“PCD”) includes each master processor identifying a plurality of resources of the PCD in a storage device, such as a message RAM. This message RAM is part of the PCD. A master processor may identify desired states for the plurality of resources in the message RAM. Then, the master processor may generate an alert that the plurality of resources and desired states for resources have been set. After receiving the alert, a controller may determine if one or more previous requests have been processed to completion. If so, then the controller may review the contents of message RAM to identify the plurality of resources and to identify the desired states of the resources.

When appropriate, the controller may pass the desired states to the plurality of resources. The controller may also determine if a desired state exceeds a limit of a resource and if the desired state exceeds the limit, then the controller may adjust a value of the desired state so that the value falls within the limit of the resource.

The system also includes establishing a meta-resource comprising a table. This table may list a plurality of resources and fields that indicate whether a processor should be notified by a controller of status changes to the resources. Based on values in the meta-resource that are assigned to each master processor of the PCD, the controller may send alerts of status changes for resources to one or more processors.

DETAILED DESCRIPTION

In this description, the terms “communication device,” “wireless device,” “wireless telephone,” “wireless communication device,” and “wireless handset” are used interchangeably. With the advent of third generation (“3G”) and fourth generation (“4G”) wireless technology, greater bandwidth availability has enabled more portable computing devices with a greater variety of wireless capabilities.

In this description, the term “portable computing device” (“PCD”) is used to describe any device operating on a limited capacity power supply, such as a battery. Although battery operated PCDs have been in use for decades, technological advances in rechargeable batteries coupled with the advent of third generation (“3G”) and fourth generation (“4G”) wireless technology, have enabled numerous PCDs with multiple capabilities. Therefore, a PCD may be a cellular telephone, a satellite telephone, a pager, a PDA, a smartphone, a navigation device, a smartbook or reader, a media player, a combination of the aforementioned devices, and a laptop computer with a wireless connection, among others.

Referring toFIG. 1, this figure is a functional block diagram of an exemplary, non-limiting aspect of a PCD100in the form of a wireless telephone for implementing methods and systems for managing resources among processors110,126of the PCD100. As shown, the PCD100includes an on-chip system102that includes a multi-core, first central processing unit (“CPU”)110A, a second CPU110B that is a single-core type, and an analog signal processor126. These processors110A,110B, and126may be coupled together. The first CPU110A may comprise a zeroth core222, a first core224, and an Nth core230as understood by one of ordinary skill in the art. In an alternate embodiment, instead of using two CPUs110, two digital signal processors (“DSPs”) may also be employed as understood by one of ordinary skill in the art.

FIG. 1includes one or more controller module(s)101. For the remainder of this description, the controller module(s)101will be referred to in the singular, as a controller101, and not plural. One of ordinary skill in the art will recognize that the controller101may be divided into various parts and executed by different processors110,126without departing from the invention. Alternatively, the controller101may be organized as a single element and executed by a single processor110or126.

The controller101may comprise software which is executed by the CPUs110. However, the controller101may also be formed from hardware and/or firmware as understood by one of ordinary skill in the art.

In general, the controller101may be responsible for supporting interprocessor communications, such as managing requests for resources that originate from the CPUs110and the processor126. In one exemplary embodiment, the controller101supports an interprocessor communication protocol that manages resource requests among one or more master processors110,126. Resource requests may be issued by a master processor110to request an action or function from a resource.

Resources may include clocks and other low-level processors that support tasks, commands, and features of software applications that are executed by one or more master processors110,126. The controller101may be designed to prevent resource request conflicts among a plurality of master processors110,126.

FIG. 1shows that the PCD100may include memory or message RAM112. The controller101running on the CPUs110may access the message RAM112to manage resources105(SeeFIG. 2) as will be described in further detail below.

In a particular aspect, one or more of the method steps described herein may implemented by executable instructions and parameters stored in the memory112that form the controller101. These instructions that form the controller101may be executed by the CPUs110, the analog signal processor126, or another processor. Further, the processors,110,126, the memory112, the instructions stored therein, or a combination thereof may serve as a means for performing one or more of the method steps described herein.

FIG. 1: Other Elements of the PCD100

As illustrated inFIG. 1, the CPU110may also be coupled to one or more internal on-chip or external off-chip thermal sensors157. The on-chip thermal sensors157may comprise one or more proportional to absolute temperature (“PTAT”) temperature sensors that are based on vertical PNP structure and are usually dedicated to complementary metal oxide semiconductor (“CMOS”) very large-scale integration (“VLSI”) circuits. Off-chip thermal sensors157may comprise one or more thermistors. The thermal sensors157may produce a voltage drop that is converted to digital signals with an analog-to-digital converter (“ADC”) controller. However, other types of thermal sensors157may be employed as understood by one of ordinary skill in the art.

A display controller128and a touchscreen controller130are coupled to the digital signal processor110. A touchscreen display132external to the on-chip system102is coupled to the display controller128and the touchscreen controller130.

FIG. 1is a schematic diagram illustrating an embodiment of a portable computing device (PCD) that includes a video coder/decoder (“codec”)134, e.g., a phase-alternating line (“PAL”) encoder, a sequential couleur avec memoire (“SECAM”) encoder, a national television system(s) committee (“NTSC”) encoder or any other type of video encoder134. The video codec134is coupled to the multicore central processing unit (“CPU”)110. A video amplifier136is coupled to the video encoder134and the touchscreen display132. A video port138is coupled to the video amplifier136. As depicted inFIG. 1, a universal serial bus (“USB”) controller140is coupled to the CPU110. Also, a USB port142is coupled to the USB controller140. A subscriber identity module (SIM) card146may also be coupled to the CPU110. Further, as shown inFIG. 1, a digital camera148may be coupled to the CPU110. In an exemplary aspect, the digital camera148is a charge-coupled device (“CCD”) camera or a complementary metal-oxide semiconductor (“CMOS”) camera.

As further illustrated inFIG. 1, a stereo audio CODEC150may be coupled to the analog signal processor126. Moreover, an audio amplifier152may be coupled to the stereo audio CODEC150. In an exemplary aspect, a first stereo speaker154and a second stereo speaker156are coupled to the audio amplifier152.FIG. 1shows that a microphone amplifier158may be also coupled to the stereo audio CODEC150. Additionally, a microphone160may be coupled to the microphone amplifier158. In a particular aspect, a frequency modulation (“FM”) radio tuner162may be coupled to the stereo audio CODEC150. Also, an FM antenna164is coupled to the FM radio tuner162. Further, stereo headphones166may be coupled to the stereo audio CODEC150.

FIG. 1further indicates that a radio frequency (“RF”) transceiver168may be coupled to the analog signal processor126. An RF switch170may be coupled to the RF transceiver168and an RF antenna172. As shown inFIG. 1, a keypad174may be coupled to the analog signal processor126. Also, a mono headset with a microphone176may be coupled to the analog signal processor126. Further, a vibrator device178may be coupled to the analog signal processor126.FIG. 1also shows that a power supply180, for example a battery, is coupled to the on-chip system102. In a particular aspect, the power supply180includes a rechargeable DC battery or a DC power supply that is derived from an alternating current (“AC”) to DC transformer that is connected to an AC power source.

As depicted inFIG. 1, the touchscreen display132, the video port138, the USB port142, the camera148, the first stereo speaker154, the second stereo speaker156, the microphone160, the FM antenna164, the stereo headphones166, the RF switch170, the RF antenna172, the keypad174, the mono headset176, the vibrator178, thermal sensors157B, and the power supply180are external to the on-chip system102.

FIG. 2is a functional block diagram illustrating relationships among the controller101, master processors110,126, low-level drivers103, shared resources105A-C, and local resources105D-H. This figure illustrates a how the touchscreen132may be coupled to the touchscreen driver/controller130. The touchscreen driver/controller130may be coupled to clock code113A of a first master processor110A.

The first master processor110A may be coupled to message RAM112and the controller101. The controller101may be coupled to the clock code113A of the first master processor110A and the controller101may comprise one or more low-level drivers103. The one or more low-level drivers103may be responsible for communicating with one or more shared resources105A-C. Shared resources105A-C may comprise any type of device that supports tasks or functions of a master processor110. Shared resources105A-C may include devices such as clocks of other processors as well as single function elements like graphical processors, decoders, and the like.

The shared resources105A-C may be coupled to one or more local resources105D-H. The one or more local resources105D-H may be similar to the shared resources105A-C in that they may comprise any type of device that supports tasks or functions of a master processor110. Local resources105D-H may include devices such as clocks of other processors as well as single function elements like graphical processors, decoders, and the like. The local resources105D-H may comprise leaf nodes. Leaf nodes are understood by one of ordinary skill in the art as local resources105D-H that are not referred to or dependent upon other resources105.

The controller101may be responsible for managing requests that are issued from the one or more master processors110,126. For example, the controller101may manage a request that originates from the first master processor110A. The first master processor110A may issue this request in response to an operator manipulating the touchscreen132. The touchscreen132may issue signals to the touchscreen driver/controller130. The touchscreen driver/controller130may in turn issue signals to the clock code113A of the first master processor110A.

In the exemplary embodiment illustrated inFIG. 2, prior to first the master processor110A issuing a request to the controller101, the first master processor110A sends information to the message RAM112as will be described in further detail below. After the first master processor110A sends information to the message RAM112, then the first master processor110A issues a request to the controller101to review the information stored in message RAM112.

Based on the information contained within the message RAM112, the controller101may issue the request originating from the first master processor110A to one or more low-level drivers103. The low-level drivers103, in turn, issue commands to the one or more shared resources105A-C.

FIG. 3is a functional block diagram illustrating details about the controller101and message RAM112forming an interprocessor communication system300. The controller101may be coupled to the first master processor110A and the second master processor110B, similar to the exemplary embodiment illustrated inFIG. 2. The controller101may be coupled to these processors110A,110B by request interrupt lines109A, B and acknowledge interrupt lines107A, B.

The controller101may also be coupled to message random access memory (“RAM”)112. The first master processor110A and the second master processor110B may also be coupled to the message RAM112. While the exemplary embodiment uses the RAM type, other memory devices or a combination of memory devices may be employed as appreciated by one of ordinary skill in the art. Other memory devices include, but are not limited to, dynamic random access memory (“DRAM”) “off-chip”102, static random access memory (“SRAM”) “on-chip”122, cache memory, electrically erasable programmable read only memory (“EEPROM”), etc.

The controller101may maintain in its internal memory one or more tables307that comprise one or more configuration sets311,313. The controller's internal memory may comprise a memory device such as RAM. The one or more configuration sets311,313list various states of resources105that are associated and required by a particular master processor110.

For example, table307may comprise a first configuration set311A and a second configuration set313A that lists states for a plurality of resources105enumerated in a list309. This first configuration set311A and second configuration set313A may be assigned to the first master processor110A ofFIG. 2. Meanwhile, a third configuration set311B and fourth configuration set313B may be assigned to the second master processor110B ofFIG. 2.

Each configuration set311,313lists a state desired by a master processor110for a particular resource105. The exemplary configuration sets311,313illustrated inFIG. 3demonstrate that a particular resource105may have one or more settings for a particular state. For example, the first local resource (Local Resource #1) for the first configuration set311A as illustrated inFIG. 3comprises at least four settings. These settings may comprise numeric values that correspond to particular states of a resource105. Meanwhile, the first shared resource (#1) may only comprise a single setting for each configuration set311,313.

In the exemplary embodiment illustrated inFIG. 3, a zero may designate an “off” state while the number one may designate an “on” state. The numeric values are not limited to only binary states and may include other values, such as alpha-numeric, and numerical values in the hundreds or thousands. For example, numeric values may include settings like 100 or 200 to designate clock speeds in MHz or GHz as understood by one of ordinary skill the art.

Each first configuration set311may comprise an active set which is a default set for a particular master processor110while the processor110is operating in a normal fashion. Each second configuration set313corresponding to a master processor110may comprise a sleep set which is a set designated for low-level power consumption or a sleep state for a particular processor110. As illustrated inFIG. 3, the controller101is coupled to message RAM112. Message RAM112may include a first portion301that includes a resource status section315. The resource status section315lists the current aggregate state of all resources105that are managed by the controller101. The resource status section315in the exemplary embodiment illustrated inFIG. 3may comprise a table having a single column. This single column table lists values corresponding to the status of each resource105that may be managed by the controller101.

In the exemplary embodiment illustrated inFIG. 3, the status section315reflects that the first shared resource (#1)105A has a status value of “1”, while the second shared resource (#2)105B has a status value of “1.” The Nth shared resource (#N)105C has a status value of “0”, while the first local resource (#1)105D has four status values of “1, 0, 1, and 1” respectively. While only four resources105are illustrated in the resource status section315of the exemplary embodiment ofFIG. 3, one of ordinary skill the art recognizes that usually all resources105managed by the controller101are presented in the resource status section315.

The resource status section315may be accessed by the controller101. The controller101may write and read to the resource status section315. Meanwhile, each master processor110may only read information from the resource status section315to obtain status of resources105that are of interest to a particular processor110,126.

Message RAM112may further comprise additional portions303, also referred to as per-master regions. The per-master regions303correspond to each master processor110,126and the requests issued from a single master processor110,126.

For example, a first per-master region303A of the message RAM112may comprise sub-sections318A,333A, and336A that directly correspond with operations and requests originating from the first master processor110A. Similarly, a second per-master region303B of the message RAM112may also comprise sub-sections such as a second control section318B and as well as others (not illustrated) that are similar to the three provided in the first per-master region303A of the message RAM112.

Each per-master region303of the message RAM112tracks the state of requests from a single master processor110,126. The three sub-sections of each per-master region303within the message RAM112include a control section318, a request section333, and an acknowledgment section336.

Each control section318may comprise at least four status fields: a change request field321, a resource indication request field324, a resource indication acknowledgment field327, and a change acknowledgment field330. Both the controller101and an assigned, single master processor110or126may read and write to the fields contained within this control section. Therefore, for the first control section318A that is assigned to the first master processor110A, the first master processor110A and controller101and only the first master processor110A and controller101(not any other master110) may both read and write to the four fields321,324,327, and330of the control section318A.

The second subsection333A of the first per-master region303A of the message RAM112may comprise a request section333A. Similar to the control section318A of the first per-master region303A, only the controller101and the first master processor110A may interact with the request section333A. However, only the assigned master processor110A may write to the request section333A. The controller101may only read the values contained within the request section333A. In the exemplary embodiment illustrated inFIG. 3, the first shared resource (SR#1)105A has a request section status value of “0.” The second shared resource (SR#2)105B also has a status value of “0.” The Nth shared resource (SR#N) has a status value of “1,” while the first local resource (LR#1) has status values of four zeros.

The third subsection336B is the acknowledgment section336B. The acknowledgement section336B of the first per-master region303A lists values corresponding to previous requests made to particular resources105. Typically, the values of this acknowledgment section336B mirror the values provided in the request section333A.

FIG. 4AandFIG. 4Bare logical flowcharts400A,400B illustrating a method400for managing requests among one or more master processors110,126. Decision block405is the first step of the method400. In decision block405, the a requesting master processor110or126determines if the change request field321and resource indication request field324of the control section318in the message RAM112are equal to the value of zero. In this step, the master processor110or126is making sure a previous request that has not been completed and which originated from another processor110,126is not overwritten in message RAM112by a current request.

If the inquiry to decision step405is negative, then the “NO” branch is followed back to the beginning of block405in a loop. If the inquiry to decision block405is positive, meaning that a previous request has been processed, then the “YES” branch is followed to block410.

In block410, the required resource state for all of the requested resources105is written by a requesting master processor110or126into the request section333of the master region303of the message RAM112as illustrated inFIG. 3. Next, in block415, values are written into the resource indication request field324by a master processor110or126to indicate which resources105are being requested by the master110or126.

In block420, values are written into the change request field321of the control section318in the message RAM112to identify which configuration set311or313has been selected for the requested resources105. Next, in block425, the requesting master processor110or126transmits a request interrupt along one of the request interrupt lines109to the controller101.

In block430, the controller101receives the request interrupt from the request interrupt line109and determines which master110or126has made the request. Next, in decision block435, the controller101determines if the change acknowledgment field330and the resource indication acknowledgment field327have values of zero. In this step, the controller101is determining if a prior request is still being processed before the controller101starts to manage or process a request.

If the inquiry to decision block435is negative, then the “NO” branch is followed to block440in which the controller101sends a message back to the requesting master processor110or126that a previous request is still being processed by the system. After block440, the method400returns back to the start of block435. If the inquiry to decision block435is positive, meaning that the change acknowledgment field330and resource indication acknowledgment field327have values of zero, then the method400proceeds to block445.

In block445, the controller101reads the change request field321and the resource indication request field324of the control section318in the message RAM112in order to identify what resources105have been requested. Next, in block450, the controller101reads all relevant request states from the request section333of the message RAM112and caches (stores) these values locally within the controller101. Next, in block455, the controller101writes a zero value to the change request field321and to the resource indication field324of the control section318in the message RAM112.

The method400continues from block455to block460in which the method400resumes at process or routine block465ofFIG. 4B. The process or routine block465ofFIG. 4Bmay comprise a plurality of steps that are described in further detail below in connection withFIG. 5. In process block465, the controller101identifies the desired states for each resource105from the request originating from a master processor110or126. The controller101then passes the requested state(s) to the one or more resources105if and when appropriate.

After process or routine block465, in block470, the controller101may write a status of the resources105that were changed by the request in the change acknowledgement field330and resource indication acknowledgment field327of the message RAM112.

Next, in block475, the controller101may transmit an acknowledge interrupt along one of the acknowledge interrupt lines107ofFIG. 3to the master110or126that originated the request. In block480, the change acknowledgement field330and resource indication acknowledgment field327of the control section318of the message RAM112may be read by the master processor110or126receiving the acknowledge interrupt. These fields330and327may comprise the current values of states associated with the resources105which were requested by the master processor110or126. The master processor110or126may optionally acknowledge the state of these two fields by sending a message to the controller101.

In block485, the master processor110or126that received the acknowledge interrupt may then write zeros to the change acknowledgment field330and the resource indication acknowledgment field327of the control section318in the message RAM112to allow other master processors110or126to issue other requests to the resources105. The method400may return and start back to decision block405as described above.

FIG. 5is a logical flowchart illustrating a submethod or routine465(corresponding toFIG. 4B) for identifying states of resources105from a request and passing states to the resources105when appropriate. Block505is the first step of the submethod465. In block505, for each resource105listed in the resource indication request field324of the control section318in the message RAM112, the requested state is read by the controller101from the request section333of the master portion303of the message RAM112.

In the exemplary embodiment illustrated inFIG. 3, the first shared resource (SR#1)105A has a requested state value of zero while the second shared resource (SR#2)105B has a requested state value of zero too. The Nth shared resource (SR#N)105C has a requested state value of one, while the first local resource (LR#1)105D has four requested state values of zero.

Next, in decision block510, the controller101determines if the requested state for a particular resource105is part of a sleep configuration set311or an active configurations set313. If the inquiry to decision block510returns an “Active Set”, then the “Active Set” branch is followed to block515. If the inquiry to decision block510returns a “Sleep Set,” then “Sleep Set” branch is followed to block525.

In block515, the controller101passes the requested state to one or more low-level drivers103, which in turn, transmits the requested state to a particular resource, such as a shared resource105A-105C or a local resource105D-105G as illustrated inFIG. 2. Next, in block520, if the requested state for a resource105causes a status change to a particular resource105, the new status of the resource is written into the resource status section315of the message RAM112by the controller101.

In block525, the requested state is saved by the controller101into the resource status section315of the message RAM112. In block530, the requested state(s) are copied to the acknowledgment section336within message RAM112. The sub-method465then returns to block470ofFIG. 4B.

FIG. 6is a submethod or routine600for processing requests outside of limits for a resource105. The submethod600includes blocks which have been numbered to correspond with the numbered blocks of the method400and submethod465as illustrated inFIG. 4A,FIG. 4B, andFIG. 5. Therefore, if a numbered block of the submethod600has a value greater than a corresponding numbered block of the method400or submethod465, then the numbered block of the submethod600would occur after the corresponding numbered block of the method400or submethod465.

For example, decision block513is the first step of submethod600. Decision block513has a value which is greater than block510of submethod465and a value which is less than block515. Therefore, decision block513would occur after decision block510but before block515of submethod465as understood by one of ordinary skill in the art.

In decision block513, the controller101may determine if the requested state exceeds the limits of a resource105. For example, if a particular resource105has a maximum clock speed of 800 MHz, and the requested state is 900 MHz, then this requested state exceeds the limits of this resource105.

If the inquiry to decision block513is negative, then the “No” branch is followed and the submethod600returns to block515of submethod465inFIG. 5. If the inquiry to decision block513is positive, meaning that the requested state does exceed the limits of a particular resource105, then the “Yes” branch is followed to block518.

In block518, the controller101may determine the maximum or minimum limit of a resource105and set the resource105to an appropriate limit that is closest to the requested state. So for the example noted above, if the maximum clock speed of a resource is 800 MHz, and the requested state is 900 MHz, then the controller101will set the clock speed to the maximum value of 800 MHz which is 100 MHz less than the requested state. In block519, the controller101may set a modification flag to indicate the limit which was selected by the controller101for the requested state.

Block482follows block519since block482is now added to the method400ofFIG. 4Bafter block480. In block482, which now follows block480ofFIG. 4B, a master110or126originating an active request may read the modification flag set in block519when the when the master reads the control section318of the message RAM112ofFIG. 3. The submethod600then returns to block515ofFIG. 5.

Certain steps in the processes or process flows described in this specification naturally precede others for the invention to function as described. However, the invention is not limited to the order of the steps described if such order or sequence does not alter the functionality of the invention. That is, it is recognized that some steps may performed before, after, or parallel (substantially simultaneously with) other steps without departing from the disclosed system and method. In some instances, certain steps may be omitted or not performed without departing from the method as understood by one of ordinary skill in the art. Further, words such as “thereafter”, “then”, “next”, etc. are not intended to limit the order of the steps. These words are simply used to guide the reader through the description of the exemplary method.

For example, block530which requires the controller101copied the requested state to the acknowledgment section336of the message RAM112may be skipped entirely if the status of each resource105has not been changed. This elimination of block530may reduce processing time consumed by the controller101.

As another example, certain steps may be changed to support a multi-thread environment. Particularly, decision block435in which the change acknowledgment field330and resource indication acknowledgment field327are reviewed by the controller101may be moved or shifted just prior to block530ofFIG. 5. Similarly, additional techniques may be employed between or near steps as understood by one of ordinary skill in the art.

For example, an exponential backoff technique may be employed between block440and block435. For a controller, it is allowed to check the state of the resources105in decision block435. This means that a first pass between block440and block435may have a fixed duration of 100 milliseconds. A second pass between block440and block435may have a fixed duration of 200 milliseconds. A third pass between block440and block435may have a fixed duration of one second as understood by one of ordinary skill in the art.

FIGS. 7A-7Billustrate tables700that are part of notification meta-resources105J for processors110. The notification meta-resources105J, and particularly the tables700, may be stored and accessed in the request section333of the message RAM112. In an exemplary embodiment, each processor110or126is assigned to its own individual notification meta-resource105J, similar to the control section318, the request section333, and the acknowledgment section336which exist in each per-master region303of the message RAM112.

Each notification meta-resource105J allows a master processor110or126to sign up for receiving status reports for particular resources105that may be of interest to the master processor110. A master processor110or126may write and record in the meta-resource105J which resources105that it wants the controller101to generate status reports. The controller101reviews each meta-resource105J corresponding to each master110or126to determine if the controller101needs to send a status report regarding a resource105to a particular master processor110or126.

As illustrated inFIG. 7A, a notification meta-resource105J may comprise a first row of configuration field values which correspond with each resource105that may be available to a particular master110or126. The second row of a notification meta-resource105J may comprise a registration field values which correspond with each resource105that may be available to a particular master110or126. The configuration field defines notifications and the registration field defines how states from a primary set of notifications may be inherited.

In the exemplary embodiment illustrated inFIG. 7, the configuration field and registration field may comprise binary states: ones or zeros. A zero state in the configuration field indicates that a particular master processor110or126wishes to inherit its settings for resource change notifications. In this case, the state of the registration bit is not used, and notifications will be delivered or not based on the settings from the primary set.

A one state in the configuration field indicates that a particular master processor110or126does not want to inherit notification settings for a particular resource105, but instead will explicitly configure notifications using the registration bit. In this case, a one state in the registration field indicates that a particular master processor110or126desires to receive the notifications about changes in a particular resource105. Likewise, a zero state in the registration field indicates a desire to not receive notifications while in the current set, regardless of the setting in the primary set. Primary sets are discussed in further detail below.

A summary for the configuration and registration fields is provided in Table 1 below:

TABLE 1Summary for Configuration and Registration FieldsConfigurationRegistrationFieldFieldMeaning0XInherit settings10Do not inherit, do not receive notification11Do not inherit, receive notification

Each master processor110or126may have a plurality of notification meta-resources that are assigned to particular states of a particular master processor110or126. For example, in the exemplary embodiment illustrated inFIG. 7B, three sets of notification meta-resources105J1,105J2, and105J3may be assigned to a particular master processor110or126.

The first notification meta-resource105J1may comprise a particular master processor's primary set for notifications. The primary set may be the default set for how a particular master110or126desires to be notified for particular resources105in which the master processor110or126has an interest. Both rows of the first column of the primary set105J1have a value of one to indicate that the master processor110or126assigned to this notification meta-resource105J desires to receive notifications for the first shared resource (SR#1)105A.

Both rows of the fourth column of the primary set105J1have a value of one to indicate that the master processor110or126assigned to this notification meta-resource105J desires to receive notifications for the first local resource (LR#1)105D.

The second and third sets105J2and105J3of the notification meta-resources may comprise sleep sets as understood by one of ordinary skill in the art. For example, the configuration field in the first row of the second and third columns of the third set105J3may have a value of zero to indicate that the master processor110or126assigned to this meta-resource105J3wishes to inherit any notifications with respect to the second (SR#2)105B and third shared resources (SR#3)105C. In this example, the primary set configuration for SR#2105B and SR#3105C also indicate that no notification should be delivered. Meanwhile, the configuration field in the first row of the first and fourth columns are one to indicate that the master processor110or126assigned to this meta-resource105J3does not wish to inherit from the primary set. In this case, there will be notifications for LR#1105C since the registered bit in the second row of the fourth column is one. There will not be any notifications delivered for SR#1105A since the registered bit in the second row of the first column is zero.

The presence of two rows in a particular notification meta-resource105J is to allow differentiation between a value which has no preference (and should be therefore inherited from the primary set) and a value which has been explicitly set. Generally, a master processor110or126will configure its notifications in the primary set105J1and expect those notifications to be honored at all times. However, it is possible that the master processor110or126may want a different configuration while asleep, but only for some resources105. Therefore, a single piece of information is insufficient to construe the three possible states: inherit, explicitly register to receive additional notification in sleep, or explicitly deregister to not receive notification in sleep even if the notification would be delivered via the primary set.

FIG. 8is a logical flowchart illustrating a submethod or subroutine800for managing notification meta-resources105J. The steps of submethod800generally refer to several steps of the method400illustrated inFIGS. 4A-4B. Block436is the first step of submethod800.

Block436occurs after the “YES” branch is followed from decision block435. In block436, the controller101writes the status of the resources105to the change acknowledgment field330of the control section318of the message RAM112. This action by the controller101sets a notification flag.

While subroutine800has been described as integrated with method400, one of ordinary skill in the art recognizes that a request to the controller101is not needed in order for a notification of resource change to occur. After step435, a new state in which the status of one or more resources changes may occur if a master processor110or126requested a new state, or some state internal to the controller101changed. It is understood to one of ordinary skill in the art that notifications may originate asynchronously relative to requests made to a master processor110or126.

Next, in block446, which occurs after block445ofFIG. 4A, the controller101records which resources105have changed in the resource indication acknowledgment field327of the control section318in the message RAM112. Next, in block452/476, which occurs after steps450and475ofFIGS. 4A-4B, based on the values in the notification meta-resource105J assigned for each master processor110or126, the controller101sends an acknowledge interrupts to each interested master processor110or126. This means that block446occurs after block450ofFIG. 4Aand block475ofFIG. 4B.

Next, in block481, after step480ofFIG. 4B, the controller101reviews the resource indication acknowledgment field327of the control section318of the message RAM112and based on values in the notification meta-resource105J for each master110or126, the controller notifies interested master(s) of a status change.

Next, in block482, each master110or126reads the resource status section315of the message RAM112to learn the current state of the resources105.

In view of the disclosure above, one of ordinary skill in programming is able to write computer code or identify appropriate hardware and/or circuits to implement the disclosed invention without difficulty based on the flow charts and associated description in this specification, for example. Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer implemented processes is explained in more detail in the above description and in conjunction with the figures which may illustrate various process flows.

Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (“DSL”), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.

Disk and disc, as used herein, includes compact disc (“CD”), laser disc, optical disc, digital versatile disc (“DVD”), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.