Patent Description:
DisplayPort specifications currently do not have link power management mechanisms; however, embedded DisplayPort (eDP) specifications define a mechanism for Advanced Link Power Management (ALPM). The current eDP link management technique involves the use of wake signaling over a sideband AUX (auxiliary) interface. This technique may have one or more issues when applied to DisplayPort embodiments, however. For instance, it may require a tight coupling between the main link and the AUX interface that is unmanageable over the display topology (which may include a number of different devices, e.g., docks, branch devices, LTTPRs, etc.).

Document <CIT> relates to an apparatus for implementing a display port interface. The apparatus may include a source processor and a sink processor coupled through an interface. Document <CIT> describes techniques to transmit commands to a display device. Document <CIT> discloses a source device including an adaptive link training circuitry. Document <CIT> relates to Signal Conditioner Discovery and Control in a Multi-Segment Data Path.

Further embodiments are set forth in the dependent claims. Any references to inventions or embodiments not falling within the scope of the independent claims are to be interpreted as examples useful for understanding the invention.

In the following description, numerous specific details are set forth, such as examples of specific configurations, structures, architectural details, etc. in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that these specific details need not be employed to practice embodiments of the present disclosure. In some instances, well known components or methods may be utilized, and such details haven't been described in detail in order to avoid unnecessarily obscuring embodiments of the present disclosure.

<FIG> illustrates a block diagram of an example computing system <NUM> in accordance with certain embodiments. The example computing system <NUM> comprises a display <NUM> coupled to a video source device <NUM> (also referred to herein as a "display source" or "source") via a link <NUM>. In the example shown, the display <NUM> is coupled to a video source device <NUM> to display a representation of a video signal received from the video source device <NUM>. The display <NUM> comprises a scaler chip <NUM>, a display driver <NUM>, a panel <NUM>, and a memory <NUM>. Some embodiments may include a display with any suitable combination of components (including any of those shown or other components). Scaler chip <NUM> includes standby controller <NUM>, port input selector <NUM>, image processor <NUM>, timing controller (TCON) interface <NUM>, backlight controller <NUM>, central processing unit (CPU) <NUM>, and memory controller <NUM>.

Standby controller <NUM> is operable to manage operations associated with entry into standby and exit from standby for the display <NUM>. For example, the standby controller <NUM> may coordinate a context save and restore procedure, or the entry into and exit from standby for the display <NUM>. In various embodiments, standby controller <NUM> may coordinate with other components of display <NUM>. In some embodiments, all or a portion of standby controller <NUM> may be integrated within another component of the scaler chip <NUM>, such as the port input selector <NUM> or CPU <NUM>; or other component of the display <NUM>. Thus, in some embodiments the standby controller <NUM> may be a distinct logic component or may include a collection of logic from various components of the scaler chip <NUM> (or other components of the display <NUM>).

Port input selector <NUM> is operable to select a port from among a plurality of ports of the display <NUM> and to pass a video signal received through the port to a processing pipeline of the display <NUM>. The port input selector <NUM> may include a port interface that comprises or is coupled to a plurality of ports of the display. The display <NUM> may include any number of ports of any type. For example, display <NUM> may include a DisplayPort™ port, a High-Definition Multimedia Interface (HDMITM) port, a Universal Serial Bus (USB) port, a Digital Visual Interface (DVI) port, a Video Graphics Array (VGA) port, or other suitable port. Display <NUM> may include any suitable combination of ports, including multiple ports of the same type or multiple ports of different types. The port input selector <NUM> may include selection logic coupled to the port interface to select a particular port and to pass the signal received through the particular port on to additional logic (e.g., the standby controller <NUM>, the image processor <NUM>, etc.). In some embodiments, the port input selector <NUM> may also include conversion logic to receive a signal from any of the ports of the display <NUM> and convert the signal to a common format (e.g., a digital pixel format) for further processing.

Image processor <NUM> may receive a video signal from the port input selector <NUM> and perform further processing on the video signal. In some embodiments, the image processor <NUM> may execute one or more algorithms to improve the image quality of the video signal. For example, image processor <NUM> may perform resolution upscaling, contrast adjustment, color adjustment, or other suitable image processing. In some embodiments, image processor <NUM> may superimpose one or more images (e.g., a user menu of the display <NUM>) on the video signal.

TCON interface <NUM> may receive a processed signal from image processor <NUM> and convert the signal to a format (e.g., a serial high speed interface format such as Embedded DisplayPort™ (eDP) or V-by-One®) compatible with a TCON of the display driver <NUM>.

Backlight controller <NUM> may include a backlight driver and may generate signals that may be used by the backlight driver to produce current to light up the panel <NUM>.

