From patchwork Tue Dec 7 14:53:49 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rodrigo Siqueira Jordao X-Patchwork-Id: 12662031 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 11671C433EF for ; Tue, 7 Dec 2021 14:54:40 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9D4917B868; Tue, 7 Dec 2021 14:54:28 +0000 (UTC) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2047.outbound.protection.outlook.com [40.107.236.47]) by gabe.freedesktop.org (Postfix) with ESMTPS id B79BD7B801; Tue, 7 Dec 2021 14:54:25 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kRQSQ7MrkKaqHyns72XszTnEQ/Pt0sqR2A/P3gU9EHyHs5DEE5T32/eAzLQOv+C6OaMPuVvC/NZ1L7ToUsQyZioxFiBUlsEZWGwE74NH/xDAuSFWZvAQ5IvSguEG7iF8RFxpf3TQpHnUyJjMa461P2HZx5gFtjIxDu7ADpwVBYKF1L01QvOdLZJfIiijb2X/kPMLpO+AsSwXal7+eJ4FZgO+wE56SHS6mC0Ade5xmdeh2ZDbBdyC5+32d8pk5k58u/x+5UMhPrU5I6XOcePAAqLprGzXJ4nj93bSTZAW7EVzvpf4gC4eGiawHBzu519T0dvZCuY5AmElHLQTnSJqJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=g7mXo/pbuMzSncxMXVuY90BL+fDdox4ZR4si2VYoGGE=; b=M+cPzqpZoRyByqZNmqDqQKucjf2JDuA8Xl/wNIr4rULU+2z5S6Hf3aZnmcloOVOYGQ2rkSGSb1/sttaaCNNVqG9kWRoi+AYYIL/zQbkGpuFzxO3VyG/LckwSlwGRAJm9BdyY8kxG+dFvAV7q26AGR/ipmFcap0bpCKoJS/dFJNZRgRQqXFBk1sfO1bJpc2MrDKqlAK3E8nZI1pnEu68uREAY4XwIMsT9GCZ541/AO1f/sE2N2YwIWZbdZt3vNBfqgmsZ6BGYCJ8AXsjqxgYZBoIpzLhnf+EAyDViNsT7uyAIIynQCu4LxZvKAEe7+Os5hScfJ6BRm7RJrOSttSd8PQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=emersion.fr smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g7mXo/pbuMzSncxMXVuY90BL+fDdox4ZR4si2VYoGGE=; b=Aig8NQU4ohNul39jtbgzzkio5adsbPR4VwoLuIWu/q1x1HARQLGv5WvaXGqQv7K6sK6H9ToIMm28OvsawosFukg+SWYlbXLgQeYJg/JV1H38TnP7Y+vaHNCFd0VN6aTlToY8PTKm1ZK34Px35HH9N3egmD0qQwlT7SUpj5pDGIE= Received: from DM6PR13CA0021.namprd13.prod.outlook.com (2603:10b6:5:bc::34) by DM4PR12MB5054.namprd12.prod.outlook.com (2603:10b6:5:389::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.22; Tue, 7 Dec 2021 14:54:20 +0000 Received: from DM6NAM11FT025.eop-nam11.prod.protection.outlook.com (2603:10b6:5:bc:cafe::bf) by DM6PR13CA0021.outlook.office365.com (2603:10b6:5:bc::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.5 via Frontend Transport; Tue, 7 Dec 2021 14:54:20 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; Received: from SATLEXMB04.amd.com (165.204.84.17) by DM6NAM11FT025.mail.protection.outlook.com (10.13.172.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4755.13 via Frontend Transport; Tue, 7 Dec 2021 14:54:20 +0000 Received: from atma2.hitronhub.home (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Tue, 7 Dec 2021 08:54:16 -0600 From: Rodrigo Siqueira To: Simon Ser , Michel Daenzer , "Bas Nieuwenhuizen" , Marek Olsak , Roman Gilg , Nicholas Kazlauskas , Harry Wentland , "Mark Yacoub" , Sean Paul , "Pekka Paalanen" , Yann Dirson , Daniel Vetter Subject: [PATCH v3 5/6] Documentation/gpu: Add basic overview of DC pipeline Date: Tue, 7 Dec 2021 09:53:49 -0500 Message-ID: <20211207145350.286037-6-Rodrigo.Siqueira@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211207145350.286037-1-Rodrigo.Siqueira@amd.com> References: <20211207145350.286037-1-Rodrigo.Siqueira@amd.com> MIME-Version: 1.0 X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e80a7db4-67f9-49cb-3113-08d9b991732f X-MS-TrafficTypeDiagnostic: DM4PR12MB5054:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:13; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: liCVHOuB6WRtcG5K9InaWqVWS9UCBNnX+UpMaW9PRkg7JOOJ4wttZ+9am1Z21PkGjsr88dKthWsuFFDEPa73uhDGQl5oSOUVF1IN27hQxRiNX5FZijsadkTZ5oRysslp9X7d+TGFtd6CcY5osewXkEK9cpNPg1BYhckCwwyRBvxPb43M5aujbsijXEI+hfm61zg4qx8M6AAerbbj5mSYeL2bdLX11biQfiGRaiPCvmep184AzcAwKlxdZoSBE06EhavlitNMdsHEhKjUr0/lxGiqwzQs4cVfcBUEPVz+uIBpbvZBW3P6edYqOOO1Lw0gex+h/5cddNVMeUooXH8JV88rNjDRoGyKfVS0zyxeSiiuw4rYs+dNyKQWMpJ8LQWL6H5HRIMpjeDU3zXvBeeZfnjqA3FOeJ0iPVCJkbC9GdAseAFkiXYHoXHFLP4nziW+SiDKUeGL7dDOIEdF7ojOb+Dq9NSIwzdmJKy0ZggSU33seDddTWKfep4a8xgcQ3dgDGRwPIcfgacdxkNWnJfNYAJSlguR+Qz6X0WReiRZ05baA7ZesDWEHRc/G3ejaB8E6BmSr5v6rz73QskkYBSDaH74egx9MUJtUjtwtfCC1KtNqGGSe1/CwGblENiLiLYblTQZz6W6I00ii0dUe/lwSSkXfwwt+Bc5eDagazzu4nShAXZTclOza6q7MarvExbfGPY9v0wgx4YL0thwOA9phBp54suR5VmVhGzUemwUwnDYKlkzq6tPD06/YkHaYSQXUCeb5rFe+tR6NbK1S67djOqMyvmdWyMvieY9NQFDGN8Iy+muzQOyCwKLPoh2vr/Oa1KNvGOlyMNdOsgL6OuDznhPJWIPYNaIzVizvDldnBWfzFFjxHrYnulyK2on00g9SB5PSqPNPjNefbUElyYW+mwNFgsy8rT8PXuYqt2bgW3Ngw43PLdYEu90lYLpPzaWIxPcjsm8XExZeMfiGen4Gw== X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:SATLEXMB04.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(36840700001)(46966006)(40470700001)(8936002)(26005)(2616005)(5660300002)(1076003)(19273905006)(4326008)(336012)(8676002)(6666004)(7416002)(16526019)(30864003)(186003)(921005)(86362001)(36756003)(36860700001)(426003)(54906003)(81166007)(82310400004)(83380400001)(70206006)(47076005)(2906002)(70586007)(40460700001)(316002)(508600001)(356005)(110136005)(36900700001)(559001)(579004)(563064011); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2021 14:54:20.2567 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e80a7db4-67f9-49cb-3113-08d9b991732f X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT025.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5054 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-doc@vger.kernel.org, qingqing.zhuo@amd.com, roman.li@amd.com, amd-gfx@lists.freedesktop.org, aurabindo.pillai@amd.com, nicholas.choi@amd.com, dri-devel@lists.freedesktop.org, Alex Deucher , bhawanpreet.lakha@amd.com, Christian Koenig Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" This commit describes how DCN works by providing high-level diagrams with an explanation of each component. In particular, it details the Global Sync signals. Change since V2: - Add a comment about MMHUBBUB. Signed-off-by: Rodrigo Siqueira --- .../gpu/amdgpu/display/config_example.svg | 414 ++++++ .../amdgpu/display/dc_pipeline_overview.svg | 1125 +++++++++++++++++ .../gpu/amdgpu/display/dcn-overview.rst | 171 +++ .../gpu/amdgpu/display/global_sync_vblank.svg | 485 +++++++ Documentation/gpu/amdgpu/display/index.rst | 23 +- 5 files changed, 2206 insertions(+), 12 deletions(-) create mode 100644 Documentation/gpu/amdgpu/display/config_example.svg create mode 100644 Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg create mode 100644 Documentation/gpu/amdgpu/display/dcn-overview.rst create mode 100644 Documentation/gpu/amdgpu/display/global_sync_vblank.svg diff --git a/Documentation/gpu/amdgpu/display/config_example.svg b/Documentation/gpu/amdgpu/display/config_example.svg new file mode 100644 index 000000000000..cdac9858601c --- /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_pipeline_overview.svg b/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg new file mode 100644 index 000000000000..9adecebfe65b --- /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-overview.rst b/Documentation/gpu/amdgpu/display/dcn-overview.rst new file mode 100644 index 000000000000..f98624d7828e --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst @@ -0,0 +1,171 @@ +======================= +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. + +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/global_sync_vblank.svg b/Documentation/gpu/amdgpu/display/global_sync_vblank.svg new file mode 100644 index 000000000000..48f5dc4fd5d3 --- /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 index a443866332ac..fe2ecad8df81 100644 --- a/Documentation/gpu/amdgpu/display/index.rst +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -2,28 +2,27 @@ drm/amd/display - Display Core (DC) =================================== -*placeholder - general description of supported platforms, what dc is, etc.* - -Because it is partially shared with other operating systems, the Display Core -Driver is divided in two pieces. +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 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. -It doesn't help that the entire package is frequently referred to as DC. But -with the context in mind, it should be clear. +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: -When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for -supported ASICs. To force disable, set `amdgpu.dc=0` on kernel command line. -Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`. +1. Read frame information from memory; +2. Perform required transformation; +3. Send pixel data to sink devices. -To determine if DC is loaded, search dmesg for the following entry: +If you want to learn more about our driver details, take a look at the below +table of content: .. toctree:: display-manager.rst dc-debug.rst - -``Display Core initialized with `` + dcn-overview.rst