Lines Matching +full:a +full:- +full:display
1 .. SPDX-License-Identifier: GPL-2.0
4 drm/komeda Arm display driver
7 The drm/komeda driver supports the Arm display processor D71 and later products,
8 this document gives a brief overview of driver design: how it works and why
11 Overview of D71 like display IPs
14 From D71, Arm display IP begins to adopt a flexible and modularized
15 architecture. A display pipeline is made up of multiple individual and
17 specific capabilities that can give the flowed pipeline pixel data a
23 -----
30 ------
34 for layer scaling, or connected to compositor and scale the whole display
39 -------------------
40 Compositor blends multiple layers or pixel data flows into one single display
43 user can also insert a scaler between compositor and wb_layer to down scale
44 the display frame first and then write to memory.
47 --------------------------
52 -----------------------------
57 --------------------------------
58 Final stage of display pipeline, Timing controller is not for the pixel
59 handling, but only for controlling the display timing.
62 ------
67 them to two Layers A and B, and does the scaling independently. After scaling
72 --------
83 - Dual display mode
84 Two pipelines work independently and separately to drive two display outputs.
86 - Single display mode
87 Two pipelines work together to drive only one display output.
91 pipeline_A.timing_ctrlr. The pipeline_B works just like a "slave" of
95 -------------------------
97 .. kernel-render:: DOT
114 "Scaler-0";
115 "Scaler-1";
116 "Scaler-0/1"
120 "Layer-0" -> "Scaler-0"
121 "Layer-1" -> "Scaler-0"
122 "Layer-2" -> "Scaler-1"
123 "Layer-3" -> "Scaler-1"
125 "Layer-0" -> "Compiz"
126 "Layer-1" -> "Compiz"
127 "Layer-2" -> "Compiz"
128 "Layer-3" -> "Compiz"
129 "Scaler-0" -> "Compiz"
130 "Scaler-1" -> "Compiz"
132 "Compiz" -> "Scaler-0/1" -> "Wb_layer"
133 "Compiz" -> "Improc" -> "Timing Controller"
136 "Wb_layer" -> "Memory"
137 "Timing Controller" -> "Monitor"
141 --------------------------------
143 .. kernel-render:: DOT
161 "Slave.Scaler-0";
162 "Slave.Scaler-1";
166 "Slave.Layer-0" -> "Slave.Scaler-0"
167 "Slave.Layer-1" -> "Slave.Scaler-0"
168 "Slave.Layer-2" -> "Slave.Scaler-1"
169 "Slave.Layer-3" -> "Slave.Scaler-1"
171 "Slave.Layer-0" -> "Slave.Compiz"
172 "Slave.Layer-1" -> "Slave.Compiz"
173 "Slave.Layer-2" -> "Slave.Compiz"
174 "Slave.Layer-3" -> "Slave.Compiz"
175 "Slave.Scaler-0" -> "Slave.Compiz"
176 "Slave.Scaler-1" -> "Slave.Compiz"
185 "Scaler-0";
186 "Scaler-1";
187 "Scaler-0/1"
191 "Layer-0" -> "Scaler-0"
192 "Layer-1" -> "Scaler-0"
193 "Layer-2" -> "Scaler-1"
194 "Layer-3" -> "Scaler-1"
196 "Slave.Compiz" -> "Compiz"
197 "Layer-0" -> "Compiz"
198 "Layer-1" -> "Compiz"
199 "Layer-2" -> "Compiz"
200 "Layer-3" -> "Compiz"
201 "Scaler-0" -> "Compiz"
202 "Scaler-1" -> "Compiz"
204 "Compiz" -> "Scaler-0/1" -> "Wb_layer"
205 "Compiz" -> "Improc" -> "Timing Controller"
208 "Wb_layer" -> "Memory"
209 "Timing Controller" -> "Monitor"
212 Sub-pipelines for input and output
213 ----------------------------------
215 A complete display pipeline can be easily divided into three sub-pipelines
221 .. kernel-render:: DOT
231 "Scaler-n";
234 "Layer-n" -> "Scaler-n" -> "Compiz"
237 .. kernel-render:: DOT
245 "Layer-0/1" -> "Scaler-0" -> "Merger"
246 "Layer-2/3" -> "Scaler-1" -> "Merger"
247 "Merger" -> "Compiz"
252 .. kernel-render:: DOT
262 "Scaler-n";
265 "Compiz" -> "Scaler-n" -> "Wb_layer"
268 .. kernel-render:: DOT
276 "Compiz" -> "Splitter"
277 "Splitter" -> "Scaler-0" -> "Merger"
278 "Splitter" -> "Scaler-1" -> "Merger"
279 "Merger" -> "Wb_layer"
282 Display output pipeline
284 .. kernel-render:: DOT
285 :alt: display digraph
286 :caption: display output data flow
292 "Compiz" -> "Improc" -> "Timing Controller"
295 In the following section we'll see these three sub-pipelines will be handled
296 by KMS-plane/wb_conn/crtc respectively.
302 --------------------------------
305 a similar architecture: Pipeline/Component to describe the HW features and
306 capabilities, and a specific component includes two parts:
308 - Data flow controlling.
309 - Specific component capabilities and features.
311 So the driver defines a common header struct komeda_component to describe the
312 data flow control and all specific components are a subclass of this base
315 .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
322 still need a @struct komeda_dev to describe the whole view of the device, and
323 the control-abilites of device.
330 - CORE: for common features and capabilities handling.
331 - CHIP: for register programming and HW specific feature (limitation) handling.
335 - struct komeda_dev_funcs
336 - struct komeda_pipeline_funcs
337 - struct komeda_component_funcs
339 .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_dev.h
345 .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
347 .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.h
350 Attach komeda_dev to DRM-KMS
353 Komeda abstracts resources by pipeline/component, but DRM-KMS uses
354 crtc/plane/connector. One KMS-obj cannot represent only one single component,
355 since the requirements of a single KMS object cannot simply be achieved by a
357 Like set mode, gamma, ctm for KMS all target on CRTC-obj, but komeda needs
359 And a KMS-Plane may require multiple komeda resources: layer/scaler/compiz.
361 So, one KMS-Obj represents a sub-pipeline of komeda resources.
363 - Plane: `Layer(input) pipeline`_
364 - Wb_connector: `Writeback(output) pipeline`_
365 - Crtc: `Display output pipeline`_
368 component, and at any one time a pipeline/component only can be used by one
369 user. And pipeline/component will be treated as private object of DRM-KMS; the
373 -----------------------------------------
376 - `Single pipeline data flow`_
377 - `Dual pipeline with Slave enabled`_
379 The easiest way is binding a plane to a fixed Layer pipeline, but consider the
382 - Layer Split, See `Layer(input) pipeline`_
384 Layer_Split is quite complicated feature, which splits a big image into two
387 To avoid such a problem, it needs a complicated Split calculation and some
391 - Slave pipeline, See `Dual pipeline with Slave enabled`_
395 hide this limitation to the user. The way to do this is to pick a suitable
396 Layer according to plane_state->zpos.
398 So for komeda, the KMS-plane doesn't represent a fixed komeda layer pipeline,
400 Layers to fit the requirement of one KMS-plane.
403 ---------------------------------------------
407 .. code-block:: c
420 -----------------------------------------------------------
425 .. code-block:: c
440 ---------------------------
445 .. code-block:: c
466 ----------------------
468 .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_kms.h
472 -------------------
473 .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
475 .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_plane.c
478 Build komeda to be a Linux module driver
483 - komeda_dev: describes the real display hardware.
484 - komeda_kms_dev: attaches or connects komeda_dev to DRM-KMS.
487 the module driver is only a simple wrapper to pass the Linux command