JP2013544006A - Minimizing resource latency between processor application states in portable computing devices by scheduling resource set migration - Google Patents

Abstract

  A resource state set corresponding to the application state is maintained in memory. A request may be issued to a processor operating in a first application state corresponding to the first resource state set to transition to a second application state corresponding to the second resource state set. A start time for starting the resource transition to the state indicated by the second resource state set is scheduled based on the estimated amount of processing time until the transition is completed. A process is started in which the state of the resource is switched from the state indicated by the first resource state set to the state indicated by the second resource state set. Scheduling the process to start at a time that can complete the process just in time so that the processor can use the resource state as soon as it enters the second application state minimizes the negative effects of resource latency. Contribute to.

Description

US Provisional Patent Application 61 / 425,677 filed December 21, 2010 entitled "METHOD AND SYSTEM FOR RAPID ENTRY INTO AND FOR RAPID EXITING FROM SLEEP STATES FOR PROCESSORS OF A PORTABLE COMPUTING DEVICE" The benefit from the filing date of the US Provisional Patent Application No. 61 / 544,927, filed October 7, 2011, entitled “MINIMIZING RESOURCE LATENCY BETWEEN PROCESSOR APPLICATION STATES BY SCHEDULING RESOURCE SET TRANSITIONS”. Claimed by the specification, which are hereby incorporated by reference in their entirety. This application relates to co-pending U.S. Patent Application No. __________ filed under `` MINIMIZING RESOURCE LATENCY BETWEEN PROCESSOR APPLICATION STATES IN A PORTABLE COMPUTING DEVICE BY USING A NEXT-ACTIVE STATE SET '' This application is a co-pending U.S. Patent Application No. 13 / 069,071, filed March 22, 2011 entitled `` METHOD AND SYSTEM FOR RAPID ENTRY INTO AND FOR RAPID EXITING FROM SLEEP STATES FOR PROCESSORS OF A PORTABLE COMPUTING DEVICE ''. Both applications are assigned to the assignee of the present application.

  Portable computing devices ("PCD") are becoming a necessity for people at the individual and professional level. These devices may include cellular phones, personal digital assistants (“PDAs”), portable game consoles, palmtop computers, and other portable electronic devices.

  PCDs typically have complex and compact electronic packaging that is typically made from multiple processing units including a central processing unit, digital signal processor, and the like. Most of this hardware can be part of a System-on-a-chip (“SOC”) design as will be appreciated by those skilled in the art.

  Conventional PCDs often encounter significant delay times when each processor in various SOCs attempts to enter a low power state. In a low power state, the processor or similar subsystem is not executing an application program or is otherwise in an idle state, and such a low power state is also referred to as a sleep state, as will be appreciated by those skilled in the art.

  One problem faced by conventional processors is that some communication usually occurs in software because the processor goes to sleep. This problem is further complicated by the fact that some resources are shared resources that need to coordinate state across multiple SOC subsystems.

  Within a given subsystem of the SOC, the management of local resources is usually easy and can be done from the idle state of the respective operating system. However, to manage the shutdown of a shared resource, the state often has to be coordinated by the resource's controller. Conventional solutions have addressed this shutdown complexity by using a synchronous handshake in software before the subsystem is allowed to go to sleep. This approach is disadvantageous for several reasons: Software handshaking is slow. Software handshaking is prone to all kinds of delays, especially interrupt service and context switching problems.

  Software handshaking delays power savings. Since handshaking is in software, the instruction processing core needs to be maintained until all handshaking is complete. This is very disadvantageous in terms of power savings because the processor core is large and complex.

  Therefore, what is needed in the art is a method and system for allowing a PCD processor to go to sleep without a software handshake.

  A method and system for managing application states such as sleep state and active state of a portable computing device are described. A resource state set corresponding to the application state is maintained in memory. A request is issued to a processor operating in the first application state corresponding to the first resource state set to transition from the first application state to the second application state corresponding to the second resource state set. Can be done. A start time for starting the resource transition to the state indicated by the second resource state set is scheduled based on the estimated amount of processing time until the resource transition is completed. At the scheduled start time, a process is initiated in which the state of one or more resources is switched from the state indicated by the first resource state set to the state indicated by the second resource state set. Scheduling a process that transitions resource state to start at a time when the processor can complete the process just in time so that the resource state is available as soon as it enters the second application state. Contributes to minimizing adverse effects.

  In the drawings, like reference numerals refer to like parts throughout the various figures unless otherwise specified. For reference numbers with a letter designation such as “102A” or “102B”, the letter designation may distinguish between two similar parts or elements present in the same figure. Character designation of reference numbers may be omitted if the reference number is intended to encompass all parts having the same reference number in all figures.

1 is a functional block diagram illustrating one embodiment of a portable computing device (PCD). FIG. 3 is a functional block diagram illustrating a relationship between a controller, system power manager, master processor, low level driver, shared resource, and local resource. It is a functional block diagram which shows the detail regarding a controller and a trigger set. FIG. 6 illustrates an exemplary active / sleep trigger set for a processor. 6 is a logic flowchart illustrating a method for managing a trigger set and separately moving a processor from a first application state such as an awake state to a second application state such as a sleep state. 6 is a logic flowchart illustrating a method for managing a trigger set and separately moving a processor from a second application state such as a sleep state to a third application state such as an awake state. It is a functional block diagram of a controller buffer memory. FIG. 6 is a logic flow diagram illustrating an alternative method for transitioning a processor from a first application state such as an awake state to a second application state such as a sleep state. It is a functional block diagram of an alternative controller buffer memory. FIG. 6 is a logic flow diagram illustrating another alternative method for transitioning a processor from a first application state such as an awake state to a second application state such as a sleep state. It is a timeline showing a race condition between processes related to two requests. 12 is a timeline showing the results of an exemplary method for mitigating the race condition of FIG. FIG. 7 is a logic flow diagram similar to FIG. 6 illustrating a method for transitioning a processor from a sleep application state to an awake application state, including scheduling a process that changes a resource state. FIG. 6 is a logic flow diagram illustrating a method for mitigating a race condition when scheduling a process that changes a resource state. FIG. 6 is a timeline showing a race condition between processes associated with scheduled and unscheduled requests. FIG. 16 is a timeline illustrating the results of an exemplary method for mitigating the race condition of FIG. FIG. 16 is a timeline showing the results of a second exemplary method for mitigating the race condition of FIG. FIG. 17 is a timeline showing the results of another exemplary method for mitigating the race condition of FIG. FIG. 5 is a timeline showing portions of processing or work associated with transitioning to a resource state set. It is a timeline which shows the state of wasted power when the actual work is completed earlier than scheduled. FIG. 21 is a timeline showing the results of an exemplary method for mitigating the wasted power state of FIG. FIG. 18 is a timeline similar to FIG. 17 showing a work portion. 6 is a logic flow diagram illustrating a method for scheduling a process associated with handling multiple resource state set transition requests.

  The word “exemplary” is used herein to mean “serving as an example, instance, or illustration”. Any aspect described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects.

  As used herein, the term “application” may include files with executable content, such as object code, scripts, bytecodes, markup language files, and patches. In addition, an “application” as referred to herein may include files that are not inherently executable, such as documents that may need to be opened, or other data files that need to be accessed.

  The term “content” may also include files with executable content, such as object code, scripts, bytecodes, markup language files, and patches. In addition, “content” as referred to herein may include files that are not inherently executable, such as documents that may need to be opened or other data files that need to be accessed.

  As used herein, the terms “component”, “database”, “module”, “system”, etc., refer to hardware, firmware, a combination of hardware and software, software, and running software. Rather, it is intended to refer to a computer-related entity. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, an execution thread, a program, and / or a computer. By way of illustration, both an application running on a computing device and the computing device can be a component. One or more components may exist within a process and / or thread of execution, localizing one component to one computer, and / or distributed among two or more computers It is possible. In addition, these components can execute from various computer readable media having various data structures stored thereon. Each component is one or more data packets (e.g., data from one component that interacts with another component in a distributed system, and / or the Internet via a signal, etc. via a signal). It can communicate via a local process and / or a remote process, such as following a signal having data from one component interacting with other systems on the network.

  As used herein, the terms “communication device”, “wireless device”, “wireless telephone”, “wireless communication device”, and “wireless handset” are used interchangeably. The emergence of third-generation (“3G”) and fourth-generation (“4G”) wireless technologies has expanded the available bandwidth so that more portable computing with more wireless capabilities The device is available.

  As used herein, the term “portable computing device” (“PCD”) is used to describe any device that operates from a limited capacity power source, such as a battery. Although battery-powered PCDs have been used for decades, the technological advancement of rechargeable batteries brought about with the advent of third-generation (`` 3G '') and fourth-generation (`` 4G '') wireless technologies Enables multiple PCDs with multiple functions. Thus, the PCD may be a laptop computer having a cellular phone, satellite phone, pager, PDA, smartphone, navigation device, smart book or reader, media player, combination of devices described above, and a wireless connection, among others.

