Documentation/linux_tv/media/v4l/func-mmap.rst

   1 .. -*- coding: utf-8; mode: rst -*-
   2
   3 .. _func-mmap:
   4
   5 ***********
   6 V4L2 mmap()
   7 ***********
   8
   9 NAME
  10 ====
  11
  12 v4l2-mmap - Map device memory into application address space
  13
  14 SYNOPSIS
  15 ========
  16
  17 .. code-block:: c
  18
  19     #include <unistd.h>
  20     #include <sys/mman.h>
  21
  22
  23 .. cpp:function:: void *mmap( void *start, size_t length, int prot, int flags, int fd, off_t offset )
  24
  25
  26 ARGUMENTS
  27 =========
  28
  29 ``start``
  30     Map the buffer to this address in the application's address space.
  31     When the ``MAP_FIXED`` flag is specified, ``start`` must be a
  32     multiple of the pagesize and mmap will fail when the specified
  33     address cannot be used. Use of this option is discouraged;
  34     applications should just specify a ``NULL`` pointer here.
  35
  36 ``length``
  37     Length of the memory area to map. This must be the same value as
  38     returned by the driver in the struct
  39     :ref:`v4l2_buffer <v4l2-buffer>` ``length`` field for the
  40     single-planar API, and the same value as returned by the driver in
  41     the struct :ref:`v4l2_plane <v4l2-plane>` ``length`` field for
  42     the multi-planar API.
  43
  44 ``prot``
  45     The ``prot`` argument describes the desired memory protection.
  46     Regardless of the device type and the direction of data exchange it
  47     should be set to ``PROT_READ`` | ``PROT_WRITE``, permitting read
  48     and write access to image buffers. Drivers should support at least
  49     this combination of flags. Note the Linux ``video-buf`` kernel
  50     module, which is used by the bttv, saa7134, saa7146, cx88 and vivi
  51     driver supports only ``PROT_READ`` | ``PROT_WRITE``. When the
  52     driver does not support the desired protection the
  53     :ref:`mmap() <func-mmap>` function fails.
  54
  55     Note device memory accesses (e. g. the memory on a graphics card
  56     with video capturing hardware) may incur a performance penalty
  57     compared to main memory accesses, or reads may be significantly
  58     slower than writes or vice versa. Other I/O methods may be more
  59     efficient in this case.
  60
  61 ``flags``
  62     The ``flags`` parameter specifies the type of the mapped object,
  63     mapping options and whether modifications made to the mapped copy of
  64     the page are private to the process or are to be shared with other
  65     references.
  66
  67     ``MAP_FIXED`` requests that the driver selects no other address than
  68     the one specified. If the specified address cannot be used,
  69     :ref:`mmap() <func-mmap>` will fail. If ``MAP_FIXED`` is specified,
  70     ``start`` must be a multiple of the pagesize. Use of this option is
  71     discouraged.
  72
  73     One of the ``MAP_SHARED`` or ``MAP_PRIVATE`` flags must be set.
  74     ``MAP_SHARED`` allows applications to share the mapped memory with
  75     other (e. g. child-) processes. Note the Linux ``video-buf`` module
  76     which is used by the bttv, saa7134, saa7146, cx88 and vivi driver
  77     supports only ``MAP_SHARED``. ``MAP_PRIVATE`` requests copy-on-write
  78     semantics. V4L2 applications should not set the ``MAP_PRIVATE``,
  79     ``MAP_DENYWRITE``, ``MAP_EXECUTABLE`` or ``MAP_ANON`` flag.
  80
  81 ``fd``
  82     File descriptor returned by :ref:`open() <func-open>`.
  83
  84 ``offset``
  85     Offset of the buffer in device memory. This must be the same value
  86     as returned by the driver in the struct
  87     :ref:`v4l2_buffer <v4l2-buffer>` ``m`` union ``offset`` field for
  88     the single-planar API, and the same value as returned by the driver
  89     in the struct :ref:`v4l2_plane <v4l2-plane>` ``m`` union
  90     ``mem_offset`` field for the multi-planar API.
  91
  92
  93 DESCRIPTION
  94 ===========
  95
  96 The :ref:`mmap() <func-mmap>` function asks to map ``length`` bytes starting at
  97 ``offset`` in the memory of the device specified by ``fd`` into the
  98 application address space, preferably at address ``start``. This latter
  99 address is a hint only, and is usually specified as 0.
 100
 101 Suitable length and offset parameters are queried with the
 102 :ref:`VIDIOC_QUERYBUF` ioctl. Buffers must be
 103 allocated with the :ref:`VIDIOC_REQBUFS` ioctl
 104 before they can be queried.
 105
 106 To unmap buffers the :ref:`munmap() <func-munmap>` function is used.
 107
 108
 109 RETURN VALUE
 110 ============
 111
 112 On success :ref:`mmap() <func-mmap>` returns a pointer to the mapped buffer. On
 113 error ``MAP_FAILED`` (-1) is returned, and the ``errno`` variable is set
 114 appropriately. Possible error codes are:
 115
 116 EBADF
 117     ``fd`` is not a valid file descriptor.
 118
 119 EACCES
 120     ``fd`` is not open for reading and writing.
 121
 122 EINVAL
 123     The ``start`` or ``length`` or ``offset`` are not suitable. (E. g.
 124     they are too large, or not aligned on a ``PAGESIZE`` boundary.)
 125
 126     The ``flags`` or ``prot`` value is not supported.
 127
 128     No buffers have been allocated with the
 129     :ref:`VIDIOC_REQBUFS` ioctl.
 130
 131 ENOMEM
 132     Not enough physical or virtual memory was available to complete the
 133     request.