CPU <NUM> may provide various functions of the display <NUM>. For example, the CPU <NUM> may manage the on-screen display and user configuration adjustments of the display <NUM>. The CPU <NUM> may communicate with other components of the display <NUM> (e.g., to bring up a menu or change the brightness of the display in response to a user selection).

Memory controller <NUM> may control the transfer of data between one or more components of the scaler chip <NUM> and the memory <NUM>. Memory <NUM> may include any suitable volatile or non-volatile memory to support the operations of the display <NUM>. For example, the memory <NUM> may be used to store instructions executed by the components (e.g., CPU <NUM>, standby controller <NUM>, image processor <NUM>, or other component), frame data (e.g., values of pixels), on-screen display data, or other suitable data. In some embodiments, memory <NUM> may comprise multiple different memory modules (e.g., each of which may be dedicated to particular types of data) located on any one or more components of the display <NUM>. For example, in various embodiments, the scaler chip <NUM> may include one or more memory modules to support the operation of the scaler chip <NUM>.

Display driver <NUM> may comprise circuitry to receive a video signal and to drive electrical signals to the display elements of the panel <NUM> to cause the panel <NUM> to display the video. In a particular embodiment, display driver may comprise a TCON. In a particular embodiment, display driver <NUM> comprises one or more row and column drivers to drive the display elements. The display driver <NUM> may include one or more digital to analog converters (DACs) to produce the appropriate currents to drive the display elements.

In various embodiments, panel <NUM> may generate light or allow for the transmission of light in a plurality of pixels. Panel <NUM> may comprise a display substrate on which a plurality of pixels are located. The pixels define a display area within which a video signal comprising still images, videos, or other content defined by a video signal can be displayed. Panel <NUM> may utilize any suitable display technology, such as, e.g., a thin-film-transistor liquid crystal display (TFT LCD), micro-light emitting diode (micro-LED), organic LED (OLED), quantum dot LED (QLED), or other suitable display technology.

The components of the display <NUM> may be arranged in any suitable manner. In one embodiment, a first printed circuit board may comprise the scaler chip <NUM> and a second printed circuit board may comprise the display driver <NUM> (in some embodiments a separate printed circuit board may house the TCON). In some embodiments, memory <NUM> or a portion thereof may be included on the first printed circuit board (or integrated on the scaler chip <NUM>).

Video source device <NUM> may be any suitable computing device to communicate a video signal to the display <NUM>. For example, video source device <NUM> may be a desktop computing system, a laptop computing system, a server computing system, a storage system, a handheld device, a tablet, or other suitable computing device.

In the embodiment depicted, video source device <NUM> comprises processor <NUM>, operating system <NUM> (which may be executed by processor <NUM>), memory <NUM>, I/O controller <NUM>, and graphics processing unit (GPU) <NUM>. Processor <NUM> is depicted as including two processing cores 134A and 134B, though the processor <NUM> may include any suitable number of cores.

The operating system <NUM> may execute a display driver <NUM> that controls the connection from the video source device <NUM> over the link <NUM> to the display <NUM> and the communication of the video signal (and supporting communications) over the connection.

The GPU <NUM> may generate the video signal that is communicated to the display <NUM>. In the embodiment depicted, the GPU <NUM> is a discrete component, though in other embodiments, the GPU <NUM> may be integrated with processor <NUM>.

Memory <NUM> may include any suitable volatile or non-volatile memory to support the operations of the display <NUM>. The memory <NUM> may be used to store instructions executed by the components (e.g., processor <NUM> or GPU <NUM>), or other suitable data. In some embodiments, memory <NUM> may comprise multiple different memory modules (e.g., each of which may be dedicated to particular types of data) located on any one or more components of the display video source device <NUM>. In some embodiments, memory <NUM> may comprise a system memory.

Link <NUM> may comprise any suitable transmission medium operable to communicate analog or digital data between the display <NUM> and the video source device <NUM>. In some embodiments, link <NUM> may comprise a cable with a connector on each end. For example, link <NUM> may comprise a DisplayPort™ cable, an HDMI™ cable, a USB cable, a DVI cable, a VGA cable, or other suitable cable. In some embodiments, the link <NUM> may be an internal connection between the video source device <NUM> and the display <NUM> (e.g., for notebook computers or other computer systems with connected or embedded displays).

In some embodiments, the link <NUM> may implement a specification-based protocol, such as a DisplayPort or Embedded DisplayPort (eDP) protocol. Current eDP specifications define a mechanism for Advanced Link Power Management (ALPM), while current DisplayPort specifications do not have link power management mechanisms. The current eDP link management technique involves the use of wake signaling over a sideband AUX (auxiliary) interface. This technique may have one or more issues, however, when applied to DisplayPort topologies. For instance, it may require a tight coupling between the main link and the AUX interface that is unmanageable over the display topology (which may include a number of different devices, e.g., docks, branch devices, LTTPRs (Link-Training Tunable PHY Repeaters), etc.). There is no current solution in DisplayPort specifications for link state power management over the display topology-i.e., once the display is on, the link must stay up and in an active state.

