<!DOCTYPE html>
<html lang="en" data-content_root="../">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>drm/vc4 Broadcom VC4 Graphics Driver — The Linux Kernel documentation</title>
<link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="../_static/alabaster.css?v=3918102e" />
<script src="../_static/documentation_options.js?v=5929fcd5"></script>
<script src="../_static/doctools.js?v=9bcbadda"></script>
<script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="drm/vkms Virtual Kernel Modesetting" href="vkms.html" />
<link rel="prev" title="drm/v3d Broadcom V3D Graphics Driver" href="v3d.html" />
<link rel="stylesheet" href="../_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/logo.svg" alt="Logo of The Linux Kernel"/>
</a></p>
<h1 class="logo"><a href="../index.html">The Linux Kernel</a></h1>
<p class="blurb">6.18.50</p>
<search id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script>
<p>
<h3 class="kernel-toc-contents">Contents</h3>
<input type="checkbox" class="kernel-toc-toggle" id = "kernel-toc-toggle" checked>
<label class="kernel-toc-title" for="kernel-toc-toggle"></label>
<div class="kerneltoc" id="kerneltoc">
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/development-process.html">Development process</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/submitting-patches.html">Submitting patches</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/code-of-conduct.html">Code of conduct</a></li>
<li class="toctree-l1"><a class="reference internal" href="../maintainer/index.html">Maintainer handbook</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/index.html">All development-process docs</a></li>
</ul>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../core-api/index.html">Core API</a></li>
<li class="toctree-l1"><a class="reference internal" href="../driver-api/index.html">Driver APIs</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../subsystem-apis.html">Subsystems</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#core-subsystems">Core subsystems</a></li>
<li class="toctree-l2 current"><a class="reference internal" href="../subsystem-apis.html#human-interfaces">Human interfaces</a><ul class="current">
<li class="toctree-l3"><a class="reference internal" href="../input/index.html">Input Documentation</a></li>
<li class="toctree-l3"><a class="reference internal" href="../hid/index.html">Human Interface Devices (HID)</a></li>
<li class="toctree-l3"><a class="reference internal" href="../sound/index.html">Sound Subsystem Documentation</a></li>
<li class="toctree-l3 current"><a class="reference internal" href="index.html">GPU Driver Developer’s Guide</a></li>
<li class="toctree-l3"><a class="reference internal" href="../fb/index.html">Frame Buffer</a></li>
<li class="toctree-l3"><a class="reference internal" href="../leds/index.html">LEDs</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#networking-interfaces">Networking interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#storage-interfaces">Storage interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#other-subsystems">Other subsystems</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../locking/index.html">Locking</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/license-rules.html">Licensing rules</a></li>
<li class="toctree-l1"><a class="reference internal" href="../doc-guide/index.html">Writing documentation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/index.html">Development tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/testing-overview.html">Testing guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kernel-hacking/index.html">Hacking guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../trace/index.html">Tracing</a></li>
<li class="toctree-l1"><a class="reference internal" href="../fault-injection/index.html">Fault injection</a></li>
<li class="toctree-l1"><a class="reference internal" href="../livepatch/index.html">Livepatching</a></li>
<li class="toctree-l1"><a class="reference internal" href="../rust/index.html">Rust</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/index.html">Administration</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kbuild/index.html">Build system</a></li>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/reporting-issues.html">Reporting issues</a></li>
<li class="toctree-l1"><a class="reference internal" href="../tools/index.html">Userspace tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../userspace-api/index.html">Userspace API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../firmware-guide/index.html">Firmware</a></li>
<li class="toctree-l1"><a class="reference internal" href="../devicetree/index.html">Firmware and Devicetree</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../arch/index.html">CPU architectures</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../staging/index.html">Unsorted documentation</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../translations/index.html">Translations</a></li>
</ul>
</div>
<script type="text/javascript"> <!--
var sbar = document.getElementsByClassName("sphinxsidebar")[0];
let currents = document.getElementsByClassName("current")
if (currents.length) {
sbar.scrollTop = currents[currents.length - 1].offsetTop;
}
--> </script>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/gpu/vc4.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="drm-vc4-broadcom-vc4-graphics-driver">
<h1>drm/vc4 Broadcom VC4 Graphics Driver<a class="headerlink" href="#drm-vc4-broadcom-vc4-graphics-driver" title="Link to this heading">¶</a></h1>
<p>The Broadcom VideoCore 4 (present in the Raspberry Pi) contains a
OpenGL ES 2.0-compatible 3D engine called V3D, and a highly
configurable display output pipeline that supports HDMI, DSI, DPI,
and Composite TV output.</p>
<p>The 3D engine also has an interface for submitting arbitrary
compute shader-style jobs using the same shader processor as is
used for vertex and fragment shaders in GLES 2.0. However, given
that the hardware isn’t able to expose any standard interfaces like
OpenGL compute shaders or OpenCL, it isn’t supported by this
driver.</p>
<section id="display-hardware-handling">
<h2>Display Hardware Handling<a class="headerlink" href="#display-hardware-handling" title="Link to this heading">¶</a></h2>
<p>This section covers everything related to the display hardware including
the mode setting infrastructure, plane, sprite and cursor handling and
display, output probing and related topics.</p>
<section id="pixel-valve-drm-crtc">
<h3>Pixel Valve (DRM CRTC)<a class="headerlink" href="#pixel-valve-drm-crtc" title="Link to this heading">¶</a></h3>
<p>In VC4, the Pixel Valve is what most closely corresponds to the
DRM’s concept of a CRTC. The PV generates video timings from the
encoder’s clock plus its configuration. It pulls scaled pixels from
the HVS at that timing, and feeds it to the encoder.</p>
<p>However, the DRM CRTC also collects the configuration of all the
DRM planes attached to it. As a result, the CRTC is also
responsible for writing the display list for the HVS channel that
the CRTC will use.</p>
<p>The 2835 has 3 different pixel valves. pv0 in the audio power
domain feeds DSI0 or DPI, while pv1 feeds DS1 or SMI. pv2 in the
image domain can feed either HDMI or the SDTV controller. The
pixel valve chooses from the CPRMAN clocks (HSM for HDMI, VEC for
SDTV, etc.) according to which output type is chosen in the mux.</p>
<p>For power management, the pixel valve’s registers are all clocked
by the AXI clock, while the timings and FIFOs make use of the
output-specific clock. Since the encoders also directly consume
the CPRMAN clocks, and know what timings they need, they are the
ones that set the clock.</p>
</section>
<section id="hvs">
<h3>HVS<a class="headerlink" href="#hvs" title="Link to this heading">¶</a></h3>
<p>The Hardware Video Scaler (HVS) is the piece of hardware that does
translation, scaling, colorspace conversion, and compositing of
pixels stored in framebuffers into a FIFO of pixels going out to
the Pixel Valve (CRTC). It operates at the system clock rate (the
system audio clock gate, specifically), which is much higher than
the pixel clock rate.</p>
<p>There is a single global HVS, with multiple output FIFOs that can
be consumed by the PVs. This file just manages the resources for
the HVS, while the vc4_crtc.c code actually drives HVS setup for
each CRTC.</p>
</section>
<section id="hvs-planes">
<h3>HVS planes<a class="headerlink" href="#hvs-planes" title="Link to this heading">¶</a></h3>
<p>Each DRM plane is a layer of pixels being scanned out by the HVS.</p>
<p>At atomic modeset check time, we compute the HVS display element
state that would be necessary for displaying the plane (giving us a
chance to figure out if a plane configuration is invalid), then at
atomic flush time the CRTC will ask us to write our element state
into the region of the HVS that it has allocated for us.</p>
</section>
<section id="hdmi-encoder">
<h3>HDMI encoder<a class="headerlink" href="#hdmi-encoder" title="Link to this heading">¶</a></h3>
<p>The HDMI core has a state machine and a PHY. On BCM2835, most of
the unit operates off of the HSM clock from CPRMAN. It also
internally uses the PLLH_PIX clock for the PHY.</p>
<p>HDMI infoframes are kept within a small packet ram, where each
packet can be individually enabled for including in a frame.</p>
<p>HDMI audio is implemented entirely within the HDMI IP block. A
register in the HDMI encoder takes SPDIF frames from the DMA engine
and transfers them over an internal MAI (multi-channel audio
interconnect) bus to the encoder side for insertion into the video
blank regions.</p>
<p>The driver’s HDMI encoder does not yet support power management.
The HDMI encoder’s power domain and the HSM/pixel clocks are kept
continuously running, and only the HDMI logic and packet ram are
powered off/on at disable/enable time.</p>
<p>The driver does not yet support CEC control, though the HDMI
encoder block has CEC support.</p>
</section>
<section id="dsi-encoder">
<h3>DSI encoder<a class="headerlink" href="#dsi-encoder" title="Link to this heading">¶</a></h3>
<p>BCM2835 contains two DSI modules, DSI0 and DSI1. DSI0 is a
single-lane DSI controller, while DSI1 is a more modern 4-lane DSI
controller.</p>
<p>Most Raspberry Pi boards expose DSI1 as their “DISPLAY” connector,
while the compute module brings both DSI0 and DSI1 out.</p>
<p>This driver has been tested for DSI1 video-mode display only
currently, with most of the information necessary for DSI0
hopefully present.</p>
</section>
<section id="dpi-encoder">
<h3>DPI encoder<a class="headerlink" href="#dpi-encoder" title="Link to this heading">¶</a></h3>
<p>The VC4 DPI hardware supports MIPI DPI type 4 and Nokia ViSSI
signals. On BCM2835, these can be routed out to GPIO0-27 with the
ALT2 function.</p>
</section>
<section id="vec-composite-tv-out-encoder">
<h3>VEC (Composite TV out) encoder<a class="headerlink" href="#vec-composite-tv-out-encoder" title="Link to this heading">¶</a></h3>
<p>The VEC encoder generates PAL or NTSC composite video output.</p>
<p>TV mode selection is done by an atomic property on the encoder,
because a drm_mode_modeinfo is insufficient to distinguish between
PAL and PAL-M or NTSC and NTSC-J.</p>
</section>
</section>
<section id="kunit-tests">
<h2>KUnit Tests<a class="headerlink" href="#kunit-tests" title="Link to this heading">¶</a></h2>
<p>The VC4 Driver uses KUnit to perform driver-specific unit and
integration tests.</p>
<p>These tests are using a mock driver and can be ran using the
command below, on either arm or arm64 architectures,</p>
<div class="highlight-bash notranslate"><div class="highlight"><pre><span></span>$<span class="w"> </span>./tools/testing/kunit/kunit.py<span class="w"> </span>run<span class="w"> </span><span class="se">\</span>
<span class="w"> </span>--kunitconfig<span class="o">=</span>drivers/gpu/drm/vc4/tests/.kunitconfig<span class="w"> </span><span class="se">\</span>
<span class="w"> </span>--cross_compile<span class="w"> </span>aarch64-linux-gnu-<span class="w"> </span>--arch<span class="w"> </span>arm64
</pre></div>
</div>
<dl class="simple">
<dt>Parts of the driver that are currently covered by tests are:</dt><dd><ul class="simple">
<li><p>The HVS to PixelValve dynamic FIFO assignment, for the BCM2835-7
and BCM2711.</p></li>
</ul>
</dd>
</dl>
</section>
<section id="memory-management-and-3d-command-submission">
<h2>Memory Management and 3D Command Submission<a class="headerlink" href="#memory-management-and-3d-command-submission" title="Link to this heading">¶</a></h2>
<p>This section covers the GEM implementation in the vc4 driver.</p>
<section id="gpu-buffer-object-bo-management">
<h3>GPU buffer object (BO) management<a class="headerlink" href="#gpu-buffer-object-bo-management" title="Link to this heading">¶</a></h3>
<p>The VC4 GPU architecture (both scanout and rendering) has direct
access to system memory with no MMU in between. To support it, we
use the GEM DMA helper functions to allocate contiguous ranges of
physical memory for our BOs.</p>
<p>Since the DMA allocator is very slow, we keep a cache of recently
freed BOs around so that the kernel’s allocation of objects for 3D
rendering can return quickly.</p>
</section>
<section id="v3d-binner-command-list-bcl-validation">
<h3>V3D binner command list (BCL) validation<a class="headerlink" href="#v3d-binner-command-list-bcl-validation" title="Link to this heading">¶</a></h3>
<p>Since the VC4 has no IOMMU between it and system memory, a user
with access to execute command lists could escalate privilege by
overwriting system memory (drawing to it as a framebuffer) or
reading system memory it shouldn’t (reading it as a vertex buffer
or index buffer)</p>
<p>We validate binner command lists to ensure that all accesses are
within the bounds of the GEM objects referenced by the submitted
job. It explicitly whitelists packets, and looks at the offsets in
any address fields to make sure they’re contained within the BOs
they reference.</p>
<p>Note that because CL validation is already reading the
user-submitted CL and writing the validated copy out to the memory
that the GPU will actually read, this is also where GEM relocation
processing (turning BO references into actual addresses for the GPU
to use) happens.</p>
</section>
<section id="v3d-render-command-list-rcl-generation">
<h3>V3D render command list (RCL) generation<a class="headerlink" href="#v3d-render-command-list-rcl-generation" title="Link to this heading">¶</a></h3>
<p>In the V3D hardware, render command lists are what load and store
tiles of a framebuffer and optionally call out to binner-generated
command lists to do the 3D drawing for that tile.</p>
<p>In the VC4 driver, render command list generation is performed by the
kernel instead of userspace. We do this because validating a
user-submitted command list is hard to get right and has high CPU overhead,
while the number of valid configurations for render command lists is
actually fairly low.</p>
</section>
<section id="shader-validator-for-vc4">
<h3>Shader validator for VC4<a class="headerlink" href="#shader-validator-for-vc4" title="Link to this heading">¶</a></h3>
<p>Since the VC4 has no IOMMU between it and system memory, a user
with access to execute shaders could escalate privilege by
overwriting system memory (using the VPM write address register in
the general-purpose DMA mode) or reading system memory it shouldn’t
(reading it as a texture, uniform data, or direct-addressed TMU
lookup).</p>
<p>The shader validator walks over a shader’s BO, ensuring that its
accesses are appropriately bounded, and recording where texture
accesses are made so that we can do relocations for them in the
uniform stream.</p>
<p>Shader BO are immutable for their lifetimes (enforced by not
allowing mmaps, GEM prime export, or rendering to from a CL), so
this validation is only performed at BO creation time.</p>
</section>
<section id="v3d-interrupts">
<h3>V3D Interrupts<a class="headerlink" href="#v3d-interrupts" title="Link to this heading">¶</a></h3>
<p>We have an interrupt status register (V3D_INTCTL) which reports
interrupts, and where writing 1 bits clears those interrupts.
There are also a pair of interrupt registers
(V3D_INTENA/V3D_INTDIS) where writing a 1 to their bits enables or
disables that specific interrupt, and 0s written are ignored
(reading either one returns the set of enabled interrupts).</p>
<p>When we take a binning flush done interrupt, we need to submit the
next frame for binning and move the finished frame to the render
thread.</p>
<p>When we take a render frame interrupt, we need to wake the
processes waiting for some frame to be done, and get the next frame
submitted ASAP (so the hardware doesn’t sit idle when there’s work
to do).</p>
<p>When we take the binner out of memory interrupt, we need to
allocate some new memory and pass it to the binner so that the
current job can make progress.</p>
</section>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©The kernel development community.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 8.1.3</a>
& <a href="https://alabaster.readthedocs.io">Alabaster 0.7.16</a>
|
<a href="../_sources/gpu/vc4.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>