\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{Supporting the Camera Interface on the C.H.I.P}
\conference{Embedded Linux Conference Europe 2016}
\authors{Maxime Ripard}
\email{maxime@bootlin.com}
\institute{Bootlin}
\slidesurl{http://bootlin.com/pub/conferences/2016/elce/ripard-v4l}

\begin{document}

\section{Supporting the Camera Interface on the C.H.I.P}

\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, Linux driver development, Yocto Project /
      OpenEmbedded and Buildroot {\bf 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.4 at the moment)
  \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 NAND support
    \item Display, GPU
    \item Audio, Camera, VPU
    \end{itemize}
  \item Plus board specific developments
    \begin{itemize}
    \item WiFi regulators
    \item DIP
    \end{itemize}
  \end{itemize}
\end{frame}

\subsection{Video Capture in Linux}

\begin{frame}{V4L2}
  \begin{itemize}
  \item Introduced in 2002, in 2.5.46
  \item Supports a wide range of devices
    \begin{itemize}
    \item Video Capture (Camera, tuners)
    \item Memory to memory devices (Hardware codecs, scalers, deinterlacers)
    \item Radio receivers and transceivers
    \item SDR
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{V4L2: A dumb pipeline}
  \begin{center}
    \includegraphics[width=\textwidth]{v4l-dumb.pdf}
  \end{center}
\end{frame}

\begin{frame}{Formats}
  \begin{itemize}
  \item There's a wide range of video formats...
  \item ... And even weird variations of them
  \item Most of the time, the controller and the sensor don't support
    the same set of formats
  \item Some negotiation needs to happen between the controller and
    the camera to agree on a common format.
  \end{itemize}
\end{frame}

\begin{frame}{Streaming}
  \begin{itemize}
  \item You also need to implement the streaming hooks
  \item Addresses two things:
    \begin{itemize}
    \item Memory Management: Buffer allocation, queuing and dequeuing
    \item Streaming control
    \end{itemize}
  \item With the formats, the only really needed operations
  \end{itemize}
\end{frame}

\begin{frame}{Streaming modes}
  \begin{center}
    \includegraphics[width=\textwidth]{v4l-streaming.pdf}
  \end{center}
\end{frame}

\begin{frame}{Videobuf2}
  \begin{itemize}
  \item Generic implementation of that streaming API
  \item Relies on a smaller, simpler set of callbacks to implement
  \item Different videobuf implementations, depending on your setup
    (backed by vmalloc, scatter gather DMA or contiguous DMA)
  \item Also has a notion of streaming modes, which control the source
    of the buffers, among
    \begin{itemize}
    \item The driver
    \item The user-space (if the device supports it)
    \item Some other device (through DMA-BUF)
    \end{itemize}
  \item The new callbacks are only there to tell videobuf the size and
    number of buffers to allocate, insert new buffers in a DMA chain,
    or start and stop the streaming
  \end{itemize}
\end{frame}

\begin{frame}{Controls}
  \begin{itemize}
  \item Your device might need additional set up for things like 
    \begin{itemize}
    \item White balance
    \item Saturation
    \item Brightness
    \item etc.
    \end{itemize}
  \item By default, no controls are implemented, but the driver needs
    to declare them during probe, and handle them in a dedicated
    callback.
  \end{itemize}
\end{frame}

\begin{frame}{Driver view}
  \begin{itemize}
  \item You'll usually have two drivers:
    \begin{itemize}
    \item One for the controller, usually in \code{drivers/media/platform}
    \item And one for the camera, in \code{drivers/media/i2c}
    \end{itemize}
  \item By default, exposed to the userspace as one single device
    \code{/dev/videoX}
  \item You need some synchronization between the two: v4l2-async
  \item Very similar to what is found in ASoC or DRM
  \item Basically a two-stage probe
  \end{itemize}
\end{frame}

\begin{frame}{State machine}
  \begin{center}
    \includegraphics[height=0.75\textheight]{v4l-state-machine.pdf}
  \end{center}
\end{frame}

\begin{frame}{Multi-plane}
  \begin{itemize}
  \item Some formats require multi-plane support
  \item Depending on the format, it might need 1 to 3 buffers
  \item Supported in v4l through a different capture type
  \item The callbacks are different too, but very similar
  \item You basically just have to deal with more buffers
  \end{itemize}
\end{frame}

\begin{frame}{More complicated setup}
  \begin{center}
    \includegraphics[width=\textwidth]{v4l-media.pdf}
  \end{center}
\end{frame}

\begin{frame}{Media}
  \begin{itemize}
  \item When the pipeline gets more complicated, the amount of
    controls to expose in the video device starts to be impossible to
    deal with
  \item The media controller API allows to expose one device file per
    component in the pipeline
  \item Each of them can be accessed independently, for example with
    media-ctl
  \item It might even simplify your driver, because all the format
    negotiation will not be relevant anymore.
  \end{itemize}
\end{frame}

\begin{frame}{Tests!}
  \begin{itemize}
  \item v4l2-compliance is awesome
  \item v4l2-info
  \item yavta
  \item Any v4l enabled application (Cheese?)
  \end{itemize}
\end{frame}

\section{Future developments}

\begin{frame}{Integration with DRM}
  \begin{itemize}
  \item Our camera and display engines can work in the same format
    (but no driver support for it yet in the DRM driver)
  \item The display engine is even able to re-scale the video coming
    from the camera (but there's no driver support for it yet).
  \item Finding which component in userspace could do that. Gstreamer?
    Something a la ALSA cards configuration files?
  \end{itemize}
\end{frame}

\begin{frame}{VPU Support}
  \begin{itemize}
  \item We have some work on-going to support the VPU on the Allwinner
    SoCs
  \item Reverse engineering
  \item Decoding works for some codecs and image formats
  \item Encoding is not really understood right now
  \item Figure it out and support encoding through the VPU
  \end{itemize}
\end{frame}

\questionslide{}

\end{document}