\documentclass[aspectratio=169,obeyspaces,spaces,hyphens,dvipsnames]{beamer}
\usepackage[utf8]{inputenc}
\usepackage{minted}
\usepackage{hyperref}

\mode<presentation>
\usetheme{Bootlin}

\def\signed #1{{\leavevmode\unskip\nobreak\hfil\penalty50\hskip2em
  \hbox{}\nobreak\hfil(#1)%
  \parfillskip=0pt \finalhyphendemerits=0 \endgraf}}

\newsavebox\mybox
\newenvironment{aquote}[1]
  {\savebox\mybox{#1}\begin{quotation}}
  {\signed{\usebox\mybox}\end{quotation}}

\title{An introduction to the Linux DRM subsystem}
\conference{Kernel Recipes 2017}
\authors{Maxime Ripard}
\email{maxime@bootlin.com}
\institute{Bootlin}
\slidesurl{http://bootlin.com/pub/conferences/2017/kr/ripard-drm}

\begin{document}

\section{An introduction to the Linux DRM subsystem}

\begin{frame}{Maxime Ripard}
  \begin{itemize}
  \item Embedded Linux engineer and trainer at Bootlin
    \begin{itemize}
    \item Embedded Linux {\bf development}: kernel and driver
      development, system integration, boot time and power consumption
      optimization, consulting, etc.
    \item Embedded Linux {\bf training}, Linux driver development
      training and Android system development training, with materials
      freely available under a Creative Commons license.
    \item \url{http://bootlin.com}
    \end{itemize}
  \item Contributions
    \begin{itemize}
    \item {\bf Co-maintainer for the sunXi SoCs} from Allwinner
    \item Contributor to a couple of other open-source projects, {\bf
        Buildroot}, {\bf U-Boot}, {\bf Barebox}
    \end{itemize}
  \item Living in {\bf Toulouse}, south west of France
  \end{itemize}
\end{frame}

\subsection{Introduction}

\begin{frame}
  \begin{center}
    A long long time ago, in a galaxy (not so) far, far away
  \end{center}
\end{frame}

\begin{frame}{Framebuffers}
  \begin{itemize}
  \item Display hardware was dead simple...
  \item .. and so was the API to drive it.
  \item Introducing... fbdev!
  \item Allows for three things:
    \begin{itemize}
    \item Mode-Setting
    \item Accessing the (only) buffer
    \item Optional 2d acceleration: draw, copy, etc.
    \item And access to the device registers...
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{That 90's show}
  \begin{center}
    \includegraphics[width=\textwidth]{framebuffer.pdf}
  \end{center}
\end{frame}

\begin{frame}{Back to the future}
  \begin{itemize}
  \item Two different trends
    \begin{itemize}
    \item Embedded devices starting to show up, with their low power
      needs $\Rightarrow$ Display engines need to accelerate more
      things
    \item Desktop displays getting more and more fancy in order to
      play Quake in 4k VR $\Rightarrow$ Bigger and bigger GPUs
    \end{itemize}
  \item Led to two different outcomes:
    \begin{itemize}
    \item Interface to drive GPU devices through the kernel: DRM
    \item Hacks piling on in order to fit embedded use-cases: omapdss,
      pxafb
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Composition Evolved}
  \begin{center}
    \includegraphics[width=\textwidth]{evolved-display.pdf}
  \end{center}  
\end{frame}

\begin{frame}{The droid you're looking at}
  \begin{center}
    \includegraphics[width=\textwidth]{android-composition.png}\\
    Sean Paul and Zach Reizner - Google - XDC2016
  \end{center}
\end{frame}

\begin{frame}{Can I talk to the manager?}
  \begin{itemize}
  \item DRM was initially introduced to deal with the GPU's need
    \begin{itemize}
    \item Initialize the card, load its firmware, etc.
    \item Share the GPU command queue between multiple applications
    \item Manage the memory (allocation, access)
    \item But not modesetting!
    \end{itemize}
  \item All the modesetting was in the userspace, especially in X
  \item Race between rendering and modesetting
  \item Only one graphical application that needed to remain there all
    the time
  \item (Lack of) Abstraction!
  \item Introduction of the Kernel Mode-Setting (KMS) to move the
    modesetting back into the kernel
  \end{itemize}
\end{frame}

\begin{frame}{Kill it with fire!}
  \begin{itemize}
  \item Now, fbdev could be implemented on top of KMS...
  \item ... Or removed entirely
  \item Call for deprecation in 2012 (Hi Laurent!)
  \item Last fbdev driver merged in 2014
  \item First ARM DRM driver: exynos in 2011
  \item Followed: arm, armada, atmel-hclcdc, fsl-dcu, hisilicon, imx,
    mediatek, meson, msm, mxsfb, omapdrm, pl111, rcar-du, rockchip,
    shmobile, sti, stm, sun4i, tegra, tve200, etc...
  \end{itemize}
\end{frame}

\begin{frame}{Two nodes to go please}
  \begin{itemize}
  \item Initially, DRM was created for devices that were both
    displaying and rendering (your traditionnal PC graphics card).
  \item On embedded devices, it's never really been like that
    \begin{itemize}
    \item the GPU is discrete and comes from a third party
    \item the display engine is usually designed by the SoC vendor
    \end{itemize}
  \item DRM and KMS APIs requiring the same level of privilege, with
    one master, and were both exposed on the same device file
  \item Creation of render nodes
  \item Also useful for things like GPGPU, off-screen rendering,
    more flexible access control
  \end{itemize}
\end{frame}

\subsection {DRM/KMS}

\begin{frame}{The pixels must flow}
  \begin{center}
    \includegraphics[width=\textwidth]{kms-display.pdf}
  \end{center}
\end{frame}

\begin{frame}<1>[label=components]
  \frametitle{KMS components}
  \begin{itemize}
  \item Planes
    \begin{itemize}
    \item Image source
    \item Associated with one (or more!) framebuffers
    \item Holds a resized / cropped version of that framebuffer
    \end{itemize}
    \pause

  \item CRTCs
    \begin{itemize}
    \item Take the planes, and does the composition
    \item Contains the display mode and parameters
    \end{itemize}
    \pause

  \item Encoders
    \begin{itemize}
    \item Take the raw data from the CRTC and convert it to a
      particular format
    \end{itemize}
    \pause

  \item Connectors
    \begin{itemize}
    \item Outputs the encoded data to an external display
    \item Handles hotplug events
    \item Reads EDIDs
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Page flipping}
  \begin{center}
    \includegraphics[height=0.8\textheight]{page-flipping.pdf}
  \end{center}
\end{frame}

\againframe<2->{components}

\begin{frame}{Allwinner display pipeline}
  \begin{center}
    \includegraphics[width=\textwidth]{allwinner-display.pdf}
  \end{center}
\end{frame}

\begin{frame}{DRM vs SoC pipeline}
  \begin{center}
    \includegraphics[width=\textwidth]{allwinner-display-split.pdf}
  \end{center}
\end{frame}

\begin{frame}{DRM Stack: KMS}
  \begin{center}
    \includegraphics[height=0.75\textheight]{drm-stack-kms.pdf}
  \end{center}
\end{frame}

\begin{frame}{DRM Stack: GEM}
  \begin{center}
    \includegraphics[height=0.75\textheight]{drm-stack-gem.pdf}
  \end{center}
\end{frame}

\begin{frame}{DRM Stack: CMA}
  \begin{center}
    \includegraphics[height=0.75\textheight]{drm-stack-cma.pdf}
  \end{center}
\end{frame}

\begin{frame}{DRM Stack: PRIME}
  \begin{center}
    \includegraphics[height=0.75\textheight]{drm-stack-prime.pdf}
  \end{center}
\end{frame}

\begin{frame}{DRM Stack: GPUs}
  \begin{center}
    \includegraphics[height=0.75\textheight]{drm-stack-generic-gpu.pdf}
  \end{center}
\end{frame}

\subsection{Vendor solutions...}

\begin{frame}{Solutions}
  \begin{itemize}
  \item The GPU found in most Allwinner SoCs is the Mali-400 from ARM
    (with a variable number of cores)
  \item There are two options to support that GPU:
    \begin{itemize}
    \item Lima
      \begin{itemize}
      \item Reversed engineered proof-of-concept
      \item Triggered the reverse engineering effort of the GPUs
        (freedreno, etnaviv, etc.)
      \item Development (close to?) stopped three years ago, and then
        resumed a couple of monthes ago
      \end{itemize}
    \item ARM-Provided support
      \begin{itemize}
      \item Featureful
      \item Two parts: GPL kernel driver and proprietary OpenGL ES
        implementation
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{DRM Stack: GPU}
  \begin{center}
    \includegraphics[height=0.75\textheight]{drm-stack-gpu.pdf}
  \end{center}
\end{frame}

\begin{frame}{Development}
  \begin{itemize}
  \item Everything is provided by ARM on their website (if you're lucky)
  \item On the userspace side, you just need to put the library they
    provided on your system
  \item On the driver side, you need to create a platform glue that
    will deal with:
    \begin{itemize}
    \item Memory mapping
    \item Interrupts
    \item Clocks
    \item Reset lines
    \item Power Domains
    \item Basically everything needed for the GPU to operate properly
      on your SoC
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{X11 integration}
  \begin{itemize}
  \item We need a DDX (Device Dependent X) driver
  \item \code{xf86-video-modesetting} is working on top of KMS and
    GBM (MESA-defined user-space API to allocate buffers)
  \item ARM developped \code{xf86-video-armsoc} for SoC using a 3rd
    party GPU (Mali, PowerVR, Vivante, etc.)
  \item Relies on KMS for the display configuration, driver-specific
    ioctl for buffer allocations and vendor-provided OpenGL ES
    implementation
  \item Just have to write a small glue to use your driver allocator,
    and give some hints to X about what your hardware support (hw
    cursor, vblank, etc.)
  \end{itemize}
\end{frame}

\questionslide{}

\end{document}