1<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Display Hardware Handling</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><link rel="home" href="index.html" title="Linux GPU Driver Developer's Guide"><link rel="up" href="drmI915.html" title="Chapter 4. drm/i915 Intel GFX Driver"><link rel="prev" href="API-intel-vgt-balloon.html" title="intel_vgt_balloon"><link rel="next" href="API-intel-fb-obj-invalidate.html" title="intel_fb_obj_invalidate"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Display Hardware Handling</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="API-intel-vgt-balloon.html">Prev</a> </td><th width="60%" align="center">Chapter 4. drm/i915 Intel GFX Driver</th><td width="20%" align="right"> <a accesskey="n" href="API-intel-fb-obj-invalidate.html">Next</a></td></tr></table><hr></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id-1.4.3.4"></a>Display Hardware Handling</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.3">Mode Setting Infrastructure</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.4">Frontbuffer Tracking</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.5">Display FIFO Underrun Reporting</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.6">Plane Configuration</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.7">Atomic Plane Helpers</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.8">Output Probing</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.9">Hotplug</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.10">High Definition Audio</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.11">Panel Self Refresh PSR (PSR/SRD)</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.12">Frame Buffer Compression (FBC)</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.13">Display Refresh Rate Switching (DRRS)</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.14">DPIO</a></span></dt><dt><span class="sect2"><a href="ch04s02.html#id-1.4.3.4.15">CSR firmware support for DMC</a></span></dt></dl></div><p> 2 This section covers everything related to the display hardware including 3 the mode setting infrastructure, plane, sprite and cursor handling and 4 display, output probing and related topics. 5 </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.3"></a>Mode Setting Infrastructure</h3></div></div></div><p> 6 The i915 driver is thus far the only DRM driver which doesn't use the 7 common DRM helper code to implement mode setting sequences. Thus it 8 has its own tailor-made infrastructure for executing a display 9 configuration change. 10 </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.4"></a>Frontbuffer Tracking</h3></div></div></div><div class="toc"><dl class="toc"><dt><span class="refentrytitle"><a href="API-intel-fb-obj-invalidate.html"><span class="phrase">intel_fb_obj_invalidate</span></a></span><span class="refpurpose"> — 11 invalidate frontbuffer object 12 </span></dt><dt><span class="refentrytitle"><a href="API-intel-frontbuffer-flush.html"><span class="phrase">intel_frontbuffer_flush</span></a></span><span class="refpurpose"> — 13 flush frontbuffer 14 </span></dt><dt><span class="refentrytitle"><a href="API-intel-fb-obj-flush.html"><span class="phrase">intel_fb_obj_flush</span></a></span><span class="refpurpose"> — 15 flush frontbuffer object 16 </span></dt><dt><span class="refentrytitle"><a href="API-intel-frontbuffer-flip-prepare.html"><span class="phrase">intel_frontbuffer_flip_prepare</span></a></span><span class="refpurpose"> — 17 prepare asynchronous frontbuffer flip 18 </span></dt><dt><span class="refentrytitle"><a href="API-intel-frontbuffer-flip-complete.html"><span class="phrase">intel_frontbuffer_flip_complete</span></a></span><span class="refpurpose"> — 19 complete asynchronous frontbuffer flip 20 </span></dt><dt><span class="refentrytitle"><a href="API-intel-frontbuffer-flip.html"><span class="phrase">intel_frontbuffer_flip</span></a></span><span class="refpurpose"> — 21 synchronous frontbuffer flip 22 </span></dt><dt><span class="refentrytitle"><a href="API-i915-gem-track-fb.html"><span class="phrase">i915_gem_track_fb</span></a></span><span class="refpurpose"> — 23 update frontbuffer tracking 24 </span></dt></dl></div><p> 25 </p><p> 26 Many features require us to track changes to the currently active 27 frontbuffer, especially rendering targeted at the frontbuffer. 28 </p><p> 29 To be able to do so GEM tracks frontbuffers using a bitmask for all possible 30 frontbuffer slots through <code class="function"><a class="link" href="API-i915-gem-track-fb.html" title="i915_gem_track_fb">i915_gem_track_fb</a></code>. The function in this file are 31 then called when the contents of the frontbuffer are invalidated, when 32 frontbuffer rendering has stopped again to flush out all the changes and when 33 the frontbuffer is exchanged with a flip. Subsystems interested in 34 frontbuffer changes (e.g. PSR, FBC, DRRS) should directly put their callbacks 35 into the relevant places and filter for the frontbuffer slots that they are 36 interested int. 37 </p><p> 38 On a high level there are two types of powersaving features. The first one 39 work like a special cache (FBC and PSR) and are interested when they should 40 stop caching and when to restart caching. This is done by placing callbacks 41 into the invalidate and the flush functions: At invalidate the caching must 42 be stopped and at flush time it can be restarted. And maybe they need to know 43 when the frontbuffer changes (e.g. when the hw doesn't initiate an invalidate 44 and flush on its own) which can be achieved with placing callbacks into the 45 flip functions. 46 </p><p> 47 The other type of display power saving feature only cares about busyness 48 (e.g. DRRS). In that case all three (invalidate, flush and flip) indicate 49 busyness. There is no direct way to detect idleness. Instead an idle timer 50 work delayed work should be started from the flush and flip functions and 51 cancelled as soon as busyness is detected. 52 </p><p> 53 Note that there's also an older frontbuffer activity tracking scheme which 54 just tracks general activity. This is done by the various mark_busy and 55 mark_idle functions. For display power management features using these 56 functions is deprecated and should be avoided. 57</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.5"></a>Display FIFO Underrun Reporting</h3></div></div></div><div class="toc"><dl class="toc"><dt><span class="refentrytitle"><a href="API-i9xx-check-fifo-underruns.html"><span class="phrase">i9xx_check_fifo_underruns</span></a></span><span class="refpurpose"> — 58 check for fifo underruns 59 </span></dt><dt><span class="refentrytitle"><a href="API-intel-set-cpu-fifo-underrun-reporting.html"><span class="phrase">intel_set_cpu_fifo_underrun_reporting</span></a></span><span class="refpurpose"> — 60 set cpu fifo underrrun reporting state 61 </span></dt><dt><span class="refentrytitle"><a href="API-intel-set-pch-fifo-underrun-reporting.html"><span class="phrase">intel_set_pch_fifo_underrun_reporting</span></a></span><span class="refpurpose"> — 62 set PCH fifo underrun reporting state 63 </span></dt><dt><span class="refentrytitle"><a href="API-intel-cpu-fifo-underrun-irq-handler.html"><span class="phrase">intel_cpu_fifo_underrun_irq_handler</span></a></span><span class="refpurpose"> — 64 handle CPU fifo underrun interrupt 65 </span></dt><dt><span class="refentrytitle"><a href="API-intel-pch-fifo-underrun-irq-handler.html"><span class="phrase">intel_pch_fifo_underrun_irq_handler</span></a></span><span class="refpurpose"> — 66 handle PCH fifo underrun interrupt 67 </span></dt></dl></div><p> 68 </p><p> 69 The i915 driver checks for display fifo underruns using the interrupt signals 70 provided by the hardware. This is enabled by default and fairly useful to 71 debug display issues, especially watermark settings. 72 </p><p> 73 If an underrun is detected this is logged into dmesg. To avoid flooding logs 74 and occupying the cpu underrun interrupts are disabled after the first 75 occurrence until the next modeset on a given pipe. 76 </p><p> 77 Note that underrun detection on gmch platforms is a bit more ugly since there 78 is no interrupt (despite that the signalling bit is in the PIPESTAT pipe 79 interrupt register). Also on some other platforms underrun interrupts are 80 shared, which means that if we detect an underrun we need to disable underrun 81 reporting on all pipes. 82 </p><p> 83 The code also supports underrun detection on the PCH transcoder. 84</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.6"></a>Plane Configuration</h3></div></div></div><p> 85 This section covers plane configuration and composition with the 86 primary plane, sprites, cursors and overlays. This includes the 87 infrastructure to do atomic vsync'ed updates of all this state and 88 also tightly coupled topics like watermark setup and computation, 89 framebuffer compression and panel self refresh. 90 </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.7"></a>Atomic Plane Helpers</h3></div></div></div><div class="toc"><dl class="toc"><dt><span class="refentrytitle"><a href="API-intel-create-plane-state.html"><span class="phrase">intel_create_plane_state</span></a></span><span class="refpurpose"> — 91 create plane state object 92 </span></dt><dt><span class="refentrytitle"><a href="API-intel-plane-duplicate-state.html"><span class="phrase">intel_plane_duplicate_state</span></a></span><span class="refpurpose"> — 93 duplicate plane state 94 </span></dt><dt><span class="refentrytitle"><a href="API-intel-plane-destroy-state.html"><span class="phrase">intel_plane_destroy_state</span></a></span><span class="refpurpose"> — 95 destroy plane state 96 </span></dt><dt><span class="refentrytitle"><a href="API-intel-plane-atomic-get-property.html"><span class="phrase">intel_plane_atomic_get_property</span></a></span><span class="refpurpose"> — 97 fetch plane property value 98 </span></dt><dt><span class="refentrytitle"><a href="API-intel-plane-atomic-set-property.html"><span class="phrase">intel_plane_atomic_set_property</span></a></span><span class="refpurpose"> — 99 set plane property value 100 </span></dt></dl></div><p> 101 </p><p> 102 The functions here are used by the atomic plane helper functions to 103 implement legacy plane updates (i.e., drm_plane-><code class="function">update_plane</code> and 104 drm_plane-><code class="function">disable_plane</code>). This allows plane updates to use the 105 atomic state infrastructure and perform plane updates as separate 106 prepare/check/commit/cleanup steps. 107</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.8"></a>Output Probing</h3></div></div></div><p> 108 This section covers output probing and related infrastructure like the 109 hotplug interrupt storm detection and mitigation code. Note that the 110 i915 driver still uses most of the common DRM helper code for output 111 probing, so those sections fully apply. 112 </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.9"></a>Hotplug</h3></div></div></div><div class="toc"><dl class="toc"><dt><span class="refentrytitle"><a href="API-intel-hpd-irq-storm-detect.html"><span class="phrase">intel_hpd_irq_storm_detect</span></a></span><span class="refpurpose"> — 113 gather stats and detect HPD irq storm on a pin 114 </span></dt><dt><span class="refentrytitle"><a href="API-intel-hpd-irq-handler.html"><span class="phrase">intel_hpd_irq_handler</span></a></span><span class="refpurpose"> — 115 main hotplug irq handler 116 </span></dt><dt><span class="refentrytitle"><a href="API-intel-hpd-init.html"><span class="phrase">intel_hpd_init</span></a></span><span class="refpurpose"> — 117 initializes and enables hpd support 118 </span></dt></dl></div><p> 119 </p><p> 120 Simply put, hotplug occurs when a display is connected to or disconnected 121 from the system. However, there may be adapters and docking stations and 122 Display Port short pulses and MST devices involved, complicating matters. 123 </p><p> 124 Hotplug in i915 is handled in many different levels of abstraction. 125 </p><p> 126 The platform dependent interrupt handling code in i915_irq.c enables, 127 disables, and does preliminary handling of the interrupts. The interrupt 128 handlers gather the hotplug detect (HPD) information from relevant registers 129 into a platform independent mask of hotplug pins that have fired. 130 </p><p> 131 The platform independent interrupt handler <code class="function"><a class="link" href="API-intel-hpd-irq-handler.html" title="intel_hpd_irq_handler">intel_hpd_irq_handler</a></code> in 132 intel_hotplug.c does hotplug irq storm detection and mitigation, and passes 133 further processing to appropriate bottom halves (Display Port specific and 134 regular hotplug). 135 </p><p> 136 The Display Port work function <code class="function">i915_digport_work_func</code> calls into 137 <code class="function">intel_dp_hpd_pulse</code> via hooks, which handles DP short pulses and DP MST long 138 pulses, with failures and non-MST long pulses triggering regular hotplug 139 processing on the connector. 140 </p><p> 141 The regular hotplug work function <code class="function">i915_hotplug_work_func</code> calls connector 142 detect hooks, and, if connector status changes, triggers sending of hotplug 143 uevent to userspace via <code class="function"><a class="link" href="API-drm-kms-helper-hotplug-event.html" title="drm_kms_helper_hotplug_event">drm_kms_helper_hotplug_event</a></code>. 144 </p><p> 145 Finally, the userspace is responsible for triggering a modeset upon receiving 146 the hotplug uevent, disabling or enabling the crtc as needed. 147 </p><p> 148 The hotplug interrupt storm detection and mitigation code keeps track of the 149 number of interrupts per hotplug pin per a period of time, and if the number 150 of interrupts exceeds a certain threshold, the interrupt is disabled for a 151 while before being re-enabled. The intention is to mitigate issues raising 152 from broken hardware triggering massive amounts of interrupts and grinding 153 the system to a halt. 154 </p><p> 155 Current implementation expects that hotplug interrupt storm will not be 156 seen when display port sink is connected, hence on platforms whose DP 157 callback is handled by i915_digport_work_func reenabling of hpd is not 158 performed (it was never expected to be disabled in the first place ;) ) 159 this is specific to DP sinks handled by this routine and any other display 160 such as HDMI or DVI enabled on the same port will have proper logic since 161 it will use i915_hotplug_work_func where this logic is handled. 162</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.10"></a>High Definition Audio</h3></div></div></div><div class="toc"><dl class="toc"><dt><span class="refentrytitle"><a href="API-intel-audio-codec-enable.html"><span class="phrase">intel_audio_codec_enable</span></a></span><span class="refpurpose"> — 163 Enable the audio codec for HD audio 164 </span></dt><dt><span class="refentrytitle"><a href="API-intel-audio-codec-disable.html"><span class="phrase">intel_audio_codec_disable</span></a></span><span class="refpurpose"> — 165 Disable the audio codec for HD audio 166 </span></dt><dt><span class="refentrytitle"><a href="API-intel-init-audio.html"><span class="phrase">intel_init_audio</span></a></span><span class="refpurpose"> — 167 Set up chip specific audio functions 168 </span></dt><dt><span class="refentrytitle"><a href="API-i915-audio-component-init.html"><span class="phrase">i915_audio_component_init</span></a></span><span class="refpurpose"> — 169 initialize and register the audio component 170 </span></dt><dt><span class="refentrytitle"><a href="API-i915-audio-component-cleanup.html"><span class="phrase">i915_audio_component_cleanup</span></a></span><span class="refpurpose"> — 171 deregister the audio component 172 </span></dt><dt><span class="refentrytitle"><a href="API-struct-i915-audio-component-ops.html"><span class="phrase">struct i915_audio_component_ops</span></a></span><span class="refpurpose"> — 173 callbacks defined in gfx driver 174 </span></dt><dt><span class="refentrytitle"><a href="API-struct-i915-audio-component.html"><span class="phrase">struct i915_audio_component</span></a></span><span class="refpurpose"> — 175 used for audio video interaction 176 </span></dt></dl></div><p> 177 </p><p> 178 The graphics and audio drivers together support High Definition Audio over 179 HDMI and Display Port. The audio programming sequences are divided into audio 180 codec and controller enable and disable sequences. The graphics driver 181 handles the audio codec sequences, while the audio driver handles the audio 182 controller sequences. 183 </p><p> 184 The disable sequences must be performed before disabling the transcoder or 185 port. The enable sequences may only be performed after enabling the 186 transcoder and port, and after completed link training. Therefore the audio 187 enable/disable sequences are part of the modeset sequence. 188 </p><p> 189 The codec and controller sequences could be done either parallel or serial, 190 but generally the ELDV/PD change in the codec sequence indicates to the audio 191 driver that the controller sequence should start. Indeed, most of the 192 co-operation between the graphics and audio drivers is handled via audio 193 related registers. (The notable exception is the power management, not 194 covered here.) 195 </p><p> 196 The struct i915_audio_component is used to interact between the graphics 197 and audio drivers. The struct i915_audio_component_ops *ops in it is 198 defined in graphics driver and called in audio driver. The 199 struct i915_audio_component_audio_ops *audio_ops is called from i915 driver. 200</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.11"></a>Panel Self Refresh PSR (PSR/SRD)</h3></div></div></div><div class="toc"><dl class="toc"><dt><span class="refentrytitle"><a href="API-intel-psr-enable.html"><span class="phrase">intel_psr_enable</span></a></span><span class="refpurpose"> — 201 Enable PSR 202 </span></dt><dt><span class="refentrytitle"><a href="API-intel-psr-disable.html"><span class="phrase">intel_psr_disable</span></a></span><span class="refpurpose"> — 203 Disable PSR 204 </span></dt><dt><span class="refentrytitle"><a href="API-intel-psr-single-frame-update.html"><span class="phrase">intel_psr_single_frame_update</span></a></span><span class="refpurpose"> — 205 Single Frame Update 206 </span></dt><dt><span class="refentrytitle"><a href="API-intel-psr-invalidate.html"><span class="phrase">intel_psr_invalidate</span></a></span><span class="refpurpose"> — 207 Invalidade PSR 208 </span></dt><dt><span class="refentrytitle"><a href="API-intel-psr-flush.html"><span class="phrase">intel_psr_flush</span></a></span><span class="refpurpose"> — 209 Flush PSR 210 </span></dt><dt><span class="refentrytitle"><a href="API-intel-psr-init.html"><span class="phrase">intel_psr_init</span></a></span><span class="refpurpose"> — 211 Init basic PSR work and mutex. 212 </span></dt></dl></div><p> 213 </p><p> 214 Since Haswell Display controller supports Panel Self-Refresh on display 215 panels witch have a remote frame buffer (RFB) implemented according to PSR 216 spec in eDP1.3. PSR feature allows the display to go to lower standby states 217 when system is idle but display is on as it eliminates display refresh 218 request to DDR memory completely as long as the frame buffer for that 219 display is unchanged. 220 </p><p> 221 Panel Self Refresh must be supported by both Hardware (source) and 222 Panel (sink). 223 </p><p> 224 PSR saves power by caching the framebuffer in the panel RFB, which allows us 225 to power down the link and memory controller. For DSI panels the same idea 226 is called <span class="quote">“<span class="quote">manual mode</span>”</span>. 227 </p><p> 228 The implementation uses the hardware-based PSR support which automatically 229 enters/exits self-refresh mode. The hardware takes care of sending the 230 required DP aux message and could even retrain the link (that part isn't 231 enabled yet though). The hardware also keeps track of any frontbuffer 232 changes to know when to exit self-refresh mode again. Unfortunately that 233 part doesn't work too well, hence why the i915 PSR support uses the 234 software frontbuffer tracking to make sure it doesn't miss a screen 235 update. For this integration <code class="function"><a class="link" href="API-intel-psr-invalidate.html" title="intel_psr_invalidate">intel_psr_invalidate</a></code> and <code class="function"><a class="link" href="API-intel-psr-flush.html" title="intel_psr_flush">intel_psr_flush</a></code> 236 get called by the frontbuffer tracking code. Note that because of locking 237 issues the self-refresh re-enable code is done from a work queue, which 238 must be correctly synchronized/cancelled when shutting down the pipe." 239</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.12"></a>Frame Buffer Compression (FBC)</h3></div></div></div><div class="toc"><dl class="toc"><dt><span class="refentrytitle"><a href="API-intel-fbc-enabled.html"><span class="phrase">intel_fbc_enabled</span></a></span><span class="refpurpose"> — 240 Is FBC enabled? 241 </span></dt><dt><span class="refentrytitle"><a href="API-intel-fbc-disable.html"><span class="phrase">intel_fbc_disable</span></a></span><span class="refpurpose"> — 242 disable FBC 243 </span></dt><dt><span class="refentrytitle"><a href="API---intel-fbc-update.html"><span class="phrase">__intel_fbc_update</span></a></span><span class="refpurpose"> — 244 enable/disable FBC as needed, unlocked 245 </span></dt><dt><span class="refentrytitle"><a href="API-intel-fbc-init.html"><span class="phrase">intel_fbc_init</span></a></span><span class="refpurpose"> — 246 Initialize FBC 247 </span></dt></dl></div><p> 248 </p><p> 249 FBC tries to save memory bandwidth (and so power consumption) by 250 compressing the amount of memory used by the display. It is total 251 transparent to user space and completely handled in the kernel. 252 </p><p> 253 The benefits of FBC are mostly visible with solid backgrounds and 254 variation-less patterns. It comes from keeping the memory footprint small 255 and having fewer memory pages opened and accessed for refreshing the display. 256 </p><p> 257 i915 is responsible to reserve stolen memory for FBC and configure its 258 offset on proper registers. The hardware takes care of all 259 compress/decompress. However there are many known cases where we have to 260 forcibly disable it to allow proper screen updates. 261</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.13"></a>Display Refresh Rate Switching (DRRS)</h3></div></div></div><div class="toc"><dl class="toc"><dt><span class="refentrytitle"><a href="API-intel-dp-set-drrs-state.html"><span class="phrase">intel_dp_set_drrs_state</span></a></span><span class="refpurpose"> — 262 program registers for RR switch to take effect 263 </span></dt><dt><span class="refentrytitle"><a href="API-intel-edp-drrs-enable.html"><span class="phrase">intel_edp_drrs_enable</span></a></span><span class="refpurpose"> — 264 init drrs struct if supported 265 </span></dt><dt><span class="refentrytitle"><a href="API-intel-edp-drrs-disable.html"><span class="phrase">intel_edp_drrs_disable</span></a></span><span class="refpurpose"> — 266 Disable DRRS 267 </span></dt><dt><span class="refentrytitle"><a href="API-intel-edp-drrs-invalidate.html"><span class="phrase">intel_edp_drrs_invalidate</span></a></span><span class="refpurpose"> — 268 Disable Idleness DRRS 269 </span></dt><dt><span class="refentrytitle"><a href="API-intel-edp-drrs-flush.html"><span class="phrase">intel_edp_drrs_flush</span></a></span><span class="refpurpose"> — 270 Restart Idleness DRRS 271 </span></dt><dt><span class="refentrytitle"><a href="API-intel-dp-drrs-init.html"><span class="phrase">intel_dp_drrs_init</span></a></span><span class="refpurpose"> — 272 Init basic DRRS work and mutex. 273 </span></dt></dl></div><p> 274 </p><p> 275 Display Refresh Rate Switching (DRRS) is a power conservation feature 276 which enables swtching between low and high refresh rates, 277 dynamically, based on the usage scenario. This feature is applicable 278 for internal panels. 279 </p><p> 280 Indication that the panel supports DRRS is given by the panel EDID, which 281 would list multiple refresh rates for one resolution. 282 </p><p> 283 DRRS is of 2 types - static and seamless. 284 Static DRRS involves changing refresh rate (RR) by doing a full modeset 285 (may appear as a blink on screen) and is used in dock-undock scenario. 286 Seamless DRRS involves changing RR without any visual effect to the user 287 and can be used during normal system usage. This is done by programming 288 certain registers. 289 </p><p> 290 Support for static/seamless DRRS may be indicated in the VBT based on 291 inputs from the panel spec. 292 </p><p> 293 DRRS saves power by switching to low RR based on usage scenarios. 294 </p><p> 295 eDP DRRS:- 296 The implementation is based on frontbuffer tracking implementation. 297 When there is a disturbance on the screen triggered by user activity or a 298 periodic system activity, DRRS is disabled (RR is changed to high RR). 299 When there is no movement on screen, after a timeout of 1 second, a switch 300 to low RR is made. 301 For integration with frontbuffer tracking code, 302 <code class="function"><a class="link" href="API-intel-edp-drrs-invalidate.html" title="intel_edp_drrs_invalidate">intel_edp_drrs_invalidate</a></code> and <code class="function"><a class="link" href="API-intel-edp-drrs-flush.html" title="intel_edp_drrs_flush">intel_edp_drrs_flush</a></code> are called. 303 </p><p> 304 DRRS can be further extended to support other internal panels and also 305 the scenario of video playback wherein RR is set based on the rate 306 requested by userspace. 307</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.14"></a>DPIO</h3></div></div></div><p> 308 </p><p> 309 VLV, CHV and BXT have slightly peculiar display PHYs for driving DP/HDMI 310 ports. DPIO is the name given to such a display PHY. These PHYs 311 don't follow the standard programming model using direct MMIO 312 registers, and instead their registers must be accessed trough IOSF 313 sideband. VLV has one such PHY for driving ports B and C, and CHV 314 adds another PHY for driving port D. Each PHY responds to specific 315 IOSF-SB port. 316 </p><p> 317 Each display PHY is made up of one or two channels. Each channel 318 houses a common lane part which contains the PLL and other common 319 logic. CH0 common lane also contains the IOSF-SB logic for the 320 Common Register Interface (CRI) ie. the DPIO registers. CRI clock 321 must be running when any DPIO registers are accessed. 322 </p><p> 323 In addition to having their own registers, the PHYs are also 324 controlled through some dedicated signals from the display 325 controller. These include PLL reference clock enable, PLL enable, 326 and CRI clock selection, for example. 327 </p><p> 328 Eeach channel also has two splines (also called data lanes), and 329 each spline is made up of one Physical Access Coding Sub-Layer 330 (PCS) block and two TX lanes. So each channel has two PCS blocks 331 and four TX lanes. The TX lanes are used as DP lanes or TMDS 332 data/clock pairs depending on the output type. 333 </p><p> 334 Additionally the PHY also contains an AUX lane with AUX blocks 335 for each channel. This is used for DP AUX communication, but 336 this fact isn't really relevant for the driver since AUX is 337 controlled from the display controller side. No DPIO registers 338 need to be accessed during AUX communication, 339 </p><p> 340 Generally on VLV/CHV the common lane corresponds to the pipe and 341 the spline (PCS/TX) corresponds to the port. 342 </p><p> 343 For dual channel PHY (VLV/CHV): 344 </p><p> 345 pipe A == CMN/PLL/REF CH0 346 </p><p> 347 pipe B == CMN/PLL/REF CH1 348 </p><p> 349 port B == PCS/TX CH0 350 </p><p> 351 port C == PCS/TX CH1 352 </p><p> 353 This is especially important when we cross the streams 354 ie. drive port B with pipe B, or port C with pipe A. 355 </p><p> 356 For single channel PHY (CHV): 357 </p><p> 358 pipe C == CMN/PLL/REF CH0 359 </p><p> 360 port D == PCS/TX CH0 361 </p><p> 362 On BXT the entire PHY channel corresponds to the port. That means 363 the PLL is also now associated with the port rather than the pipe, 364 and so the clock needs to be routed to the appropriate transcoder. 365 Port A PLL is directly connected to transcoder EDP and port B/C 366 PLLs can be routed to any transcoder A/B/C. 367 </p><p> 368 Note: DDI0 is digital port B, DD1 is digital port C, and DDI2 is 369 digital port D (CHV) or port A (BXT). 370</p><div class="table"><a name="dpiox2"></a><p class="title"><b>Table 4.1. Dual channel PHY (VLV/CHV/BXT)</b></p><div class="table-contents"><table summary="Dual channel PHY (VLV/CHV/BXT)" border="1"><colgroup><col class="c0"><col class="c1"><col class="c2"><col class="c3"><col class="c4"><col class="c5"><col class="c6"><col class="c7"></colgroup><thead><tr><th colspan="4">CH0</th><th colspan="4">CH1</th></tr></thead><tbody align="center" valign="top"><tr><td colspan="4" align="center" valign="top">CMN/PLL/REF</td><td colspan="4" align="center" valign="top">CMN/PLL/REF</td></tr><tr><td colspan="2" align="center" valign="top">PCS01</td><td colspan="2" align="center" valign="top">PCS23</td><td colspan="2" align="center" valign="top">PCS01</td><td colspan="2" align="center" valign="top">PCS23</td></tr><tr><td align="center" valign="top">TX0</td><td align="center" valign="top">TX1</td><td align="center" valign="top">TX2</td><td align="center" valign="top">TX3</td><td align="center" valign="top">TX0</td><td align="center" valign="top">TX1</td><td align="center" valign="top">TX2</td><td align="center" valign="top">TX3</td></tr><tr><td colspan="4" align="center" valign="top">DDI0</td><td colspan="4" align="center" valign="top">DDI1</td></tr></tbody></table></div></div><br class="table-break"><div class="table"><a name="dpiox1"></a><p class="title"><b>Table 4.2. Single channel PHY (CHV/BXT)</b></p><div class="table-contents"><table summary="Single channel PHY (CHV/BXT)" border="1"><colgroup><col class="c0"><col class="c1"><col class="c2"><col class="c3"></colgroup><thead><tr><th colspan="4">CH0</th></tr></thead><tbody align="center" valign="top"><tr><td colspan="4" align="center" valign="top">CMN/PLL/REF</td></tr><tr><td colspan="2" align="center" valign="top">PCS01</td><td colspan="2" align="center" valign="top">PCS23</td></tr><tr><td align="center" valign="top">TX0</td><td align="center" valign="top">TX1</td><td align="center" valign="top">TX2</td><td align="center" valign="top">TX3</td></tr><tr><td colspan="4" align="center" valign="top">DDI2</td></tr></tbody></table></div></div><br class="table-break"></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="id-1.4.3.4.15"></a>CSR firmware support for DMC</h3></div></div></div><div class="toc"><dl class="toc"><dt><span class="refentrytitle"><a href="API-intel-csr-load-status-get.html"><span class="phrase">intel_csr_load_status_get</span></a></span><span class="refpurpose"> — 371 to get firmware loading status. 372 </span></dt><dt><span class="refentrytitle"><a href="API-intel-csr-load-status-set.html"><span class="phrase">intel_csr_load_status_set</span></a></span><span class="refpurpose"> — 373 help to set firmware loading status. 374 </span></dt><dt><span class="refentrytitle"><a href="API-intel-csr-load-program.html"><span class="phrase">intel_csr_load_program</span></a></span><span class="refpurpose"> — 375 write the firmware from memory to register. 376 </span></dt><dt><span class="refentrytitle"><a href="API-intel-csr-ucode-init.html"><span class="phrase">intel_csr_ucode_init</span></a></span><span class="refpurpose"> — 377 initialize the firmware loading. 378 </span></dt><dt><span class="refentrytitle"><a href="API-intel-csr-ucode-fini.html"><span class="phrase">intel_csr_ucode_fini</span></a></span><span class="refpurpose"> — 379 unload the CSR firmware. 380 </span></dt></dl></div><p> 381 </p><p> 382 Display Context Save and Restore (CSR) firmware support added from gen9 383 onwards to drive newly added DMC (Display microcontroller) in display 384 engine to save and restore the state of display engine when it enter into 385 low-power state and comes back to normal. 386 </p><p> 387 Firmware loading status will be one of the below states: FW_UNINITIALIZED, 388 FW_LOADED, FW_FAILED. 389 </p><p> 390 Once the firmware is written into the registers status will be moved from 391 FW_UNINITIALIZED to FW_LOADED and for any erroneous condition status will 392 be moved to FW_FAILED. 393</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="API-intel-vgt-balloon.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="drmI915.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="API-intel-fb-obj-invalidate.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"><span class="phrase">intel_vgt_balloon</span> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> <span class="phrase">intel_fb_obj_invalidate</span></td></tr></table></div></body></html> 394