FIG. 1: Elements of PCD 100 for Minimizing Resource Latency Between Processor Application States Referring to FIG. 1, this diagram illustrates a method and system for managing the rapid sleep states of processors 110, 126 within PCD 100. FIG. 2 is a functional block diagram of an exemplary, non-limiting aspect of PCD 100 in the form of a wireless telephone to implement As shown, PCD 100 includes an on-chip system 102 that includes a first central processing unit (“CPU”) 110A that is multi-core, a second CPU 110B that is a single-core type, and an analog signal processor 126.

  These three processors 110A, 110B, and 126 may be coupled. The first CPU 110A can include a zeroth core 222, a first core 224, and an Nth core 230, as will be appreciated by those skilled in the art. In an alternative embodiment, instead of using two CPUs 110, two digital signal processors ("DSPs") can be used as will be appreciated by those skilled in the art. In further exemplary embodiments, any of the foregoing may be used in combination, as will be appreciated by those skilled in the art.

  FIG. 1 includes one or more controller modules 101. In the remainder of this description, controller module 101 is referred to as controller 101 in the singular rather than plural. One skilled in the art will recognize that the controller 101 can be divided into various parts and executed by different processors 110, 126 without departing from the invention. Alternatively, the controller 101 can be organized as a single element and executed by a single processor 110 or 126.

  FIG. 1 also shows a system power manager 157. A system power manager (“SPM”) 157 is coupled to the CPU 110A and the controller 101. The SPM 157 generally includes hardware such as a processor. However, software and / or firmware may be used for the SPM 157 as will be appreciated by those skilled in the art. The SPM 157 may serve to monitor the status of the processors 110, 126 and buses. The SPM 157 can detect when the processors 110, 126 are about to enter or exit the sleep state. The SPM 157 can communicate these states of the processors 110 and 126 to the controller 101. More generally, the SPM 157 can detect when the processors 110, 126 are about to transition from one application state to another application state. The application state of the processors 110, 126 is the sleep state in which the processors 110, 126 are effectively idle, not running application programs, and the awake or active state running one or more application programs. In addition or alternatively, any of the following states may be included. A state in which the processors 110 and 126 are operating and operating at a faster speed or a slower speed than when operating in another state. A state defined by the processors 110 and 126 executing the application program, which is different from another state defined by the processors 110 and 126 executing another application program. A state defined by processors 110 and 126 that are executing a certain number of application programs simultaneously, and a state that is different from another state defined by processors 110 and 126 that are concurrently executing a different number of application programs .

  The controller 101 can include software executed by the CPU 110. However, the controller 101 may be formed from hardware and / or firmware, as will be appreciated by those skilled in the art.

  In general, the controller 101 can serve to facilitate the processors 110, 126 to quickly enter and exit the sleep state. The controller 101 can include one or more tables comprising resource sets and trigger sets, as described in more detail below with respect to FIG. Controller 101 may have its own interrupt controller (not shown) for when all other hardware elements in PCD 100 are placed in a low power state and are not functioning.

  Controller 101 also manages resource requests between one or more master processors 110, 126. The resource request may be issued by the master processor 110 requesting an action or function by the resource 105 (see FIG. 2).

  Resource 105, described more generally below, includes, for example, clocks and other low-level processors that support the tasks, commands, and features of software applications executed by one or more master processors 110, 126. Can be included. The controller 101 may be designed to prevent resource request contention between multiple master processors 110, 126.

  FIG. 1 shows that the PCD 100 can include a memory 112. The controller 101 operating on the CPU 110 accesses the memory 112 to facilitate a quick sleep state and to facilitate a quick exit from the sleep state, as described in further detail below. Can do.

  In certain aspects, one or more of the method steps described herein may be implemented by executable instructions and parameters stored in memory 112 that forms controller 101. These instructions that form controller 101 may be executed by CPU 110, analog signal processor 126, or another processor. Further, the processors 110, 126, memory 112, instructions stored in the memory 112, or combinations thereof, may operate as a means for performing one or more of the method steps described herein.

