Patent Description:
The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on a transitory or non-transitory machine-readable (e.g., computer-readable) storage medium, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).

Referring now to <FIG>, an illustrative compute device <NUM> is configured to display frames on a display114. The display <NUM> establishes a link with another component of the compute device <NUM>, such as with a graphics processor <NUM>. The display <NUM> receives images from the graphics processor <NUM> at a particular rate, such as <NUM> frames per second.

In certain cases, such as when a user is reading a document without scrolling, the compute device <NUM> determines that the same frame should be displayed multiple times. The graphics processor <NUM> may send an indication to the display <NUM> that the link between the graphics processor <NUM> and the display <NUM> will be put in a sleep state. The display <NUM> can be put into a self-refresh mode in which the display <NUM> will continue displaying the same frame. Initially, the display <NUM> may continue displaying the frame at the same frame rate, such as <NUM> frames per second. After a certain number of frames, such as <NUM> frames, the display <NUM> may change to a lower refresh rate, such as <NUM> frames per second, continuing to display the same frame. When the frame to be displayed changes, the graphics processor <NUM> may send a wake signal to the display <NUM> and continue sending frames at the initial rate of <NUM> frames per second. The display <NUM> can then continue displaying images at the initial rate of <NUM> frames per second.

It should be appreciated that reducing the frame rate can reduce the power used by the display <NUM>. By reducing the refresh rate, the display <NUM> reduces the power used driving the voltage across pixels of the display <NUM>, which can significantly reduce the power used by the display <NUM>. For example, in one embodiment, the display <NUM> may use <NUM> milliwatts on driving circuitry (e.g., timing controller <NUM> and/or source driver <NUM> shown in <FIG>) when the display <NUM> is at a refresh rate of <NUM> frames per second and may use <NUM> milliwatts on driving circuitry when the display <NUM> is reduced to a refresh rate of <NUM> frames per second in a self-refresh mode, a savings of <NUM> milliwatts. In another example, the display <NUM> may use <NUM> milliwatts on driving circuitry when the display <NUM> is at a refresh rate of <NUM> frames per second and may use <NUM> milliwatts on driving circuitry when the display <NUM> is at a refresh rate of <NUM> frames per second, a savings of <NUM> milliwatts.

The compute device <NUM> may be embodied as any type of compute device. For example, the compute device <NUM> may be embodied as or otherwise be included in, without limitation, a server computer, an embedded computing system, a System-on-a-Chip (SoC), a multiprocessor system, a processor-based system, a consumer electronic device, a smartphone, a cellular phone, a desktop computer, a tablet computer, a notebook computer, a laptop computer, a network device, a router, a switch, a networked computer, a wearable computer, a handset, a messaging device, a camera device, and/or any other computing device. The illustrative compute device <NUM> includes a processor <NUM>, a memory <NUM>, an input/output (I/O) subsystem <NUM>, data storage <NUM>, a communication circuit <NUM>, a graphics processor <NUM>, a display <NUM>, and one or more peripheral devices <NUM>. In some embodiments, one or more of the illustrative components of the compute device <NUM> may be incorporated in, or otherwise form a portion of, another component. For example, the memory <NUM>, or portions thereof, may be incorporated in the processor <NUM> in some embodiments. In some embodiments, one or more of the illustrative components may be physically separated from another component.

The processor <NUM> may be embodied as any type of processor capable of performing the functions described herein. For example, the processor <NUM> may be embodied as a single or multi-core processor(s), a single or multi-socket processor, a digital signal processor, a graphics processor, a neural network compute engine, an image processor, a microcontroller, or other processor or processing/controlling circuit. Similarly, the memory <NUM> may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. In operation, the memory <NUM> may store various data and software used during operation of the compute device <NUM> such as operating systems, applications, programs, libraries, and drivers. The memory <NUM> is communicatively coupled to the processor <NUM> via the I/O subsystem <NUM>, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor <NUM>, the memory <NUM>, and other components of the compute device <NUM>. For example, the I/O subsystem <NUM> may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations. The I/O subsystem <NUM> may connect various internal and external components of the compute device <NUM> to each other with use of any suitable connector, interconnect, bus, protocol, etc., such as an SoC fabric, PCIe®, USB2, USB3, USB4, NVMe®, Thunderbolt®, and/or the like. In some embodiments, the I/O subsystem <NUM> may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor <NUM>, the memory <NUM>, and other components of the compute device <NUM> on a single integrated circuit chip.

