\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{Bringing display and 3D to the C.H.I.P computer}
\conference{Embedded Linux Conference 2016}
\authors{Maxime Ripard}
\email{maxime@bootlin.com}
\institute{Bootlin}
\slidesurl{http://bootlin.com/pub/conferences/2016/elc/ripard-drm}

\begin{document}

\section{Bringing display and 3D to the C.H.I.P computer}

\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}{C.H.I.P. ?}
  \begin{itemize}
  \item 9\$ SBC
  \item Based on an Allwinner R8 (equivalent to A13)
  \item 1GHz Cortex-A8 CPU
  \item Mali 400 GPU
  \item Plenty of GPIOs to bitbang stuff (and real controllers too!)
  \item Running mainline-ish Linux kernel (4.3, soon to be 4.4)
  \end{itemize}
\end{frame}

\begin{frame}{Development effort}
  \begin{itemize}
  \item A significant part of the work already done
  \item But key features for a desktop-like application were missing
    \begin{itemize}
    \item Audio
    \item NAND support
    \item Display
    \end{itemize}
  \item Plus board specific developments
    \begin{itemize}
    \item Wifi regulators
    \item DIP
    \end{itemize}
  \end{itemize}
\end{frame}

\subsection{How to display things in Linux?}

\begin{frame}{Doing display things}
  \begin{itemize}
  \item Different solutions, provided by different subsystems:
    \begin{itemize}
    \item FBDEV: Framebuffer Device
    \item DRM/KMS: Direct Rendering Manager / Kernel Mode Setting
    \item More exotic ones: V4L2, auxdisplay
    \end{itemize}
  \item How to choose one: it depends on your needs
    \begin{itemize}
    \item Each subsytem provides its own set of features
    \item Different levels of complexity
    \item Different levels of activity
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Which one to choose?}
  \begin{itemize}
  \item DRM
    \begin{itemize}
    \item Actively maintained
    \item Provides fine grained control on the display pipeline
    \item Widely used by user-space graphic stacks
    \item Provides a full set of advanced features
    \end{itemize}
  \item FBDEV
    \begin{itemize}
    \item Deprecated?
    \item Does not provides all the features found in the modern
      display controllers (overlays, sprites, hw cursor, ...)
    \end{itemize}
  \end{itemize}
\end{frame}

\subsection {DRM/KMS}

\begin{frame}{DRM/KMS: Definition}
  \begin{itemize}
  \item DRM stands for Direct Rendering Manager and was introduced
        to deal with graphic cards embedding GPUs
  \item KMS stands for Kernel Mode Setting and is a sub-part of the
        DRM API
  \item Though rendering and mode setting are now split in two
        different APIs (accessible through \code{/dev/dri/renderX} and
	\code{/dev/dri/controlDX})
  \item KMS provide a way to configure the display pipeline of a
        graphic card (or an embedded system)
  \item KMS is what we're interested in when looking for an FBDEV
        alternative
  \end{itemize}
\end{frame}

\begin{frame}{DRM/KMS pipeline}
  \begin{center}
    \includegraphics[width=\textwidth]{kms-display.pdf}
  \end{center}
\end{frame}

\begin{frame}{KMS components}
  \begin{itemize}
  \item Planes
    \begin{itemize}
    \item Image source
    \item Associated with one (or more!) framebuffers
    \item Holds a resized version of that framebuffer
    \end{itemize}

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

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

  \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}{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}

\subsection{GPU integration}

\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 (closed to?) stopped two years 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
    MESA (Gallium3D)
  \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}