Embodiments of the present disclosure may provide a unified link-based mechanism for entry and exit from power managed link states in both DP and eDP topologies. In certain instances, embodiments of the present disclosure may be comparable in power to the current eDP mechanism, but may be able to be deployed for both eDP and DP topologies. In particular embodiments, for instance, a Low Frequency Periodic Signaling (LFPS) may be utilized over a main link. The LFPS does not require a handshake over the AUX interface and can therefore be applied to a DisplayPort topology. In addition, it provides a low latency and low power mechanism that can be used for eDP as well, allowing for a unified approach for link state power management for both eDP and DP topologies.

<FIG> illustrates an example sleep signaling sequence <NUM> in a DisplayPort-based topology in accordance with certain embodiments. In particular, the examples show a sleep signal pattern <NUM> that is transmitted from a DisplayPort-compatible or eDP-compatible transmitter (DPTX) <NUM> (e.g., video source device <NUM> of <FIG>) to a DisplayPort-compatible or eDP-compatible receiver (DPRX) <NUM> (e.g., display <NUM> of <FIG>) via a number of intermediate LTTPRs <NUM>-<NUM>. As per certain DisplayPort specifications (e.g., DP v2. <NUM>), a source device (e.g., source device <NUM> of <FIG>) may be required in certain instances to indicate to a sink device (e.g., display <NUM> of <FIG>) through an AUX-based DPCD (DisplayPort Configuration Data) register write operation indicating that it is turning off the main link. This can add hundreds of micro-seconds of latency, which makes this scheme unusable for quick turnoff/on between active frames. However, in embodiments of the present disclosure, source device may transmit a specific pattern or packet (e.g., as described below) on the main link that indicates the main link is transitioning to a lower power state. The source, intermediate branch/retimer (e.g., LTTPR), and sink devices may accordingly transition into low power states locally after the indication is received.

As shown in <FIG>, each device in the topology may decode the advanced link power management pattern / code sequence (e.g., pattern <NUM>, which may be a ML_PHY_SLEEP as described below), or packet and react accordingly. As there are multiple devices in the example display topology shown in <FIG>, the DPTX <NUM> and LTTPRs (<NUM>-<NUM>) may continue to transmit the link power management patterns on the main link as shown until all the devices in the topology have decoded the pattern and taken appropriate action.

For instance, the DPTX <NUM> may transmit a ML_PHY_SLEEP/_STANDBY pattern (e.g., as described below) a number of times equal to the number of devices on the link other than the source device (e.g., number of intermediate devices + display), which may be equal to one more than the number of LTTPRs in the topology (TOTAL_LTTPR_CNT + <NUM>). In the example shown, that means the DPTX <NUM> transmits the pattern <NUM> times. The DPTX may transmit each sleep pattern in <NUM> bits for 8b/10b encoding or <NUM> bits for 128b/132b encoding, and may transmit a minimum of <NUM> bits (for 8b/10b) or <NUM> bits(for 128b/132b) of scrambled zeroes <NUM> between the patterns <NUM> as shown in <FIG>, after which it may provide an output at the common mode voltage (indicated by OFF in <FIG>). The DPRX <NUM>, after receiving a ML_PHY_SLEEP/_STANDBY pattern <NUM> may turn off its high-speed receiving circuit until it senses an Low Frequency Periodic Signaling (LFPS) wake signal as described below. Intermediate LTTPRs may count the number of ML_PHY_SLEEP/_STANDBY patterns it receives/detects on its UFP, and once the number of patterns detected becomes equal to its LTTPR_CNT + <NUM>, it may provide an output at the common mode voltage on its DFP TX_PHY. For example, LTTPR8 <NUM> in <FIG> (LTTPR_CNT = <NUM>) may provide the common mode voltage after detecting <NUM> ML_PHY_SLEEP/_STANDBY patterns on the UFP 228u. The maximum latency on the ML_PHY_SLEEP transmission through the LTTPR may be no more than <NUM> bits (for 8b/10b) or <NUM> bits (for 128b/132b) bit-time.

In certain instances, the pattern used for reduced bit rate (RBR) and high bit rate (HBR) frequencies could be the same patterns used in the eDP standard for link management, as shown in Table <NUM> below. In the case of ANSI8b10b encoding, the transmitter may maintain disparity across the sequence.

