^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ==============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) drm/komeda Arm display driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ==============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) The drm/komeda driver supports the Arm display processor D71 and later products,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) this document gives a brief overview of driver design: how it works and why
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) design it like that.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) Overview of D71 like display IPs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) From D71, Arm display IP begins to adopt a flexible and modularized
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) architecture. A display pipeline is made up of multiple individual and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) functional pipeline stages called components, and every component has some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) specific capabilities that can give the flowed pipeline pixel data a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) particular processing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) Typical D71 components:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) Layer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) -----
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) Layer is the first pipeline stage, which prepares the pixel data for the next
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) stage. It fetches the pixel from memory, decodes it if it's AFBC, rotates the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) source image, unpacks or converts YUV pixels to the device internal RGB pixels,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) then adjusts the color_space of pixels if needed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) Scaler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) ------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) As its name suggests, scaler takes responsibility for scaling, and D71 also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) supports image enhancements by scaler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) The usage of scaler is very flexible and can be connected to layer output
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) for layer scaling, or connected to compositor and scale the whole display
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) frame and then feed the output data into wb_layer which will then write it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) into memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) Compositor (compiz)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) Compositor blends multiple layers or pixel data flows into one single display
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) frame. its output frame can be fed into post image processor for showing it on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) the monitor or fed into wb_layer and written to memory at the same time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) user can also insert a scaler between compositor and wb_layer to down scale
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) the display frame first and then write to memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) Writeback Layer (wb_layer)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) Writeback layer does the opposite things of Layer, which connects to compiz
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) and writes the composition result to memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) Post image processor (improc)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) -----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) Post image processor adjusts frame data like gamma and color space to fit the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) requirements of the monitor.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) Timing controller (timing_ctrlr)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) --------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) Final stage of display pipeline, Timing controller is not for the pixel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) handling, but only for controlling the display timing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) Merger
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) ------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) D71 scaler mostly only has the half horizontal input/output capabilities
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) compared with Layer, like if Layer supports 4K input size, the scaler only can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) support 2K input/output in the same time. To achieve the ful frame scaling, D71
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) introduces Layer Split, which splits the whole image to two half parts and feeds
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) them to two Layers A and B, and does the scaling independently. After scaling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) the result need to be fed to merger to merge two part images together, and then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) output merged result to compiz.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) Splitter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) Similar to Layer Split, but Splitter is used for writeback, which splits the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) compiz result to two parts and then feed them to two scalers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) Possible D71 Pipeline usage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) Benefitting from the modularized architecture, D71 pipelines can be easily
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) adjusted to fit different usages. And D71 has two pipelines, which support two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) types of working mode:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) - Dual display mode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) Two pipelines work independently and separately to drive two display outputs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) - Single display mode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) Two pipelines work together to drive only one display output.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) On this mode, pipeline_B doesn't work indenpendently, but outputs its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) composition result into pipeline_A, and its pixel timing also derived from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) pipeline_A.timing_ctrlr. The pipeline_B works just like a "slave" of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) pipeline_A(master)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) Single pipeline data flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) -------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) .. kernel-render:: DOT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) :alt: Single pipeline digraph
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) :caption: Single pipeline data flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) digraph single_ppl {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) rankdir=LR;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) subgraph {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) "Memory";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) "Monitor";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) subgraph cluster_pipeline {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) style=dashed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) node [shape=box]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) node [bgcolor=grey style=dashed]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) "Scaler-0";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) "Scaler-1";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) "Scaler-0/1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) node [bgcolor=grey style=filled]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) "Layer-0" -> "Scaler-0"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) "Layer-1" -> "Scaler-0"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) "Layer-2" -> "Scaler-1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) "Layer-3" -> "Scaler-1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) "Layer-0" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) "Layer-1" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) "Layer-2" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) "Layer-3" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) "Scaler-0" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) "Scaler-1" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) "Compiz" -> "Scaler-0/1" -> "Wb_layer"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) "Compiz" -> "Improc" -> "Timing Controller"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) "Wb_layer" -> "Memory"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) "Timing Controller" -> "Monitor"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) Dual pipeline with Slave enabled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) --------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) .. kernel-render:: DOT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) :alt: Slave pipeline digraph
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) :caption: Slave pipeline enabled data flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) digraph slave_ppl {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) rankdir=LR;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) subgraph {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) "Memory";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) "Monitor";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) node [shape=box]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) subgraph cluster_pipeline_slave {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) style=dashed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) label="Slave Pipeline_B"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) node [shape=box]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) node [bgcolor=grey style=dashed]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) "Slave.Scaler-0";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) "Slave.Scaler-1";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) node [bgcolor=grey style=filled]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) "Slave.Layer-0" -> "Slave.Scaler-0"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) "Slave.Layer-1" -> "Slave.Scaler-0"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) "Slave.Layer-2" -> "Slave.Scaler-1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) "Slave.Layer-3" -> "Slave.Scaler-1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) "Slave.Layer-0" -> "Slave.Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) "Slave.Layer-1" -> "Slave.Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) "Slave.Layer-2" -> "Slave.Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) "Slave.Layer-3" -> "Slave.Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) "Slave.Scaler-0" -> "Slave.Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) "Slave.Scaler-1" -> "Slave.Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) subgraph cluster_pipeline_master {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) style=dashed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) label="Master Pipeline_A"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) node [shape=box]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) node [bgcolor=grey style=dashed]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) "Scaler-0";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) "Scaler-1";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) "Scaler-0/1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) node [bgcolor=grey style=filled]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) "Layer-0" -> "Scaler-0"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) "Layer-1" -> "Scaler-0"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) "Layer-2" -> "Scaler-1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) "Layer-3" -> "Scaler-1"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) "Slave.Compiz" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) "Layer-0" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) "Layer-1" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) "Layer-2" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) "Layer-3" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) "Scaler-0" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) "Scaler-1" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) "Compiz" -> "Scaler-0/1" -> "Wb_layer"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) "Compiz" -> "Improc" -> "Timing Controller"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) "Wb_layer" -> "Memory"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) "Timing Controller" -> "Monitor"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) Sub-pipelines for input and output
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) ----------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) A complete display pipeline can be easily divided into three sub-pipelines
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) according to the in/out usage.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) Layer(input) pipeline
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) ~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) .. kernel-render:: DOT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) :alt: Layer data digraph
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) :caption: Layer (input) data flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) digraph layer_data_flow {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) rankdir=LR;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) node [shape=box]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) node [bgcolor=grey style=dashed]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) "Scaler-n";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) "Layer-n" -> "Scaler-n" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) .. kernel-render:: DOT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) :alt: Layer Split digraph
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) :caption: Layer Split pipeline
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) digraph layer_data_flow {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) rankdir=LR;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) node [shape=box]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) "Layer-0/1" -> "Scaler-0" -> "Merger"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) "Layer-2/3" -> "Scaler-1" -> "Merger"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) "Merger" -> "Compiz"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) Writeback(output) pipeline
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) ~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) .. kernel-render:: DOT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) :alt: writeback digraph
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) :caption: Writeback(output) data flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) digraph writeback_data_flow {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) rankdir=LR;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) node [shape=box]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) node [bgcolor=grey style=dashed]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) "Scaler-n";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) "Compiz" -> "Scaler-n" -> "Wb_layer"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) .. kernel-render:: DOT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) :alt: split writeback digraph
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) :caption: Writeback(output) Split data flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) digraph writeback_data_flow {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) rankdir=LR;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) node [shape=box]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) "Compiz" -> "Splitter"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) "Splitter" -> "Scaler-0" -> "Merger"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) "Splitter" -> "Scaler-1" -> "Merger"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) "Merger" -> "Wb_layer"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) Display output pipeline
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) ~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) .. kernel-render:: DOT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) :alt: display digraph
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) :caption: display output data flow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) digraph single_ppl {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) rankdir=LR;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) node [shape=box]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) "Compiz" -> "Improc" -> "Timing Controller"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) In the following section we'll see these three sub-pipelines will be handled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) by KMS-plane/wb_conn/crtc respectively.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) Komeda Resource abstraction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) struct komeda_pipeline/component
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) --------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) To fully utilize and easily access/configure the HW, the driver side also uses
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) a similar architecture: Pipeline/Component to describe the HW features and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) capabilities, and a specific component includes two parts:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) - Data flow controlling.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) - Specific component capabilities and features.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) So the driver defines a common header struct komeda_component to describe the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) data flow control and all specific components are a subclass of this base
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) structure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) Resource discovery and initialization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) =====================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) Pipeline and component are used to describe how to handle the pixel data. We
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) still need a @struct komeda_dev to describe the whole view of the device, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) the control-abilites of device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) We have &komeda_dev, &komeda_pipeline, &komeda_component. Now fill devices with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) pipelines. Since komeda is not for D71 only but also intended for later products,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) of course we’d better share as much as possible between different products. To
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) achieve this, split the komeda device into two layers: CORE and CHIP.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) - CORE: for common features and capabilities handling.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) - CHIP: for register programing and HW specific feature (limitation) handling.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) CORE can access CHIP by three chip function structures:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) - struct komeda_dev_funcs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) - struct komeda_pipeline_funcs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) - struct komeda_component_funcs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_dev.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) Format handling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) Attach komeda_dev to DRM-KMS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) Komeda abstracts resources by pipeline/component, but DRM-KMS uses
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) crtc/plane/connector. One KMS-obj cannot represent only one single component,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) since the requirements of a single KMS object cannot simply be achieved by a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) single component, usually that needs multiple components to fit the requirement.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) Like set mode, gamma, ctm for KMS all target on CRTC-obj, but komeda needs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) compiz, improc and timing_ctrlr to work together to fit these requirements.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) And a KMS-Plane may require multiple komeda resources: layer/scaler/compiz.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) So, one KMS-Obj represents a sub-pipeline of komeda resources.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) - Plane: `Layer(input) pipeline`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) - Wb_connector: `Writeback(output) pipeline`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) - Crtc: `Display output pipeline`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) So, for komeda, we treat KMS crtc/plane/connector as users of pipeline and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) component, and at any one time a pipeline/component only can be used by one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) user. And pipeline/component will be treated as private object of DRM-KMS; the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) state will be managed by drm_atomic_state as well.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) How to map plane to Layer(input) pipeline
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) -----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) Komeda has multiple Layer input pipelines, see:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) - `Single pipeline data flow`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) - `Dual pipeline with Slave enabled`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) The easiest way is binding a plane to a fixed Layer pipeline, but consider the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) komeda capabilities:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) - Layer Split, See `Layer(input) pipeline`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) Layer_Split is quite complicated feature, which splits a big image into two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) parts and handles it by two layers and two scalers individually. But it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) imports an edge problem or effect in the middle of the image after the split.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) To avoid such a problem, it needs a complicated Split calculation and some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) special configurations to the layer and scaler. We'd better hide such HW
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) related complexity to user mode.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) - Slave pipeline, See `Dual pipeline with Slave enabled`_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) Since the compiz component doesn't output alpha value, the slave pipeline
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) only can be used for bottom layers composition. The komeda driver wants to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) hide this limitation to the user. The way to do this is to pick a suitable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) Layer according to plane_state->zpos.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) So for komeda, the KMS-plane doesn't represent a fixed komeda layer pipeline,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) but multiple Layers with same capabilities. Komeda will select one or more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) Layers to fit the requirement of one KMS-plane.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) Make component/pipeline to be drm_private_obj
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) ---------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) Add :c:type:`drm_private_obj` to :c:type:`komeda_component`, :c:type:`komeda_pipeline`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) struct komeda_component {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) struct drm_private_obj obj;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) struct komeda_pipeline {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) struct drm_private_obj obj;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) Tracking component_state/pipeline_state by drm_atomic_state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) -----------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) Add :c:type:`drm_private_state` and user to :c:type:`komeda_component_state`,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) :c:type:`komeda_pipeline_state`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) struct komeda_component_state {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) struct drm_private_state obj;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429) void *binding_user;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) struct komeda_pipeline_state {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) struct drm_private_state obj;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) struct drm_crtc *crtc;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) komeda component validation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) ---------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) Komeda has multiple types of components, but the process of validation are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443) similar, usually including the following steps:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) int komeda_xxxx_validate(struct komeda_component_xxx xxx_comp,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) struct komeda_component_output *input_dflow,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) struct drm_plane/crtc/connector *user,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) struct drm_plane/crtc/connector_state, *user_state)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) setup 1: check if component is needed, like the scaler is optional depending
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) on the user_state; if unneeded, just return, and the caller will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) put the data flow into next stage.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) Setup 2: check user_state with component features and capabilities to see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) if requirements can be met; if not, return fail.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) Setup 3: get component_state from drm_atomic_state, and try set to set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) user to component; fail if component has been assigned to another
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) user already.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) Setup 3: configure the component_state, like set its input component,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) convert user_state to component specific state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) Setup 4: adjust the input_dflow and prepare it for the next stage.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465) komeda_kms Abstraction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_kms.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) komde_kms Functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) .. kernel-doc:: drivers/gpu/drm/arm/display/komeda/komeda_plane.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) Build komeda to be a Linux module driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479) ========================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) Now we have two level devices:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) - komeda_dev: describes the real display hardware.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) - komeda_kms_dev: attachs or connects komeda_dev to DRM-KMS.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) All komeda operations are supplied or operated by komeda_dev or komeda_kms_dev,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) the module driver is only a simple wrapper to pass the Linux command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) (probe/remove/pm) into komeda_dev or komeda_kms_dev.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags