diff options
Diffstat (limited to 'Documentation/gpu')
43 files changed, 2915 insertions, 378 deletions
diff --git a/Documentation/gpu/amdgpu/apu-asic-info-table.csv b/Documentation/gpu/amdgpu/apu-asic-info-table.csv index 18868abe2a91..5dd4b8762d19 100644 --- a/Documentation/gpu/amdgpu/apu-asic-info-table.csv +++ b/Documentation/gpu/amdgpu/apu-asic-info-table.csv @@ -7,7 +7,9 @@ SteamDeck, VANGOGH, DCN 3.0.1, 10.3.1, VCN 3.1.0, 5.2.1, 11.5.0 Ryzen 5000 series / Ryzen 7x30 series, GREEN SARDINE / Cezanne / Barcelo / Barcelo-R, DCN 2.1, 9.3, VCN 2.2, 4.1.1, 12.0.1 Ryzen 6000 series / Ryzen 7x35 series / Ryzen 7x36 series, YELLOW CARP / Rembrandt / Rembrandt-R, 3.1.2, 10.3.3, VCN 3.1.1, 5.2.3, 13.0.3 Ryzen 7000 series (AM5), Raphael, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5 +Ryzen 9000 series (AM5), Granite Ridge, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5 Ryzen 7x45 series (FL1), Dragon Range, 3.1.5, 10.3.6, 3.1.2, 5.2.6, 13.0.5 Ryzen 7x20 series, Mendocino, 3.1.6, 10.3.7, 3.1.1, 5.2.7, 13.0.8 Ryzen 7x40 series, Phoenix, 3.1.4, 11.0.1 / 11.0.4, 4.0.2, 6.0.1, 13.0.4 / 13.0.11 Ryzen 8x40 series, Hawk Point, 3.1.4, 11.0.1 / 11.0.4, 4.0.2, 6.0.1, 13.0.4 / 13.0.11 +Ryzen AI 300 series, Strix Point, 3.5.0, 11.5.0, 4.0.5, 6.1.0, 14.0.0 diff --git a/Documentation/gpu/amdgpu/debugging.rst b/Documentation/gpu/amdgpu/debugging.rst new file mode 100644 index 000000000000..e75f97d0e4ea --- /dev/null +++ b/Documentation/gpu/amdgpu/debugging.rst @@ -0,0 +1,80 @@ +=============== + GPU Debugging +=============== + +GPUVM Debugging +=============== + +To aid in debugging GPU virtual memory related problems, the driver supports a +number of options module parameters: + +`vm_fault_stop` - If non-0, halt the GPU memory controller on a GPU page fault. + +`vm_update_mode` - If non-0, use the CPU to update GPU page tables rather than +the GPU. + + +Decoding a GPUVM Page Fault +=========================== + +If you see a GPU page fault in the kernel log, you can decode it to figure +out what is going wrong in your application. A page fault in your kernel +log may look something like this: + +:: + + [gfxhub0] no-retry page fault (src_id:0 ring:24 vmid:3 pasid:32777, for process glxinfo pid 2424 thread glxinfo:cs0 pid 2425) + in page starting at address 0x0000800102800000 from IH client 0x1b (UTCL2) + VM_L2_PROTECTION_FAULT_STATUS:0x00301030 + Faulty UTCL2 client ID: TCP (0x8) + MORE_FAULTS: 0x0 + WALKER_ERROR: 0x0 + PERMISSION_FAULTS: 0x3 + MAPPING_ERROR: 0x0 + RW: 0x0 + +First you have the memory hub, gfxhub and mmhub. gfxhub is the memory +hub used for graphics, compute, and sdma on some chips. mmhub is the +memory hub used for multi-media and sdma on some chips. + +Next you have the vmid and pasid. If the vmid is 0, this fault was likely +caused by the kernel driver or firmware. If the vmid is non-0, it is generally +a fault in a user application. The pasid is used to link a vmid to a system +process id. If the process is active when the fault happens, the process +information will be printed. + +The GPU virtual address that caused the fault comes next. + +The client ID indicates the GPU block that caused the fault. +Some common client IDs: + +- CB/DB: The color/depth backend of the graphics pipe +- CPF: Command Processor Frontend +- CPC: Command Processor Compute +- CPG: Command Processor Graphics +- TCP/SQC/SQG: Shaders +- SDMA: SDMA engines +- VCN: Video encode/decode engines +- JPEG: JPEG engines + +PERMISSION_FAULTS describe what faults were encountered: + +- bit 0: the PTE was not valid +- bit 1: the PTE read bit was not set +- bit 2: the PTE write bit was not set +- bit 3: the PTE execute bit was not set + +Finally, RW, indicates whether the access was a read (0) or a write (1). + +In the example above, a shader (cliend id = TCP) generated a read (RW = 0x0) to +an invalid page (PERMISSION_FAULTS = 0x3) at GPU virtual address +0x0000800102800000. The user can then inspect their shader code and resource +descriptor state to determine what caused the GPU page fault. + +UMR +=== + +`umr <https://gitlab.freedesktop.org/tomstdenis/umr>`_ is a general purpose +GPU debugging and diagnostics tool. Please see the umr +`documentation <https://umr.readthedocs.io/en/main/>`_ for more information +about its capabilities. diff --git a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv index 882d2518f8ed..d2f10ee69dfc 100644 --- a/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv +++ b/Documentation/gpu/amdgpu/dgpu-asic-info-table.csv @@ -15,7 +15,8 @@ Radeon (RX/Pro) 500 /540(X) /550 /640 /WX2100 /WX3100 /WX200 Series, POLARIS12, Radeon (RX|TM) (PRO|WX) Vega /MI25 /V320 /V340L /8200 /9100 /SSG MxGPU, VEGA10, DCE 12, 9.0.1, VCE 4.0.0 / UVD 7.0.0, 4.0.0 AMD Radeon (Pro) VII /MI50 /MI60, VEGA20, DCE 12, 9.4.0, VCE 4.1.0 / UVD 7.2.0, 4.2.0 MI100, ARCTURUS, *, 9.4.1, VCN 2.5.0, 4.2.2 -MI200, ALDEBARAN, *, 9.4.2, VCN 2.6.0, 4.4.0 +MI200 Series, ALDEBARAN, *, 9.4.2, VCN 2.6.0, 4.4.0 +MI300 Series, AQUA_VANJARAM, *, 9.4.3, VCN 4.0.3, 4.4.2 AMD Radeon (RX|Pro) 5600(M|XT) /5700 (M|XT|XTB) /W5700, NAVI10, DCN 2.0.0, 10.1.10, VCN 2.0.0, 5.0.0 AMD Radeon (Pro) 5300 /5500XTB/5500(XT|M) /W5500M /W5500, NAVI14, DCN 2.0.0, 10.1.1, VCN 2.0.2, 5.0.2 AMD Radeon RX 6800(XT) /6900(XT) /W6800, SIENNA_CICHLID, DCN 3.0.0, 10.3.0, VCN 3.0.0, 5.2.0 @@ -23,4 +24,5 @@ AMD Radeon RX 6700 XT / 6800M / 6700M, NAVY_FLOUNDER, DCN 3.0.0, 10.3.2, VCN 3.0 AMD Radeon RX 6600(XT) /6600M /W6600 /W6600M, DIMGREY_CAVEFISH, DCN 3.0.2, 10.3.4, VCN 3.0.16, 5.2.4 AMD Radeon RX 6500M /6300M /W6500M /W6300M, BEIGE_GOBY, DCN 3.0.3, 10.3.5, VCN 3.0.33, 5.2.5 AMD Radeon RX 7900 XT /XTX, , DCN 3.2.0, 11.0.0, VCN 4.0.0, 6.0.0 +AMD Radeon RX 7800 XT, , DCN 3.2.0, 11.0.3, VCN 4.0.0, 6.0.3 AMD Radeon RX 7600M (XT) /7700S /7600S, , DCN 3.2.1, 11.0.2, VCN 4.0.4, 6.0.2 diff --git a/Documentation/gpu/amdgpu/display/dc-arch-overview.svg b/Documentation/gpu/amdgpu/display/dc-arch-overview.svg new file mode 100644 index 000000000000..23394931cf26 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-arch-overview.svg @@ -0,0 +1,731 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + width="1204.058" + height="510.57321" + viewBox="0 0 318.57366 135.08917" + version="1.1" + id="svg8" + inkscape:version="1.2.2 (b0a8486541, 2022-12-01)" + sodipodi:docname="dc-arch-overview.svg" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns="http://www.w3.org/2000/svg" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:dc="http://purl.org/dc/elements/1.1/"> + <defs + id="defs2"> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="marker8858" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8616" + style="fill:#aa00d4;fill-opacity:1;fill-rule:evenodd;stroke:#aa00d4;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Send" + orient="auto" + refY="0" + refX="0" + id="Arrow2Send" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8622" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="matrix(-0.3,0,0,-0.3,0.69,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8592" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1pt;stroke-opacity:1" + transform="matrix(-0.8,0,0,-0.8,-10,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8610" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="matrix(-1.1,0,0,-1.1,-1.1,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path1200" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-1" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-9" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-7" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-8" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-4" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-5" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-0" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-3" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-6" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-1" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-6" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-1" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-0-7" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-3-4" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-6-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-1-0" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-8" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-6" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path1200-6" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="marker8858-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8616-5" + style="fill:#00ffcc;fill-opacity:1;fill-rule:evenodd;stroke:#00ffcc;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-56" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-0-2" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-3-9" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="1.4" + inkscape:cx="812.5" + inkscape:cy="315" + inkscape:document-units="mm" + inkscape:current-layer="layer1" + showgrid="false" + inkscape:window-width="3840" + inkscape:window-height="2083" + inkscape:window-x="0" + inkscape:window-y="0" + inkscape:window-maximized="1" + showguides="false" + fit-margin-top="0" + fit-margin-left="0" + fit-margin-right="0" + fit-margin-bottom="0" + units="px" + inkscape:snap-global="false" + inkscape:showpageshadow="2" + inkscape:pagecheckerboard="0" + inkscape:deskcolor="#d1d1d1" /> + <metadata + id="metadata5"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1" + transform="translate(399.57097,11.171866)"> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:6.54816px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + x="-297.75696" + y="109.44505" + id="text1063" /> + <path + style="fill:#008000;stroke:#008000;stroke-width:0.463298;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.463298, 0.926596;stroke-dashoffset:0;stroke-opacity:1" + d="m -120.41395,84.001461 h -9.04766" + id="path1171-0-7" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.982225;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.982225, 1.96445;stroke-dashoffset:0;stroke-opacity:1" + d="m -129.96274,90.649221 h 8.66407" + id="path1171-7-1-3-8" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#3771c8;stroke-width:0.745037;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + d="m -121.33167,97.283841 h -7.91265" + id="path7149-3-7-8" + inkscape:connector-curvature="0" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:6.54816px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + x="-115.55721" + y="85.330681" + id="text12079"><tspan + sodipodi:role="line" + id="tspan12077" + x="-115.55721" + y="85.330681" + style="font-size:4.80199px;stroke-width:0.163704">Board/Platform</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:6.54816px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + x="-115.75885" + y="92.435066" + id="text12079-3"><tspan + sodipodi:role="line" + id="tspan12077-1" + x="-115.75885" + y="92.435066" + style="font-size:4.80199px;stroke-width:0.163704">SoC</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:6.54816px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + x="-115.6041" + y="98.608604" + id="text12079-3-4"><tspan + sodipodi:role="line" + id="tspan12077-1-9" + x="-115.6041" + y="98.608604" + style="font-size:4.80199px;stroke-width:0.163704">Component</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-368.54205" + y="92.633011" + id="text1010-5"><tspan + sodipodi:role="line" + x="-368.54205" + y="92.633011" + style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan1057">DRAM</tspan></text> + <g + id="g730" + transform="translate(6.9386906,-2.5203356)"> + <text + id="text838-5-2-6-2" + y="32.372173" + x="-372.97867" + style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + xml:space="preserve"><tspan + id="tspan936-1-2-3" + style="text-align:center;text-anchor:middle;stroke-width:0.163704" + y="32.372173" + x="-372.97867" + sodipodi:role="line">dc_plane</tspan></text> + <rect + ry="6.9139691e-07" + y="18.717371" + x="-390.50565" + height="23.904575" + width="35.080177" + id="rect834-5-2-6-75" + style="fill:none;stroke:#000000;stroke-width:0.561714;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <g + id="g738" + transform="translate(6.9386906,31.346346)"> + <text + id="text734" + y="32.372173" + x="-372.97867" + style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + xml:space="preserve"><tspan + id="tspan732" + style="text-align:center;text-anchor:middle;stroke-width:0.163704" + y="32.372173" + x="-372.97867" + sodipodi:role="line">dc_plane</tspan></text> + <rect + ry="6.9139691e-07" + y="18.717371" + x="-390.50565" + height="23.904575" + width="35.080177" + id="rect736" + style="fill:none;stroke:#000000;stroke-width:0.561714;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <rect + ry="2.1256196e-06" + y="8.5983658" + x="-389.18051" + height="73.491852" + width="46.307304" + id="rect744" + style="fill:none;stroke:#3771c8;stroke-width:1.13159;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <g + id="g757" + transform="translate(-19.949528,-8.6078171)"> + <text + id="text600" + y="56.289795" + x="-256.91336" + style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + xml:space="preserve"><tspan + id="tspan598" + style="text-align:center;text-anchor:middle;stroke-width:0.163704" + y="56.289795" + x="-256.91336" + sodipodi:role="line">DC</tspan></text> + <rect + ry="1.7458606e-06" + y="23.771139" + x="-289.21854" + height="60.361938" + width="65.042557" + id="rect602" + style="fill:none;stroke:#000000;stroke-width:1.21541;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <rect + ry="2.3633565e-06" + y="4.4885707" + x="-316.43292" + height="81.711441" + width="79.57225" + id="rect787" + style="fill:none;stroke:#3771c8;stroke-width:1.5641;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <g + id="g765" + transform="translate(6.5577393,-7.020317)"> + <text + id="text608" + y="31.942825" + x="-189.71797" + style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + xml:space="preserve"><tspan + id="tspan606" + style="text-align:center;text-anchor:middle;stroke-width:0.163704" + y="31.942825" + x="-189.71797" + sodipodi:role="line">dc_link</tspan></text> + <rect + ry="6.8036792e-07" + y="18.197111" + x="-211.99069" + height="23.523254" + width="44.846642" + id="rect610" + style="fill:none;stroke:#000000;stroke-width:0.630025;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <rect + ry="1.0582555e-06" + y="4.3160448" + x="-210.69141" + height="36.588463" + width="55.543594" + id="rect794" + style="fill:none;stroke:#3771c8;stroke-width:0.874443;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <g + id="g781" + transform="translate(6.5577393,37.542802)"> + <text + id="text777" + y="31.942825" + x="-189.71797" + style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + xml:space="preserve"><tspan + id="tspan775" + style="text-align:center;text-anchor:middle;stroke-width:0.163704" + y="31.942825" + x="-189.71797" + sodipodi:role="line">dc_link</tspan></text> + <rect + ry="6.8036792e-07" + y="18.197111" + x="-211.99069" + height="23.523254" + width="44.846642" + id="rect779" + style="fill:none;stroke:#000000;stroke-width:0.630025;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <rect + ry="1.0582555e-06" + y="50.466679" + x="-210.69141" + height="36.588463" + width="55.543594" + id="rect796" + style="fill:none;stroke:#3771c8;stroke-width:0.874443;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <g + id="g2151" + transform="translate(2.1659807,-25.895798)"> + <rect + ry="9.2671934e-07" + y="29.395185" + x="-132.25786" + height="32.040688" + width="44.742229" + id="rect618" + style="fill:none;stroke:#3771c8;stroke-width:0.734435;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <g + id="g838" + transform="translate(1.9073486e-6,0.26687336)"> + <text + id="text616" + y="47.132744" + x="-110.03735" + style="font-style:normal;font-weight:normal;font-size:6.54814px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163704" + xml:space="preserve"><tspan + id="tspan614" + style="text-align:center;text-anchor:middle;stroke-width:0.163704" + y="47.132744" + x="-110.03735" + sodipodi:role="line">dc_link</tspan></text> + <rect + ry="5.7260945e-07" + y="35.249866" + x="-126.21788" + height="19.797579" + width="32.66227" + id="rect833" + style="fill:none;stroke:#000000;stroke-width:0.493257;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + </g> + <rect + ry="3.6076738e-06" + y="-9.4559708" + x="-397.85507" + height="124.73286" + width="250.94243" + id="rect1307" + style="fill:none;stroke:#008000;stroke-width:3.43179;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:6.86358, 3.43179;stroke-dashoffset:0" /> + <rect + ry="2.9172609e-06" + y="-4.5401988" + x="-393.52301" + height="100.8623" + width="174.14117" + id="rect1990" + style="fill:none;stroke:#ff0000;stroke-width:2.57074;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:2.57074, 5.14148;stroke-dashoffset:0" /> + <path + style="fill:none;stroke:#aa00d4;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1" + d="m -317.69814,47.452094 h -23.80954" + id="path2142" /> + <path + style="fill:none;stroke:#aa00d4;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1" + d="m -130.71642,19.101665 h -23.80954" + id="path2144" /> + <g + aria-label="}" + transform="rotate(180,-59.876965,-0.22738225)" + style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#aa00d4;fill-opacity:1;stroke:none;stroke-width:0.264583" + id="text1003-5"> + <path + d="m 92.00239,-21.748413 h 0.86816 c 0,0 15.81267,-0.177767 16.15994,-0.5333 0.35553,-0.355534 1.10026,-1.124479 1.10026,-2.306836 v -20.048953 c 0,-1.289844 0.18603,-2.228288 0.5581,-2.815332 0.37207,-0.587044 0.45004,-0.992187 1.36781,-1.215429 -0.91777,-0.206706 -0.99574,-0.603581 -1.36781,-1.190625 -0.37207,-0.587045 -0.5581,-1.529623 -0.5581,-2.827735 v -19.913761 c 0,-1.174088 -0.74473,-1.938899 -1.10026,-2.294433 -0.34727,-0.363802 -15.00239,-0.545703 -16.15994,-0.545703 h -0.86816 v -1.773536 h 0.78134 c 2.05879,0 17.33403,0.305924 18.02029,0.917774 0.69453,0.60358 1.0418,1.81901 1.0418,3.646289 v 19.814542 c 0,1.231966 0.22324,2.087728 0.66973,2.567285 0.44648,0.471289 1.25677,0.706934 2.43086,0.706934 h 0.76894 v 1.773535 h -0.76894 c -1.17409,0 -1.98438,0.239778 -2.43086,0.719336 -0.44649,0.479557 -0.66973,1.343587 -0.66973,2.59209 v 19.937331 c 0,1.827279 -0.34727,3.046842 -1.0418,3.658691 -0.68626,0.611849 -15.9615,0.917774 -18.02029,0.917774 h -0.78134 z" + style="font-size:25.4px;fill:#aa00d4;stroke-width:0.264583" + id="path1005-3" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cccsscccsscsccscsscsccscsscscc" /> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-275.85803" + y="92.633011" + id="text2157"><tspan + sodipodi:role="line" + x="-275.85803" + y="92.633011" + style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan2155">DCN</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-279.29822" + y="110.19857" + id="text3141"><tspan + sodipodi:role="line" + x="-279.29822" + y="110.19857" + style="font-weight:bold;font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan3139">SoC</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-275.85803" + y="123.8538" + id="text3375"><tspan + sodipodi:role="line" + x="-275.85803" + y="123.8538" + style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan3373">Board/Platform</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-107.57491" + y="42.939579" + id="text3379"><tspan + sodipodi:role="line" + x="-107.57491" + y="42.939579" + style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan3377">Display</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-182.71582" + y="46.643749" + id="text3383"><tspan + sodipodi:role="line" + x="-182.71582" + y="46.643749" + style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan3381">Connector</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.175px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-182.71582" + y="93.210457" + id="text3387"><tspan + sodipodi:role="line" + x="-182.71582" + y="93.210457" + style="font-size:6.35px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan3385">Connector</tspan></text> + </g> +</svg> diff --git a/Documentation/gpu/amdgpu/display/dc-components.svg b/Documentation/gpu/amdgpu/display/dc-components.svg new file mode 100644 index 000000000000..f84bb2a57c05 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-components.svg @@ -0,0 +1,732 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + width="533.42053" + height="631.18573" + viewBox="0 0 141.13418 167.00122" + version="1.1" + id="svg8" + inkscape:version="1.2.2 (b0a8486541, 2022-12-01)" + sodipodi:docname="dc-components.svg" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns="http://www.w3.org/2000/svg" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:dc="http://purl.org/dc/elements/1.1/"> + <defs + id="defs2"> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="marker8858" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8616" + style="fill:#aa00d4;fill-opacity:1;fill-rule:evenodd;stroke:#aa00d4;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Send" + orient="auto" + refY="0" + refX="0" + id="Arrow2Send" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8622" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="matrix(-0.3,0,0,-0.3,0.69,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8592" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1pt;stroke-opacity:1" + transform="matrix(-0.8,0,0,-0.8,-10,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8610" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="matrix(-1.1,0,0,-1.1,-1.1,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path1200" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-1" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-9" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-7" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-8" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-4" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-5" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-0" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-3" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-6" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-1" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-6" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-1" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-0-7" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-3-4" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-6-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-1-0" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-8" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-6" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path1200-6" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="marker8858-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8616-5" + style="fill:#00ffcc;fill-opacity:1;fill-rule:evenodd;stroke:#00ffcc;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-56" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-0-2" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-3-9" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="1.4" + inkscape:cx="482.85714" + inkscape:cy="470" + inkscape:document-units="mm" + inkscape:current-layer="layer1" + showgrid="false" + inkscape:window-width="3840" + inkscape:window-height="2083" + inkscape:window-x="0" + inkscape:window-y="0" + inkscape:window-maximized="1" + showguides="false" + fit-margin-top="0" + fit-margin-left="0" + fit-margin-right="0" + fit-margin-bottom="0" + units="px" + inkscape:snap-global="false" + inkscape:showpageshadow="2" + inkscape:pagecheckerboard="0" + inkscape:deskcolor="#d1d1d1" /> + <metadata + id="metadata5"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1" + transform="translate(384.1992,26.608359)"> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:4.0511px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.101278" + x="-330.72058" + y="57.56284" + id="text1063" /> + <rect + ry="4.7572436e-07" + y="-26.142614" + x="-383.73346" + height="16.447845" + width="140.2027" + id="rect744" + style="fill:none;stroke:#3771c8;stroke-width:0.93149;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + ry="1.0800992e-06" + y="-5.1415901" + x="-383.27942" + height="37.343693" + width="40.239418" + id="rect602" + style="fill:none;stroke:#000000;stroke-width:0.751929;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.476px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-363.2121" + y="17.270189" + id="text3379"><tspan + sodipodi:role="line" + x="-363.2121" + y="17.270189" + style="font-size:10.476px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan3377">Core</tspan></text> + <rect + ry="1.0800992e-06" + y="-5.1415901" + x="-331.06259" + height="37.343693" + width="40.239418" + id="rect526" + style="fill:none;stroke:#000000;stroke-width:0.751929;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + ry="4.4701343e-07" + y="-5.2654457" + x="-286.88507" + height="15.455184" + width="43.167706" + id="rect528" + style="fill:none;stroke:#000000;stroke-width:0.501024;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + ry="4.4701343e-07" + y="15.68337" + x="-286.88507" + height="15.455184" + width="43.167706" + id="rect530" + style="fill:none;stroke:#000000;stroke-width:0.501024;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + ry="4.4701343e-07" + y="36.959518" + x="-286.88507" + height="15.455184" + width="43.167706" + id="rect532" + style="fill:none;stroke:#000000;stroke-width:0.501024;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + ry="1.6213723e-06" + y="60.089264" + x="-286.65378" + height="56.057846" + width="42.705132" + id="rect534" + style="fill:none;stroke:#000000;stroke-width:0.949072;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + ry="4.4031123e-07" + y="37.077362" + x="-382.96875" + height="15.223459" + width="92.225845" + id="rect536" + style="fill:none;stroke:#000000;stroke-width:0.726817;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + ry="4.4031123e-07" + y="59.989784" + x="-382.96875" + height="15.223459" + width="92.225845" + id="rect538" + style="fill:none;stroke:#000000;stroke-width:0.726817;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + ry="4.4031123e-07" + y="80.283493" + x="-382.96875" + height="15.223459" + width="92.225845" + id="rect540" + style="fill:none;stroke:#000000;stroke-width:0.726817;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + ry="4.3543034e-07" + y="124.89404" + x="-382.88803" + height="15.054706" + width="139.2859" + id="rect554" + style="fill:none;stroke:#000000;stroke-width:0.888245;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:8.73001px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-311.29712" + y="-16.144287" + id="text660"><tspan + sodipodi:role="line" + x="-311.29712" + y="-16.144287" + style="font-size:8.73001px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan658">Display Core API (dc/dc.h)</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.476px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-311.40384" + y="17.511137" + id="text664"><tspan + sodipodi:role="line" + x="-311.40384" + y="17.511137" + style="font-size:10.476px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan662">Link</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-336.97806" + y="43.095863" + id="text668"><tspan + sodipodi:role="line" + x="-336.97806" + y="43.095863" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan666">Hardware Sequencer API</tspan><tspan + sodipodi:role="line" + x="-336.97806" + y="48.552124" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan670">(dc/inc/hw_sequence.h)</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-337.03479" + y="68.73642" + id="text750"><tspan + sodipodi:role="line" + x="-337.03479" + y="68.73642" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan748">Hardware Sequencer</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-336.98022" + y="89.209091" + id="text756"><tspan + sodipodi:role="line" + x="-336.98022" + y="89.209091" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan754">Block Level API (dc/inc/hw)</tspan></text> + <g + id="g1543" + transform="matrix(0.61866289,0,0,0.61866289,-146.50941,-10.146755)"> + <rect + ry="7.3007396e-07" + y="180.25436" + x="-382.5336" + height="25.241808" + width="29.376135" + id="rect542" + style="fill:none;stroke:#000000;stroke-width:0.528201;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-367.99722" + y="195.3941" + id="text838"><tspan + sodipodi:role="line" + x="-367.99722" + y="195.3941" + style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan836">DCHUB</tspan></text> + </g> + <a + id="a1538" + transform="matrix(0.61866289,0,0,0.61866289,-154.037,-10.146755)"> + <rect + ry="7.3027257e-07" + y="180.25093" + x="-339.82092" + height="25.248676" + width="28.609333" + id="rect546" + style="fill:none;stroke:#000000;stroke-width:0.521332;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-325.67853" + y="195.35883" + id="text842"><tspan + sodipodi:role="line" + x="-325.67853" + y="195.35883" + style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan840">HUBP</tspan></text> + </a> + <g + id="g1533" + transform="matrix(0.61866289,0,0,0.61866289,-154.69251,-10.146755)"> + <rect + ry="7.3027257e-07" + y="180.25093" + x="-308.59961" + height="25.248676" + width="28.609333" + id="rect844" + style="fill:none;stroke:#000000;stroke-width:0.521332;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-294.45721" + y="195.3941" + id="text848"><tspan + sodipodi:role="line" + x="-294.45721" + y="195.3941" + style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan846">DPP</tspan></text> + </g> + <g + id="g1528" + transform="matrix(0.61866289,0,0,0.61866289,-155.67539,-10.146755)"> + <rect + ry="7.3027257e-07" + y="180.25093" + x="-276.84912" + height="25.248676" + width="28.609333" + id="rect850" + style="fill:none;stroke:#000000;stroke-width:0.521332;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-262.77728" + y="195.3941" + id="text854"><tspan + sodipodi:role="line" + x="-262.77728" + y="195.3941" + style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan852">MPC</tspan></text> + </g> + <g + id="g1523" + transform="matrix(0.61866289,0,0,0.61866289,-157.64019,-10.146755)"> + <rect + ry="7.3027257e-07" + y="180.25093" + x="-243.51147" + height="25.248676" + width="28.609333" + id="rect856" + style="fill:none;stroke:#000000;stroke-width:0.521332;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:7.05556px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.264583" + x="-229.2068" + y="193.25275" + id="text860"><tspan + sodipodi:role="line" + x="-229.2068" + y="193.25275" + style="font-size:7.05556px;text-align:center;text-anchor:middle;stroke-width:0.264583" + id="tspan858">...</tspan></text> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-313.35858" + y="133.55629" + id="text951"><tspan + sodipodi:role="line" + x="-313.35858" + y="133.55629" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan949">Hardware Registers</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-265.39505" + y="86.926537" + id="text1044"><tspan + sodipodi:role="line" + x="-265.39505" + y="86.926537" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan1042">DMUB</tspan><tspan + sodipodi:role="line" + x="-265.39505" + y="92.382797" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan1046">Block</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-265.42343" + y="43.272846" + id="text1052"><tspan + sodipodi:role="line" + x="-265.42343" + y="43.272846" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan1048">DMUB Hardware API</tspan><tspan + sodipodi:role="line" + x="-265.42343" + y="48.729107" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan1050">(dmub/dmub_srv.h)</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-265.40161" + y="24.997644" + id="text1058"><tspan + sodipodi:role="line" + x="-265.40161" + y="24.997644" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan1056">DMUB Service</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:4.36501px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.163688" + x="-265.30121" + y="0.99768418" + id="text1064"><tspan + sodipodi:role="line" + x="-265.30121" + y="0.99768418" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan1062">DMUB Service API</tspan><tspan + sodipodi:role="line" + x="-265.30121" + y="6.4539466" + style="font-size:4.36501px;text-align:center;text-anchor:middle;stroke-width:0.163688" + id="tspan1066">(dc/dc_dmub_srv.h)</tspan></text> + </g> +</svg> diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst b/Documentation/gpu/amdgpu/display/dc-debug.rst index 817631b1dbf3..013f63b271f3 100644 --- a/Documentation/gpu/amdgpu/display/dc-debug.rst +++ b/Documentation/gpu/amdgpu/display/dc-debug.rst @@ -2,6 +2,181 @@ Display Core Debug tools ======================== +In this section, you will find helpful information on debugging the amdgpu +driver from the display perspective. This page introduces debug mechanisms and +procedures to help you identify if some issues are related to display code. + +Narrow down display issues +========================== + +Since the display is the driver's visual component, it is common to see users +reporting issues as a display when another component causes the problem. This +section equips users to determine if a specific issue was caused by the display +component or another part of the driver. + +DC dmesg important messages +--------------------------- + +The dmesg log is the first source of information to be checked, and amdgpu +takes advantage of this feature by logging some valuable information. When +looking for the issues associated with amdgpu, remember that each component of +the driver (e.g., smu, PSP, dm, etc.) is loaded one by one, and this +information can be found in the dmesg log. In this sense, look for the part of +the log that looks like the below log snippet:: + + [ 4.254295] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x744C 0x1002:0x0E3B 0xC8). + [ 4.254718] [drm] register mmio base: 0xFCB00000 + [ 4.254918] [drm] register mmio size: 1048576 + [ 4.260095] [drm] add ip block number 0 <soc21_common> + [ 4.260318] [drm] add ip block number 1 <gmc_v11_0> + [ 4.260510] [drm] add ip block number 2 <ih_v6_0> + [ 4.260696] [drm] add ip block number 3 <psp> + [ 4.260878] [drm] add ip block number 4 <smu> + [ 4.261057] [drm] add ip block number 5 <dm> + [ 4.261231] [drm] add ip block number 6 <gfx_v11_0> + [ 4.261402] [drm] add ip block number 7 <sdma_v6_0> + [ 4.261568] [drm] add ip block number 8 <vcn_v4_0> + [ 4.261729] [drm] add ip block number 9 <jpeg_v4_0> + [ 4.261887] [drm] add ip block number 10 <mes_v11_0> + +From the above example, you can see the line that reports that `<dm>`, +(**Display Manager**), was loaded, which means that display can be part of the +issue. If you do not see that line, something else might have failed before +amdgpu loads the display component, indicating that we don't have a +display issue. + +After you identified that the DM was loaded correctly, you can check for the +display version of the hardware in use, which can be retrieved from the dmesg +log with the command:: + + dmesg | grep -i 'display core' + +This command shows a message that looks like this:: + + [ 4.655828] [drm] Display Core v3.2.285 initialized on DCN 3.2 + +This message has two key pieces of information: + +* **The DC version (e.g., v3.2.285)**: Display developers release a new DC version + every week, and this information can be advantageous in a situation where a + user/developer must find a good point versus a bad point based on a tested + version of the display code. Remember from page :ref:`Display Core <amdgpu-display-core>`, + that every week the new patches for display are heavily tested with IGT and + manual tests. +* **The DCN version (e.g., DCN 3.2)**: The DCN block is associated with the + hardware generation, and the DCN version conveys the hardware generation that + the driver is currently running. This information helps to narrow down the + code debug area since each DCN version has its files in the DC folder per DCN + component (from the example, the developer might want to focus on + files/folders/functions/structs with the dcn32 label might be executed). + However, keep in mind that DC reuses code across different DCN versions; for + example, it is expected to have some callbacks set in one DCN that are the same + as those from another DCN. In summary, use the DCN version just as a guide. + +From the dmesg file, it is also possible to get the ATOM bios code by using:: + + dmesg | grep -i 'ATOM BIOS' + +Which generates an output that looks like this:: + + [ 4.274534] amdgpu: ATOM BIOS: 113-D7020100-102 + +This type of information is useful to be reported. + +Avoid loading display core +-------------------------- + +Sometimes, it might be hard to figure out which part of the driver is causing +the issue; if you suspect that the display is not part of the problem and your +bug scenario is simple (e.g., some desktop configuration) you can try to remove +the display component from the equation. First, you need to identify `dm` ID +from the dmesg log; for example, search for the following log:: + + [ 4.254295] [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x744C 0x1002:0x0E3B 0xC8). + [..] + [ 4.260095] [drm] add ip block number 0 <soc21_common> + [ 4.260318] [drm] add ip block number 1 <gmc_v11_0> + [..] + [ 4.261057] [drm] add ip block number 5 <dm> + +Notice from the above example that the `dm` id is 5 for this specific hardware. +Next, you need to run the following binary operation to identify the IP block +mask:: + + 0xffffffff & ~(1 << [DM ID]) + +From our example the IP mask is:: + + 0xffffffff & ~(1 << 5) = 0xffffffdf + +Finally, to disable DC, you just need to set the below parameter in your +bootloader:: + + amdgpu.ip_block_mask = 0xffffffdf + +If you can boot your system with the DC disabled and still see the issue, it +means you can rule DC out of the equation. However, if the bug disappears, you +still need to consider the DC part of the problem and keep narrowing down the +issue. In some scenarios, disabling DC is impossible since it might be +necessary to use the display component to reproduce the issue (e.g., play a +game). + +**Note: This will probably lead to the absence of a display output.** + +Display flickering +------------------ + +Display flickering might have multiple causes; one is the lack of proper power +to the GPU or problems in the DPM switches. A good first generic verification +is to set the GPU to use high voltage:: + + bash -c "echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level" + +The above command sets the GPU/APU to use the maximum power allowed which +disables DPM switches. If forcing DPM levels high does not fix the issue, it +is less likely that the issue is related to power management. If the issue +disappears, there is a good chance that other components might be involved, and +the display should not be ignored since this could be a DPM issues. From the +display side, if the power increase fixes the issue, it is worth debugging the +clock configuration and the pipe split police used in the specific +configuration. + +Display artifacts +----------------- + +Users may see some screen artifacts that can be categorized into two different +types: localized artifacts and general artifacts. The localized artifacts +happen in some specific areas, such as around the UI window corners; if you see +this type of issue, there is a considerable chance that you have a userspace +problem, likely Mesa or similar. The general artifacts usually happen on the +entire screen. They might be caused by a misconfiguration at the driver level +of the display parameters, but the userspace might also cause this issue. One +way to identify the source of the problem is to take a screenshot or make a +desktop video capture when the problem happens; after checking the +screenshot/video recording, if you don't see any of the artifacts, it means +that the issue is likely on the the driver side. If you can still see the +problem in the data collected, it is an issue that probably happened during +rendering, and the display code just got the framebuffer already corrupted. + +Disabling/Enabling specific features +==================================== + +DC has a struct named `dc_debug_options`, which is statically initialized by +all DCE/DCN components based on the specific hardware characteristic. This +structure usually facilitates the bring-up phase since developers can start +with many disabled features and enable them individually. This is also an +important debug feature since users can change it when debugging specific +issues. + +For example, dGPU users sometimes see a problem where a horizontal fillet of +flickering happens in some specific part of the screen. This could be an +indication of Sub-Viewport issues; after the users identified the target DCN, +they can set the `force_disable_subvp` field to true in the statically +initialized version of `dc_debug_options` to see if the issue gets fixed. Along +the same lines, users/developers can also try to turn off `fams2_config` and +`enable_single_display_2to1_odm_policy`. In summary, the `dc_debug_options` is +an interesting form for identifying the problem. + DC Visual Confirmation ====================== @@ -76,6 +251,18 @@ change in real-time by using something like:: When reporting a bug related to DC, consider attaching this log before and after you reproduce the bug. +Collect Firmware information +============================ + +When reporting issues, it is important to have the firmware information since +it can be helpful for debugging purposes. To get all the firmware information, +use the command:: + + cat /sys/kernel/debug/dri/0/amdgpu_firmware_info + +From the display perspective, pay attention to the firmware of the DMCU and +DMCUB. + DMUB Firmware Debug =================== diff --git a/Documentation/gpu/amdgpu/display/dcn-blocks.rst b/Documentation/gpu/amdgpu/display/dcn-blocks.rst new file mode 100644 index 000000000000..756957128dad --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn-blocks.rst @@ -0,0 +1,57 @@ +.. _dcn_blocks: + +========== +DCN Blocks +========== + +In this section, you will find some extra details about some of the DCN blocks +and the code documentation when it is automatically generated. + +DCHUBBUB +-------- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h + :doc: overview + +HUBP +---- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h + :doc: overview + +DPP +--- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h + :internal: + +MPC +--- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :internal: + :no-identifiers: mpcc_blnd_cfg mpcc_alpha_blend_mode + +OPP +--- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h + :internal: + +DIO +--- + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.c + :internal: diff --git a/Documentation/gpu/amdgpu/display/dcn-overview.rst b/Documentation/gpu/amdgpu/display/dcn-overview.rst index 9fea6500448b..eb54a6802e04 100644 --- a/Documentation/gpu/amdgpu/display/dcn-overview.rst +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst @@ -1,3 +1,5 @@ +.. _dcn_overview: + ======================= Display Core Next (DCN) ======================= diff --git a/Documentation/gpu/amdgpu/display/display-contributing.rst b/Documentation/gpu/amdgpu/display/display-contributing.rst new file mode 100644 index 000000000000..36f3077eee00 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/display-contributing.rst @@ -0,0 +1,168 @@ +.. _display_todos: + +============================== +AMDGPU - Display Contributions +============================== + +First of all, if you are here, you probably want to give some technical +contribution to the display code, and for that, we say thank you :) + +This page summarizes some of the issues you can help with; keep in mind that +this is a static page, and it is always a good idea to try to reach developers +in the amdgfx or some of the maintainers. Finally, this page follows the DRM +way of creating a TODO list; for more information, check +'Documentation/gpu/todo.rst'. + +Gitlab issues +============= + +Users can report issues associated with AMD GPUs at: + +- https://gitlab.freedesktop.org/drm/amd + +Usually, we try to add a proper label to all new tickets to make it easy to +filter issues. If you can reproduce any problem, you could help by adding more +information or fixing the issue. + +Level: diverse + +IGT +=== + +`IGT`_ provides many integration tests that can be run on your GPU. We always +want to pass a large set of tests to increase the test coverage in our CI. If +you wish to contribute to the display code but are unsure where a good place +is, we recommend you run all IGT tests and try to fix any failure you see in +your hardware. Keep in mind that this failure can be an IGT problem or a kernel +issue; it is necessary to analyze case-by-case. + +Level: diverse + +.. _IGT: https://gitlab.freedesktop.org/drm/igt-gpu-tools + +Compilation +=========== + +Fix compilation warnings +------------------------ + +Enable the W1 or W2 warning level in the kernel compilation and try to fix the +issues on the display side. + +Level: Starter + +Fix compilation issues when using um architecture +------------------------------------------------- + +Linux has a User-mode Linux (UML) feature, and the kernel can be compiled to +the **um** architecture. Compiling for **um** can bring multiple advantages +from the test perspective. We currently have some compilation issues in this +area that we need to fix. + +Level: Intermediate + +Code Refactor +============= + +Add prefix to DC functions to improve the debug with ftrace +----------------------------------------------------------- + +The Ftrace debug feature (check 'Documentation/trace/ftrace.rst') is a +fantastic way to check the code path when developers try to make sense of a +bug. Ftrace provides a filter mechanism that can be useful when the developer +has some hunch of which part of the code can cause the issue; for this reason, +if a set of functions has a proper prefix, it becomes easy to create a good +filter. Additionally, prefixes can improve stack trace readability. + +The DC code does not follow some prefix rules, which makes the Ftrace filter +more complicated and reduces the readability of the stack trace. If you want +something simple to start contributing to the display, you can make patches for +adding prefixes to DC functions. To create those prefixes, use part of the file +name as a prefix for all functions in the target file. Check the +'amdgpu_dm_crtc.c` and `amdgpu_dm_plane.c` for some references. However, we +strongly advise not to send huge patches changing these prefixes; otherwise, it +will be hard to review and test, which can generate second thoughts from +maintainers. Try small steps; in case of double, you can ask before you put in +effort. We recommend first looking at folders like dceXYZ, dcnXYZ, basics, +bios, core, clk_mgr, hwss, resource, and irq. + +Level: Starter + +Reduce code duplication +----------------------- + +AMD has an extensive portfolio with various dGPUs and APUs that amdgpu +supports. To maintain the new hardware release cadence, DCE/DCN was designed in +a modular design, making the bring-up for new hardware fast. Over the years, +amdgpu accumulated some technical debt in the code duplication area. For this +task, it would be a good idea to find a tool that can discover code duplication +(including patterns) and use it as guidance to reduce duplications. + +Level: Intermediate + +Make atomic_commit_[check|tail] more readable +--------------------------------------------- + +The functions responsible for atomic commit and tail are intricate and +extensive. In particular `amdgpu_dm_atomic_commit_tail` is a long function and +could benefit from being split into smaller helpers. Improvements in this area +are more than welcome, but keep in mind that changes in this area will affect +all ASICs, meaning that refactoring requires a comprehensive verification; in +other words, this effort can take some time for validation. + +Level: Advanced + +Documentation +============= + +Expand kernel-doc +----------------- + +Many DC functions do not have a proper kernel-doc; understanding a function and +adding documentation is a great way to learn more about the amdgpu driver and +also leave an outstanding contribution to the entire community. + +Level: Starter + +Beyond AMDGPU +============= + +AMDGPU provides features that are not yet enabled in the userspace. This +section highlights some of the coolest display features, which could be enabled +with the userspace developer helper. + +Enable underlay +--------------- + +AMD display has this feature called underlay (which you can read more about at +'Documentation/gpu/amdgpu/display/mpo-overview.rst') which is intended to +save power when playing a video. The basic idea is to put a video in the +underlay plane at the bottom and the desktop in the plane above it with a hole +in the video area. This feature is enabled in ChromeOS, and from our data +measurement, it can save power. + +Level: Unknown + +Adaptive Backlight Modulation (ABM) +----------------------------------- + +ABM is a feature that adjusts the display panel's backlight level and pixel +values depending on the displayed image. This power-saving feature can be very +useful when the system starts to run off battery; since this will impact the +display output fidelity, it would be good if this option was something that +users could turn on or off. + +Level: Unknown + + +HDR & Color management & VRR +---------------------------- + +HDR, Color Management, and VRR are huge topics and it's hard to put these into +concise ToDos. If you are interested in this topic, we recommend checking some +blog posts from the community developers to better understand some of the +specific challenges and people working on the subject. If anyone wants to work +on some particular part, we can try to help with some basic guidance. Finally, +keep in mind that we already have some kernel-doc in place for those areas. + +Level: Unknown diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst index be2651ecdd7f..b269ff3f7a54 100644 --- a/Documentation/gpu/amdgpu/display/display-manager.rst +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -132,10 +132,7 @@ The DRM blend mode and its elements are then mapped by AMDGPU display manager (MPC), as follows: .. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h - :doc: mpc-overview - -.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h - :functions: mpcc_blnd_cfg + :identifiers: mpcc_blnd_cfg Therefore, the blending configuration for a single MPCC instance on the MPC tree is defined by :c:type:`mpcc_blnd_cfg`, where @@ -147,7 +144,7 @@ alpha and plane alpha values. It sets one of the three modes for :c:type:`MPCC_ALPHA_BLND_MODE`, as described below. .. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h - :functions: mpcc_alpha_blend_mode + :identifiers: mpcc_alpha_blend_mode DM then maps the elements of `enum mpcc_alpha_blend_mode` to those in the DRM blend formula, as follows: diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst index f8a4f53d70d8..bd2d797c123e 100644 --- a/Documentation/gpu/amdgpu/display/index.rst +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -7,18 +7,80 @@ drm/amd/display - Display Core (DC) AMD display engine is partially shared with other operating systems; for this reason, our Display Core Driver is divided into two pieces: -1. **Display Core (DC)** contains the OS-agnostic components. Things like +#. **Display Core (DC)** contains the OS-agnostic components. Things like hardware programming and resource management are handled here. -2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the - amdgpu base driver and DRM are implemented here. +#. **Display Manager (DM)** contains the OS-dependent components. Hooks to the + amdgpu base driver and DRM are implemented here. For example, you can check + display/amdgpu_dm/ folder. + +------------------ +DC Code validation +------------------ + +Maintaining the same code base across multiple OSes requires a lot of +synchronization effort between repositories and exhaustive validation. In the +DC case, we maintain a tree to centralize code from different parts. The shared +repository has integration tests with our Internal Linux CI farm, and we run a +comprehensive set of IGT tests in various AMD GPUs/APUs (mostly recent dGPUs +and APUs). Our CI also checks ARM64/32, PPC64/32, and x86_64/32 compilation +with DCN enabled and disabled. + +When we upstream a new feature or some patches, we pack them in a patchset with +the prefix **DC Patches for <DATE>**, which is created based on the latest +`amd-staging-drm-next <https://gitlab.freedesktop.org/agd5f/linux>`_. All of +those patches are under a DC version tested as follows: + +* Ensure that every patch compiles and the entire series pass our set of IGT + test in different hardware. +* Prepare a branch with those patches for our validation team. If there is an + error, a developer will debug as fast as possible; usually, a simple bisect + in the series is enough to point to a bad change, and two possible actions + emerge: fix the issue or drop the patch. If it is not an easy fix, the bad + patch is dropped. +* Finally, developers wait a few days for community feedback before we merge + the series. + +It is good to stress that the test phase is something that we take extremely +seriously, and we never merge anything that fails our validation. Follows an +overview of our test set: + +#. Manual test + * Multiple Hotplugs with DP and HDMI. + * Stress test with multiple display configuration changes via the user interface. + * Validate VRR behaviour. + * Check PSR. + * Validate MPO when playing video. + * Test more than two displays connected at the same time. + * Check suspend/resume. + * Validate FPO. + * Check MST. +#. Automated test + * IGT tests in a farm with GPUs and APUs that support DCN and DCE. + * Compilation validation with the latest GCC and Clang from LTS distro. + * Cross-compilation for PowerPC 64/32, ARM 64/32, and x86 32. + +In terms of test setup for CI and manual tests, we usually use: + +#. The latest Ubuntu LTS. +#. In terms of userspace, we only use fully updated open-source components + provided by the distribution official package manager. +#. Regarding IGT, we use the latest code from the upstream. +#. Most of the manual tests are conducted in the GNome but we also use KDE. + +Notice that someone from our test team will always reply to the cover letter +with the test report. + +-------------- +DC Information +-------------- The display pipe is responsible for "scanning out" a rendered frame from the GPU memory (also called VRAM, FrameBuffer, etc.) to a display. In other words, it would: -1. Read frame information from memory; -2. Perform required transformation; -3. Send pixel data to sink devices. +#. Read frame information from memory; +#. Perform required transformation; +#. Send pixel data to sink devices. If you want to learn more about our driver details, take a look at the below table of content: @@ -26,7 +88,10 @@ table of content: .. toctree:: display-manager.rst - dc-debug.rst dcn-overview.rst + dcn-blocks.rst + programming-model-dcn.rst mpo-overview.rst + dc-debug.rst + display-contributing.rst dc-glossary.rst diff --git a/Documentation/gpu/amdgpu/display/programming-model-dcn.rst b/Documentation/gpu/amdgpu/display/programming-model-dcn.rst new file mode 100644 index 000000000000..c1b48d49fb0b --- /dev/null +++ b/Documentation/gpu/amdgpu/display/programming-model-dcn.rst @@ -0,0 +1,162 @@ +==================== +DC Programming Model +==================== + +In the :ref:`Display Core Next (DCN) <dcn_overview>` and :ref:`DCN Block +<dcn_blocks>` pages, you learned about the hardware components and how they +interact with each other. On this page, the focus is shifted to the display +code architecture. Hence, it is reasonable to remind the reader that the code +in DC is shared with other OSes; for this reason, DC provides a set of +abstractions and operations to connect different APIs with the hardware +configuration. See DC as a service available for a Display Manager (amdgpu_dm) +to access and configure DCN/DCE hardware (DCE is also part of DC, but for +simplicity's sake, this documentation only examines DCN). + +.. note:: + For this page, we will use the term GPU to refers to dGPU and APU. + +Overview +======== + +From the display hardware perspective, it is plausible to expect that if a +problem is well-defined, it will probably be implemented at the hardware level. +On the other hand, when there are multiple ways of achieving something without +a very well-defined scope, the solution is usually implemented as a policy at +the DC level. In other words, some policies are defined in the DC core +(resource management, power optimization, image quality, etc.), and the others +implemented in hardware are enabled via DC configuration. + +In terms of hardware management, DCN has multiple instances of the same block +(e.g., HUBP, DPP, MPC, etc), and during the driver execution, it might be +necessary to use some of these instances. The core has policies in place for +handling those instances. Regarding resource management, the DC objective is +quite simple: minimize the hardware shuffle when the driver performs some +actions. When the state changes from A to B, the transition is considered +easier to maneuver if the hardware resource is still used for the same set of +driver objects. Usually, adding and removing a resource to a `pipe_ctx` (more +details below) is not a problem; however, moving a resource from one `pipe_ctx` +to another should be avoided. + +Another area of influence for DC is power optimization, which has a myriad of +arrangement possibilities. In some way, just displaying an image via DCN should +be relatively straightforward; however, showing it with the best power +footprint is more desirable, but it has many associated challenges. +Unfortunately, there is no straight-forward analytic way to determine if a +configuration is the best one for the context due to the enormous variety of +variables related to this problem (e.g., many different DCN/DCE hardware +versions, different displays configurations, etc.) for this reason DC +implements a dedicated library for trying some configuration and verify if it +is possible to support it or not. This type of policy is extremely complex to +create and maintain, and amdgpu driver relies on Display Mode Library (DML) to +generate the best decisions. + +In summary, DC must deal with the complexity of handling multiple scenarios and +determine policies to manage them. All of the above information is conveyed to +give the reader some idea about the complexity of driving a display from the +driver's perspective. This page hopes to allow the reader to better navigate +over the amdgpu display code. + +Display Driver Architecture Overview +==================================== + +The diagram below provides an overview of the display driver architecture; +notice it illustrates the software layers adopted by DC: + +.. kernel-figure:: dc-components.svg + +The first layer of the diagram is the high-level DC API represented by the +`dc.h` file; below it are two big blocks represented by Core and Link. Next is +the hardware configuration block; the main file describing it is +the`hw_sequencer.h`, where the implementation of the callbacks can be found in +the hardware sequencer folder. Almost at the end, you can see the block level +API (`dc/inc/hw`), which represents each DCN low-level block, such as HUBP, +DPP, MPC, OPTC, etc. Notice on the left side of the diagram that we have a +different set of layers representing the interaction with the DMUB +microcontroller. + +Basic Objects +------------- + +The below diagram outlines the basic display objects. In particular, pay +attention to the names in the boxes since they represent a data structure in +the driver: + +.. kernel-figure:: dc-arch-overview.svg + +Let's start with the central block in the image, `dc`. The `dc` struct is +initialized per GPU; for example, one GPU has one `dc` instance, two GPUs have +two `dc` instances, and so forth. In other words we have one 'dc' per 'amdgpu' +instance. In some ways, this object behaves like the `Singleton` pattern. + +After the `dc` block in the diagram, you can see the `dc_link` component, which +is a low-level abstraction for the connector. One interesting aspect of the +image is that connectors are not part of the DCN block; they are defined by the +platform/board and not by the SoC. The `dc_link` struct is the high-level data +container with information such as connected sinks, connection status, signal +types, etc. After `dc_link`, there is the `dc_sink`, which is the object that +represents the connected display. + +.. note:: + For historical reasons, we used the name `dc_link`, which gives the + wrong impression that this abstraction only deals with physical connections + that the developer can easily manipulate. However, this also covers + conections like eDP or cases where the output is connected to other devices. + +There are two structs that are not represented in the diagram since they were +elaborated in the DCN overview page (check the DCN block diagram :ref:`Display +Core Next (DCN) <dcn_overview>`); still, it is worth bringing back for this +overview which is `dc_stream` and `dc_state`. The `dc_stream` stores many +properties associated with the data transmission, but most importantly, it +represents the data flow from the connector to the display. Next we have +`dc_state`, which represents the logic state within the hardware at the moment; +`dc_state` is composed of `dc_stream` and `dc_plane`. The `dc_stream` is the DC +version of `drm_crtc` and represents the post-blending pipeline. + +Speaking of the `dc_plane` data structure (first part of the diagram), you can +think about it as an abstraction similar to `drm_plane` that represents the +pre-blending portion of the pipeline. This image was probably processed by GFX +and is ready to be composited under a `dc_stream`. Normally, the driver may +have one or more `dc_plane` connected to the same `dc_stream`, which defines a +composition at the DC level. + +Basic Operations +---------------- + +Now that we have covered the basic objects, it is time to examine some of the +basic hardware/software operations. Let's start with the `dc_create()` +function, which directly works with the `dc` data struct; this function behaves +like a constructor responsible for the basic software initialization and +preparing for enabling other parts of the API. It is important to highlight +that this operation does not touch any hardware configuration; it is only a +software initialization. + +Next, we have the `dc_hardware_init()`, which also relies on the `dc` data +struct. Its main function is to put the hardware in a valid state. It is worth +highlighting that the hardware might initialize in an unknown state, and it is +a requirement to put it in a valid state; this function has multiple callbacks +for the hardware-specific initialization, whereas `dc_hardware_init` does the +hardware initialization and is the first point where we touch hardware. + +The `dc_get_link_at_index` is an operation that depends on the `dc_link` data +structure. This function retrieves and enumerates all the `dc_links` available +on the device; this is required since this information is not part of the SoC +definition but depends on the board configuration. As soon as the `dc_link` is +initialized, it is useful to figure out if any of them are already connected to +the display by using the `dc_link_detect()` function. After the driver figures +out if any display is connected to the device, the challenging phase starts: +configuring the monitor to show something. Nonetheless, dealing with the ideal +configuration is not a DC task since this is the Display Manager (`amdgpu_dm`) +responsibility which in turn is responsible for dealing with the atomic +commits. The only interface DC provides to the configuration phase is the +function `dc_validate_with_context` that receives the configuration information +and, based on that, validates whether the hardware can support it or not. It is +important to add that even if the display supports some specific configuration, +it does not mean the DCN hardware can support it. + +After the DM and DC agree upon the configuration, the stream configuration +phase starts. This task activates one or more `dc_stream` at this phase, and in +the best-case scenario, you might be able to turn the display on with a black +screen (it does not show anything yet since it does not have any plane +associated with it). The final step would be to call the +`dc_update_planes_and_stream,` which will add or remove planes. + diff --git a/Documentation/gpu/amdgpu/driver-core.rst b/Documentation/gpu/amdgpu/driver-core.rst index 467e6843aef6..32723a925377 100644 --- a/Documentation/gpu/amdgpu/driver-core.rst +++ b/Documentation/gpu/amdgpu/driver-core.rst @@ -179,4 +179,4 @@ IP Blocks :doc: IP Blocks .. kernel-doc:: drivers/gpu/drm/amd/include/amd_shared.h - :identifiers: amd_ip_block_type amd_ip_funcs + :identifiers: amd_ip_block_type amd_ip_funcs DC_DEBUG_MASK diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst index 912e699fd373..302d039928ee 100644 --- a/Documentation/gpu/amdgpu/index.rst +++ b/Documentation/gpu/amdgpu/index.rst @@ -15,4 +15,6 @@ Next (GCN), Radeon DNA (RDNA), and Compute DNA (CDNA) architectures. ras thermal driver-misc + debugging + process-isolation amdgpu-glossary diff --git a/Documentation/gpu/amdgpu/process-isolation.rst b/Documentation/gpu/amdgpu/process-isolation.rst new file mode 100644 index 000000000000..6b6d70e357a7 --- /dev/null +++ b/Documentation/gpu/amdgpu/process-isolation.rst @@ -0,0 +1,59 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= + AMDGPU Process Isolation +========================= + +The AMDGPU driver includes a feature that enables automatic process isolation on the graphics engine. This feature serializes access to the graphics engine and adds a cleaner shader which clears the Local Data Store (LDS) and General Purpose Registers (GPRs) between jobs. All processes using the GPU, including both graphics and compute workloads, are serialized when this feature is enabled. On GPUs that support partitionable graphics engines, this feature can be enabled on a per-partition basis. + +In addition, there is an interface to manually run the cleaner shader when the use of the GPU is complete. This may be preferable in some use cases, such as a single-user system where the login manager triggers the cleaner shader when the user logs out. + +Process Isolation +================= + +The `run_cleaner_shader` and `enforce_isolation` sysfs interfaces allow users to manually execute the cleaner shader and control the process isolation feature, respectively. + +Partition Handling +------------------ + +The `enforce_isolation` file in sysfs can be used to enable process isolation and automatic shader cleanup between processes. On GPUs that support graphics engine partitioning, this can be enabled per partition. The partition and its current setting (0 disabled, 1 enabled) can be read from sysfs. On GPUs that do not support graphics engine partitioning, only a single partition will be present. Writing 1 to the partition position enables enforce isolation, writing 0 disables it. + +Example of enabling enforce isolation on a GPU with multiple partitions: + +.. code-block:: console + + $ echo 1 0 1 0 > /sys/class/drm/card0/device/enforce_isolation + $ cat /sys/class/drm/card0/device/enforce_isolation + 1 0 1 0 + +The output indicates that enforce isolation is enabled on zeroth and second parition and disabled on first and fourth parition. + +For devices with a single partition or those that do not support partitions, there will be only one element: + +.. code-block:: console + + $ echo 1 > /sys/class/drm/card0/device/enforce_isolation + $ cat /sys/class/drm/card0/device/enforce_isolation + 1 + +Cleaner Shader Execution +======================== + +The driver can trigger a cleaner shader to clean up the LDS and GPR state on the graphics engine. When process isolation is enabled, this happens automatically between processes. In addition, there is a sysfs file to manually trigger cleaner shader execution. + +To manually trigger the execution of the cleaner shader, write `0` to the `run_cleaner_shader` sysfs file: + +.. code-block:: console + + $ echo 0 > /sys/class/drm/card0/device/run_cleaner_shader + +For multi-partition devices, you can specify the partition index when triggering the cleaner shader: + +.. code-block:: console + + $ echo 0 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 0 + $ echo 1 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 1 + $ echo 2 > /sys/class/drm/card0/device/run_cleaner_shader # For partition 2 + # ... and so on for each partition + +This command initiates the cleaner shader, which will run and complete before any new tasks are scheduled on the GPU. diff --git a/Documentation/gpu/amdgpu/thermal.rst b/Documentation/gpu/amdgpu/thermal.rst index 2f6166f81e6a..1768a106aab1 100644 --- a/Documentation/gpu/amdgpu/thermal.rst +++ b/Documentation/gpu/amdgpu/thermal.rst @@ -49,6 +49,12 @@ pp_power_profile_mode .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: pp_power_profile_mode +pm_policy +--------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: pm_policy + \*_busy_percent --------------- @@ -94,6 +100,18 @@ fan_minimum_pwm .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c :doc: fan_minimum_pwm +fan_zero_rpm_enable +---------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: fan_zero_rpm_enable + +fan_zero_rpm_stop_temperature +----------------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: fan_zero_rpm_stop_temperature + GFXOFF ====== diff --git a/Documentation/gpu/automated_testing.rst b/Documentation/gpu/automated_testing.rst index 2d5a28866afe..6d7c6086034d 100644 --- a/Documentation/gpu/automated_testing.rst +++ b/Documentation/gpu/automated_testing.rst @@ -68,19 +68,25 @@ known to behave unreliably. These tests won't cause a job to fail regardless of the result. They will still be run. Each new flake entry must be associated with a link to the email reporting the -bug to the author of the affected driver, the board name or Device Tree name of -the board, the first kernel version affected, the IGT version used for tests, -and an approximation of the failure rate. +bug to the author of the affected driver or the relevant GitLab issue. The entry +must also include the board name or Device Tree name, the first kernel version +affected, the IGT version used for tests, and an approximation of the failure rate. They should be provided under the following format:: - # Bug Report: $LORE_OR_PATCHWORK_URL + # Bug Report: $LORE_URL_OR_GITLAB_ISSUE # Board Name: broken-board.dtb # Linux Version: 6.6-rc1 # IGT Version: 1.28-gd2af13d9f # Failure Rate: 100 flaky-test +Use the appropriate link below to create a GitLab issue: +amdgpu driver: https://gitlab.freedesktop.org/drm/amd/-/issues +i915 driver: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues +msm driver: https://gitlab.freedesktop.org/drm/msm/-/issues +xe driver: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues + drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt ----------------------------------------------------------- diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst index e5070a0e95ab..971cdb4816fc 100644 --- a/Documentation/gpu/driver-uapi.rst +++ b/Documentation/gpu/driver-uapi.rst @@ -18,6 +18,11 @@ VM_BIND / EXEC uAPI .. kernel-doc:: include/uapi/drm/nouveau_drm.h +drm/panthor uAPI +================ + +.. kernel-doc:: include/uapi/drm/panthor_drm.h + drm/xe uAPI =========== diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index b899cbc5c2b4..1f17ad0790d7 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -22,6 +22,8 @@ GPU Driver Documentation afbc komeda-kms panfrost + panthor + zynqmp .. only:: subproject and html diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst index 58b5a1d1219d..cbcfe30de777 100644 --- a/Documentation/gpu/drm-client.rst +++ b/Documentation/gpu/drm-client.rst @@ -13,3 +13,6 @@ Kernel clients .. kernel-doc:: drivers/gpu/drm/drm_client_modeset.c :export: + +.. kernel-doc:: drivers/gpu/drm/drm_client_event.c + :export: diff --git a/Documentation/gpu/drm-compute.rst b/Documentation/gpu/drm-compute.rst new file mode 100644 index 000000000000..f90c3e63aa9e --- /dev/null +++ b/Documentation/gpu/drm-compute.rst @@ -0,0 +1,54 @@ +================================== +Long running workloads and compute +================================== + +Long running workloads (compute) are workloads that will not complete in 10 +seconds. (The time let the user wait before he reaches for the power button). +This means that other techniques need to be used to manage those workloads, +that cannot use fences. + +Some hardware may schedule compute jobs, and have no way to pre-empt them, or +have their memory swapped out from them. Or they simply want their workload +not to be preempted or swapped out at all. + +This means that it differs from what is described in driver-api/dma-buf.rst. + +As with normal compute jobs, dma-fence may not be used at all. In this case, +not even to force preemption. The driver with is simply forced to unmap a BO +from the long compute job's address space on unbind immediately, not even +waiting for the workload to complete. Effectively this terminates the workload +when there is no hardware support to recover. + +Since this is undesirable, there need to be mitigations to prevent a workload +from being terminated. There are several possible approach, all with their +advantages and drawbacks. + +The first approach you will likely try is to pin all buffers used by compute. +This guarantees that the job will run uninterrupted, but also allows a very +denial of service attack by pinning as much memory as possible, hogging the +all GPU memory, and possibly a huge chunk of CPU memory. + +A second approach that will work slightly better on its own is adding an option +not to evict when creating a new job (any kind). If all of userspace opts in +to this flag, it would prevent cooperating userspace from forced terminating +older compute jobs to start a new one. + +If job preemption and recoverable pagefaults are not available, those are the +only approaches possible. So even with those, you want a separate way of +controlling resources. The standard kernel way of doing so is cgroups. + +This creates a third option, using cgroups to prevent eviction. Both GPU and +driver-allocated CPU memory would be accounted to the correct cgroup, and +eviction would be made cgroup aware. This allows the GPU to be partitioned +into cgroups, that will allow jobs to run next to each other without +interference. + +The interface to the cgroup would be similar to the current CPU memory +interface, with similar semantics for min/low/high/max, if eviction can +be made cgroup aware. + +What should be noted is that each memory region (tiled memory for example) +should have its own accounting. + +The key is set to the regionid set by the driver, for example "tile0". +For the value of $card, we use drmGetUnique(). diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 5fd20a306718..cb9ae282771c 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -57,8 +57,8 @@ is larger than the driver minor, the DRM_IOCTL_SET_VERSION call will return an error. Otherwise the driver's set_version() method will be called with the requested version. -Name, Description and Date -~~~~~~~~~~~~~~~~~~~~~~~~~~ +Name and Description +~~~~~~~~~~~~~~~~~~~~ char \*name; char \*desc; char \*date; The driver name is printed to the kernel log at initialization time, @@ -69,30 +69,12 @@ The driver description is a purely informative string passed to userspace through the DRM_IOCTL_VERSION ioctl and otherwise unused by the kernel. -The driver date, formatted as YYYYMMDD, is meant to identify the date of -the latest modification to the driver. However, as most drivers fail to -update it, its value is mostly useless. The DRM core prints it to the -kernel log at initialization time and passes it to userspace through the -DRM_IOCTL_VERSION ioctl. - Module Initialization --------------------- .. kernel-doc:: include/drm/drm_module.h :doc: overview -Managing Ownership of the Framebuffer Aperture ----------------------------------------------- - -.. kernel-doc:: drivers/gpu/drm/drm_aperture.c - :doc: overview - -.. kernel-doc:: include/drm/drm_aperture.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/drm_aperture.c - :export: - Device Instance and Driver Handling ----------------------------------- @@ -153,18 +135,6 @@ Managed Resources .. kernel-doc:: include/drm/drm_managed.h :internal: -Bus-specific Device Registration and PCI Support ------------------------------------------------- - -A number of functions are provided to help with device registration. The -functions deal with PCI and platform devices respectively and are only -provided for historical reasons. These are all deprecated and shouldn't -be used in new drivers. Besides that there's a few helpers for pci -drivers. - -.. kernel-doc:: drivers/gpu/drm/drm_pci.c - :export: - Open/Close, File Operations and IOCTLs ====================================== diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 59cfe8a7a8ba..b4ee25af1702 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -116,9 +116,6 @@ fbdev Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c :export: -.. kernel-doc:: drivers/gpu/drm/drm_fbdev_generic.c - :export: - format Helper Functions Reference ================================= @@ -175,7 +172,7 @@ Bridge Operations Bridge Connector Helper ----------------------- -.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c +.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c :doc: overview @@ -198,7 +195,7 @@ MIPI-DSI bridge operation Bridge Connector Helper Reference --------------------------------- -.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c +.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c :export: Panel-Bridge Helper Reference @@ -224,6 +221,9 @@ Panel Helper Reference .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c :export: +.. kernel-doc:: drivers/gpu/drm/drm_panel_backlight_quirks.c + :export: + Panel Self Refresh Helper Reference =================================== diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 13d3627d8bc0..abfe220764e1 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -398,6 +398,21 @@ Plane Damage Tracking Functions Reference .. kernel-doc:: include/drm/drm_damage_helper.h :internal: +Plane Panic Feature +------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_panic.c + :doc: overview + +Plane Panic Functions Reference +------------------------------- + +.. kernel-doc:: include/drm/drm_panic.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_panic.c + :export: + Display Modes Function Reference ================================ @@ -496,6 +511,13 @@ addition to the one mentioned above: * An IGT test must be submitted where reasonable. +For historical reasons, non-standard, driver-specific properties exist. If a KMS +driver wants to add support for one of those properties, the requirements for +new properties apply where possible. Additionally, the documented behavior must +match the de facto semantics of the existing property to ensure compatibility. +Developers of the driver that first added the property should help with those +tasks and must ACK the documented behavior if possible. + Property Types and Blob Property Support ---------------------------------------- diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 370d820be248..b75cc9a70d1f 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -305,13 +305,26 @@ Kernel Mode Driver ------------------ The KMD is responsible for checking if the device needs a reset, and to perform -it as needed. Usually a hang is detected when a job gets stuck executing. KMD -should keep track of resets, because userspace can query any time about the -reset status for a specific context. This is needed to propagate to the rest of -the stack that a reset has happened. Currently, this is implemented by each -driver separately, with no common DRM interface. Ideally this should be properly -integrated at DRM scheduler to provide a common ground for all drivers. After a -reset, KMD should reject new command submissions for affected contexts. +it as needed. Usually a hang is detected when a job gets stuck executing. + +Propagation of errors to userspace has proven to be tricky since it goes in +the opposite direction of the usual flow of commands. Because of this vendor +independent error handling was added to the &dma_fence object, this way drivers +can add an error code to their fences before signaling them. See function +dma_fence_set_error() on how to do this and for examples of error codes to use. + +The DRM scheduler also allows setting error codes on all pending fences when +hardware submissions are restarted after an reset. Error codes are also +forwarded from the hardware fence to the scheduler fence to bubble up errors +to the higher levels of the stack and eventually userspace. + +Fence errors can be queried by userspace through the generic SYNC_IOC_FILE_INFO +IOCTL as well as through driver specific interfaces. + +Additional to setting fence errors drivers should also keep track of resets per +context, the DRM scheduler provides the drm_sched_entity_error() function as +helper for this use case. After a reset, KMD should reject new command +submissions for affected contexts. User Mode Driver ---------------- diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 7aca5c7a7b1d..b7fc106dad99 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -73,6 +73,11 @@ scope of each device, in which case `drm-pdev` shall be present as well. Userspace should make sure to not double account any usage statistics by using the above described criteria in order to associate data to individual clients. +- drm-client-name: <valstr> + +String optionally set by userspace using DRM_IOCTL_SET_CLIENT_NAME. + + Utilization ^^^^^^^^^^^ @@ -112,6 +117,19 @@ larger value within a reasonable period. Upon observing a value lower than what was previously read, userspace is expected to stay with that larger previous value until a monotonic update is seen. +- drm-total-cycles-<keystr>: <uint> + +Engine identifier string must be the same as the one specified in the +drm-cycles-<keystr> tag and shall contain the total number cycles for the given +engine. + +This is a timestamp in GPU unspecified unit that matches the update rate +of drm-cycles-<keystr>. For drivers that implement this interface, the engine +utilization can be calculated entirely on the GPU clock domain, without +considering the CPU sleep time between 2 samples. + +A driver may implement either this key or drm-maxfreq-<keystr>, but not both. + - drm-maxfreq-<keystr>: <uint> [Hz|MHz|KHz] Engine identifier string must be the same as the one specified in the @@ -121,42 +139,64 @@ percentage utilization of the engine, whereas drm-engine-<keystr> only reflects time active without considering what frequency the engine is operating as a percentage of its maximum frequency. +A driver may implement either this key or drm-total-cycles-<keystr>, but not +both. + Memory ^^^^^^ -- drm-memory-<region>: <uint> [KiB|MiB] +Each possible memory type which can be used to store buffer objects by the GPU +in question shall be given a stable and unique name to be used as the "<region>" +string. -Each possible memory type which can be used to store buffer objects by the -GPU in question shall be given a stable and unique name to be returned as the -string here. The name "memory" is reserved to refer to normal system memory. +The region name "memory" is reserved to refer to normal system memory. -Value shall reflect the amount of storage currently consumed by the buffer +The value shall reflect the amount of storage currently consumed by the buffer objects belong to this client, in the respective memory region. Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' indicating kibi- or mebi-bytes. -- drm-shared-<region>: <uint> [KiB|MiB] +- drm-total-<region>: <uint> [KiB|MiB] -The total size of buffers that are shared with another file (ie. have more -than a single handle). +The total size of all requested buffers, including both shared and private +memory. The backing store for the buffers does not need to be currently +instantiated to count under this category. To avoid double-counting, if a buffer +has multiple regions where it can be allocated to, the implementation should +consistently select a single region for accounting purposes. -- drm-total-<region>: <uint> [KiB|MiB] +- drm-shared-<region>: <uint> [KiB|MiB] -The total size of buffers that including shared and private memory. +The total size of buffers that are shared with another file (i.e., have more +than one handle). The same requirement to avoid double-counting that applies to +drm-total-<region> also applies here. - drm-resident-<region>: <uint> [KiB|MiB] -The total size of buffers that are resident in the specified region. +The total size of buffers that are resident (i.e., have their backing store +present or instantiated) in the specified region. + +- drm-memory-<region>: <uint> [KiB|MiB] + +This key is deprecated and is only printed by amdgpu; it is an alias for +drm-resident-<region>. - drm-purgeable-<region>: <uint> [KiB|MiB] -The total size of buffers that are purgeable. +The total size of buffers that are resident and purgeable. + +For example, drivers that implement functionality similar to 'madvise' can count +buffers that have instantiated backing stores but have been marked with an +equivalent of MADV_DONTNEED. - drm-active-<region>: <uint> [KiB|MiB] The total size of buffers that are active on one or more engines. +One practical example of this could be the presence of unsignaled fences in a +GEM buffer reservation object. Therefore, the active category is a subset of the +resident category. + Implementation Details ====================== @@ -168,5 +208,7 @@ be documented above and where possible, aligned with other drivers. Driver specific implementations ------------------------------- -:ref:`i915-usage-stats` -:ref:`panfrost-usage-stats` +* :ref:`i915-usage-stats` +* :ref:`panfrost-usage-stats` +* :ref:`panthor-usage-stats` +* :ref:`xe-usage-stats` diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 0ca1550fd9dc..7a469df675d8 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -35,10 +35,10 @@ Interrupt Handling :functions: intel_irq_init intel_irq_init_hw intel_hpd_init .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c - :functions: intel_runtime_pm_disable_interrupts + :functions: intel_irq_suspend .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c - :functions: intel_runtime_pm_enable_interrupts + :functions: intel_irq_resume Intel GVT-g Guest Support(vGPU) ------------------------------- @@ -150,7 +150,7 @@ High Definition Audio .. kernel-doc:: drivers/gpu/drm/i915/display/intel_audio.c :internal: -.. kernel-doc:: include/drm/i915_component.h +.. kernel-doc:: include/drm/intel/i915_component.h :internal: Intel HDMI LPE Audio Support @@ -204,6 +204,12 @@ DMC Firmware Support .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c :internal: +DMC wakelock support +-------------------- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc_wl.c + :doc: DMC wakelock support + Video BIOS Table (VBT) ---------------------- diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 37e383ccf73f..7dcb15850afd 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -13,6 +13,7 @@ GPU Driver Developer's Guide drm-usage-stats driver-uapi drm-client + drm-compute drivers backlight vga-switcheroo diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index f05eccd2c07c..3cd0c8860b94 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -154,21 +154,23 @@ Conference talks * `An Overview of the Linux and Userspace Graphics Stack <https://www.youtube.com/watch?v=wjAJmqwg47k>`_ - Paul Kocialkowski (2020) * `Getting pixels on screen on Linux: introduction to Kernel Mode Setting <https://www.youtube.com/watch?v=haes4_Xnc5Q>`_ - Simon Ser (2020) -* `Everything Great about Upstream Graphics <https://www.youtube.com/watch?v=kVzHOgt6WGE>`_ - Daniel Vetter (2019) +* `Everything Great about Upstream Graphics <https://www.youtube.com/watch?v=kVzHOgt6WGE>`_ - Simona Vetter (2019) * `An introduction to the Linux DRM subsystem <https://www.youtube.com/watch?v=LbDOCJcDRoo>`_ - Maxime Ripard (2017) -* `Embrace the Atomic (Display) Age <https://www.youtube.com/watch?v=LjiB_JeDn2M>`_ - Daniel Vetter (2016) +* `Embrace the Atomic (Display) Age <https://www.youtube.com/watch?v=LjiB_JeDn2M>`_ - Simona Vetter (2016) * `Anatomy of an Atomic KMS Driver <https://www.youtube.com/watch?v=lihqR9sENpc>`_ - Laurent Pinchart (2015) -* `Atomic Modesetting for Drivers <https://www.youtube.com/watch?v=kl9suFgbTc8>`_ - Daniel Vetter (2015) +* `Atomic Modesetting for Drivers <https://www.youtube.com/watch?v=kl9suFgbTc8>`_ - Simona Vetter (2015) * `Anatomy of an Embedded KMS Driver <https://www.youtube.com/watch?v=Ja8fM7rTae4>`_ - Laurent Pinchart (2013) Slides and articles ------------------- +* `The Linux graphics stack in a nutshell, part 1 <https://lwn.net/Articles/955376/>`_ - Thomas Zimmermann (2023) +* `The Linux graphics stack in a nutshell, part 2 <https://lwn.net/Articles/955708/>`_ - Thomas Zimmermann (2023) * `Understanding the Linux Graphics Stack <https://bootlin.com/doc/training/graphics/graphics-slides.pdf>`_ - Bootlin (2022) * `DRM KMS overview <https://wiki.st.com/stm32mpu/wiki/DRM_KMS_overview>`_ - STMicroelectronics (2021) * `Linux graphic stack <https://studiopixl.com/2017-05-13/linux-graphic-stack-an-overview>`_ - Nathan Gauër (2017) -* `Atomic mode setting design overview, part 1 <https://lwn.net/Articles/653071/>`_ - Daniel Vetter (2015) -* `Atomic mode setting design overview, part 2 <https://lwn.net/Articles/653466/>`_ - Daniel Vetter (2015) +* `Atomic mode setting design overview, part 1 <https://lwn.net/Articles/653071/>`_ - Simona Vetter (2015) +* `Atomic mode setting design overview, part 2 <https://lwn.net/Articles/653466/>`_ - Simona Vetter (2015) * `The DRM/KMS subsystem from a newbie’s point of view <https://bootlin.com/pub/conferences/2014/elce/brezillon-drm-kms/brezillon-drm-kms.pdf>`_ - Boris Brezillon (2014) * `A brief introduction to the Linux graphics stack <https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/>`_ - Iago Toral (2014) * `The Linux Graphics Stack <https://blog.mecheye.net/2012/06/the-linux-graphics-stack/>`_ - Jasper St. Pierre (2012) diff --git a/Documentation/gpu/kms-properties.csv b/Documentation/gpu/kms-properties.csv index 0f9590834829..bfbfbf4f102d 100644 --- a/Documentation/gpu/kms-properties.csv +++ b/Documentation/gpu/kms-properties.csv @@ -17,7 +17,6 @@ Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,De ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector ,,“suggested Y”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB -i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normally in the range 0..1.0 are remapped to the range 16/255..235/255." ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD @@ -38,7 +37,6 @@ i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:2 ,,“dot_crawl”,RANGE,"Min=0, Max=1",Connector,TBD ,SDVO-TV/LVDS,“brightness”,RANGE,"Min=0, Max= SDVO dependent",Connector,TBD CDV gma-500,Generic,"""Broadcast RGB""",ENUM,"{ “Full”, “Limited 16:235” }",Connector,TBD -,,"""Broadcast RGB""",ENUM,"{ “off”, “auto”, “on” }",Connector,TBD Poulsbo,Generic,“backlight”,RANGE,"Min=0, Max=100",Connector,TBD ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst index 633a016563ae..eaea40eb725b 100644 --- a/Documentation/gpu/komeda-kms.rst +++ b/Documentation/gpu/komeda-kms.rst @@ -86,7 +86,7 @@ types of working mode: - Single display mode Two pipelines work together to drive only one display output. - On this mode, pipeline_B doesn't work indenpendently, but outputs its + On this mode, pipeline_B doesn't work independently, but outputs its composition result into pipeline_A, and its pixel timing also derived from pipeline_A.timing_ctrlr. The pipeline_B works just like a "slave" of pipeline_A(master) diff --git a/Documentation/gpu/msm-preemption.rst b/Documentation/gpu/msm-preemption.rst new file mode 100644 index 000000000000..d768ca09fdec --- /dev/null +++ b/Documentation/gpu/msm-preemption.rst @@ -0,0 +1,99 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:orphan: + +============== +MSM Preemption +============== + +Preemption allows Adreno GPUs to switch to a higher priority ring when work is +pushed to it, reducing latency for high priority submissions. + +When preemption is enabled 4 rings are initialized, corresponding to different +priority levels. Having multiple rings is purely a software concept as the GPU +only has registers to keep track of one graphics ring. +The kernel is able to switch which ring is currently being processed by +requesting preemption. When certain conditions are met, depending on the +priority level, the GPU will save its current state in a series of buffers, +then restores state from a similar set of buffers specified by the kernel. It +then resumes execution and fires an IRQ to let the kernel know the context +switch has completed. + +This mechanism can be used by the kernel to switch between rings. Whenever a +submission occurs the kernel finds the highest priority ring which isn't empty +and preempts to it if said ring is not the one being currently executed. This is +also done whenever a submission completes to make sure execution resumes on a +lower priority ring when a higher priority ring is done. + +Preemption levels +----------------- + +Preemption can only occur at certain boundaries. The exact conditions can be +configured by changing the preemption level, this allows to compromise between +latency (ie. the time that passes between when the kernel requests preemption +and when the SQE begins saving state) and overhead (the amount of state that +needs to be saved). + +The GPU offers 3 levels: + +Level 0 + Preemption only occurs at the submission level. This requires the least amount + of state to be saved as the execution of userspace submitted IBs is never + interrupted, however it offers very little benefit compared to not enabling + preemption of any kind. + +Level 1 + Preemption occurs at either bin level, if using GMEM rendering, or draw level + in the sysmem rendering case. + +Level 2 + Preemption occurs at draw level. + +Level 1 is the mode that is used by the msm driver. + +Additionally the GPU allows to specify a `skip_save_restore` option. This +disables the saving and restoring of all registers except those relating to the +operation of the SQE itself, reducing overhead. Saving and restoring is only +skipped when using GMEM with Level 1 preemption. When enabling this userspace is +expected to set the state that isn't preserved whenever preemption occurs which +is done by specifying preamble and postambles. Those are IBs that are executed +before and after preemption. + +Preemption buffers +------------------ + +A series of buffers are necessary to store the state of rings while they are not +being executed. There are different kinds of preemption records and most of +those require one buffer per ring. This is because preemption never occurs +between submissions on the same ring, which always run in sequence when the ring +is active. This means that only one context per ring is effectively active. + +SMMU_INFO + This buffer contains info about the current SMMU configuration such as the + ttbr0 register. The SQE firmware isn't actually able to save this record. + As a result SMMU info must be saved manually from the CP to a buffer and the + SMMU record updated with info from said buffer before triggering + preemption. + +NON_SECURE + This is the main preemption record where most state is saved. It is mostly + opaque to the kernel except for the first few words that must be initialized + by the kernel. + +SECURE + This saves state related to the GPU's secure mode. + +NON_PRIV + The intended purpose of this record is unknown. The SQE firmware actually + ignores it and therefore msm doesn't handle it. + +COUNTER + This record is used to save and restore performance counters. + +Handling the permissions of those buffers is critical for security. All but the +NON_PRIV records need to be inaccessible from userspace, so they must be mapped +in the kernel address space with the MSM_BO_MAP_PRIV flag. +For example, making the NON_SECURE record accessible from userspace would allow +any process to manipulate a saved ring's RPTR which can be used to skip the +execution of some packets in a ring and execute user commands with higher +privileges. diff --git a/Documentation/gpu/panfrost.rst b/Documentation/gpu/panfrost.rst index b80e41f4b2c5..51ba375fd80d 100644 --- a/Documentation/gpu/panfrost.rst +++ b/Documentation/gpu/panfrost.rst @@ -38,3 +38,12 @@ the currently possible format options: Possible `drm-engine-` key names are: `fragment`, and `vertex-tiler`. `drm-curfreq-` values convey the current operating frequency for that engine. + +Users must bear in mind that engine and cycle sampling are disabled by default, +because of power saving concerns. `fdinfo` users and benchmark applications which +query the fdinfo file must make sure to toggle the job profiling status of the +driver by writing into the appropriate sysfs node:: + + echo <N> > /sys/bus/platform/drivers/panfrost/[a-f0-9]*.gpu/profiling + +Where `N` is either `0` or `1`, depending on the desired enablement status. diff --git a/Documentation/gpu/panthor.rst b/Documentation/gpu/panthor.rst new file mode 100644 index 000000000000..3f8979fa2b86 --- /dev/null +++ b/Documentation/gpu/panthor.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +========================= + drm/Panthor CSF driver +========================= + +.. _panthor-usage-stats: + +Panthor DRM client usage stats implementation +============================================== + +The drm/Panthor driver implements the DRM client usage stats specification as +documented in :ref:`drm-client-usage-stats`. + +Example of the output showing the implemented key value pairs and entirety of +the currently possible format options: + +:: + pos: 0 + flags: 02400002 + mnt_id: 29 + ino: 491 + drm-driver: panthor + drm-client-id: 10 + drm-engine-panthor: 111110952750 ns + drm-cycles-panthor: 94439687187 + drm-maxfreq-panthor: 1000000000 Hz + drm-curfreq-panthor: 1000000000 Hz + drm-total-memory: 16480 KiB + drm-shared-memory: 0 + drm-active-memory: 16200 KiB + drm-resident-memory: 16480 KiB + drm-purgeable-memory: 0 + +Possible `drm-engine-` key names are: `panthor`. +`drm-curfreq-` values convey the current operating frequency for that engine. + +Users must bear in mind that engine and cycle sampling are disabled by default, +because of power saving concerns. `fdinfo` users and benchmark applications which +query the fdinfo file must make sure to toggle the job profiling status of the +driver by writing into the appropriate sysfs node:: + + echo <N> > /sys/bus/platform/drivers/panthor/[a-f0-9]*.gpu/profiling + +Where `N` is a bit mask where cycle and timestamp sampling are respectively +enabled by the first and second bits. diff --git a/Documentation/gpu/rfc/i915_vm_bind.h b/Documentation/gpu/rfc/i915_vm_bind.h index 8a8fcd4fceac..bc26dc126104 100644 --- a/Documentation/gpu/rfc/i915_vm_bind.h +++ b/Documentation/gpu/rfc/i915_vm_bind.h @@ -93,12 +93,11 @@ struct drm_i915_gem_timeline_fence { * Multiple VA mappings can be created to the same section of the object * (aliasing). * - * The @start, @offset and @length must be 4K page aligned. However the DG2 - * and XEHPSDV has 64K page size for device local memory and has compact page - * table. On those platforms, for binding device local-memory objects, the - * @start, @offset and @length must be 64K aligned. Also, UMDs should not mix - * the local memory 64K page and the system memory 4K page bindings in the same - * 2M range. + * The @start, @offset and @length must be 4K page aligned. However the DG2 has + * 64K page size for device local memory and has compact page table. On that + * platform, for binding device local-memory objects, the @start, @offset and + * @length must be 64K aligned. Also, UMDs should not mix the local memory 64K + * page and the system memory 4K page bindings in the same 2M range. * * Error code -EINVAL will be returned if @start, @offset and @length are not * properly aligned. In version 1 (See I915_PARAM_VM_BIND_VERSION), error code diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index e4f7b005138d..476719771eef 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -31,7 +31,3 @@ host such documentation: .. toctree:: i915_vm_bind.rst - -.. toctree:: - - xe.rst diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst deleted file mode 100644 index 97cf87578f97..000000000000 --- a/Documentation/gpu/rfc/xe.rst +++ /dev/null @@ -1,234 +0,0 @@ -========================== -Xe – Merge Acceptance Plan -========================== -Xe is a new driver for Intel GPUs that supports both integrated and -discrete platforms starting with Tiger Lake (first Intel Xe Architecture). - -This document aims to establish a merge plan for the Xe, by writing down clear -pre-merge goals, in order to avoid unnecessary delays. - -Xe – Overview -============= -The main motivation of Xe is to have a fresh base to work from that is -unencumbered by older platforms, whilst also taking the opportunity to -rearchitect our driver to increase sharing across the drm subsystem, both -leveraging and allowing us to contribute more towards other shared components -like TTM and drm/scheduler. - -This is also an opportunity to start from the beginning with a clean uAPI that is -extensible by design and already aligned with the modern userspace needs. For -this reason, the memory model is solely based on GPU Virtual Address space -bind/unbind (‘VM_BIND’) of GEM buffer objects (BOs) and execution only supporting -explicit synchronization. With persistent mapping across the execution, the -userspace does not need to provide a list of all required mappings during each -submission. - -The new driver leverages a lot from i915. As for display, the intent is to share -the display code with the i915 driver so that there is maximum reuse there. - -As for the power management area, the goal is to have a much-simplified support -for the system suspend states (S-states), PCI device suspend states (D-states), -GPU/Render suspend states (R-states) and frequency management. It should leverage -as much as possible all the existent PCI-subsystem infrastructure (pm and -runtime_pm) and underlying firmware components such PCODE and GuC for the power -states and frequency decisions. - -Repository: - -https://gitlab.freedesktop.org/drm/xe/kernel (branch drm-xe-next) - -Xe – Platforms -============== -Currently, Xe is already functional and has experimental support for multiple -platforms starting from Tiger Lake, with initial support in userspace implemented -in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO -(for OpenCL and Level0). - -During a transition period, platforms will be supported by both Xe and i915. -However, the force_probe mechanism existent in both drivers will allow only one -official and by-default probe at a given time. - -For instance, in order to probe a DG2 which PCI ID is 0x5690 by Xe instead of -i915, the following set of parameters need to be used: - -``` -i915.force_probe=!5690 xe.force_probe=5690 -``` - -In both drivers, the ‘.require_force_probe’ protection forces the user to use the -force_probe parameter while the driver is under development. This protection is -only removed when the support for the platform and the uAPI are stable. Stability -which needs to be demonstrated by CI results. - -In order to avoid user space regressions, i915 will continue to support all the -current platforms that are already out of this protection. Xe support will be -forever experimental and dependent on the usage of force_probe for these -platforms. - -When the time comes for Xe, the protection will be lifted on Xe and kept in i915. - -Xe – Pre-Merge Goals - Work-in-Progress -======================================= - -Display integration with i915 ------------------------------ -In order to share the display code with the i915 driver so that there is maximum -reuse, the i915/display/ code is built twice, once for i915.ko and then for -xe.ko. Currently, the i915/display code in Xe tree is polluted with many 'ifdefs' -depending on the build target. The goal is to refactor both Xe and i915/display -code simultaneously in order to get a clean result before they land upstream, so -that display can already be part of the initial pull request towards drm-next. - -However, display code should not gate the acceptance of Xe in upstream. Xe -patches will be refactored in a way that display code can be removed, if needed, -from the first pull request of Xe towards drm-next. The expectation is that when -both drivers are part of the drm-tip, the introduction of cleaner patches will be -easier and speed up. - -Xe – uAPI high level overview -============================= - -...Warning: To be done in follow up patches after/when/where the main consensus in various items are individually reached. - -Xe – Pre-Merge Goals - Completed -================================ - -Drm_exec --------- -Helper to make dma_resv locking for a big number of buffers is getting removed in -the drm_exec series proposed in https://patchwork.freedesktop.org/patch/524376/ -If that happens, Xe needs to change and incorporate the changes in the driver. -The goal is to engage with the Community to understand if the best approach is to -move that to the drivers that are using it or if we should keep the helpers in -place waiting for Xe to get merged. - -This item ties into the GPUVA, VM_BIND, and even long-running compute support. - -As a key measurable result, we need to have a community consensus documented in -this document and the Xe driver prepared for the changes, if necessary. - -Userptr integration and vm_bind -------------------------------- -Different drivers implement different ways of dealing with execution of userptr. -With multiple drivers currently introducing support to VM_BIND, the goal is to -aim for a DRM consensus on what’s the best way to have that support. To some -extent this is already getting addressed itself with the GPUVA where likely the -userptr will be a GPUVA with a NULL GEM call VM bind directly on the userptr. -However, there are more aspects around the rules for that and the usage of -mmu_notifiers, locking and other aspects. - -This task here has the goal of introducing a documentation of the basic rules. - -The documentation *needs* to first live in this document (API session below) and -then moved to another more specific document or at Xe level or at DRM level. - -Documentation should include: - - * The userptr part of the VM_BIND api. - - * Locking, including the page-faulting case. - - * O(1) complexity under VM_BIND. - -The document is now included in the drm documentation :doc:`here </gpu/drm-vm-bind-async>`. - -Some parts of userptr like mmu_notifiers should become GPUVA or DRM helpers when -the second driver supporting VM_BIND+userptr appears. Details to be defined when -the time comes. - -The DRM GPUVM helpers do not yet include the userptr parts, but discussions -about implementing them are ongoing. - -ASYNC VM_BIND -------------- -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get -Xe merged, it is mandatory to have a consensus with other drivers and Mesa. -It needs to be clear how to handle async VM_BIND and interactions with userspace -memory fences. Ideally with helper support so people don't get it wrong in all -possible ways. - -As a key measurable result, the benefits of ASYNC VM_BIND and a discussion of -various flavors, error handling and sample API suggestions are documented in -:doc:`The ASYNC VM_BIND document </gpu/drm-vm-bind-async>`. - -Drm_scheduler -------------- -Xe primarily uses Firmware based scheduling (GuC FW). However, it will use -drm_scheduler as the scheduler ‘frontend’ for userspace submission in order to -resolve syncobj and dma-buf implicit sync dependencies. However, drm_scheduler is -not yet prepared to handle the 1-to-1 relationship between drm_gpu_scheduler and -drm_sched_entity. - -Deeper changes to drm_scheduler should *not* be required to get Xe accepted, but -some consensus needs to be reached between Xe and other community drivers that -could also benefit from this work, for coupling FW based/assisted submission such -as the ARM’s new Mali GPU driver, and others. - -As a key measurable result, the patch series introducing Xe itself shall not -depend on any other patch touching drm_scheduler itself that was not yet merged -through drm-misc. This, by itself, already includes the reach of an agreement for -uniform 1 to 1 relationship implementation / usage across drivers. - -Long running compute: minimal data structure/scaffolding --------------------------------------------------------- -The generic scheduler code needs to include the handling of endless compute -contexts, with the minimal scaffolding for preempt-ctx fences (probably on the -drm_sched_entity) and making sure drm_scheduler can cope with the lack of job -completion fence. - -The goal is to achieve a consensus ahead of Xe initial pull-request, ideally with -this minimal drm/scheduler work, if needed, merged to drm-misc in a way that any -drm driver, including Xe, could re-use and add their own individual needs on top -in a next stage. However, this should not block the initial merge. - -Dev_coredump ------------- - -Xe needs to align with other drivers on the way that the error states are -dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump -infrastructure to report error states, since it produces a standardized way -by exposing a virtual and temporary /sys/class/devcoredump device. - -As the key measurable result, Xe driver needs to provide GPU snapshots captured -at hang time through devcoredump, but without depending on any core modification -of devcoredump infrastructure itself. - -Later, when we are in-tree, the goal is to collaborate with devcoredump -infrastructure with overall possible improvements, like multiple file support -for better organization of the dumps, snapshot support, dmesg extra print, -and whatever may make sense and help the overall infrastructure. - -DRM_VM_BIND ------------ -Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to -fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the -development of a common new drm_infrastructure. However, the Xe team needs to -engage with the community to explore the options of a common API. - -As a key measurable result, the DRM_VM_BIND needs to be documented in this file -below, or this entire block deleted if the consensus is for independent drivers -vm_bind ioctls. - -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get -Xe merged, it is mandatory to enforce the overall locking scheme for all major -structs and list (so vm and vma). So, a consensus is needed, and possibly some -common helpers. If helpers are needed, they should be also documented in this -document. - -GPU VA ------- -Two main goals of Xe are meeting together here: - -1) Have an uAPI that aligns with modern UMD needs. - -2) Early upstream engagement. - -RedHat engineers working on Nouveau proposed a new DRM feature to handle keeping -track of GPU virtual address mappings. This is still not merged upstream, but -this aligns very well with our goals and with our VM_BIND. The engagement with -upstream and the port of Xe towards GPUVA is already ongoing. - -As a key measurable result, Xe needs to be aligned with the GPU VA and working in -our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA -related patch should be independent and present on dri-devel or acked by -maintainers to go along with the first Xe pull request towards drm-next. diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 41a264bf84ce..256d0d1cb216 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -37,7 +37,7 @@ Audit each individual driver, make sure it'll work with the generic implementation (there's lots of outdated locking leftovers in various implementations), and then remove it. -Contact: Daniel Vetter, respective driver maintainers +Contact: Simona Vetter, respective driver maintainers Level: Intermediate @@ -61,7 +61,7 @@ do by directly using the new atomic helper driver callbacks. .. [2] https://lwn.net/Articles/653071/ .. [3] https://lwn.net/Articles/653466/ -Contact: Daniel Vetter, respective driver maintainers +Contact: Simona Vetter, respective driver maintainers Level: Advanced @@ -75,7 +75,7 @@ helper should also be moved from drm_plane_helper.c to the atomic helpers, to avoid confusion - the other helpers in that file are all deprecated legacy helpers. -Contact: Ville Syrjälä, Daniel Vetter, driver maintainers +Contact: Ville Syrjälä, Simona Vetter, driver maintainers Level: Advanced @@ -97,7 +97,7 @@ with the current helpers: - Then we could go through all the drivers and remove the more-or-less confused checks for plane_state->fb and plane_state->crtc. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Advanced @@ -116,7 +116,30 @@ Somewhat related is the legacy_cursor_update hack, which should be replaced with the new atomic_async_check/commit functionality in the helpers in drivers that still look at that flag. -Contact: Daniel Vetter, respective driver maintainers +Contact: Simona Vetter, respective driver maintainers + +Level: Advanced + +Rename drm_atomic_state +----------------------- + +The KMS framework uses two slightly different definitions for the ``state`` +concept. For a given object (plane, CRTC, encoder, etc., so +``drm_$OBJECT_state``), the state is the entire state of that object. However, +at the device level, ``drm_atomic_state`` refers to a state update for a +limited number of objects. + +The state isn't the entire device state, but only the full state of some +objects in that device. This is confusing to newcomers, and +``drm_atomic_state`` should be renamed to something clearer like +``drm_atomic_commit``. + +In addition to renaming the structure itself, it would also imply renaming some +related functions (``drm_atomic_state_alloc``, ``drm_atomic_state_get``, +``drm_atomic_state_put``, ``drm_atomic_state_init``, +``__drm_atomic_state_free``, etc.). + +Contact: Maxime Ripard <mripard@kernel.org> Level: Advanced @@ -146,7 +169,7 @@ interfaces to fix these issues: ``_helper_funcs`` since they are not part of the core ABI. There's a ``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -171,7 +194,7 @@ performance-critical drivers it might also be better to go with a more fine-grained per-buffer object and per-context lockings scheme. Currently only the ``msm`` and `i915` drivers use ``struct_mutex``. -Contact: Daniel Vetter, respective driver maintainers +Contact: Simona Vetter, respective driver maintainers Level: Advanced @@ -220,19 +243,6 @@ Contact: Maintainer of the driver you plan to convert Level: Intermediate -Convert drivers to use drm_fbdev_generic_setup() ------------------------------------------------- - -Most drivers can use drm_fbdev_generic_setup(). Driver have to implement -atomic modesetting and GEM vmap support. Historically, generic fbdev emulation -expected the framebuffer in system memory or system-like memory. By employing -struct iosys_map, drivers with frambuffers in I/O memory can be supported -as well. - -Contact: Maintainer of the driver you plan to convert - -Level: Intermediate - Reimplement functions in drm_fbdev_fb_ops without fbdev ------------------------------------------------------- @@ -241,7 +251,7 @@ being rewritten without dependencies on the fbdev module. Some of the helpers could further benefit from using struct iosys_map instead of raw pointers. -Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter +Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter Level: Advanced @@ -287,7 +297,7 @@ Various hold-ups: version of the varios drm_gem_fb_create functions. Maybe called drm_gem_fb_create/_with_dirty/_with_funcs as needed. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -319,7 +329,7 @@ everything after it has done the write-protect/mkwrite trickery: Might be good to also have some igt testcases for this. -Contact: Daniel Vetter, Noralf Tronnes +Contact: Simona Vetter, Noralf Tronnes Level: Advanced @@ -349,7 +359,7 @@ between setting up the &drm_driver structure and calling drm_dev_register(). - Once all drivers are converted, remove the load/unload callbacks. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -412,7 +422,7 @@ The task is to use struct iosys_map where it makes sense. * TTM might benefit from using struct iosys_map internally. * Framebuffer copying and blitting helpers should operate on struct iosys_map. -Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vetter +Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Simona Vetter Level: Intermediate @@ -459,30 +469,50 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de> Level: Starter -Clean up checks for already prepared/enabled in panels ------------------------------------------------------- +Remove disable/unprepare in remove/shutdown in panel-simple and panel-edp +------------------------------------------------------------------------- + +As of commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in +drm_panel"), we have a check in the drm_panel core to make sure nobody +double-calls prepare/enable/disable/unprepare. Eventually that should probably +be turned into a WARN_ON() or somehow made louder. + +At the moment, we expect that we may still encounter the warnings in the +drm_panel core when using panel-simple and panel-edp. Since those panel +drivers are used with a lot of different DRM modeset drivers they still +make an extra effort to disable/unprepare the panel themsevles at shutdown +time. Specifically we could still encounter those warnings if the panel +driver gets shutdown() _before_ the DRM modeset driver and the DRM modeset +driver properly calls drm_atomic_helper_shutdown() in its own shutdown() +callback. Warnings could be avoided in such a case by using something like +device links to ensure that the panel gets shutdown() after the DRM modeset +driver. + +Once all DRM modeset drivers are known to shutdown properly, the extra +calls to disable/unprepare in remove/shutdown in panel-simple and panel-edp +should be removed and this TODO item marked complete. -In a whole pile of panel drivers, we have code to make the -prepare/unprepare/enable/disable callbacks behave as no-ops if they've already -been called. To get some idea of the duplicated code, try:: +Contact: Douglas Anderson <dianders@chromium.org> - git grep 'if.*>prepared' -- drivers/gpu/drm/panel - git grep 'if.*>enabled' -- drivers/gpu/drm/panel +Level: Intermediate -In the patch ("drm/panel: Check for already prepared/enabled in drm_panel") -we've moved this check to the core. Now we can most definitely remove the -check from the individual panels and save a pile of code. +Transition away from using mipi_dsi_*_write_seq() +------------------------------------------------- -In adition to removing the check from the individual panels, it is believed -that even the core shouldn't need this check and that should be considered -an error if other code ever relies on this check. The check in the core -currently prints a warning whenever something is relying on this check with -dev_warn(). After a little while, we likely want to promote this to a -WARN(1) to help encourage folks not to rely on this behavior. +The macros mipi_dsi_generic_write_seq() and mipi_dsi_dcs_write_seq() are +non-intuitive because, if there are errors, they return out of the *caller's* +function. We should move all callers to use mipi_dsi_generic_write_seq_multi() +and mipi_dsi_dcs_write_seq_multi() macros instead. + +Once all callers are transitioned, the macros and the functions that they call, +mipi_dsi_generic_write_chatty() and mipi_dsi_dcs_write_buffer_chatty(), can +probably be removed. Alternatively, if people feel like the _multi() variants +are overkill for some use cases, we could keep the mipi_dsi_*_write_seq() +variants but change them not to return out of the caller. Contact: Douglas Anderson <dianders@chromium.org> -Level: Starter/Intermediate +Level: Starter Core refactorings @@ -528,7 +558,7 @@ This is a really varied tasks with lots of little bits and pieces: <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_ for some example code that could be reused. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Advanced @@ -557,7 +587,7 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -578,7 +608,7 @@ Both these problems can be solved by switching over to drmm_kzalloc(), and the various convenience wrappers provided, e.g. drmm_crtc_alloc_with_planes(), drmm_universal_plane_alloc(), ... and so on. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -598,7 +628,7 @@ cache is also tied to &drm_gem_object.import_attach. Meanwhile we paper over this problem for USB devices by fishing out the USB host controller device, as long as that supports DMA. Otherwise importing can still needlessly fail. -Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter +Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter Level: Advanced @@ -679,7 +709,7 @@ Plan to fix this: 2. In all, only look at one of the three status bits set by the above helpers. 3. Remove the other two status bits. -Contact: Daniel Vetter +Contact: Simona Vetter Level: Intermediate @@ -804,6 +834,22 @@ Contact: Javier Martinez Canillas <javierm@redhat.com> Level: Advanced +Querying errors from drm_syncobj +================================ + +The drm_syncobj container can be used by driver independent code to signal +complection of submission. + +One minor feature still missing is a generic DRM IOCTL to query the error +status of binary and timeline drm_syncobj. + +This should probably be improved by implementing the necessary kernel interface +and adding support for that in the userspace stack. + +Contact: Christian König + +Level: Starter + Outside DRM =========== diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst index c224ecaee81e..92cfb25e64d3 100644 --- a/Documentation/gpu/xe/index.rst +++ b/Documentation/gpu/xe/index.rst @@ -23,3 +23,5 @@ DG2, etc is provided to prototype the driver. xe_firmware xe_tile xe_debugging + xe_devcoredump + xe-drm-usage-stats.rst diff --git a/Documentation/gpu/xe/xe-drm-usage-stats.rst b/Documentation/gpu/xe/xe-drm-usage-stats.rst new file mode 100644 index 000000000000..482d503ae68a --- /dev/null +++ b/Documentation/gpu/xe/xe-drm-usage-stats.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +.. _xe-usage-stats: + +======================================== +Xe DRM client usage stats implementation +======================================== + +.. kernel-doc:: drivers/gpu/drm/xe/xe_drm_client.c + :doc: DRM Client usage stats diff --git a/Documentation/gpu/xe/xe_devcoredump.rst b/Documentation/gpu/xe/xe_devcoredump.rst new file mode 100644 index 000000000000..ae4ec0e34dc0 --- /dev/null +++ b/Documentation/gpu/xe/xe_devcoredump.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +================== +Xe Device Coredump +================== + +.. kernel-doc:: drivers/gpu/drm/xe/xe_devcoredump.c + :doc: Xe device coredump + +Internal API +============ + +.. kernel-doc:: drivers/gpu/drm/xe/xe_devcoredump.c + :internal: diff --git a/Documentation/gpu/xe/xe_mm.rst b/Documentation/gpu/xe/xe_mm.rst index 6c8fd8b4a466..95864a4502dd 100644 --- a/Documentation/gpu/xe/xe_mm.rst +++ b/Documentation/gpu/xe/xe_mm.rst @@ -7,6 +7,21 @@ Memory Management .. kernel-doc:: drivers/gpu/drm/xe/xe_bo_doc.h :doc: Buffer Objects (BO) +GGTT +==== + +.. kernel-doc:: drivers/gpu/drm/xe/xe_ggtt.c + :doc: Global Graphics Translation Table (GGTT) + +GGTT Internal API +----------------- + +.. kernel-doc:: drivers/gpu/drm/xe/xe_ggtt_types.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/xe/xe_ggtt.c + :internal: + Pagetable building ================== diff --git a/Documentation/gpu/zynqmp.rst b/Documentation/gpu/zynqmp.rst new file mode 100644 index 000000000000..1a6f9193de22 --- /dev/null +++ b/Documentation/gpu/zynqmp.rst @@ -0,0 +1,147 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +=============================================== +Xilinx ZynqMP Ultrascale+ DisplayPort Subsystem +=============================================== + +This subsystem handles DisplayPort video and audio output on the ZynqMP. It +supports in-memory framebuffers with the DisplayPort DMA controller +(xilinx-dpdma), as well as "live" video and audio from the programmable logic +(PL). This subsystem can perform several transformations, including color space +conversion, alpha blending, and audio mixing, although not all features are +currently supported. + +debugfs +------- + +To support debugging and compliance testing, several test modes can be enabled +though debugfs. The following files in /sys/kernel/debug/dri/X/DP-1/test/ +control the DisplayPort test modes: + +active: + Writing a 1 to this file will activate test mode, and writing a 0 will + deactivate test mode. Writing a 1 or 0 when the test mode is already + active/inactive will re-activate/re-deactivate test mode. When test + mode is inactive, changes made to other files will have no (immediate) + effect, although the settings will be saved for when test mode is + activated. When test mode is active, changes made to other files will + apply immediately. + +custom: + Custom test pattern value + +downspread: + Enable/disable clock downspreading (spread-spectrum clocking) by + writing 1/0 + +enhanced: + Enable/disable enhanced framing + +ignore_aux_errors: + Ignore AUX errors when set to 1. Writes to this file take effect + immediately (regardless of whether test mode is active) and affect all + AUX transfers. + +ignore_hpd: + Ignore hotplug events (such as cable removals or monitor link + retraining requests) when set to 1. Writes to this file take effect + immediately (regardless of whether test mode is active). + +laneX_preemphasis: + Preemphasis from 0 (lowest) to 2 (highest) for lane X + +laneX_swing: + Voltage swing from 0 (lowest) to 3 (highest) for lane X + +lanes: + Number of lanes to use (1, 2, or 4) + +pattern: + Test pattern. May be one of: + + video + Use regular video input + + symbol-error + Symbol error measurement pattern + + prbs7 + Output of the PRBS7 (x^7 + x^6 + 1) polynomial + + 80bit-custom + A custom 80-bit pattern + + cp2520 + HBR2 compliance eye pattern + + tps1 + Link training symbol pattern TPS1 (/D10.2/) + + tps2 + Link training symbol pattern TPS2 + + tps3 + Link training symbol pattern TPS3 (for HBR2) + +rate: + Rate in hertz. One of + + * 5400000000 (HBR2) + * 2700000000 (HBR) + * 1620000000 (RBR) + +You can dump the displayport test settings with the following command:: + + for prop in /sys/kernel/debug/dri/1/DP-1/test/*; do + printf '%-17s ' ${prop##*/} + if [ ${prop##*/} = custom ]; then + hexdump -C $prop | head -1 + else + cat $prop + fi + done + +The output could look something like:: + + active 1 + custom 00000000 00 00 00 00 00 00 00 00 00 00 |..........| + downspread 0 + enhanced 1 + ignore_aux_errors 1 + ignore_hpd 1 + lane0_preemphasis 0 + lane0_swing 3 + lane1_preemphasis 0 + lane1_swing 3 + lanes 2 + pattern prbs7 + rate 1620000000 + +The recommended test procedure is to connect the board to a monitor, +configure test mode, activate test mode, and then disconnect the cable +and connect it to your test equipment of choice. For example, one +sequence of commands could be:: + + echo 1 > /sys/kernel/debug/dri/1/DP-1/test/enhanced + echo tps1 > /sys/kernel/debug/dri/1/DP-1/test/pattern + echo 1620000000 > /sys/kernel/debug/dri/1/DP-1/test/rate + echo 1 > /sys/kernel/debug/dri/1/DP-1/test/ignore_aux_errors + echo 1 > /sys/kernel/debug/dri/1/DP-1/test/ignore_hpd + echo 1 > /sys/kernel/debug/dri/1/DP-1/test/active + +at which point the cable could be disconnected from the monitor. + +Internals +--------- + +.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_disp.h + +.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_dpsub.h + +.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_kms.h + +.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_disp.c + +.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_dp.c + +.. kernel-doc:: drivers/gpu/drm/xlnx/zynqmp_kms.c |