An example of an advanced main link power management packet for UHBR* frequencies with 128b_132b encoding are shown in Table <NUM> below. The <NUM>-bit CDI may be set to <NUM> and XORing <NUM> of the <NUM>-bit CDIs with <NUM> for DC balancing may continue as in normal operation. The sequence shown in Table <NUM> is without pre-coding-during transmission pre-coding would be applied to the sequence, hence DC balancing may be maintained. The pattern may be transmitted starting at any <NUM>-bit Word boundary.

<FIG> illustrates an example Low Frequency Periodic Signaling (LFPS)-based sequence <NUM> in accordance with certain embodiments. The example LFPS sequence <NUM> may be transmitted by a display source (e.g., video source device <NUM> of <FIG>) over a link (e.g., link <NUM>) to a display (e.g., display <NUM> of <FIG>) to wake the display from a sleep or standby state. In certain embodiments, the LFPS sequence <NUM> may be implemented in a DisplayPort or Embedded DisplayPort (eDP)-based topology.

In certain embodiments, two low-power link states may be defined, e.g., a "ML_PHY_SLEEP" sleep state and "ML_PHY_StandBy" standby state. These link states may address a wake scenario for Decision Feedback (DFE) refresh at HBR3 (High Bit Rate <NUM>) and UHBR (Ultra High Bit Rate). In some instances, the standby state may be implemented, e.g., when the main link off time is below <NUM> uSec, and the sleep state may be implemented when the main link off time is 40uSec and above. Aspects of the example LFPS sequence <NUM> or another type of LFPS signal may be sent over the main link to exit from either of these power management link states.

The example LFPS sequence <NUM> includes segments <NUM>, <NUM>, <NUM>, <NUM>. The segment <NUM> indicates a common mode, e.g., the standby or sleep mode as described above. The segment <NUM> includes a set of low-frequency pulses that are used to indicate a transition out of the sleep or standby state. In certain embodiments, the segment <NUM> includes at least <NUM> fixed length pulses with a pulse length (tPeriod) between 25ns - 50ns, amounting to a total segment time between 175ns - 400ns. The segment <NUM> is a silent period in which no signals are transmitted. In certain embodiments, the period of silence may be defined as the lanes in Common Mode, and the silence period may be between 80nS - 120nS before a signal is transmitted in the segment <NUM>. The signal transmitted in the segment <NUM> may be a PHY link (physical link) establishment signal. For instance, in the example shown, the segment <NUM> includes a ML_PHY_LOCK or ML_PHY_LOCK_LTTPR pattern transmission. The ML_PHY_LOCK/ML_PHY_LOCK_LTTPR pattern transmission may be used for calibration, equalization, and/or activation by a display or LTTPR in certain instances.

In certain embodiments that implement reduced bit rate (RBR) or ultra high bit rate (UHBR) frequencies that use ANSI8b10b coding, the ML_PHY_LOCK pattern may include TPS4 (CP2520 Pattern <NUM>) - K28. <NUM>-, K28. <NUM>-, K28. <NUM>+, K28. <NUM>-, <NUM>00hs, and the ML_PHY_LOCK_LTTPR may include the CP2520 Pattern <NUM> with count indication of <NUM>: - K28. <NUM>-, K28. <NUM>+, K28. <NUM>+, K28. <NUM>- <NUM>00hs. In certain embodiments that implement UHBR* frequencies that use 128b/132b encoding, the ML_PHY_LOCK pattern is the same as 128b/132b_tps2 with one change where the LT_SCRAMBLER_RESET PHY sync replaces replaced every 4th PHY_SYNC_ONLY PHY sync symbol, as opposed to every 16th on the 128b/132b_tps2. This pattern may reduce wake latency in certain instances. The ML_PHY_LOCK_LTTPR pattern for 128b/132b_tps2_wake_LTTPR may be the same as the 128b/132b_tps2_wake pattern but with new coding for PHY_SYN_ONLY symbol 3355AA55h, replacing 333C3C3Ch.

In some embodiments, devices in the topology may repeat the transmission of the LFPS downstream to other devices of the topology after detecting the pulse sequence of segment <NUM>. For example, an upward facing port (UFP) in a branch device (e.g., LTTPR_UFP) may transmit or repeat the LFPS to the next downstream device once a threshold number of pulses (e.g., <NUM>) are detected. Table <NUM> below indicates example LFPS Parameters that may be implemented. In some eDP topology embodiments, the LPFS may use lower clock frequencies (e.g., <NUM>) to reduce power with increased latency.