The data storage <NUM> may be embodied as any type of device or devices configured for the short-term or long-term storage of data. For example, the data storage <NUM> may include any one or more memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices.

The communication circuit <NUM> may be embodied as any type of interface capable of interfacing the compute device <NUM> with other compute devices, such as over one or more wired or wireless connections. In some embodiments, the communication circuit <NUM> may be capable of interfacing with any appropriate cable type, such as an electrical cable or an optical cable. The communication circuit <NUM> may be configured to use any one or more communication technology and associated protocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, near field communication (NFC), etc.). The communication circuit <NUM> may be located on silicon separate from the processor <NUM>, or the communication circuit <NUM> may be included in a multi-chip package with the processor <NUM>, or even on the same die as the processor <NUM>. The communication circuit <NUM> may be embodied as one or more add-in-boards, daughtercards, network interface cards, controller chips, chipsets, specialized components such as a field programmable gate array (FPGA) or application specific integrated circuit (ASIC), or other devices that may be used by the compute device <NUM> to connect with another compute device. In some embodiments, communication circuit <NUM> may be embodied as part of a system-on-a-chip (SoC) that includes one or more processors, or included on a multichip package that also contains one or more processors. In some embodiments, the communication circuit <NUM> may include a local processor (not shown) and/or a local memory (not shown) that are both local to the communication circuit <NUM>. In such embodiments, the local processor of the communication circuit <NUM> may be capable of performing one or more of the functions of the processor <NUM> described herein. Additionally or alternatively, in such embodiments, the local memory of the communication circuit <NUM> may be integrated into one or more components of the compute device <NUM> at the board level, socket level, chip level, and/or other levels.

The graphics processor <NUM> is configured to perform graphics calculations, such as rendering graphics to be displayed on the display <NUM>. Additionally or alternatively, in some embodiments, the graphics processor <NUM> may perform general computing tasks and/or may perform off-load tasks that the graphics processor <NUM> is well-suited for, such as large parallel operations. The graphics processor <NUM> may be embodied as any type of processor capable of performing the functions described herein. For example, the graphics processor <NUM> may be embodied as a single or multi-core processor(s), a single or multi-socket processor, a digital signal processor, a microcontroller, or other processor or processing/controlling circuit.

The display <NUM> may be embodied as any type of display on which information may be displayed to a user of the compute device <NUM>, such as a touchscreen display, a liquid crystal display (LCD), a thin film transistor LCD (TFT-LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a cathode ray tube (CRT) display, a plasma display, an image projector (e.g., 2D or 3D), a laser projector, a heads-up display, and/or other display technology.

The illustrative display <NUM> may have a variable refresh rate, such as any refresh rate between <NUM> and <NUM> frames per second (i.e., between <NUM> and <NUM> Hertz), such as <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc. In some embodiments, such as embodiments with an OLED display, the refresh rate may be as low as <NUM> frame per second.

The display <NUM> may have any suitable resolution, such as <NUM> x <NUM>, <NUM> x <NUM>, <NUM> x <NUM>, <NUM> x <NUM>, <NUM> x <NUM>, <NUM> x <NUM>, etc. The illustrative display <NUM> has three channels, one each for red, green, and blue. Each channel may be set to any <NUM>-bit value (i.e., <NUM>-<NUM>).

In some embodiments, the compute device <NUM> may include other or additional components, such as those commonly found in a compute device. For example, the compute device <NUM> may also have peripheral devices <NUM>, such as a keyboard, a mouse, a speaker, a microphone, a camera, an external storage device, etc. In some embodiments, the compute device <NUM> may be connected to a dock that can interface with various devices, including peripheral devices <NUM>.

Referring now to <FIG>, in an illustrative embodiment, the graphics processor <NUM> is connected to the display <NUM> by an interconnect <NUM>. The interconnect <NUM> may be embodied as, e.g., a cable including one or more wires, one or more electrical traces on a circuit board, one or more pins, or any other suitable interconnect. Th interconnect <NUM> may contain, e.g., one or more wires for each of several lanes, one or more wires for an auxiliary channel, one or more wires for a hot plug detect, and/or one or more wires for other connector pins. In some embodiments, there may be a wireless connection in addition to or in place of a wired interconnect <NUM>. In the illustrative embodiment, the graphics processor <NUM> and the display establish a link over the interconnect <NUM>. The interconnect <NUM> may implement a connection between the display <NUM> and the graphics processor <NUM> using any suitable signal(s) or protocols, such as DisplayPort, Embedded DisplayPort (eDP), low voltage differential signaling (LVDS), flat panel display link (FPD-Link), internal display port (iDP), etc. The graphics processor <NUM> may use a local timing circuit, such as a phase locked loop (PLL) <NUM>, to send signals to the display <NUM>.

The display <NUM> includes a timing controller <NUM>, a source driver, a display element <NUM>, and a PLL <NUM>. The timing controller <NUM> is configured to receive frames and other signals from the graphics processor <NUM>. The timing controller <NUM> may store a frame received from the graphics processor <NUM> in a local frame buffer. In some embodiments, the timing controller <NUM> may have two buffers, one of which is used to receive a frame from the graphics processor <NUM>, and one of which is used to send a frame to the source driver <NUM>.

The source driver <NUM> is configured to receive a signal from the timing controller <NUM> to write a frame on the display element <NUM>. The display element <NUM> may be embodied as any suitable display element, such as an array of pixels of liquid crystal cells. The source driver <NUM> may be embodied as, e.g., gate driver circuitry to activate a transistor to select a row (or column) of pixels, along with circuitry to apply a voltage to a column (or row) of pixels. In the illustrative embodiment, the transistor selects a single row (or column), and a voltage is applied to a single column (or row). As a result, only the pixel in the selected row and column is written to. The voltage applied may be controlled to select the amount of light to pass through the liquid crystal. For example, in the illustrative embodiment, the voltage may charge a capacitor, which causes a voltage across a liquid crystal. The voltage across the liquid crystal controls the amount of light that passes through the liquid crystal cell. In the illustrative embodiment, the source driver alternates voltage across each cell, such as each time the frame is refreshed. Such an alternating voltage may be required to prevent damage to the liquid crystal cell.

In the illustrative embodiment, the timing controller <NUM> receives a timing signal from the graphics processor <NUM> over the interconnect <NUM>. When the link between the display <NUM> and the graphics processor <NUM> is in a sleep state, the timing controller <NUM> may use a local PLL <NUM> to control timing of the timing controller <NUM>. When the link is placed into a wake state, the timing controller <NUM> can resynchronize to the signal from the graphics processor <NUM>.

It should be appreciated that the embodiment shown in <FIG> is one possible embodiment, but other configurations are possible as well. For example, in some embodiments, the display <NUM> may connect to a component other than the graphics processor <NUM>, such as to the I/O subsystem <NUM>, the processor <NUM>, a system-on-a-chip, etc. As another example, some or all of the components shown in the display <NUM> may not be included or may be included in other components. For example, in some embodiments, the timing controller <NUM> may include the source driver <NUM> and/or may not include the PLL <NUM>.

Referring now to <FIG>, in an illustrative embodiment, the compute device <NUM> establishes an environment <NUM> during operation. The illustrative environment <NUM> includes a graphics controller <NUM> and a display controller <NUM>. The various modules of the environment <NUM> may be embodied as hardware, software, firmware, or a combination thereof. For example, the various modules, logic, and other components of the environment <NUM> may form a portion of, or otherwise be established by, the processor <NUM> or other hardware components of the compute device <NUM> such as the memory <NUM>, the data storage <NUM>, etc. As such, in some embodiments, one or more of the modules of the environment <NUM> may be embodied as circuitry or collection of electrical devices (e.g., graphics controller circuitry <NUM>, display controller circuitry <NUM>, etc.). It should be appreciated that, in such embodiments, one or more of the circuits (e.g., the graphics controller circuitry <NUM>, the display controller circuitry <NUM>, etc.) may form a portion of one or more of the processor <NUM>, the memory <NUM>, the I/O subsystem <NUM>, the data storage <NUM>, the graphics processor <NUM>, the display <NUM>, and/or other components of the compute device <NUM>. For example, in some embodiments, some or all of the modules may be embodied as the processor <NUM> as well as the memory <NUM> and/or data storage <NUM> storing instructions to be executed by the processor <NUM>. For example, in the illustrative embodiment, the display controller <NUM> may include some or all of the timing controller <NUM> and the source driver <NUM>. Additionally, in some embodiments, one or more of the illustrative modules may form a portion of another module and/or one or more of the illustrative modules may be independent of one another. Further, in some embodiments, one or more of the modules of the environment <NUM> may be embodied as virtualized hardware components or emulated architecture, which may be established and maintained by the processor <NUM> or other components of the compute device <NUM>. It should be appreciated that some of the functionality of one or more of the modules of the environment <NUM> may require a hardware implementation, in which case embodiments of modules which implement such functionality will be embodied at least partially as hardware.

The graphics controller <NUM>, which may be embodied as hardware, firmware, software, virtualized hardware, emulated architecture, and/or a combination thereof as discussed above, is configured to control the graphics processor <NUM> and/or other components that interface with the display <NUM>. The graphics controller <NUM> may control parameters of the link with the display <NUM>, such as a resolution and a base refresh rate. The graphics controller <NUM> may determine that the link to the display <NUM> should be placed in a sleep state, such as when the next frame to be displayed is the same as the last frame. The graphics controller <NUM> may determine that the link to the display <NUM> should be placed in a sleep state in any suitable manner, such as based on an active application, user input, a user profile, a power profile, etc. When the graphics controller <NUM> determines that new frames should be sent to the display <NUM> again, the graphics controller <NUM> can place the link back into a wake state.

In some embodiments, the graphics controller <NUM> may need to send one or a small number of frames to the display <NUM> while the link is in the sleep state. For example, a blinking cursor may be a periodic change in the frame that does not indicate that the frame is expected to change again soon. In such embodiments, the graphics controller <NUM> may send one or a small number of frames to the display <NUM> asynchronously, by placing the link back into a wake state.

The display controller <NUM>, which may be embodied as hardware, firmware, software, virtualized hardware, emulated architecture, and/or a combination thereof as discussed above, is configured to control frames displayed on the display <NUM>. The display controller <NUM> may determine parameters of the display <NUM>, such as available resolutions, available refresh rates, a bit depth, available communication protocol, etc. The display controller <NUM> may send the parameters to another component of the compute device <NUM> to use for communication with the display <NUM>.

The display controller <NUM> is configured to manage communication with a source device, such as a graphics processor <NUM>. The display controller <NUM> may establish a link with the source device. As part of establishing a link, the display controller <NUM> may receive parameters for operation, such as a resolution and a base refresh rate, which is the refresh rate at which the source device will send frames to the display <NUM> when the link to the display <NUM> is active. It should be appreciated that the base refresh rate may be lower than a maximum refresh rate of the display <NUM> and may be higher than a minimum refresh rate of the display <NUM>. The display controller <NUM> may also receive parameters related to how to operate when the link is in a sleep state, such as a number of frames to display before reducing the refresh rate or an indication of an active application running on the compute device <NUM>. The display controller <NUM> may use the indication of the application that is active in determining how many frames to display at the base refresh rate when the display <NUM> is in the self-refresh mode.

When the link is active, the display controller <NUM> receives frames from the graphics processor <NUM> at the base refresh rate. In the illustrative embodiments, a frame may be sent as a packet, and sending the packet may not take the entire time between frames. For example, if the base refresh rate is <NUM> (with a time between frames of approximately <NUM> milliseconds), the time required to transmit the image may be less than <NUM> milliseconds, such as <NUM> milliseconds. The display controller <NUM> may store the frame in a remote frame buffer and display the frame on the display <NUM>.

The display controller <NUM> may receive an indication from the graphics processor <NUM> that the link is going to a sleep state, such as by receiving a sleep pattern from the graphics processor <NUM>. When the link is in the sleep state, the display controller <NUM> may enter a self-refresh mode to continue refreshing the display <NUM> with the last frame received from the source device.

In the illustrative embodiment, when the display controller <NUM> initially enters the self-refresh mode, the display controller <NUM> continues displaying the last frame at the base refresh rate for a pre-determined number of frames. The pre-determined number of frames may be determined based on, e.g., a number sent by the source device, an indication of the active application of the compute device <NUM>, etc. The pre-determined number of frames may be any number of frames, such as <NUM>-<NUM> frames. Once the display controller <NUM> has displayed the frame at the base refresh rate the pre-determined number of times, the display controller <NUM> switches to a reduced refresh rate. In the illustrative embodiment, the reduced refresh rate is a minimum refresh rate of the display <NUM>, such as <NUM>. It should be appreciated that, by reducing the refresh rate, the display controller <NUM> may reduce the power the display <NUM> uses. For example, the source driver <NUM> may be inactive between frames, reducing or eliminating power used by the source driver <NUM> for a large fraction of the time. It should be appreciated that waiting longer than the time between frames at the minimum refresh rate may damage the liquid crystal in a liquid crystal pixel. In other embodiments, the reduced refresh rate may be another rate between the base refresh rate and a minimum rate of the display <NUM>.

In some cases, the graphics processor <NUM> may send one or more asynchronous frames to the display <NUM> by waking up the link. The asynchronous frames may be sent when there is a small number of new frames to send, such as caused by a blinking of a cursor. In the illustrative embodiment, the display controller <NUM> does not reset the number of times the last frame has been sent to the source driver <NUM> upon receipt of an asynchronous frame in block <NUM>. Rather, the display controller <NUM> may continue using a reduced refresh rate. In other embodiments, the display controller <NUM> does reset the number of times the last frame has been sent to the source driver <NUM> upon receipt of an asynchronous frame. It should be appreciated that the asynchronous frame may be received at any time in the self-refresh mode, such as when the display controller <NUM> is writing a frame to the display element <NUM> or during the time between writing frames.

When the graphics processor <NUM> is ready to wake the link, it sends an indication to the display controller <NUM>, such as by sending a wake pattern over an auxiliary channel. It should be appreciated that the display controller <NUM> may receive an indication to exit the self-refresh mode at any time, such as when the display controller <NUM> is writing a frame to the display element <NUM> or during the time between sending frames. As such, the display controller <NUM> may need to complete the current frame refresh simultaneously with receipt of the next frame. The display controller <NUM> may write the next frame as soon as possible, such as at the maximum refresh rate. In some embodiments, the display controller <NUM> may drop a frame if a frame is received while a frame is being sent to the source driver <NUM>. After the link is placed in the wake state, the display controller <NUM> resynchronizes its internal timing generator to that of the source device, such as by recovering a clock signal from the link. Once the link is back in the wake state, the display controller <NUM> can receive the next frame and continue displaying frames at the base refresh rate.

Referring now to <FIG>, in use, the compute device <NUM> may execute a method <NUM> for low power self-refreshing of a display. In the illustrative embodiment, some or all of the method <NUM> may be performed by the display <NUM> or components of the display, such as the display controller <NUM>, the timing controller <NUM>, and/or the source driver <NUM>. The method <NUM> begins in block <NUM>, in which the compute device <NUM> determines parameters of a display <NUM>. The compute device <NUM> may determine, e.g., available resolutions, available refresh rates, a bit depth, available communication protocol, etc..

In block <NUM>, the display <NUM> establishes a link with a source device, such as the graphics processor <NUM>. As part of establishing a link, the display <NUM> may receive parameters for operation, such as a resolution. In block <NUM>, the display <NUM> receives a base refresh rate, which is the refresh rate at which the source device will send frames to the display <NUM> when the link to the display <NUM> is active. It should be appreciated that the base refresh rate may be lower than a maximum refresh rate of the display <NUM> and may be higher than a minimum refresh rate of the display <NUM>. The display <NUM> may also receive parameters related to how to operate when the link is in a sleep state, such as a number of frames to display before reducing the refresh rate or an indication of an application running on the compute device <NUM>.

In block <NUM>, the display <NUM> receives a frame from the graphics processor <NUM> at the base refresh rate. In the illustrative embodiments, a frame may be sent as a packet, and sending the packet may not take the entire time between frames. For example, if the base refresh rate is <NUM> (with a time between frames of approximately <NUM> milliseconds), the time required to transmit the image may be less than <NUM> milliseconds, such as <NUM> milliseconds. The display <NUM> may store the frame in a remote frame buffer in block <NUM>. In block <NUM>, the display <NUM> may send the frame to the source driver <NUM> to display the frame.

In block <NUM>, the display <NUM> determines whether to enter a self-refresh mode. In the illustrative embodiment, the display <NUM> determines that it should enter a self-refresh mode by receiving an indication from the graphics processor <NUM> that the link is going to a sleep state, such as by receiving a sleep pattern from the graphics processor <NUM>. In other embodiments, the display <NUM> may determine that it should enter a self-refresh mode by receiving any suitable signal or no signal at all.

In block <NUM>, if the display <NUM> is not to enter a self-refresh mode, the method <NUM> loops back to block <NUM> to receive a frame at the base refresh rate. If the display <NUM> is to enter a self-refresh mode, the method <NUM> proceeds to block <NUM> in <FIG>.

Referring now to <FIG>, in block <NUM>, the display <NUM> determines whether to display frames at a reduced refresh rate. In the illustrative embodiment, in block <NUM>, the display <NUM> determines whether the last frame has been resent to the source driver <NUM> since the display <NUM> entered the self-refresh mode at least a threshold number of times, such as <NUM> times. The threshold may be any suitable value, such as any value between <NUM> and <NUM>. If the last frame has been resent at least the threshold number of times, then the frame should be displayed at the reduced refresh rate. In some embodiments, the threshold may depend on the application of the compute device <NUM> that is currently being used. For example, a web browser may have a different threshold value than an application for viewing documents. The threshold may be determined by, e.g., the processor <NUM> based on the current application and then sent to the display <NUM>, or the display <NUM> may determine the threshold based on an indication received from the compute device <NUM> of what application is currently active.

In block <NUM>, if the display <NUM> is not to run at a reduced refresh rate, the method <NUM> proceeds to block <NUM> to resend the last frame to the source driver <NUM> at the base refresh rate. If the display <NUM> is to run at a reduced refresh rate, the method <NUM> proceeds to block <NUM> to resend the last frame to the source driver <NUM> at a reduced refresh rate. In the illustrative embodiment, the reduced refresh rate is a minimum refresh rate of the display <NUM>, such as <NUM>. It should be appreciated that, by reducing the refresh rate, the display <NUM> may reduce the power it uses. For example, the source driver <NUM> may be inactive between frames, reducing or eliminating power used by the source driver <NUM> for a large fraction of the time. It should be appreciated that waiting longer than the time between frames at the minimum refresh rate may damage the liquid crystal in a liquid crystal pixel. In other embodiments, the reduced refresh rate may be another rate between the base refresh rate and a minimum rate of the display <NUM>.

After resending the last frame at either block <NUM> or block <NUM>, the method <NUM> proceeds to optional block <NUM>. In some cases, the graphics processor <NUM> may send one or more asynchronous frames to the display <NUM> by waking the link. The asynchronous frames may be sent when there is a small number of new frames to send, such as caused by a blinking of a cursor. In the illustrative embodiment, the display <NUM> does not reset the number of times the last frame has been sent to the source driver <NUM> that was referred to in block <NUM> upon receipt of an asynchronous frame in block <NUM>. In other embodiments, the display <NUM> does reset the number of times the last frame has been sent to the source driver <NUM> upon receipt of an asynchronous frame. It should be appreciated that the asynchronous frame may be received at any time in the loop between block <NUM> and <NUM>, such as when the display <NUM> is sending a frame in block <NUM> or <NUM> or during the time between sending frames.

In block <NUM>, the display <NUM> determines whether to exit the self-refresh mode. The display <NUM> may determine to exit self-refresh mode by receiving an indication from the graphics processor <NUM> of a change of the link to a wake status, such as by receiving a wake pattern over an auxiliary channel or by receiving a new frame.

In block <NUM>, if the display <NUM> is not to exit the self-refresh mode, the display <NUM> loops back to block <NUM> to determine whether the display at the reduced refresh rate. If the display <NUM> is to exit the self-refresh mode, the display <NUM> proceeds to optional block <NUM>.

It should be appreciated that the display <NUM> may receive an indication to exit the self-refresh mode at any time, such as when sending the frame to the source driver <NUM> in block <NUM>. As such, the display <NUM> may need to complete the current frame refresh in block <NUM> simultaneously with receipt of the next frame. The display <NUM> may write the next frame as soon as possible, such as at the maximum refresh rate. In some embodiments, the display <NUM> may drop a frame if a frame is received while a frame is being sent to the source driver <NUM>.

Claim 1:
An apparatus (<NUM>) for displaying frames, the apparatus comprising:
a display (<NUM>), the display (<NUM>) comprising a display controller (<NUM>);
a source device (<NUM>);
a storage device, wherein the storage device comprises a plurality of instructions stored thereon that, when executed, causes the apparatus to determine an active application executing on the processor, wherein the active application is an application of the apparatus that is currently being used;
display controller circuitry configured to:
establish, by the display controller (<NUM>), a link with the source device (<NUM>);
receive an indication of a base refresh rate from the source device (<NUM>), wherein the base refresh rate is a refresh rate at which the source device (<NUM>) will send frames to the display when the link to the display is active;
receive a frame from the source device (<NUM>);
send, based on the base refresh rate, the frame to a source driver to display the frame;
determine whether to enter a self-refresh mode in which the display (<NUM>) will continue displaying the same frame;
resend, in response to a determination to enter the self-refresh mode, the frame to the source driver a plurality of times at a reduced refresh rate, wherein the reduced refresh rate is lower than the base refresh rate, wherein the display controller circuitry is further configured to resend, in response to the determination to enter the self-refresh mode, the frame to the source driver a plurality of times at the base refresh rate a pre-determined number of times prior to resending the frame the plurality of times at the reduced refresh rate.