From 0102c8c7fdfc4bd700971daff2b94470f4eafae4 Mon Sep 17 00:00:00 2001 From: Dapeng Mi Date: Thu, 17 Sep 2026 09:52:33 +0800 Subject: perf/x86/intel: Rename DMR offcore_rsp attribute to offmodule_rsp DMR introduces Offmodule Response events in place of the legacy Offcore Response events, but it still exposes the inherited offcore_rsp PMU attribute for programming the corresponding MSR data. Rename the DMR PMU attribute to offmodule_rsp so the sysfs interface matches the underlying event name and avoids user & tooling confusion. Signed-off-by: Dapeng Mi Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://patch.msgid.link/20260917015234.981153-12-dapeng1.mi@linux.intel.com --- .../gpu/amdgpu/display/config_example.svg | 414 ++++++ .../gpu/amdgpu/display/dc-arch-overview.svg | 731 ++++++++++ Documentation/gpu/amdgpu/display/dc-components.svg | 732 ++++++++++ Documentation/gpu/amdgpu/display/dc-debug.rst | 305 ++++ Documentation/gpu/amdgpu/display/dc-glossary.rst | 228 +++ .../gpu/amdgpu/display/dc_pipeline_overview.svg | 1125 ++++++++++++++ Documentation/gpu/amdgpu/display/dcn-blocks.rst | 57 + Documentation/gpu/amdgpu/display/dcn-overview.rst | 232 +++ .../gpu/amdgpu/display/dcn2_cm_drm_current.svg | 1370 ++++++++++++++++++ .../gpu/amdgpu/display/dcn3_cm_drm_current.svg | 1529 ++++++++++++++++++++ .../gpu/amdgpu/display/display-contributing.rst | 168 +++ .../gpu/amdgpu/display/display-manager.rst | 189 +++ .../gpu/amdgpu/display/global_sync_vblank.svg | 485 +++++++ Documentation/gpu/amdgpu/display/index.rst | 97 ++ Documentation/gpu/amdgpu/display/mpo-cursor.svg | 435 ++++++ Documentation/gpu/amdgpu/display/mpo-overview.rst | 242 ++++ .../multi-display-hdcp-mpo-less-pipe-ex.svg | 220 +++ .../gpu/amdgpu/display/multi-display-hdcp-mpo.svg | 171 +++ .../gpu/amdgpu/display/pipeline_4k_no_split.svg | 958 ++++++++++++ .../gpu/amdgpu/display/pipeline_4k_split.svg | 1062 ++++++++++++++ .../gpu/amdgpu/display/programming-model-dcn.rst | 162 +++ .../display/single-display-mpo-multi-video.svg | 339 +++++ .../gpu/amdgpu/display/single-display-mpo.svg | 266 ++++ .../gpu/amdgpu/display/trace-groups-table.csv | 29 + 24 files changed, 11546 insertions(+) create mode 100644 Documentation/gpu/amdgpu/display/config_example.svg create mode 100644 Documentation/gpu/amdgpu/display/dc-arch-overview.svg create mode 100644 Documentation/gpu/amdgpu/display/dc-components.svg create mode 100644 Documentation/gpu/amdgpu/display/dc-debug.rst create mode 100644 Documentation/gpu/amdgpu/display/dc-glossary.rst create mode 100644 Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg create mode 100644 Documentation/gpu/amdgpu/display/dcn-blocks.rst create mode 100644 Documentation/gpu/amdgpu/display/dcn-overview.rst create mode 100644 Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg create mode 100644 Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg create mode 100644 Documentation/gpu/amdgpu/display/display-contributing.rst create mode 100644 Documentation/gpu/amdgpu/display/display-manager.rst create mode 100644 Documentation/gpu/amdgpu/display/global_sync_vblank.svg create mode 100644 Documentation/gpu/amdgpu/display/index.rst create mode 100644 Documentation/gpu/amdgpu/display/mpo-cursor.svg create mode 100644 Documentation/gpu/amdgpu/display/mpo-overview.rst create mode 100644 Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg create mode 100644 Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_split.svg create mode 100644 Documentation/gpu/amdgpu/display/programming-model-dcn.rst create mode 100644 Documentation/gpu/amdgpu/display/single-display-mpo-multi-video.svg create mode 100644 Documentation/gpu/amdgpu/display/single-display-mpo.svg create mode 100644 Documentation/gpu/amdgpu/display/trace-groups-table.csv (limited to 'Documentation/gpu/amdgpu/display') diff --git a/Documentation/gpu/amdgpu/display/config_example.svg b/Documentation/gpu/amdgpu/display/config_example.svg new file mode 100644 index 000000000..cdac98586 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/config_example.svg @@ -0,0 +1,414 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + Configurations + A + B + C + + + + + + A + B + C + C + Old config + Old config + + + VUpdate + UpdateLock + Register updatePending Status + Buf 0 + Buf 1 + + 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 000000000..23394931c --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-arch-overview.svg @@ -0,0 +1,731 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + Board/Platform + SoC + Component + DRAM + + dc_plane + + + + dc_plane + + + + + DC + + + + + dc_link + + + + + dc_link + + + + + + + dc_link + + + + + + + + + + + DCN + SoC + Board/Platform + Display + Connector + Connector + + diff --git a/Documentation/gpu/amdgpu/display/dc-components.svg b/Documentation/gpu/amdgpu/display/dc-components.svg new file mode 100644 index 000000000..f84bb2a57 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-components.svg @@ -0,0 +1,732 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + Core + + + + + + + + + + Display Core API (dc/dc.h) + Link + Hardware Sequencer API(dc/inc/hw_sequence.h) + Hardware Sequencer + Block Level API (dc/inc/hw) + + + DCHUB + + + + HUBP + + + + DPP + + + + MPC + + + + ... + + Hardware Registers + DMUBBlock + DMUB Hardware API(dmub/dmub_srv.h) + DMUB Service + DMUB Service API(dc/dc_dmub_srv.h) + + diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst b/Documentation/gpu/amdgpu/display/dc-debug.rst new file mode 100644 index 000000000..605dca21f --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-debug.rst @@ -0,0 +1,305 @@ +======================== +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 + [ 4.260318] [drm] add ip block number 1 + [ 4.260510] [drm] add ip block number 2 + [ 4.260696] [drm] add ip block number 3 + [ 4.260878] [drm] add ip block number 4 + [ 4.261057] [drm] add ip block number 5 + [ 4.261231] [drm] add ip block number 6 + [ 4.261402] [drm] add ip block number 7 + [ 4.261568] [drm] add ip block number 8 + [ 4.261729] [drm] add ip block number 9 + [ 4.261887] [drm] add ip block number 10 + +From the above example, you can see the line that reports that ``, +(**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 `, + 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 + [ 4.260318] [drm] add ip block number 1 + [..] + [ 4.261057] [drm] add ip block number 5 + +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 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 +====================== + +Display core provides a feature named visual confirmation, which is a set of +bars added at the scanout time by the driver to convey some specific +information. In general, you can enable this debug option by using:: + + echo > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +Where `N` is an integer number for some specific scenarios that the developer +wants to enable, you will see some of these debug cases in the following +subsection. + +Multiple Planes Debug +--------------------- + +If you want to enable or debug multiple planes in a specific user-space +application, you can leverage a debug feature named visual confirm. For +enabling it, you will need:: + + echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +You need to reload your GUI to see the visual confirmation. When the plane +configuration changes or a full update occurs there will be a colored bar at +the bottom of each hardware plane being drawn on the screen. + +* The color indicates the format - For example, red is AR24 and green is NV12 +* The height of the bar indicates the index of the plane +* Pipe split can be observed if there are two bars with a difference in height + covering the same plane + +Consider the video playback case in which a video is played in a specific +plane, and the desktop is drawn in another plane. The video plane should +feature one or two green bars at the bottom of the video depending on pipe +split configuration. + +* There should **not** be any visual corruption +* There should **not** be any underflow or screen flashes +* There should **not** be any black screens +* There should **not** be any cursor corruption +* Multiple plane **may** be briefly disabled during window transitions or + resizing but should come back after the action has finished + +Pipe Split Debug +---------------- + +Sometimes we need to debug if DCN is splitting pipes correctly, and visual +confirmation is also handy for this case. Similar to the MPO case, you can use +the below command to enable visual confirmation:: + + echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +In this case, if you have a pipe split, you will see one small red bar at the +bottom of the display covering the entire display width and another bar +covering the second pipe. In other words, you will see a bit high bar in the +second pipe. + +DTN Debug +========= + +DC (DCN) provides an extensive log that dumps multiple details from our +hardware configuration. Via debugfs, you can capture those status values by +using Display Test Next (DTN) log, which can be captured via debugfs by using:: + + cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log + +Since this log is updated accordingly with DCN status, you can also follow the +change in real-time by using something like:: + + sudo watch -d cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log + +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 +=================== + +Sometimes, dmesg logs aren't enough. This is especially true if a feature is +implemented primarily in DMUB firmware. In such cases, all we see in dmesg when +an issue arises is some generic timeout error. So, to get more relevant +information, we can trace DMUB commands by enabling the relevant bits in +`amdgpu_dm_dmub_trace_mask`. + +Currently, we support the tracing of the following groups: + +Trace Groups +------------ + +.. csv-table:: + :header-rows: 1 + :widths: 1, 1 + :file: ./trace-groups-table.csv + +**Note: Not all ASICs support all of the listed trace groups** + +So, to enable just PSR tracing you can use the following command:: + + # echo 0x8020 > /sys/kernel/debug/dri/0/amdgpu_dm_dmub_trace_mask + +Then, you need to enable logging trace events to the buffer, which you can do +using the following:: + + # echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en + +Lastly, after you are able to reproduce the issue you are trying to debug, +you can disable tracing and read the trace log by using the following:: + + # echo 0 > /sys/kernel/debug/dri/0/amdgpu_dm_dmcub_trace_event_en + # cat /sys/kernel/debug/dri/0/amdgpu_dm_dmub_tracebuffer + +So, when reporting bugs related to features such as PSR and ABM, consider +enabling the relevant bits in the mask before reproducing the issue and +attach the log that you obtain from the trace buffer in any bug reports that you +create. diff --git a/Documentation/gpu/amdgpu/display/dc-glossary.rst b/Documentation/gpu/amdgpu/display/dc-glossary.rst new file mode 100644 index 000000000..accb7c053 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-glossary.rst @@ -0,0 +1,228 @@ +=========== +DC Glossary +=========== + +On this page, we try to keep track of acronyms related to the display +component. If you do not find what you are looking for, look at the +'Documentation/gpu/amdgpu/amdgpu-glossary.rst'; if you cannot find it anywhere, +consider asking on the amd-gfx mailing list and update this page. + +.. glossary:: + + ABM + Adaptive Backlight Modulation + + APU + Accelerated Processing Unit + + ASIC + Application-Specific Integrated Circuit + + ASSR + Alternate Scrambler Seed Reset + + AZ + Azalia (HD audio DMA engine) + + BPC + Bits Per Colour/Component + + BPP + Bits Per Pixel + + Clocks + * PCLK: Pixel Clock + * SYMCLK: Symbol Clock + * SOCCLK: GPU Engine Clock + * DISPCLK: Display Clock + * DPPCLK: DPP Clock + * DCFCLK: Display Controller Fabric Clock + * REFCLK: Real Time Reference Clock + * PPLL: Pixel PLL + * FCLK: Fabric Clock + * MCLK: Memory Clock + + CRC + Cyclic Redundancy Check + + CRTC + Cathode Ray Tube Controller - commonly called "Controller" - Generates + raw stream of pixels, clocked at pixel clock + + CVT + Coordinated Video Timings + + DAL + Display Abstraction layer + + DC (Software) + Display Core + + DC (Hardware) + Display Controller + + DCC + Delta Colour Compression + + DCE + Display Controller Engine + + DCHUB + Display Controller HUB + + ARB + Arbiter + + VTG + Vertical Timing Generator + + DCN + Display Core Next + + DCCG + Display Clock Generator block + + DDC + Display Data Channel + + DIO + Display IO + + DPP + Display Pipes and Planes + + DSC + Display Stream Compression (Reduce the amount of bits to represent pixel + count while at the same pixel clock) + + dGPU + discrete GPU + + DMIF + Display Memory Interface + + DML + Display Mode Library + + DMCU + Display Micro-Controller Unit + + DMCUB + Display Micro-Controller Unit, version B + + DPCD + DisplayPort Configuration Data + + DPM(S) + Display Power Management (Signaling) + + DRR + Dynamic Refresh Rate + + DWB + Display Writeback + + FB + Frame Buffer + + FBC + Frame Buffer Compression + + FEC + Forward Error Correction + + FRL + Fixed Rate Link + + GCO + Graphical Controller Object + + GSL + Global Swap Lock + + iGPU + integrated GPU + + ISR + Interrupt Service Request + + ISV + Independent Software Vendor + + KMD + Kernel Mode Driver + + LB + Line Buffer + + LFC + Low Framerate Compensation + + LTTPR + Link Training Tunable Phy Repeater + + LUT + Lookup Table + + MALL + Memory Access at Last Level + + MPC/MPCC + Multiple pipes and plane combine + + MPO + Multi Plane Overlay + + MST + Multi Stream Transport + + NBP State + Northbridge Power State + + NBIO + North Bridge Input/Output + + ODM + Output Data Mapping + + OPM + Output Protection Manager + + OPP + Output Plane Processor + + OPTC + Output Pipe Timing Combiner + + OTG + Output Timing Generator + + PCON + Power Controller + + PGFSM + Power Gate Finite State Machine + + PSR + Panel Self Refresh + + SCL + Scaler + + SDP + Scalable Data Port + + SLS + Single Large Surface + + SST + Single Stream Transport + + TMDS + Transition-Minimized Differential Signaling + + TTU + Time to Underflow + + VRR + Variable Refresh Rate diff --git a/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg b/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg new file mode 100644 index 000000000..9adecebfe --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg @@ -0,0 +1,1125 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + DCHUB + HUBP(n) + + + DPP(n) + + + + MPC + + + + OPTC + + + + DIO + + + + DCCG + + + + DMU + + + + + AZ + + + + MMHUBBUB + + + + DWB(n) + + + + + + + + + + + + + Global sync + Pixel data + Sideband signal + Config. Bus + + SDP + + Monitor + + OPP + + + + + + + + + + + + + dc_plane + dc_stream + + + + dc_state + + + + Code struct + + + + dc_link + + + + Floating pointcalculation + + + + bit-depthreduction/dither + } + Notes + + diff --git a/Documentation/gpu/amdgpu/display/dcn-blocks.rst b/Documentation/gpu/amdgpu/display/dcn-blocks.rst new file mode 100644 index 000000000..756957128 --- /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 new file mode 100644 index 000000000..eb54a6802 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst @@ -0,0 +1,232 @@ +.. _dcn_overview: + +======================= +Display Core Next (DCN) +======================= + +To equip our readers with the basic knowledge of how AMD Display Core Next +(DCN) works, we need to start with an overview of the hardware pipeline. Below +you can see a picture that provides a DCN overview, keep in mind that this is a +generic diagram, and we have variations per ASIC. + +.. kernel-figure:: dc_pipeline_overview.svg + +Based on this diagram, we can pass through each block and briefly describe +them: + +* **Display Controller Hub (DCHUB)**: This is the gateway between the Scalable + Data Port (SDP) and DCN. This component has multiple features, such as memory + arbitration, rotation, and cursor manipulation. + +* **Display Pipe and Plane (DPP)**: This block provides pre-blend pixel + processing such as color space conversion, linearization of pixel data, tone + mapping, and gamut mapping. + +* **Multiple Pipe/Plane Combined (MPC)**: This component performs blending of + multiple planes, using global or per-pixel alpha. + +* **Output Pixel Processing (OPP)**: Process and format pixels to be sent to + the display. + +* **Output Pipe Timing Combiner (OPTC)**: It generates time output to combine + streams or divide capabilities. CRC values are generated in this block. + +* **Display Output (DIO)**: Codify the output to the display connected to our + GPU. + +* **Display Writeback (DWB)**: It provides the ability to write the output of + the display pipe back to memory as video frames. + +* **Multi-Media HUB (MMHUBBUB)**: Memory controller interface for DMCUB and DWB + (Note that DWB is not hooked yet). + +* **DCN Management Unit (DMU)**: It provides registers with access control and + interrupts the controller to the SOC host interrupt unit. This block includes + the Display Micro-Controller Unit - version B (DMCUB), which is handled via + firmware. + +* **DCN Clock Generator Block (DCCG)**: It provides the clocks and resets + for all of the display controller clock domains. + +* **Azalia (AZ)**: Audio engine. + +The above diagram is an architecture generalization of DCN, which means that +every ASIC has variations around this base model. Notice that the display +pipeline is connected to the Scalable Data Port (SDP) via DCHUB; you can see +the SDP as the element from our Data Fabric that feeds the display pipe. + +Always approach the DCN architecture as something flexible that can be +configured and reconfigured in multiple ways; in other words, each block can be +setup or ignored accordingly with userspace demands. For example, if we +want to drive an 8k@60Hz with a DSC enabled, our DCN may require 4 DPP and 2 +OPP. It is DC's responsibility to drive the best configuration for each +specific scenario. Orchestrate all of these components together requires a +sophisticated communication interface which is highlighted in the diagram by +the edges that connect each block; from the chart, each connection between +these blocks represents: + +1. Pixel data interface (red): Represents the pixel data flow; +2. Global sync signals (green): It is a set of synchronization signals composed + by VStartup, VUpdate, and VReady; +3. Config interface: Responsible to configure blocks; +4. Sideband signals: All other signals that do not fit the previous one. + +These signals are essential and play an important role in DCN. Nevertheless, +the Global Sync deserves an extra level of detail described in the next +section. + +All of these components are represented by a data structure named dc_state. +From DCHUB to MPC, we have a representation called dc_plane; from MPC to OPTC, +we have dc_stream, and the output (DIO) is handled by dc_link. Keep in mind +that HUBP accesses a surface using a specific format read from memory, and our +dc_plane should work to convert all pixels in the plane to something that can +be sent to the display via dc_stream and dc_link. + +Front End and Back End +---------------------- + +Display pipeline can be broken down into two components that are usually +referred as **Front End (FE)** and **Back End (BE)**, where FE consists of: + +* DCHUB (Mainly referring to a subcomponent named HUBP) +* DPP +* MPC + +On the other hand, BE consist of + +* OPP +* OPTC +* DIO (DP/HDMI stream encoder and link encoder) + +OPP and OPTC are two joining blocks between FE and BE. On a side note, this is +a one-to-one mapping of the link encoder to PHY, but we can configure the DCN +to choose which link encoder to connect to which PHY. FE's main responsibility +is to change, blend and compose pixel data, while BE's job is to frame a +generic pixel stream to a specific display's pixel stream. + +Data Flow +--------- + +Initially, data is passed in from VRAM through Data Fabric (DF) in native pixel +formats. Such data format stays through till HUBP in DCHUB, where HUBP unpacks +different pixel formats and outputs them to DPP in uniform streams through 4 +channels (1 for alpha + 3 for colors). + +The Converter and Cursor (CNVC) in DPP would then normalize the data +representation and convert them to a DCN specific floating-point format (i.e., +different from the IEEE floating-point format). In the process, CNVC also +applies a degamma function to transform the data from non-linear to linear +space to relax the floating-point calculations following. Data would stay in +this floating-point format from DPP to OPP. + +Starting OPP, because color transformation and blending have been completed +(i.e alpha can be dropped), and the end sinks do not require the precision and +dynamic range that floating points provide (i.e. all displays are in integer +depth format), bit-depth reduction/dithering would kick in. In OPP, we would +also apply a regamma function to introduce the gamma removed earlier back. +Eventually, we output data in integer format at DIO. + +AMD Hardware Pipeline +--------------------- + +When discussing graphics on Linux, the **pipeline** term can sometimes be +overloaded with multiple meanings, so it is important to define what we mean +when we say **pipeline**. In the DCN driver, we use the term **hardware +pipeline** or **pipeline** or just **pipe** as an abstraction to indicate a +sequence of DCN blocks instantiated to address some specific configuration. DC +core treats DCN blocks as individual resources, meaning we can build a pipeline +by taking resources for all individual hardware blocks to compose one pipeline. +In actuality, we can't connect an arbitrary block from one pipe to a block from +another pipe; they are routed linearly, except for DSC, which can be +arbitrarily assigned as needed. We have this pipeline concept for trying to +optimize bandwidth utilization. + +.. kernel-figure:: pipeline_4k_no_split.svg + +Additionally, let's take a look at parts of the DTN log (see +'Documentation/gpu/amdgpu/display/dc-debug.rst' for more information) since +this log can help us to see part of this pipeline behavior in real-time:: + + HUBP: format addr_hi width height ... + [ 0]: 8h 81h 3840 2160 + [ 1]: 0h 0h 0 0 + [ 2]: 0h 0h 0 0 + [ 3]: 0h 0h 0 0 + [ 4]: 0h 0h 0 0 + ... + MPCC: OPP DPP ... + [ 0]: 0h 0h ... + +The first thing to notice from the diagram and DTN log it is the fact that we +have different clock domains for each part of the DCN blocks. In this example, +we have just a single **pipeline** where the data flows from DCHUB to DIO, as +we intuitively expect. Nonetheless, DCN is flexible, as mentioned before, and +we can split this single pipe differently, as described in the below diagram: + +.. kernel-figure:: pipeline_4k_split.svg + +Now, if we inspect the DTN log again we can see some interesting changes:: + + HUBP: format addr_hi width height ... + [ 0]: 8h 81h 1920 2160 ... + ... + [ 4]: 0h 0h 0 0 ... + [ 5]: 8h 81h 1920 2160 ... + ... + MPCC: OPP DPP ... + [ 0]: 0h 0h ... + [ 5]: 0h 5h ... + +From the above example, we now split the display pipeline into two vertical +parts of 1920x2160 (i.e., 3440x2160), and as a result, we could reduce the +clock frequency in the DPP part. This is not only useful for saving power but +also to better handle the required throughput. The idea to keep in mind here is +that the pipe configuration can vary a lot according to the display +configuration, and it is the DML's responsibility to set up all required +configuration parameters for multiple scenarios supported by our hardware. + +Global Sync +----------- + +Many DCN registers are double buffered, most importantly the surface address. +This allows us to update DCN hardware atomically for page flips, as well as +for most other updates that don't require enabling or disabling of new pipes. + +(Note: There are many scenarios when DC will decide to reserve extra pipes +in order to support outputs that need a very high pixel clock, or for +power saving purposes.) + +These atomic register updates are driven by global sync signals in DCN. In +order to understand how atomic updates interact with DCN hardware, and how DCN +signals page flip and vblank events it is helpful to understand how global sync +is programmed. + +Global sync consists of three signals, VSTARTUP, VUPDATE, and VREADY. These are +calculated by the Display Mode Library - DML (drivers/gpu/drm/amd/display/dc/dml) +based on a large number of parameters and ensure our hardware is able to feed +the DCN pipeline without underflows or hangs in any given system configuration. +The global sync signals always happen during VBlank, are independent from the +VSync signal, and do not overlap each other. + +VUPDATE is the only signal that is of interest to the rest of the driver stack +or userspace clients as it signals the point at which hardware latches to +atomically programmed (i.e. double buffered) registers. Even though it is +independent of the VSync signal we use VUPDATE to signal the VSync event as it +provides the best indication of how atomic commits and hardware interact. + +Since DCN hardware is double-buffered the DC driver is able to program the +hardware at any point during the frame. + +The below picture illustrates the global sync signals: + +.. kernel-figure:: global_sync_vblank.svg + +These signals affect core DCN behavior. Programming them incorrectly will lead +to a number of negative consequences, most of them quite catastrophic. + +The following picture shows how global sync allows for a mailbox style of +updates, i.e. it allows for multiple re-configurations between VUpdate +events where only the last configuration programmed before the VUpdate signal +becomes effective. + +.. kernel-figure:: config_example.svg diff --git a/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg new file mode 100644 index 000000000..315ffc5a1 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg @@ -0,0 +1,1370 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Matrix + 1D LUT + 3D LUT + Unpacking + Other + drm_framebuffer + format + drm_plane + drm_crtc + Stream + MPC + DPP + + Blender + Degamma + CTM + Gamma + format + bias_and_scale + color space matrix + input_csc_color_matrix + in_transfer_func + hdr_mult + gamut_remap_matrix + in_shaper_func + lut3d_func + blend_tf + Blender + gamut_remap_matrix + func_shaper + lut3d_func + out_transfer_func + csc_color_matrix + bit_depth_param + clamping + output_color_space + Plane + Legend + DCN 2.0 + DC Interface + DRM Interface + + CNVC + Input CSC + DeGammaRAM and ROM(sRGB, BT2020 + HDR Multiply + Gamut Remap + Shaper LUTRAM + 3D LUTRAM + Blend Gamma + Blender + GammaRAM + OCSC + + + color_encoding + + pixel_blend_mode + + color_range + + + + + + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg new file mode 100644 index 000000000..7299ee9b6 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg @@ -0,0 +1,1529 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Matrix + 1D LUT + 3D LUT + Unpacking + Other + drm_framebuffer + format + drm_plane + drm_crtc + Stream + MPC + DPP + + Blender + Degamma + CTM + Gamma + format + bias_and_scale + color space matrix + input_csc_color_matrix + in_transfer_func + hdr_mult + gamut_remap_matrix + in_shaper_func + lut3d_func + blend_tf + Blender + gamut_remap_matrix + func_shaper + lut3d_func + out_transfer_func + csc_color_matrix + bit_depth_param + clamping + output_color_space + Plane + Legend + DCN 3.0 + DC Interface + DRM Interface + + CNVC + Input CSC + DeGammaROM(sRGB, BT2020, Gamma 2.2,PQ, HLG) + Post CSC + Gamma Correction + HDR Multiply + Gamut Remap + Shaper LUTRAM + 3D LUTRAM + Blend Gamma + Blender + Gamut Remap + Shaper LUTRAM + 3D LUTRAM + GammaRAM + OCSC + + + color_encoding + + pixel_blend_mode + + color_range + + + + + + + + + + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/display-contributing.rst b/Documentation/gpu/amdgpu/display/display-contributing.rst new file mode 100644 index 000000000..2f741c52d --- /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 +on the amd-gfx mailing list 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 new file mode 100644 index 000000000..f6de9e777 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -0,0 +1,189 @@ +====================== +AMDgpu Display Manager +====================== + +.. contents:: Table of Contents + :depth: 3 + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h + :internal: + +Lifecycle +========= + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: DM Lifecycle + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :functions: dm_hw_init dm_hw_fini + +Interrupts +========== + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c + :internal: + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_display.c + :functions: amdgpu_display_hotplug_work_func + +Atomic Implementation +===================== + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: atomic + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail + +Color Management Properties +=========================== + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c + :internal: + + +DC Color Capabilities between DCN generations +--------------------------------------------- + +DRM/KMS framework defines three CRTC color correction properties: degamma, +color transformation matrix (CTM) and gamma, and two properties for degamma and +gamma LUT sizes. AMD DC programs some of the color correction features +pre-blending but DRM/KMS has not per-plane color correction properties. + +In general, the DRM CRTC color properties are programmed to DC, as follows: +CRTC gamma after blending, and CRTC degamma pre-blending. Although CTM is +programmed after blending, it is mapped to DPP hw blocks (pre-blending). Other +color caps available in the hw is not currently exposed by DRM interface and +are bypassed. + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/dc.h + :doc: color-management-caps + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/dc.h + :internal: + +The color pipeline has undergone major changes between DCN hardware +generations. What's possible to do before and after blending depends on +hardware capabilities, as illustrated below by the DCN 2.0 and DCN 3.0 families +schemas. + +**DCN 2.0 family color caps and mapping** + +.. kernel-figure:: dcn2_cm_drm_current.svg + +**DCN 3.0 family color caps and mapping** + +.. kernel-figure:: dcn3_cm_drm_current.svg + +Blend Mode Properties +===================== + +Pixel blend mode is a DRM plane composition property of :c:type:`drm_plane` used to +describes how pixels from a foreground plane (fg) are composited with the +background plane (bg). Here, we present main concepts of DRM blend mode to help +to understand how this property is mapped to AMD DC interface. See more about +this DRM property and the alpha blending equations in :ref:`DRM Plane +Composition Properties `. + +Basically, a blend mode sets the alpha blending equation for plane +composition that fits the mode in which the alpha channel affects the state of +pixel color values and, therefore, the resulted pixel color. For +example, consider the following elements of the alpha blending equation: + +- *fg.rgb*: Each of the RGB component values from the foreground's pixel. +- *fg.alpha*: Alpha component value from the foreground's pixel. +- *bg.rgb*: Each of the RGB component values from the background. +- *plane_alpha*: Plane alpha value set by the **plane "alpha" property**, see + more in :ref:`DRM Plane Composition Properties `. + +in the basic alpha blending equation:: + + out.rgb = alpha * fg.rgb + (1 - alpha) * bg.rgb + +the alpha channel value of each pixel in a plane is ignored and only the plane +alpha affects the resulted pixel color values. + +DRM has three blend mode to define the blend formula in the plane composition: + +* **None**: Blend formula that ignores the pixel alpha. + +* **Pre-multiplied**: Blend formula that assumes the pixel color values in a + plane was already pre-multiplied by its own alpha channel before storage. + +* **Coverage**: Blend formula that assumes the pixel color values were not + pre-multiplied with the alpha channel values. + +and pre-multiplied is the default pixel blend mode, that means, when no blend +mode property is created or defined, DRM considers the plane's pixels has +pre-multiplied color values. On IGT GPU tools, the kms_plane_alpha_blend test +provides a set of subtests to verify plane alpha and blend mode properties. + +The DRM blend mode and its elements are then mapped by AMDGPU display manager +(DM) to program the blending configuration of the Multiple Pipe/Plane Combined +(MPC), as follows: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :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 +:c:type:`pre_multiplied_alpha` is the alpha pre-multiplied mode flag used to +set :c:type:`MPCC_ALPHA_MULTIPLIED_MODE`. It controls whether alpha is +multiplied (true/false), being only true for DRM pre-multiplied blend mode. +:c:type:`mpcc_alpha_blend_mode` defines the alpha blend mode regarding pixel +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 + :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: + +* *MPC pixel alpha* matches *DRM fg.alpha* as the alpha component value + from the plane's pixel +* *MPC global alpha* matches *DRM plane_alpha* when the pixel alpha should + be ignored and, therefore, pixel values are not pre-multiplied +* *MPC global gain* assumes *MPC global alpha* value when both *DRM + fg.alpha* and *DRM plane_alpha* participate in the blend equation + +In short, *fg.alpha* is ignored by selecting +:c:type:`MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA`. On the other hand, (plane_alpha * +fg.alpha) component becomes available by selecting +:c:type:`MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN`. And the +:c:type:`MPCC_ALPHA_MULTIPLIED_MODE` defines if the pixel color values are +pre-multiplied by alpha or not. + +Blend configuration flow +------------------------ + +The alpha blending equation is configured from DRM to DC interface by the +following path: + +1. When updating a :c:type:`drm_plane_state `, DM calls + :c:type:`amdgpu_dm_plane_fill_blending_from_plane_state()` that maps + :c:type:`drm_plane_state ` attributes to + :c:type:`dc_plane_info ` struct to be handled in the + OS-agnostic component (DC). + +2. On DC interface, :c:type:`struct mpcc_blnd_cfg ` programs the + MPCC blend configuration considering the :c:type:`dc_plane_info + ` input from DPP. + +Display Properties +================== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_display.c + :doc: property for adaptive backlight modulation diff --git a/Documentation/gpu/amdgpu/display/global_sync_vblank.svg b/Documentation/gpu/amdgpu/display/global_sync_vblank.svg new file mode 100644 index 000000000..48f5dc4fd --- /dev/null +++ b/Documentation/gpu/amdgpu/display/global_sync_vblank.svg @@ -0,0 +1,485 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + To + VStartup Period + VUpdateWidth + VReadyOffset + VUpdateOffset + VSTARTUP_START + VSYNC + VBlank + VStartup + VUpdate + VReady + + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst new file mode 100644 index 000000000..bd2d797c1 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -0,0 +1,97 @@ +.. _amdgpu-display-core: + +=================================== +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: + +#. **Display Core (DC)** contains the OS-agnostic components. Things like + hardware programming and resource management are handled 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 **, which is created based on the latest +`amd-staging-drm-next `_. 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: + +#. 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: + +.. toctree:: + + display-manager.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/mpo-cursor.svg b/Documentation/gpu/amdgpu/display/mpo-cursor.svg new file mode 100644 index 000000000..9d9de7684 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/mpo-cursor.svg @@ -0,0 +1,435 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + Cursor + + + + Plane 1 + + + + Plane 2 + + + + + CRTC + + + + Cursor + + + + Plane 1 + + + + Plane 2 + + + + CRTC + + DRM + AMD Hardware + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/mpo-overview.rst b/Documentation/gpu/amdgpu/display/mpo-overview.rst new file mode 100644 index 000000000..59a4f54a3 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/mpo-overview.rst @@ -0,0 +1,242 @@ +======================== +Multiplane Overlay (MPO) +======================== + +.. note:: You will get more from this page if you have already read the + 'Documentation/gpu/amdgpu/display/dcn-overview.rst'. + + +Multiplane Overlay (MPO) allows for multiple framebuffers to be composited via +fixed-function hardware in the display controller rather than using graphics or +compute shaders for composition. This can yield some power savings if it means +the graphics/compute pipelines can be put into low-power states. In summary, +MPO can bring the following benefits: + +* Decreased GPU and CPU workload - no composition shaders needed, no extra + buffer copy needed, GPU can remain idle. +* Plane independent page flips - No need to be tied to global compositor + page-flip present rate, reduced latency, independent timing. + +.. note:: Keep in mind that MPO is all about power-saving; if you want to learn + more about power-save in the display context, check the link: + `Power `__. + +Multiplane Overlay is only available using the DRM atomic model. The atomic +model only uses a single userspace IOCTL for configuring the display hardware +(modesetting, page-flipping, etc) - drmModeAtomicCommit. To query hardware +resources and limitations userspace also calls into drmModeGetResources which +reports back the number of planes, CRTCs, and connectors. There are three types +of DRM planes that the driver can register and work with: + +* ``DRM_PLANE_TYPE_PRIMARY``: Primary planes represent a "main" plane for a + CRTC, primary planes are the planes operated upon by CRTC modesetting and + flipping operations. +* ``DRM_PLANE_TYPE_CURSOR``: Cursor planes represent a "cursor" plane for a + CRTC. Cursor planes are the planes operated upon by the cursor IOCTLs +* ``DRM_PLANE_TYPE_OVERLAY``: Overlay planes represent all non-primary, + non-cursor planes. Some drivers refer to these types of planes as "sprites" + internally. + +To illustrate how it works, let's take a look at a device that exposes the +following planes to userspace: + +* 4 Primary planes (1 per CRTC). +* 4 Cursor planes (1 per CRTC). +* 1 Overlay plane (shared among CRTCs). + +.. note:: Keep in mind that different ASICs might expose other numbers of + planes. + +For this hardware example, we have 4 pipes (if you don't know what AMD pipe +means, look at 'Documentation/gpu/amdgpu/display/dcn-overview.rst', section +"AMD Hardware Pipeline"). Typically most AMD devices operate in a pipe-split +configuration for optimal single display output (e.g., 2 pipes per plane). + +A typical MPO configuration from userspace - 1 primary + 1 overlay on a single +display - will see 4 pipes in use, 2 per plane. + +At least 1 pipe must be used per plane (primary and overlay), so for this +hypothetical hardware that we are using as an example, we have an absolute +limit of 4 planes across all CRTCs. Atomic commits will be rejected for display +configurations using more than 4 planes. Again, it is important to stress that +every DCN has different restrictions; here, we are just trying to provide the +concept idea. + +Plane Restrictions +================== + +AMDGPU imposes restrictions on the use of DRM planes in the driver. + +Atomic commits will be rejected for commits which do not follow these +restrictions: + +* Overlay planes must be in ARGB8888 or XRGB8888 format +* Planes cannot be placed outside of the CRTC destination rectangle +* Planes cannot be downscaled more than 1/4x of their original size +* Planes cannot be upscaled more than 16x of their original size + +Not every property is available on every plane: + +* Only primary planes have color-space and non-RGB format support +* Only overlay planes have alpha blending support + +Cursor Restrictions +=================== + +Before we start to describe some restrictions around cursor and MPO, see the +below image: + +.. kernel-figure:: mpo-cursor.svg + +The image on the left side represents how DRM expects the cursor and planes to +be blended. However, AMD hardware handles cursors differently, as you can see +on the right side; basically, our cursor cannot be drawn outside its associated +plane as it is being treated as part of the plane. Another consequence of that +is that cursors inherit the color and scale from the plane. + +As a result of the above behavior, do not use legacy API to set up the cursor +plane when working with MPO; otherwise, you might encounter unexpected +behavior. + +In short, AMD HW has no dedicated cursor planes. A cursor is attached to +another plane and therefore inherits any scaling or color processing from its +parent plane. + +Use Cases +========= + +Picture-in-Picture (PIP) playback - Underlay strategy +----------------------------------------------------- + +Video playback should be done using the "primary plane as underlay" MPO +strategy. This is a 2 planes configuration: + +* 1 YUV DRM Primary Plane (e.g. NV12 Video) +* 1 RGBA DRM Overlay Plane (e.g. ARGB8888 desktop). The compositor should + prepare the framebuffers for the planes as follows: + - The overlay plane contains general desktop UI, video player controls, and video subtitles + - Primary plane contains one or more videos + +.. note:: Keep in mind that we could extend this configuration to more planes, + but that is currently not supported by our driver yet (maybe if we have a + userspace request in the future, we can change that). + +See below a single-video example: + +.. kernel-figure:: single-display-mpo.svg + +.. note:: We could extend this behavior to more planes, but that is currently + not supported by our driver. + +The video buffer should be used directly for the primary plane. The video can +be scaled and positioned for the desktop using the properties: CRTC_X, CRTC_Y, +CRTC_W, and CRTC_H. The primary plane should also have the color encoding and +color range properties set based on the source content: + +* ``COLOR_RANGE``, ``COLOR_ENCODING`` + +The overlay plane should be the native size of the CRTC. The compositor must +draw a transparent cutout for where the video should be placed on the desktop +(i.e., set the alpha to zero). The primary plane video will be visible through +the underlay. The overlay plane's buffer may remain static while the primary +plane's framebuffer is used for standard double-buffered playback. + +The compositor should create a YUV buffer matching the native size of the CRTC. +Each video buffer should be composited onto this YUV buffer for direct YUV +scanout. The primary plane should have the color encoding and color range +properties set based on the source content: ``COLOR_RANGE``, +``COLOR_ENCODING``. However, be mindful that the source color space and +encoding match for each video since it affect the entire plane. + +The overlay plane should be the native size of the CRTC. The compositor must +draw a transparent cutout for where each video should be placed on the desktop +(i.e., set the alpha to zero). The primary plane videos will be visible through +the underlay. The overlay plane's buffer may remain static while compositing +operations for video playback will be done on the video buffer. + +This kernel interface is validated using IGT GPU Tools. The following tests can +be run to validate positioning, blending, scaling under a variety of sequences +and interactions with operations such as DPMS and S3: + +- ``kms_plane@plane-panning-bottom-right-pipe-*-planes`` +- ``kms_plane@plane-panning-bottom-right-suspend-pipe-*-`` +- ``kms_plane@plane-panning-top-left-pipe-*-`` +- ``kms_plane@plane-position-covered-pipe-*-`` +- ``kms_plane@plane-position-hole-dpms-pipe-*-`` +- ``kms_plane@plane-position-hole-pipe-*-`` +- ``kms_plane_multiple@atomic-pipe-*-tiling-`` +- ``kms_plane_scaling@pipe-*-plane-scaling`` +- ``kms_plane_alpha_blend@pipe-*-alpha-basic`` +- ``kms_plane_alpha_blend@pipe-*-alpha-transparant-fb`` +- ``kms_plane_alpha_blend@pipe-*-alpha-opaque-fb`` +- ``kms_plane_alpha_blend@pipe-*-constant-alpha-min`` +- ``kms_plane_alpha_blend@pipe-*-constant-alpha-mid`` +- ``kms_plane_alpha_blend@pipe-*-constant-alpha-max`` + +Multiple Display MPO +-------------------- + +AMDGPU supports display MPO when using multiple displays; however, this feature +behavior heavily relies on the compositor implementation. Keep in mind that +userspace can define different policies. For example, some OSes can use MPO to +protect the plane that handles the video playback; notice that we don't have +many limitations for a single display. Nonetheless, this manipulation can have +many more restrictions for a multi-display scenario. The below example shows a +video playback in the middle of two displays, and it is up to the compositor to +define a policy on how to handle it: + +.. kernel-figure:: multi-display-hdcp-mpo.svg + +Let's discuss some of the hardware limitations we have when dealing with +multi-display with MPO. + +Limitations +~~~~~~~~~~~ + +For simplicity's sake, for discussing the hardware limitation, this +documentation supposes an example where we have two displays and video playback +that will be moved around different displays. + +* **Hardware limitations** + +From the DCN overview page, each display requires at least one pipe and each +MPO plane needs another pipe. As a result, when the video is in the middle of +the two displays, we need to use 2 pipes. See the example below where we avoid +pipe split: + +- 1 display (1 pipe) + MPO (1 pipe), we will use two pipes +- 2 displays (2 pipes) + MPO (1-2 pipes); we will use 4 pipes. MPO in the + middle of both displays needs 2 pipes. +- 3 Displays (3 pipes) + MPO (1-2 pipes), we need 5 pipes. + +If we use MPO with multiple displays, the userspace has to decide to enable +multiple MPO by the price of limiting the number of external displays supported +or disable it in favor of multiple displays; it is a policy decision. For +example: + +* When ASIC has 3 pipes, AMD hardware can NOT support 2 displays with MPO +* When ASIC has 4 pipes, AMD hardware can NOT support 3 displays with MPO + +Let's briefly explore how userspace can handle these two display configurations +on an ASIC that only supports three pipes. We can have: + +.. kernel-figure:: multi-display-hdcp-mpo-less-pipe-ex.svg + +- Total pipes are 3 +- User lights up 2 displays (2 out of 3 pipes are used) +- User launches video (1 pipe used for MPO) +- Now, if the user moves the video in the middle of 2 displays, one part of the + video won't be MPO since we have used 3/3 pipes. + +* **Scaling limitation** + +MPO cannot handle scaling less than 0.25 and more than x16. For example: + +If 4k video (3840x2160) is playing in windowed mode, the physical size of the +window cannot be smaller than (960x540). + +.. note:: These scaling limitations might vary from ASIC to ASIC. + +* **Size Limitation** + +The minimum MPO size is 12px. diff --git a/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg b/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg new file mode 100644 index 000000000..6d06b39e8 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg @@ -0,0 +1,220 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + ProtectedMPO plane + + + #1 + #2 + Desktop + Desktop + #3 + SoftwareComposited Video + Video will not be displayed + + diff --git a/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg b/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg new file mode 100644 index 000000000..84d53a558 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg @@ -0,0 +1,171 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + ProtectedMPO plane + + + Desktop + Desktop + Video + + diff --git a/Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg b/Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg new file mode 100644 index 000000000..5fa289d99 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg @@ -0,0 +1,958 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + DCHUB + + DPP(0) + + + + + HUBP(0) + + + + + + HUBP(1) + + + + + + HUBP(5) + + + + + ... + + ... + + + MPC(0) + + + + OPP(0) + + + ... + + + + OPTC + + + + ... + + SDP + + + + DPPCLK535.916Mhz + DISPCLK541.275 Mhz + DCFCLK506 Mhz + SymCLK + + DIO + + + + VirtualPCLK + + + diff --git a/Documentation/gpu/amdgpu/display/pipeline_4k_split.svg b/Documentation/gpu/amdgpu/display/pipeline_4k_split.svg new file mode 100644 index 000000000..b43119e7e --- /dev/null +++ b/Documentation/gpu/amdgpu/display/pipeline_4k_split.svg @@ -0,0 +1,1062 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + DCHUB + + DPP(0) + + + + + HUBP(0) + + + + + + HUBP(1) + + + + + + HUBP(5) + + + + + ... + + DPP(5) + + + + + ... + + + MPC(0) + + + + MPC(5) + + + + OPP(0) + + + ... + + + + + OPP(0) + + + + + OPTC + + + + + ... + + SDP + + + + DPPCLK267.958Mhz + DISPCLK541.275 Mhz + DCFCLK506 Mhz + SymCLK + + DIO + + + + VirtualPCLK + + + 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 000000000..bc7de97a7 --- /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) ` and :ref:`DCN Block +` 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 + connections 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) `); 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/display/single-display-mpo-multi-video.svg b/Documentation/gpu/amdgpu/display/single-display-mpo-multi-video.svg new file mode 100644 index 000000000..fa807115c --- /dev/null +++ b/Documentation/gpu/amdgpu/display/single-display-mpo-multi-video.svg @@ -0,0 +1,339 @@ + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Video Buffer (YUV) + CRTC Output + + Hardware Composition + + + + + + + + + + + + + + + + + + + + + + + + + + + Desktop Buffer (ARGB) + + diff --git a/Documentation/gpu/amdgpu/display/single-display-mpo.svg b/Documentation/gpu/amdgpu/display/single-display-mpo.svg new file mode 100644 index 000000000..fb53b0920 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/single-display-mpo.svg @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + Video Buffer (YUV)DRM PRIMARY PLANE + + Desktop Buffer (ARGB)DRM OVERLAY PLANE + + + + + + + + CRTC Output + + HardwareComposition + + + + diff --git a/Documentation/gpu/amdgpu/display/trace-groups-table.csv b/Documentation/gpu/amdgpu/display/trace-groups-table.csv new file mode 100644 index 000000000..3f6a50d1d --- /dev/null +++ b/Documentation/gpu/amdgpu/display/trace-groups-table.csv @@ -0,0 +1,29 @@ +Name, Mask Value +INFO, 0x1 +IRQ SVC, 0x2 +VBIOS, 0x4 +REGISTER, 0x8 +PHY DBG, 0x10 +PSR, 0x20 +AUX, 0x40 +SMU, 0x80 +MALL, 0x100 +ABM, 0x200 +ALPM, 0x400 +TIMER, 0x800 +HW LOCK MGR, 0x1000 +INBOX1, 0x2000 +PHY SEQ, 0x4000 +PSR STATE, 0x8000 +ZSTATE, 0x10000 +TRANSMITTER CTL, 0x20000 +PANEL CNTL, 0x40000 +FAMS, 0x80000 +DPIA, 0x100000 +SUBVP, 0x200000 +INBOX0, 0x400000 +SDP, 0x4000000 +REPLAY, 0x8000000 +REPLAY RESIDENCY, 0x20000000 +CURSOR INFO, 0x80000000 +IPS, 0x100000000 -- cgit v1.3.1