FIG. 1: Other Elements of PCD 100 As shown in FIG. 1, a display controller 128 and a touch screen controller 130 are coupled to the digital signal processor 110. A touch screen display 132 external to the on-chip system 102 is coupled to the display controller 128 and the touch screen controller 130.

  FIG. 1 shows a video coder / decoder (“codec”) 134, for example, a phase inversion line (“PAL”) encoder, a sequential color memory (“SECAM”) encoder, and a national television standards committee (“NTSC”) encoder. FIG. 6 is a schematic diagram illustrating one embodiment of a portable computing device (PCD) that includes a video encoder 134, or any other type of video encoder 134. Video codec 134 is coupled to multi-core central processing unit (“CPU”) 110. A video amplifier 136 is coupled to the video encoder 134 and the touch screen display 132. Video port 138 is coupled to video amplifier 136. As shown in FIG. 1, a universal serial bus (“USB”) controller 140 is coupled to CPU 110. A USB port 142 is coupled to the USB controller 140. A subscriber identity module (SIM) card 146 may also be coupled to the CPU 110. Further, as shown in FIG. 1, a digital camera 148 may be coupled to the CPU 110. In the exemplary embodiment, digital camera 148 is a charge coupled device (“CCD”) camera or a complementary metal oxide semiconductor (“CMOS”) camera.

  As further shown in FIG. 1, a stereo audio codec 150 may be coupled to the analog signal processor 126. Further, an audio amplifier 152 may be coupled to the stereo audio codec 150. In the exemplary embodiment, first stereo speaker 154 and second stereo speaker 156 are coupled to audio amplifier 152. FIG. 1 shows that a microphone amplifier 158 can also be coupled to the stereo audio codec 150. In addition, a microphone 160 may be coupled to the microphone amplifier 158. In certain aspects, a frequency modulation (“FM”) radio tuner 162 may be coupled to the stereo audio codec 150. An FM antenna 164 is coupled to the FM radio tuner 162. Further, a stereo headphone 166 can be coupled to the stereo audio codec 150.

  FIG. 1 further illustrates that a radio frequency (“RF”) transceiver 168 may be coupled to the analog signal processor 126. An RF switch 170 may be coupled to the RF transceiver 168 and the RF antenna 172. As shown in FIG. 1, a keypad 174 may be coupled to the analog signal processor 126. A mono headset 176 with a microphone can also be coupled to the analog signal processor 126. Further, a vibrator device 178 can be coupled to the analog signal processor 126. FIG. 1 also illustrates that a power source 180 such as a battery is coupled to the on-chip system 102. In certain aspects, the power source 180 includes a DC power source derived from a rechargeable DC battery or an AC-DC converter connected to an alternating current (“AC”) power source.

  As shown in Figure 1, touch screen display 132, video port 138, USB port 142, camera 148, first stereo speaker 154, second stereo speaker 156, microphone 160, FM antenna 164, stereo headphones 166, RF Switch 170, RF antenna 172, keypad 174, mono headset 176, vibrator 178, thermal sensor 157B, and power supply 180 are external to on-chip system 102.

  Some of the above elements of PCD 100 may include hardware, while others may include software, and some may include a combination of hardware and software. The term “resource” is used herein to refer to any such element that can be controlled by a processor, whether hardware, software, or a combination thereof. The A resource may be defined in one aspect as an encapsulation of the functionality of such an element. Except where otherwise indicated, the term “processor” or “master processor” is used herein to refer to a processor such as the first CPU 110A, the second CPU 110B, and the analog signal processor 126. Or used to refer to any other processor, controller or similar element operating under the control of software, firmware or similar control logic. As described in more detail below, an example of a resource is a software element that executes on a processor. For example, a thread of execution for a processor, such as a thread associated with an executing application program, can access a resource by causing a “request” for the resource.

  In different application states, it may be necessary or desirable for the processor to request various configurations or states of resources. For example, the bus resource can control the speed of the bus clock. In one application state, the processor can request a bus clock that allows the processor to operate at a pace of, for example, 100 MIPS (MIPS: 1 million instructions per second), while in another application state, the processor A bus clock that allows the processor to operate at a pace of 150 MIPS can be requested. For a processor that is preparing to enter an application state that is in the sleep state, the processor can request a bus clock of zero MIPS. Similarly, in one application state defined by the processor executing the first application program, the processor can request 100 MIPS, while another application state defined by the processor executing the second application program Then the processor can request 150MIPS. Similarly, in one application state defined by a processor that simultaneously executes a certain number of application programs, the processor may require 100 MIPS, while a second defined by a processor that simultaneously executes a different number of application programs. In the application state, the processor can request 150 MIPS. The above bus clock is intended only as an example of a resource that can be configured by the processor issuing the resource request, and the numbers “100” and “150” are intended as arbitrary examples of processing speed I want you to understand.

  Resource configurations or states may be grouped into resource state sets. A resource state set defines the configuration or state of one or more resources that are used together by a processor in a processor application state. For example, a set of resource states may include configuration or state information regarding bus clock resources that provide a processor with a certain number of MIPS processing speeds, and configuration or state regarding a decoder that provides the processor with a decoding function (i.e., another example of a resource). Information can be included.

  FIG. 2 is a functional block diagram showing a relationship among the controller 101, the system power manager 157, the master processors 110 and 126, the low-level driver 103, the shared resources 105A to 105C, and the local resources 105D to H that form the system 103. is there. FIG. 2 also illustrates how the touch screen 132 can be coupled to the touch screen driver / controller 130. Touch screen driver / controller 130 may be coupled to clock code 113A of first master processor 110A.

  The system 103 can switch between the set of resource states desired by the processor 110 to minimize resource latency. The term “resource latency” refers to the time when the master processor 110, 126 begins to prepare the controller 101 and system power manager 157 to transition to another resource state set, and configures that set of resources to the specified state. Refers to the delay or latency that occurs in the time it takes to become ready to be used by the processor. As will be described later, resource state sets can be broadly classified as follows. An active resource state set in which the processor is provided with resources configured to assist the processor in executing application programs and providing processing power in other ways. And a sleep resource state in which the processor is provided only with resources to help maintain the processor in a sleep state, i.e., the processor is not executing application programs or otherwise providing processing power. A processor that is in a sleep state maintains low-level functionality, but the processor does not execute software that is understood by those skilled in the art to be an application program. It should be understood that the “next active state” feature described below may apply to transitions between any set of resource states, whether active set or sleep set.

  In the exemplary embodiment shown in FIG. 2, the first master processor 110A may be coupled to the system power manager 157 and the controller 101. The controller 101 may be coupled to the clock code 113A of the first master processor 110A. The controller 101 can include one or more low level drivers 103. One or more low-level drivers 103 can serve to communicate with one or more shared resources 105A-C. Shared resources 105A-C may include any type of device that supports the tasks or functions of master processor 110. Shared resources 105A-C can include devices such as graphical processors, single functional elements such as decoders and clocks of other processors.

  Shared resources 105A-C may be coupled to one or more local resources 105D-H. One or more local resources 105D-H may be similar to shared resources 105A-C in that they may include any type of device that supports or assists with the tasks or functions of master processor 110. Local resources 105D-H may include devices such as a graphical processor, a single functional element such as a decoder, and other processor clocks. Local resources 105D-H can include leaf nodes. A leaf node will be understood by those skilled in the art as local resources 105D-H that typically do not reference or include other dependent resources 105.

  The controller 101 can serve to manage requests issued from one or more master processors 110, 126. For example, the controller 101 can manage requests originating from the first master processor 110A. The first master processor 110A can issue this request in response to the operator operating the touch screen 132. The touch screen 132 can send signals to the touch screen driver / controller 130. Then, the touch screen driver / controller 130 can output a signal to the clock code 113A of the first master processor 110A.

  The controller 101 can also serve to manage the sleep state of a particular processor 110. Prior to entering the sleep state, the processor 110 provides information for managing the sleep state. Information for managing the sleep state includes entering and exiting the sleep state. This information for managing the sleep state is hereinafter referred to as trigger and resource state. The resource state set can include resource information for configuring one or more resources to support a processor sleep state.

  A trigger can define an event that causes processor 110 to either enter or exit a sleep state. A trigger generally refers to a resource state that is contained within or accessible by the controller 101. The resource state defines the desired state of the resource 105 that a particular processor 110 needs. In an exemplary embodiment, each processor 110 may provide at least two resource state sets to the controller 101: an active set of resource states and a sleep set of resource states. However, in other embodiments, the processor provides a resource state set in addition to a single active set and a single sleep set, or a resource state set different from a single active set and a single sleep set. can do. Such other resource state sets may correspond to one or more of the processor application states described above. That is, for any application state, the processor can provide a corresponding set of resource states.

  In the exemplary embodiment, the active set of resource states may define the state of resource 105 for when processor 110 is actively executing a processing function and requesting an action / function from resource 105. The sleep set of resource states can define the state of the resource 105 when the processor 110 is in the sleep state or idle state. Triggers and resource states are described in more detail below with respect to FIG.

  FIG. 3 is a functional block diagram showing details regarding the controller 101, resource set 304, and trigger set 314. As described above, the controller 101 may include software executed by one or more of the processors 110, 126 of the PCD 100. The controller 101 may store information in the memory 112 or in an area within the controller 101 such as local storage as will be appreciated by those skilled in the art. This information can include a resource table 302 that includes a resource set 304 assigned to each master processor 110 serviced by the controller 101. This information can also include a trigger set 314 that can be unique to each master processor 110, also assigned to each master processor 110.

  Each resource set 304 generally includes information related to the state of the resource 105 desired by a particular master processor 110. Each resource set 304 assigned to a particular master processor 110 can include an active resource set 306 and a sleep resource set 308. The active resource set 306 can define or describe the state of the resource 105 when a particular master processor 110 is active or functioning normally. The sleep resource set 308 may define or describe the state of the resource 105 when a particular master processor is in a sleep state or hibernation state as will be understood by those skilled in the art. Each resource set 304 may also include additional sets such as “Set 1” and “Set 2” assigned to the first master processor 110 in the exemplary embodiment shown in FIG.

  As an example, the active resource set 306 of the first master processor (A) 110A shown in FIG. In the case of the first shared resource (SR # 1) 105A, the value is 1, the value of the second shared resource (SR # 2) 105B is 1, and the Nth shared resource (SR # N) 105C Is 1, while the four values of the first local resource (LR # 1) 105D are 1, 0, 1, and 1.

  As described above, the state of the resource 105 is not limited to a single value, and can include a plurality of values. In addition, the state of the resource can include any of several different types of parameters. For example, the state can specify hundreds of megahertz for the amount of clock speed of a particular clock that can serve as the resource 105.

  As another example, the sleep resource set 308A of the first master processor (A) 110A shown in FIG. In the case of the first shared resource (SR # 1) 105A, this resource is assigned a value of 0, and the second shared resource (SR # 2) 105B has an assigned value of 0, while the Nth shared resource Resource (SR # N) 105C has an assigned value of 0. The first local resource (LR # 1) 105D may have assigned values of 0, 1, 0 and 0.

  Each trigger set 314 assigned to a particular master processor 110 may include at least three fields: an interrupt field 316, “from set” 318, and “to set” 320. Each of these three fields of the trigger set 314 can also include a corresponding set of three columns: a trigger start column 322, a clear column 324, and a timer column 326.

  Interrupt field 316 describes actions or activities that may be generated and / or detected by system power manager 157. The interrupt field 316 can generally be characterized as a “trigger event”, which allows the controller 101 to select a specific set of resources 304 desired by a particular processor 110 based on the trigger event detected by the SPM 157. . Selection of the resource set 304 by the controller 101 can avoid the time consuming software handshake described above in the background section.

  In examining the first trigger set (trigger set # 1) of FIG. 3 for the first master processor (A) 110A, the fields of the set will be discussed in order by column. Beginning with the first column of trigger set 314A, trigger start column 322 has an action labeled “Decode Interrupt” in the first row corresponding to interrupt field 316.

  As described above, the interrupt field 316 can define a parameter that causes the controller 101 to activate the state of the resource set 304 in response to detecting the trigger start field 322. In the exemplary embodiment shown in FIG. 3, interrupt field 316A is defined or described as a “decode interrupt”, for example when PCD 100 detects video when system power manager 110 detects a “decode interrupt”. This means that this event may alert the controller 101 to examine the “From Set” field 318 in the first column 322A1 in the “Trigger Start” column.

  The “From Set” field 318 may include a value indicating the current resource set 304 that applies to the particular master processor 110 being examined by the controller 101. This field 318 may describe the resource set 304 by its identifier, eg, “active set”, “sleep set”, or set number such as “set 1” or “set 2”. Field 320 may contain “wildcards” such as asterisks.

  The wildcard designation in the “From Set” field 318 allows the controller 101 to retrieve the last known active resource set 304 that was used by a particular master processor 101. In the exemplary embodiment shown in FIG. 3, the trigger start column 322A1 of “From Set” row 318A has an asterisk or wildcard value.

  “To Set” 320 is similar to “From Set” 318 and describes Resource Set 304 by identifier, eg “Active Set”, “Sleep Set”, or Set Number like “Set 1” or “Set 2” Can be included. Field 320 may also include a “wildcard” such as an asterisk, meaning the last resource set 304 being utilized by processor 110. In the exemplary embodiment shown in FIG. 3, the trigger start column 322A1 of the “To Set” field 320A has a value of “Set 1” which is the resource set 1 described in the column 310A of the first resource set 304A. Have.

  In the example shown in FIG. 3, the decoding interrupt event alerts the controller 101 when detected by the SPM 157. The controller 101 examines the first trigger set of the first master processor 110. Since the trigger start column 322A1 describes the matching value (decoding interrupt), the controller 101 examines the “from set” field 318A and determines that the value is a wildcard value or an asterisk. The controller 101 then examines a “to set” field 320A having a value of “set 1” specifying a particular resource set 304A. Based on this information examined by the controller 101, the controller 101 switches the current resource set 304A of the first master processor 110A from the current set to the resource set “set 1”. Resource set 1 is described in column 310A of resource set 304A assigned to first master processor 110A.

  Further, when SPM 157 or controller 101 detects a “non-decode” event as shown in clear column 324A1 of the first trigger set, controller 101 examines “from set” field 318A and this value is “set 1”. Is included. Controller 101 then examines “to set” field 320, which in this example has a wildcard or asterisk value. This means that the controller 101 switches the resource set 304A of the first master processor 110A from the “set 1” resource set to the last active resource set used by the processor 110A.

  The trigger set timer field 326 may indicate the amount of time that a particular resource set 304 may be used by the controller 101. Thus, in the exemplary embodiment shown in FIG. 3, for the first trigger set timer field 326A1, this field has a value of 3 milliseconds. This means that when the decode interrupt event matches the trigger start field 322A1 of the first trigger set, the controller 101 will use the resource set 304 specified in the "To Set" field 320A for only 3 milliseconds. To do. In another exemplary embodiment, the value corresponds to a value indicating that there is no information in timer field 326, or that there is no timer trigger 326 for this transition, and that the transition applies only to non-decoding fields. A situation may occur or exist where is defined. In the situation where timer fields as shown in FIG. 3, ie timer fields 326A1 and 326A2, are defined, the transition usually begins regardless of which event first occurs between timer field 326 and clear field 324.

  FIG. 4 shows an exemplary active / sleep trigger set 314 of the processor 110. In the exemplary embodiment, interrupt field 316 in first column 322 defines a “shutdown” event as an action that initiates sleep set 308 (FIG. 3) for a particular processor 110. The “shutdown” event may include an action such as an operator selecting an on / off button to shut down the PCD 100.

  In the exemplary embodiment of FIG. 4, controller 101 causes current active resource set 306 to transition to sleep set 308 when a “shutdown” event is detected. The sleep set 308 is described in the master resource set 304 of the table 302 in FIG.

  When the controller 101 receives a message from the SPM 157 indicating that a “rise” event such as a power-on event initiated by the operator of the PCD 100 has occurred, the controller will enter the “to set” field 320 of the trigger set 314. The processor 110 is moved from the sleep set 308 to the last active resource set 304 based on the wildcard or asterisk value described in FIG.

  As described above, the system 103 is not limited to the active set 306 and the sleep set 308. The system 103 may be used to switch between resource sets 304 in events other than entering or exiting a sleep state, as shown in FIG.

  FIG. 5 is a logic flow diagram illustrating a method 500 for managing the trigger set 314 for putting the processor 110 to sleep. Block 505 is the first step of method 500. At block 505, each processor 110 may update the trigger set 314 and resource set 304 in the controller 101 (FIGS. 1-2) as needed based on data from previous use cases of the PCD 100.

  At block 510, the processor 110 may request the SPM 157 (FIG. 2) to generate a shutdown signal to the controller 101. In block 515, the SPM 157 may send a shutdown signal to the controller 101.

  The controller 101 can receive a shutdown signal at block 520 and can activate a trigger set 314 that can be assigned to a shutdown event as shown in FIG. In the exemplary embodiment shown in FIG. 4, the shutdown signal is matched with the interrupt field 316 of the trigger set 314. Trigger set 314 instructs controller 101 to access sleep set 308 as shown in “To Set” field 320. At block 525, the controller 101 can immediately send an acknowledgment signal to the SPM 157, and the controller 101 can subsequently activate the resource set 304 referenced by the trigger set 314 that matches the shutdown signal event.

  At block 530, for each matching trigger set 314, such as matching trigger set 314 that lists the “shutdown” event in the corresponding interrupt field 316 shown in FIG. 4, the controller 101 assigns the current resource set 304 to FIG. The master processor 110A can switch to a sleep set 308 such as the sleep set 308A of the first resource set 304A.

  Next, at block 535, the controller 101 can communicate the sleep request state to the low level driver 103 as shown in FIG. The low level driver 103 can communicate the requested state to the corresponding resource 105.

  In block 540, each resource 105 can issue a shutdown signal acknowledgment to the controller 101 and SPM 157. The method 500 can then end.

  FIG. 6 is a logic flow diagram illustrating a method 600 for managing a trigger set 314 for putting the processor 110 from a sleep state to an active state. Block 605 is the first step of method 600. At block 605, a wake-up condition or wake-up event is detected by the SPM 157 or a wake-up event is detected directly by the controller 101, which may have its own interrupt controller (not shown). The exemplary embodiment may be designed such that wake-up interrupts are not detectable by SPM 157. In such an exemplary embodiment, the controller 101 can use its interrupt controller to detect them and “map” them to the sleep set requirements of the master processor 110.

  Next, at block 610, the SPM 157 can send a wake-up signal to the controller 101. In block 615, the controller 101 may receive a wakeup signal from the SPM 157 and activate one or more trigger sets 314 that match the wakeup signal. For example, the controller 101 can match the wake-up signal with a “rise” event described in the interrupt field 316 in the “active” column of the trigger set 314 of FIG. In the exemplary embodiment of FIG. 4, the “to set” field 320 in the active column 324 guides the controller to the last resource set 304 used by the current processor 110.

  Therefore, at block 620, the controller 101 changes the current resource set 304 of the processor 110 based on the matching trigger set 314. Those skilled in the art will recognize that the controller 101 cycles through all of its trigger sets that it maintains as shown in FIG.

  Next, at block 625, the controller 101 can send a wakeup acknowledgment to the SPM 157 that identifies which master processor 110 has awakened from the sleep state. Next, at block 630, each processor 110 having a matching wakeup trigger set 314 is released from the sleep state and powered by the SPM 157 and returned to the active state. The method 600 then ends.

  FIGS. 7-10 illustrate another feature referred to herein as a “next active resource state set” or “next active set”. An example of the next active set is the next awake set. The next awake set or other next active set may be used in the same manner as described above with respect to FIG. 6 and the resource set 304 after switching by the controller 101 associated with the wake-up event.

  FIG. 7 is the same as FIG. 3 in that the information stored in the controller 101 is represented. In the exemplary embodiment, controller 101 may include three memory buffers, referred to herein as “A” memory buffer 702, “B” memory buffer 704, and “C” memory buffer 706 for convenience.

  FIG. 8 is a logic flow diagram similar to FIG. 5 in that it illustrates a method 800 for placing a processor in a sleep state. Block 805 is the first step of the method 800 and is similar to block 505 described above with respect to FIG. Block 805 indicates that the processor 110 may update not only the active or awake resource state set and sleep resource state set, but also the next awake resource state set. As shown in FIG. 8, the processor stores the active set in the “A” buffer 702 (FIG. 7) of the controller 101, and stores the sleep set in the “B” buffer 704 (FIG. 7) of the controller 101. The awake set can be stored in the “C” buffer 706 (FIG. 7) of the controller 101. Other aspects of block 805 are the same as described above with respect to block 505 (FIG. 5) and will not be described here.

  Blocks 810, 815, 820, 825, 830, 835 and 840 are the same as blocks 510, 515, 520, 525, 530, 535 and 540, respectively, in FIG. 5 and will not be described here. Note that when the processor initiates shutdown, it is in an awake application state that corresponds to the awake set stored in the “A” buffer 702 (FIG. 7). The processor then enters a sleep application state corresponding to the sleep set stored in the “B” buffer 704 (FIG. 7), as described above with respect to FIG. The processor wakes up from the sleep application state in the next awake application state corresponding to the next awake set stored in the “C” buffer 706 (FIG. 7) (FIG. 6). By pre-storing the next awake set update in the “C” buffer 706 (FIG. 7) and applying them as soon as possible, the controller 101 immediately follows the resource specified by such next awake set upon a wake-up event. You can begin to configure, thereby minimizing resource latency.

  FIG. 9 relates to another exemplary embodiment, where the controller 101 does not have enough memory to store all three of the resource state sets described above simultaneously. In this embodiment, the controller 101 ′ only has an “A” buffer 902 and a “B” buffer 904, and no memory space is available for the “C” buffer. In such a case, the “A” buffer 902 is reused to store the awake set (currently current) and the next awake set at different times.

  FIG. 10 is a logic flow diagram similar to FIGS. 5 and 9 in that it illustrates a method 1000 for placing a processor in a sleep state. Block 1005 is the first step of the method 800 and is similar to block 805 described above with respect to FIG. 8, but does not include storing the next awake set in the “C” buffer. In practice, the processor can store the active set in the “A” buffer 902 (FIG. 9) of the controller 101 ′ and the sleep set in the “B” buffer 904 (FIG. 9) of the controller 101 ′, The processor proceeds to the sleep application state before reusing the “A” buffer to store the next awake set until it reaches an “unrecoverable point” (this term is understood by those skilled in the art). wait. Other aspects of block 1005 are the same as described above with respect to block 505 (FIG. 5) and will not be described here.

  At block 1008, the processor performs a step that may be referred to as a pseudo-update or virtual update of the next awake set. Note that in block 1005 above, the processor may perform the actual update of the resource state set by writing the resource state set to the “A” buffer 902 and “B” buffer 904 of the controller 101 ′. Since the controller 101 ′ receives an interrupt from the processor notifying that the buffer content has been updated, the update is actual, and the controller 101 ′ will perform the action or application of the update. . The controller 101 ′ applies the updates by performing various tasks that may be necessary to prepare the update resource state set information for use. If the sleep set in buffer “B” is updated, the controller 101 ′ prepares the updated sleep set information so that it can be used if a shutdown event or similar event that later requires a switch of the resource state set occurs. be able to. If the active set in the “A” buffer 902 is updated, the controller 101 ′ can adjust the resources accordingly. The pseudo update that the processor performs at block 1008 includes storing the update for the next awake set in the “A” buffer 902 (FIG. 9) without sending an interrupt to the controller 101 ′. Since controller 101 ′ has not received an interrupt, it has not yet applied the update that occurred in “A” buffer 902 (FIG. 9). This pseudo-update occurs after a non-recoverable point where the processor 110 requests the SPM 157 (FIG. 2) to inform the controller 101 ′ of the shutdown, and additional It is guaranteed not to update.

  Blocks 1010, 1015, 1020, and 1025 are the same as described above with respect to blocks 510, 515, 520, and 525, respectively, in FIG. 5 and will not be described here.

  Then, in block 1027, the controller 101 ′ responds to the handshake that occurs between the controller 101 ′ and the processor (blocks 1020, 1025) by checking the “A” buffer 902 (FIG. 9) for updates, Updates used in the wake-up method of FIG. 6 are stored. (It may be noted that the memory buffer is also referred to as “message RAM” because of the way interrupts are used to notify the receiving controller 101 ′ of “messages” that the processor has written to the buffer.) Thus, the “A” buffer By pre-storing the next awake set in 902 (Figure 9), controller 101 'can immediately begin configuring the resource specified by such next awake set in response to a wake-up event, thereby waiting for a resource. Time can be minimized.

  Blocks 1030, 1035, and 1040 are the same as blocks 530, 535, and 540, respectively, in FIG. 5 and will not be described here. The processor then correspondingly enters the sleep application state corresponding to the sleep set stored in the “B” buffer 904 (FIG. 9), as described above with respect to FIG. The processor wakes from the sleep application state in the next awake application state corresponding to the next awake set stored in the “B” buffer 904 (FIG. 9) (FIG. 6). By pre-storing the next awake set and applying it as soon as possible, controller 101 'can immediately begin configuring the resource specified by such next awake set in response to a wake-up event, thereby Latency can be minimized.

FIGS. 11-23 illustrate another feature related to scheduling the above resource set migration. Those skilled in the art understand that in many cases such changes in the processor application program state can occur at a relatively predictable period. For example, in the PCD 100 (FIG. 1), a processor executing a video player application program may or may not be able to decode a frame of video data periodically (e.g., every X milliseconds). It may be necessary to wake up during the transition. Similarly, the processor controlling the cellular telephone function of the PCD 100 may wake, for example, in a state where the processor can periodically inspect RF communication signals (e.g., every X milliseconds) or during transition to such a state. It may be necessary to up. The time at which the application program state changes periodically can be predicted, and the amount of time required for the resource to complete the transition to the state corresponding to the next application program state is substantially fixed or constant. As such, the time required to begin the process of switching the resource state set can be predicted. For example, a processor may be predicted to need to have a set of resources in a state indicated by an exemplary resource state set (“R”) at time t _deadline . This example resource state set “R” may specify changing the bus clock resource to, for example, 100 MHz and changing the power supply resource to, for example, 3V. The amount of time (“work_time”) required for the controller 101 to confirm that the bus clock resource and the power resource have completed these transitions can be determined. (The term “work” refers to the processing, configuration and hardware control that the controller 101 must perform to achieve resource state transition.) Thus, the resource state set “R” by the time t _deadline In this example, the controller 101 is in the process of migrating the bus clock and power resources by a time at which the amount of time before t _deadline is at least equal to work_time (e.g., Steps 530 and 535 in FIG. 5, steps 830 and 835 in FIG.

  In PCD 100, two or more processors (e.g., master processors 110A, 110B, 110C, etc. in FIG. 2) may require a resource state set transition at times that are fairly close to each other, which causes controller 101 to While performing the task of migrating resources, it is necessary to simultaneously perform the task of migrating resources of another processor. Similarly, another element, such as SPM 157, may request a resource state set transition while the controller 101 is performing the task of migrating resources or is scheduled to perform the task of migrating resources. In the exemplary embodiment, such a “race” condition is undesirable because the controller 101 cannot perform these tasks simultaneously.

FIG. 11 is a timeline showing an example of the above-described race condition. The approximate time for the controller 101 to start the following scheduling method and detect a race condition is labeled “t _now ”. In the example shown in FIG. 11, the controller 101 has these resources in the requested state at time t _start _0 because the resources are in the state requested by the first processor at time t _deadline _0. It is determined that it is necessary to start a process or work ("work_0") for migrating. Similarly, controller 101 is the process in which controller 101 transitions these resources to the requested state at time t _start _1 because the resources are in the state requested by the second processor at time t _deadline _1. Alternatively, it is determined that work ("work_1") needs to be started. It can be noted that the overlap between work_0 and work_1 represents a race condition.

FIG. 12 shows a method for alleviating the race condition shown in FIG. 11 in a timeline format. To mitigate contention, the controller may schedule work_0 to complete before starting work_1. Thus controller 101, t _start _1 (i.e., modified deadline t _deadline _0 ') in order to complete the work _0 before, modification time t _start to begin the step of shifting these resources to state requests _0 'is calculated by the following formula.
t _start _0 '= t _deadline _0- (t _deadline _1-task_1)
It can be noted that t _{start —} 0 ′ in the above calculation is contrasted with t _now .

  FIG. 13 is a logic flow diagram illustrating a method 1300 for transitioning the processor 110 from a sleep application state corresponding to a sleep resource state set to an active application state corresponding to an active resource state set. The method 1300 is similar to the method 600 described above in FIG. 6 except that the method 1300 includes the step of scheduling a process or task that the controller 101 performs for a resource state change or transition. Blocks 1305, 1310, and 1315 are the same as blocks 605, 610, and 615, respectively, in FIG. 6 and will not be described here. At block 1318, the controller 101 schedules a resource state set transition for one or more processors that periodically change the application state at the discretion of the controller 101. As described above, an expected change in application state has an associated deadline for the complete transition of the resources of the resource set corresponding to the next application state. This scheduling step requires the amount of time it takes for the resource state set transition to complete ("work"), and thus the controller 101 must initiate a migration process or "work" to complete the transition by the deadline. A step of calculating time may be included. This scheduling step may also include mitigating scheduling contention in the manner described above or using alternative methods. Blocks 1320, 1325 and 1330 are the same as blocks 620, 625 and 630, respectively, and will not be described here.

FIG. 14 is a logic flow diagram illustrating a method 1400 that may be included in block 1318 of FIG. 13 for scheduling resource state set transitions. Block 1405 indicates that the controller 101 may evaluate the following equation:
t _deadline _x-work_x <t _deadline _y
Here, x and y are indexes representing two resource state transition requests (for example, from the first processor x and the second processor y), and x> y.
If the expression evaluates to false, there is no race condition between the two requests and the method ends. If the expression evaluates to true, there is a race condition of the type described above with respect to FIG. If it is determined that a race condition exists, the controller 101 can calculate the correction start time by the following formula in order to reduce the race.
t _start _x '= t _deadline _x- (t _deadline _y-work_y)
The controller 101 can use the modified start time instead of the originally scheduled resource state set transition start time.

The method for mitigating scheduling contention can also consider unscheduled resource state set transition requests. As mentioned above, scheduled resource state set transition requests occur periodically or include predictable requests. An unscheduled resource state set transition request results in an unpredictable event, such as the user performing an action that causes the PCD 100 to wake up one or more processors using the touch screen 132 (Figure 2) Can occur as Unscheduled requests do not have an associated deadline ("t _deadline ") at which the resource state set transition must be completed. In practice it is only concerned with pointing to the time to complete ("t _done ") if the resource state set transition is initiated at a particular time.

Figure 15 shows that the controller 101 begins processing the unscheduled resource state set transition request, i.e., as soon as the request occurs at t _{non-scheduled_1} , and requests until the resource state set transition completes at t _{done_1} It is a timeline which shows that a race condition may arise when work with respect to is continued. Note that the processing of scheduled requests beginning at t _start _0 and ending at t _deadline _0 (“Work_0”) overlaps with the processing of unscheduled requests (“Work_1”).

  FIG. 16 is a timeline illustrating a simple exemplary method for mitigating the race condition of FIG. To alleviate the race condition, the controller 101 can first migrate resources associated with scheduled requests and then migrate resources associated with unscheduled requests.

FIG. 17 is a timeline illustrating a second simple exemplary method for mitigating the race condition of FIG. To alleviate the race condition, the controller 101 can first migrate resources associated with scheduled requests and then migrate resources associated with unscheduled requests. However, unlike the method shown in Figure 16, the delay of unscheduled work is enabled by having work _0 start t _start _0 advanced to t _start _0 'so that work _1 can be completed early. To avoid.

FIG. 18 is a timeline illustrating another exemplary method for mitigating the race condition of FIG. To alleviate the race condition, the controller 101 can first calculate the correction start time with the following formula:
t _start _1 = (t _deadline _0-work_0) -t _now

The controller 101 can begin a subset or portion of work to migrate resources associated with unscheduled requests at the modification start time t _{start —} 1. Then, at t _{start —} 0, the controller 101 stops the work of migrating resources associated with unscheduled requests and instead switches to migrating resources associated with scheduled requests. After the controller 101 completes the migration of resources associated with the scheduled request at t _{deadline_0} , the controller 101 can return to the task of migrating the resources associated with the unscheduled request.

FIG. 19 illustrates that the work or processing involved in the resource transition associated with the resource state set change request can often be divided into subsets or portions “work ₀ ” to “work _N ”. The work or processing involved in migrating resources associated with resource state set changes can involve many individual tasks. Thus, the controller 101 can easily stop temporarily the process of transitioning to another resource state set between such individual tasks. For example, the portion of processing or work that occurs between t _{start —} 1 and t _{start —} 0 in FIG. 18 may include one or more such individual tasks.

FIG. 20 is a timeline showing that a subset or portion of work may be completed earlier than scheduled, and as a result, work may be completed at t _done earlier than the deadline t _deadline . As a result, power can be wasted as a result of resources involved in the task of consuming power faster than necessary to meet the deadline (as understood by those skilled in the art).

FIG. 21 illustrates an exemplary method for mitigating the wasted power state of FIG. To alleviate the situation, a subset or portion of the work that follows the subset or portion of the work that was completed earlier may be postponed or “deferred”. "Working _{N + 1",} in order to avoid the work power influence of by changing the resources in after the "work _N", may be postponed until the scheduled completion time of "work _N".

Figure 22 shows more fully the concept of individual tasks, for example, indicates that the work ₂ _1 is a partial may be performed between the t _start _1 and t _start _0. Note that such tasks can be performed in any suitable order, as some of the individual tasks involved in migrating resources in the resource state set are independent of other tasks. Thus, for example, work if it can be shown as involved in continuous task 19, to perform the work ₂ _1 prior work ₀ _1, no adverse effect to perform tasks discontinuously There is also. Note also that the lengths of the individual tasks or parts may not be equal to each other. Therefore, one of the individual tasks or portions such as the work ₂ _1, the time interval between t _start _1 and t _start _0 example shown in FIG. 22, the rest of the of the resource status set migration If they fit well, the controller 101 can optimize the method by executing the parts in such an order. In general, it may be desirable to perform as much work as possible for the resource state set transition as soon as possible. Therefore, executing the longer part that just fits the time interval between t _start _1 and t _start _0 in the example shown in FIG. 22 executes the shorter part in the interval, resulting in t _start _0 It may be preferable to leave no gaps just before the work is not performed.

  FIG. 23 is a logic flow diagram illustrating a method 2300 for scheduling resource state transition processing. Method 2300 more generally conveys the concept that more than two requests, scheduled or unscheduled, may need to be processed simultaneously. (For clarity, the methods described above with respect to FIGS. 11-22 relate to the processing of just one or two requests and the possibility of a race condition between them.)

Method 2300 begins at state 2305, which may be reached as a result of any of the following conditions occurring: The controller 101 has finished processing or work related to transitioning the resource state in response to the request. The controller 101 receives an unscheduled resource state set transition request. Alternatively, the controller 101 determines that the scheduled start time (“t _start ”) for processing the resource state transition is approaching. In block 2310, which represents the beginning of the method 2300, the controller 101 determines whether any processing or work is scheduled. As described above, such processing or work can be scheduled to start at periodic intervals, but the scheduled start time can be modified to mitigate race conditions.

If the controller 101 determines that it is time to perform such a scheduled process or task (“t _now ”), the controller 101 performs the process or task as indicated by block 2315. If the controller 101 determines that it is not time to perform any scheduled processing or work, the controller 101 may process the pending unscheduled request as indicated by block 2320. There can be more than one pending unscheduled request. Also, unscheduled requests can have priorities associated with them. If two or more unscheduled requests are pending, the controller 101 determines the portion of the highest priority pending unscheduled request from then to the next scheduled work start time (t _start ). Work on. The next start time t _start _next is as follows.
t _start _next = (t _deadline _next-work_next) -t _now
Note that t _start _next in the above calculation is contrasted with t _now .

  When controller 101 completes a process or work for a portion of work associated with an unscheduled request (see FIG. 19), controller 101 determines whether the process or work includes additional parts, as indicated by block 2325. Determine whether. If there are additional parts, the controller 101 operates on the next part in the same manner as described above with respect to block 2320. The term “top priority” above refers to a prioritization scheme that may be included in some embodiments. For example, unscheduled requests that result from a user "turning off" PCD 100, i.e., starting a low power state through touch screen 132 (Fig. 1), are lower than other unscheduled requests A priority may be assigned.

  Of course, certain steps of the process or process flow described herein may occur before other steps so that the present invention functions as described. However, the present invention is not limited to the described order of steps if the order or order of such steps does not change the function of the present invention. That is, some steps may be performed before or after other steps, or steps may be performed in parallel (substantially simultaneously) without departing from the disclosed systems and methods. It should be appreciated that it may be performed. In some cases, certain steps may be omitted or not performed without departing from the method as will be appreciated by those skilled in the art. Furthermore, terms such as “after”, “next”, “next” are not intended to limit the order of the steps. These terms are only used to guide the reader through the description of exemplary methods.

  In view of the above disclosure, those skilled in the art of programming can write computer code or identify appropriate hardware and / or circuitry, for example, based on the flowcharts and associated descriptions herein, and the disclosed invention. Can be easily implemented. Thus, disclosure of a specific set of program code instructions or detailed hardware devices is not deemed necessary to properly understand how the present invention should be made and used. Inventive features of the claimed process implemented by a computer are described in more detail in the above description and in conjunction with the drawings, which may show various process flows.

  In one or more exemplary aspects, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on a computer-readable medium as one or more instructions or code. Computer-readable media can include any available non-transitory media that can be accessed by a computer. By way of example, and not limitation, such computer readable media can be in the form of RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or instructions or data structures. Any other medium that can be used to carry or store the desired program code and that can be accessed by the computer can be included.

  As used herein, disk and disc include compact disc (“CD”), laser disc, optical disc, digital versatile disc (“DVD”), flexible disc, and Blu-ray disc. The disk normally reproduces data magnetically, and the disc optically reproduces data with a laser. Combinations of the above should also be included within the scope of computer-readable media.

  Although selected embodiments have been illustrated and described in detail, it will be understood that various substitutions and modifications may be made in each embodiment without departing from the spirit and scope of the invention as defined by the following claims. Let's be done.

100 PCD
101 Controller module, controller
102 On-chip system
103 Low-level driver, system
105 Resources
105A ~ C Shared resources
105A First shared resource (SR # 1)
105B Second shared resource (SR # 2)
105C Nth shared resource (SR # N)
105D ~ H Local resource
105D first local resource (LR # 1)
110 processor, CPU, master processor, digital signal processor, multi-core central processing unit (“CPU”)
110A First central processing unit (“CPU”), processor, first master processor (A)
110B Second CPU, processor, master processor
110C master processor
112 memory
113A clock code
126 processors, analog signal processors, master processors
128 display controller
130 Touch Screen Driver / Controller
132 Touch screen display, touch screen
134 Video coder / decoder (`` codec ''), video encoder
136 Video amplifier
138 video port
140 Universal Serial Bus (“USB”) controller
142 USB port
146 Subscriber Identification Module (SIM) card
148 Digital camera, camera
150 stereo audio codecs
152 audio amplifier
154 1st stereo speaker
156 Second stereo speaker
157 System Power Manager (“SPM”)
157B thermal sensor
158 Microphone amplifier
160 microphone
162 Frequency modulation (“FM”) radio tuner
164 FM antenna
166 Stereo headphones
168 radio frequency (“RF”) transceivers
170 RF switch
172 RF antenna
174 keypad
Mono headset with 176 microphone
178 Vibrator device, vibrator
180 power
222 0th core
224 1st core
230 Nth core
302 Resource table
304 resource set, master resource set
306 Active resource set, active set
308 Sleep resource set, sleep set
314 Trigger set
316 Interrupt field
318 From Set field,
320 To Set field
322 Trigger start column, trigger start field
324 Clear column, clear field, active column
326 Timer column, timer field, timer trigger
702 “A” memory buffer, “A” buffer
704 “B” memory buffer, “B” buffer
706 “C” memory buffer, “C” buffer
902 "A" buffer
904 'B' buffer

Claims (28)

A method for managing an application state of a portable computing device having at least one processor and a plurality of processor resources comprising:
Maintaining a first resource state set and a second resource state set in memory;
Requesting a processor operating in a first application state corresponding to the first resource state set to transition from the first application state to a second application state corresponding to the second resource state set Making a request;
Schedule the start time for starting the resource transition to the state indicated by the second resource state set based on the estimated amount of processing time until the resource transition to the state indicated by the second resource state set is completed Steps,
Starting a process of switching a state of one or more resources from a state indicated by the first resource state set to a state indicated by the second resource state set at a scheduled start time . The first resource state set is a sleep resource state set corresponding to a sleep application state of the processor;
The method of claim 1, wherein the second resource state set is an active resource state set corresponding to an active application state of the processor.   The method of claim 1, wherein the steps of scheduling a start time and starting the process of switching states are performed by a controller. The step of scheduling the start time is
Between a first process that switches state associated with a first request issued to a first processor and a second process that switches state associated with a second request issued to a second processor Determining whether a race condition exists in the
2. The method of claim 1, comprising mitigating the race condition by modifying a start time if it is determined that a race condition exists.   The step of modifying the start time is modifying the start time of one of the first process and the second process, so that the processing time associated with the first process is associated with the second process. 5. The method of claim 4, comprising the step of not overlapping with the processing time to be performed.   Modifying a start time includes modifying the start time of one of the first process and the second process so that any of the second processes is executed before the first process is executed. 6. The method of claim 5, comprising performing a first portion of the second process and executing a second portion of the first process after at least a portion of the second process is performed. the method of.   The portable computing device comprises at least one of a cellular phone, a satellite phone, a pager, a personal digital assistant (PDA), a smartphone, a navigation device, a smart book or reader, a media player, and a laptop computer having a wireless connection. The method of claim 1 comprising: A computer system for managing an application state of a portable computing device having at least one processor and a plurality of processor resources comprising:
Including a processing entity, the processing entity comprising:
Maintaining a first resource state set and a second resource state set in memory;
Requesting a processor operating in a first application state corresponding to the first resource state set to transition from the first application state to a second application state corresponding to the second resource state set Making a request;
Schedule the start time for starting the resource transition to the state indicated by the second resource state set based on the estimated amount of processing time until the resource transition to the state indicated by the second resource state set is completed Steps,
Starting a process of switching the state of one or more resources from the state indicated by the first resource state set to the state indicated by the second resource state set at a scheduled start time A computer system that is operable on. The first resource state set is a sleep resource state set corresponding to a sleep application state of the processor;
9. The computer system of claim 8, wherein the second resource state set is an active resource state set corresponding to an active application state of the processor.   9. The computer system of claim 8, wherein the step of scheduling a start time and the step of initiating the process of switching states are performed by a controller. The step of scheduling the start time is
Between a first process that switches state associated with a first request issued to a first processor and a second process that switches state associated with a second request issued to a second processor Determining whether a race condition exists in the
9. The computer system according to claim 8, further comprising: relieving the race condition by correcting a start time when it is determined that a race condition exists.   The step of modifying the start time is modifying the start time of one of the first process and the second process, so that the processing time associated with the first process is associated with the second process. 12. The computer system according to claim 11, comprising a step of not overlapping with a processing time to be performed.   Modifying a start time includes modifying the start time of one of the first process and the second process so that any of the second processes is executed before the first process is executed. The method of claim 11, comprising performing a first portion of the first process and executing a second portion of the first process after at least a portion of the second process is performed. Computer system.   The portable computing device comprises at least one of a cellular phone, a satellite phone, a pager, a personal digital assistant (PDA), a smartphone, a navigation device, a smart book or reader, a media player, and a laptop computer having a wireless connection. 9. The computer system according to claim 8, comprising: A computer system for managing an application state of a portable computing device having at least one processor and a plurality of processor resources comprising:
Means for managing an application state of a portable computing device having at least one processor and a plurality of processor resources, the means comprising:
Means for maintaining a first resource state set and a second resource state set in memory;
Requesting a processor operating in a first application state corresponding to the first resource state set to transition from the first application state to a second application state corresponding to the second resource state set Means for making a request;
Schedule the start time for starting the resource transition to the state indicated by the second resource state set based on the estimated amount of processing time until the resource transition to the state indicated by the second resource state set is completed Means for
Means for initiating a process of switching the state of one or more resources from the state indicated by the first resource state set to the state indicated by the second resource state set at a scheduled start time; Including computer system. The first resource state set is a sleep resource state set corresponding to a sleep application state of the processor;
The computer system of claim 15, wherein the second resource state set is an active resource state set corresponding to an active application state of the processor.   The computer system of claim 15, wherein the means for scheduling a start time and the means for initiating the process of switching states includes a controller. Said means for scheduling a start time comprises:
Between a first process that switches state associated with a first request issued to a first processor and a second process that switches state associated with a second request issued to a second processor Means for determining whether or not a race condition exists,
16. The computer system of claim 15, comprising means for mitigating the race condition by modifying a start time if it is determined that a race condition exists.   The means for correcting a start time corrects a start time of one of the first process and the second process so that a processing time associated with the first process is equal to the second process. 19. The computer system of claim 18, comprising means for avoiding overlap with processing time associated with the process.   The means for correcting a start time corrects the start time of one of the first process and the second process before any of the second processes are executed. Means for causing a second part of the first process to be executed after a first part of the first process is executed and at least a part of the second process is executed; The computer system according to claim 19.   The portable computing device comprises at least one of a cellular phone, a satellite phone, a pager, a personal digital assistant (PDA), a smartphone, a navigation device, a smart book or reader, a media player, and a laptop computer having a wireless connection. The computer system of claim 15, comprising: A computer program comprising computer readable program code, the computer readable program code being executed to implement a method for managing an application state of a portable computing device having at least one processor and a plurality of processor resources. In a computer program adapted to:
Maintaining a first resource state set and a second resource state set in memory;
Requesting a processor operating in a first application state corresponding to the first resource state set to transition from the first application state to a second application state corresponding to the second resource state set Making a request;
Schedule the start time for starting the resource transition to the state indicated by the second resource state set based on the estimated amount of processing time until the resource transition to the state indicated by the second resource state set is completed Steps,
Starting a process of switching a state of one or more resources from a state indicated by the first resource state set to a state indicated by the second resource state set at a scheduled start time; Computer program. The first resource state set is a sleep resource state set corresponding to a sleep application state of the processor;
23. The computer program according to claim 22, wherein the second resource state set is an active resource state set corresponding to an active application state of the processor.   23. The computer program product of claim 22, wherein the step of scheduling a start time and the step of initiating the process of switching states are performed by a controller. The step of scheduling the start time is
Between a first process that switches state associated with a first request issued to a first processor and a second process that switches state associated with a second request issued to a second processor Determining whether a race condition exists in the
23. The computer program according to claim 22, further comprising the step of relieving the race condition by correcting a start time when it is determined that a race condition exists.   The step of modifying the start time is modifying the start time of one of the first process and the second process, so that the processing time associated with the first process is associated with the second process. 26. The computer program according to claim 25, further comprising a step of not overlapping with a processing time to be performed.   Modifying a start time includes modifying the start time of one of the first process and the second process so that any of the second processes is executed before the first process is executed. 27. The method of claim 26, comprising performing a first portion of the second process and executing a second portion of the first process after at least a portion of the second process is performed. Computer program.   The portable computing device comprises at least one of a cellular phone, satellite phone, pager, personal digital assistant (PDA), smart phone, navigation device, smart book or reader, media player, and laptop computer having a wireless connection. 23. The computer program according to claim 22, comprising:

Images