<FIG> illustrates an example LFPS-based wake sequence <NUM> in accordance with certain embodiments. The example wake sequence <NUM> may be transmitted by a display source (e.g., video source device <NUM> of <FIG>) over a link (e.g., link <NUM>) to a display (e.g., display <NUM> of <FIG>) to wake the display from a sleep or standby state. In certain embodiments, the wake sequence <NUM> may be implemented in a DisplayPort or Embedded DisplayPort (eDP)-based topology. In the example shown, the wake sequence <NUM> includes three segments <NUM>, <NUM>, <NUM>, followed by a transmission of data on the link.

The first segment <NUM> includes a pulse sequence similar to segment <NUM> of <FIG>. In the example shown, the pulse sequence of segment <NUM> includes seven pulses in a period of 166ns - <NUM> ns. However, any suitable number of pulses and timing may be implemented in other embodiments. In certain embodiments, the pulse sequence may be repeated sequentially over each hop of a topology starting at the display source and ending with the last hop terminating in the display. In certain embodiments, the sequential wake sequence may takes about <NUM>-<NUM> usec period per hop.

The second segment <NUM> includes a physical link (PHY) establishment signaling sequence, which may include link training information for the devices of the link between the display source and display. In the example shown, the second segment <NUM> begins with a period of silence (e.g., <NUM>-120ns) followed by a ML_PHY_LOCK / ML_PHY_LOCK_LTTPR sequence for a period t1 (e.g., 25uSec for exit from Standby and 50uSec for exit from sleep to enable DFE calibration). The silence period and period t1 may be of any suitable length of time, e.g., as shown below in Table <NUM>. In certain instances, the display source (or LTTPR UFP) may have completed CDR_DONE and EQ adjustment based on the pattern (ML_LOCK_PHY for the UFP of the most upstream LTTPR and for ML_LOCK_PHY_LTTPR for the rest of the UFP's) by the end of the PHY Establishment period t1. In certain embodiments, the PHY establishment sequence may be repeated sequentially on all the hops of the topology to reduce latency. For example, each LTTPR in the topology may transmit a locally generated ML_PHY_LOCK_LTTPR pattern on its downward facing port (DFP).

The third segment <NUM> includes a sequential clock and data switch (CDS) sequence, which may be used to establish a clock signal (e.g., from the GPU) in the topology and may be when the symbol and lane alignment occur. The CDS period t2 may be link-rate dependent, in certain instances. Aspects of the CDS sequence are described further below.

These three phases may initiate completion of the exit from the low power states in the link devices to an active power state, and thereafter normal data transmission (video stream) may begin as shown.

Table <NUM> below indicates example wake sequence latencies for DisplayPort UHBR10 implementations.

<FIG> illustrate an example LFPS-based wake sequence <NUM> in a DisplayPort-based topology in accordance with certain embodiments. In particular, the examples show an LFPS-based wake sequence that is transmitted from a DisplayPort-compatible or eDP-compatible transmitter (DPTX) <NUM> (e.g., video source device <NUM> of <FIG>) to a DisplayPort-compatible or eDP-compatible receiver (DPRX) <NUM> (e.g., display <NUM> of <FIG>) via a number of intermediate LTTPRs <NUM>-<NUM>, which repeat aspects of the LFPS-based sequence as shown. The LTTPRs may be implemented at various points in the link between the DPTX and DPRX (e.g., link <NUM> of <FIG>), such as, for example, in a dock, USB hub, or other intermediate device between the DPTX and DPRX. The same or similar LFPS-based sequence shown in <FIG> may be implemented in other topologies as well.

In the example shown in <FIG>, the DPTX initiates a wake pulse sequence similar to the sequences of segment <NUM> of <FIG> and segment <NUM> of <FIG>, which is transmitted to/received by the UFP of LTTPR8 428u. The wake pulse sequence is followed by a period of silence, a PHY establishment sequence, and a CDS sequence as described above. The LTTPR8 transmits the wake pulse sequence downstream in the topology via the DFP 428d (after a small <NUM> delay). This process is repeated downsteam through the other LTTPRs as shown in <FIG> (<FIG> illustrates another view of how each of the signals of the LFPS-based wake sequence are transmitted downstream over time).

In some embodiments, an LTTPR may switch from the ML_PHY_LOCK_LTTPR pattern to the ML_PHY_LOCK pattern when it completes the concurrent PHY establishment, with the most upstream LTTPR first and the most downstream LTTPR last. The LTTPR may lock to the incoming clock signal from the GPU during the CDS sequence. Prior to entering the CDS sequence, the PHY EQ may be stable and the symbol boundary/inter-lane may be aligned with incoming ML_PHY_LOCK or ML_PHY_LOCK_LTTPR signals.

In some embodiments, the CDS sequence may include the follow operations. First, a LTTPR_UFP may detect the pattern change from the ML_PHY_LOCK_LTTPR to ML_PHY_LOCK pattern, and a loss of lanes/symbol alignment may result due to the clock switch. After three consecutive Training Pattern Sequence (TPS) cycles of the ML_PHY_LOCK pattern, the LTTPR_UFP may realign to the incoming ML_PHY_LOCK. The TPS patterns may be predetermined patterns transmitted on the main link during a link training process. After verifying at least four consecutive TPS cycles, the LTTPR may switch the reference clock of the DFP serial bit clock generation from a local clock to the recovered clock of the UFP, which may take about ~<NUM>. 3uSec in some instances. Thereafter, the LTTPR may switch the DFP transmission pattern from the locally-generated ML_PHY_LOCK_LTTPR to the incoming ML_PHY_LOCK, which may require at least two consecutive TPS cycles of ML_PHY_LOCK before switching to Normal Data in some instances. The total time required may be around <NUM> TPS cycles + <NUM>. 3uSec, in certain instances. The CDS sequence may end with a scramble reset as first symbol for 8b/10b SST or MST and POST_LT_ SCRAMBEL_RESET for 128b/132b.

<FIG> illustrates another example LFPS-based wake sequence <NUM> in a DisplayPort-based topology in accordance with certain embodiments. In particular, in the example shown, the wake signaling sequence <NUM> occurs sequentially through the topology (as opposed to the repeating implementation shown in <FIG>). For instance, the example wake sequence <NUM> includes the DPTX <NUM> (which may be implemented similar to the DPTX <NUM> of <FIG>) initiating a wake pulse sequence similar to the sequences of segment <NUM> of <FIG> and segment <NUM> of <FIG>, which is followed by a period of silence, a PHY establishment sequence, and a CDS sequence as described above. However, instead of quickly initiating the wake pulse sequence as described above with respect to <FIG> (i.e., only with slight delay of ~<NUM>-<NUM>), the LTTPR <NUM> may wait until the CDS sequence is complete before transmitting the wake pulse sequence to the next hop in the topology (e.g., another LTTPR or a DPRX). This sequential transmission pattern may continue until the DPRX is reached, after which the normal data stream may be initiated (as shown).

The example sequence <NUM> may simplify branch device implementations, e.g., in the LTTPR devices, by allowing the device to be in a deeper sleep state for a longer time, thus allowing for better power management. For instance, in some cases, the DPTX and DPRX power savings achieved through the sequence <NUM> may remain unchanged from the example sequence <NUM> described above; however, the power savings in the LTTPRs may be doubled. However, there may be a latency overhead with a fully sequential wake such as the sequence <NUM>. For example, exit time (from sleep/standby) may be 60uSec-70uSec with an additional 60uSec-70uSec per LTTPR in the topology.

One or more of the following processes may be used to initiate power state transitions in devices of a DP-based link (e.g., a link between a video source device and display that is implemented based on a DisplayPort (DP) or embedded DisplayPort (eDP) specification (e.g., DP v2. <NUM> or higher, or eDP v1. <NUM> or higher)). The example processes may be implemented in software, firmware, hardware, or a combination thereof. In some embodiments, a computer-readable medium (e.g., volatile memory non-volatile memory, or a combination thereof) may be encoded with instructions that implement one or more of the operations in the example processes below. For example, in some embodiments, operations in the example processes shown in <FIG>, may be performed by one or more components of a video source device (e.g., GPU <NUM> of <FIG>). The example processes may include additional or different operations, and the operations may be performed in the order shown or in another order. In some cases, one or more of the operations shown in <FIG> are implemented as processes that include multiple operations, sub-processes, or other types of routines. In some cases, operations can be combined, performed in another order, performed in parallel, iterated, or otherwise repeated or performed another manner.

<FIG> is a flow diagram of an example process <NUM> of initiating a transition from an active link state to a low power link state in accordance with certain embodiments. The low power link state may refer to the scenario where devices of the DP link are transitioned into a low power state and transmit/output a common mode voltage rather than active signals (e.g., video signals) on the DP link.

At <NUM>, the video display source decides to transition to the low power link state. The determination may be made for any suitable reason. At <NUM>, one or more sleep signal patterns are transmitted over the DP link. The sleep pattern may be formatted as described above with respect to <FIG>. As described above with respect to <FIG>, the number of sleep patterns transmitted by the video source device or intermediate devices may be dependent on the number of devices of the DP link. In some instances, scrambled zeroes may be transmitted between each sleep pattern transmitted. At <NUM>, after the required number of sleep patterns are transmitted on the DP link, the video source device transitions into the low power state and outputs a common mode voltage on the link (i.e., does not transmit video signals or other data on the link).

<FIG> is a flow diagram of an example process <NUM> of initiating a transition from a low power link state to an active link state in accordance with certain embodiments. The active link state may refer to the scenario where devices of the DP link are transitioned into or are in an active power state and transmit/output active data signals (e.g., video signals) on the DP link.

At <NUM>, the video display source decides to transition to the active link state. The determination may be made for any suitable reason. At <NUM>, a wake pulse sequence is transmitted on the DP link. The wake pulse sequence may be formatted as described above with respect to segment <NUM> of <FIG>. In some embodiments, a period of "silence" (i.e., the common mode voltage may be transmitted on the link) may follow the wake pulse sequence as described above with respect to <FIG>. At <NUM>, a physical link establishment signal pattern is transmitted on the link. The physical link establishment pattern may be formatted as described above with respect to <FIG>. At <NUM>, a clock establishment signal pattern is transmitted on the link. The clock establishment signal pattern may be formatted as described above with respect to <FIG>. Finally, at <NUM>, video signals are transmitted on the DP link.

<FIG> are block diagrams of example computer architectures that may be used in accordance with embodiments disclosed herein. For example, in some embodiments, a computer system (e.g., a computer system <NUM>) may contain one or more aspects shown in <FIG> (e.g., video source device <NUM> may be implemented with one or more components shown in <FIG> and <FIG>) and may implement one or more aspects of the present disclosure. Other computer architecture designs known in the art for processors and computing systems may also be used. Generally, suitable computer architectures for embodiments disclosed herein can include, but are not limited to, configurations illustrated in <FIG>.

<FIG> is an example illustration of a processor according to an embodiment. Processor <NUM> is an example of a type of hardware device that can be used in connection with the implementations above. Processor <NUM> may be any type of processor, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, a multi-core processor, a single core processor, or other device to execute code. Although only one processor <NUM> is illustrated in <FIG>, a processing element may alternatively include more than one of processor <NUM> illustrated in <FIG>. Processor <NUM> may be a single-threaded core or, for at least one embodiment, the processor <NUM> may be multi-threaded in that it may include more than one hardware thread context (or "logical processor") per core.

<FIG> also illustrates a memory <NUM> coupled to processor <NUM> in accordance with an embodiment. Memory <NUM> may be any of a wide variety of memories (including various layers of memory hierarchy) as are known or otherwise available to those of skill in the art. Such memory elements can include, but are not limited to, random access memory (RAM), read only memory (ROM), logic blocks of a field programmable gate array (FPGA), erasable programmable read only memory (EPROM), and electrically erasable programmable ROM (EEPROM).

Processor <NUM> can execute any type of instructions associated with algorithms, processes, or operations detailed herein. Generally, processor <NUM> can transform an element or an article (e.g., data) from one state or thing to another state or thing.

Code <NUM>, which may be one or more instructions to be executed by processor <NUM>, may be stored in memory <NUM>, or may be stored in software, hardware, firmware, or any suitable combination thereof, or in any other internal or external component, device, element, or object where appropriate and based on particular needs. In one example, processor <NUM> can follow a program sequence of instructions indicated by code <NUM>. Each instruction enters a front-end logic <NUM> and is processed by one or more decoders <NUM>. The decoder may generate, as its output, a micro operation such as a fixed width micro operation in a predefined format, or may generate other instructions, microinstructions, or control signals that reflect the original code instruction. Front-end logic <NUM> also includes register renaming logic <NUM> and scheduling logic <NUM>, which generally allocate resources and queue the operation corresponding to the instruction for execution.

Processor <NUM> can also include execution logic <NUM> having a set of execution units 916a, 916b, 916n, etc. Some embodiments may include a number of execution units dedicated to specific functions or sets of functions. Other embodiments may include only one execution unit or one execution unit that can perform a particular function. Execution logic <NUM> performs the operations specified by code instructions.

After completion of execution of the operations specified by the code instructions, back-end logic <NUM> can retire the instructions of code <NUM>. In one embodiment, processor <NUM> allows out of order execution but requires in order retirement of instructions. Retirement logic <NUM> may take a variety of known forms (e.g., re-order buffers or the like). In this manner, processor <NUM> is transformed during execution of code <NUM>, at least in terms of the output generated by the decoder, hardware registers and tables utilized by register renaming logic <NUM>, and any registers (not shown) modified by execution logic <NUM>.

Although not shown in <FIG>, a processing element may include other elements on a chip with processor <NUM>. For example, a processing element may include memory control logic along with processor <NUM>. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches. In some embodiments, non-volatile memory (such as flash memory or fuses) may also be included on the chip with processor <NUM>.

<FIG> illustrates a computing system <NUM> that is arranged in a point-to-point (PtP) configuration according to an embodiment. In particular, <FIG> shows a system where processors, memory, and input/output devices are interconnected by a number of point-to-point interfaces. Generally, one or more of the computing systems described herein may be configured in the same or similar manner as computing system <NUM>.

Processors <NUM> and <NUM> may also each include integrated memory controller logic (MC) <NUM> and <NUM> to communicate with memory elements <NUM> and <NUM>. In alternative embodiments, memory controller logic <NUM> and <NUM> may be discrete logic separate from processors <NUM> and <NUM>. Memory elements <NUM> and/or <NUM> may store various data to be used by processors <NUM> and <NUM> in achieving operations and functionality outlined herein.

Processors <NUM> and <NUM> may be any type of processor, such as those discussed in connection with other figures. Processors <NUM> and <NUM> may exchange data via a point-to-point (PtP) interface <NUM> using point-to-point interface circuits <NUM> and <NUM>, respectively. Processors <NUM> and <NUM> may each exchange data with a chipset <NUM> via individual point-to-point interfaces <NUM> and <NUM> using point-to-point interface circuits <NUM>, <NUM>, <NUM>, and <NUM>. Chipset <NUM> may also exchange data with a co-processor <NUM>, such as a high-performance graphics circuit, machine learning accelerator, or other co-processor <NUM>, via an interface <NUM>, which could be a PtP interface circuit. In alternative embodiments, any or all of the PtP links illustrated in <FIG> could be implemented as a multi-drop bus rather than a PtP link.

Chipset <NUM> may be in communication with a bus <NUM> via an interface circuit <NUM>. Bus <NUM> may have one or more devices that communicate over it, such as a bus bridge <NUM> and I/O devices <NUM>. Via a bus <NUM>, bus bridge <NUM> may be in communication with other devices such as a user interface <NUM> (such as a keyboard, mouse, touchscreen, or other input devices), communication devices <NUM> (such as modems, network interface devices, or other types of communication devices that may communicate through a computer network <NUM>), audio I/O devices <NUM>, and/or a data storage device <NUM>. Data storage device <NUM> may store code <NUM>, which may be executed by processors <NUM> and/or <NUM>. In alternative embodiments, any portions of the bus architectures could be implemented with one or more PtP links.

The computer system depicted in <FIG> is a schematic illustration of an embodiment of a computing system that may be utilized to implement various embodiments discussed herein. It will be appreciated that various components of the system depicted in <FIG> may be combined in a system-on-a-chip (SoC) architecture or in any other suitable configuration capable of achieving the functionality and features of examples and implementations provided herein.

While some of the systems and solutions described and illustrated herein have been described as containing or being associated with a plurality of elements, not all elements explicitly illustrated or described may be utilized in each alternative implementation of the present disclosure. Additionally, one or more of the elements described herein may be located external to a system, while in other instances, certain elements may be included within or as a portion of one or more of the other described elements, as well as other elements not described in the illustrated implementation. Further, certain elements may be combined with other components, as well as used for alternative or additional purposes in addition to those purposes described herein.

Further, it should be appreciated that the examples presented above are nonlimiting examples provided merely for purposes of illustrating certain principles and features and not necessarily limiting or constraining the potential embodiments of the concepts described herein. For instance, a variety of different embodiments can be realized utilizing various combinations of the features and components described herein, including combinations realized through the various implementations of components described herein. Other implementations, features, and details should be appreciated from the contents of this Specification.

Although this disclosure has been described in terms of certain implementations and generally associated methods, alterations and permutations of these implementations and methods will be apparent to those skilled in the art. For example, the actions described herein can be performed in a different order than as described and still achieve the desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain implementations, multitasking and parallel processing may be advantageous. Additionally, other user interface layouts and functionality can be supported. Other variations are within the scope of the following claims.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any embodiments or of what may be claimed, but rather as descriptions of features specific to particular embodiments.

Claim 1:
A method of initiating a transition to an active power state between a video source device (<NUM>) and a display (<NUM>) connected by a DisplayPort, DP, -based link (<NUM>) via one or more Link-Training Tunable PHY Repeaters, LTTPR, comprising transmitting a Low Frequency Periodic Signaling, LFPS, -based sequence over a main link of the DP-based link, the LFPS-based sequence comprising:
a wake pulse sequence (<NUM>) including a plurality of low-frequency pulses from the video source device (<NUM>) over the main link;
a physical link establishment signal pattern (<NUM>) from the video source device (<NUM>) over the main link providing link establishment information for devices on the DP-based link (<NUM>);
a clock and data switch, CDS, signal pattern (<NUM>) from the video source device (<NUM>) over the main link to establish a clock signal in the one or more LTTPR and the display (<NUM>); and
a video signal from the video source device (<NUM>) over the main link.