diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 10:05:51 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 10:05:51 +0000 |
commit | 5d1646d90e1f2cceb9f0828f4b28318cd0ec7744 (patch) | |
tree | a94efe259b9009378be6d90eb30d2b019d95c194 /Documentation/userspace-api/media/v4l/func-mmap.rst | |
parent | Initial commit. (diff) | |
download | linux-430c2fc249ea5c0536abd21c23382884005c9093.tar.xz linux-430c2fc249ea5c0536abd21c23382884005c9093.zip |
Adding upstream version 5.10.209.upstream/5.10.209upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'Documentation/userspace-api/media/v4l/func-mmap.rst')
-rw-r--r-- | Documentation/userspace-api/media/v4l/func-mmap.rst | 137 |
1 files changed, 137 insertions, 0 deletions
diff --git a/Documentation/userspace-api/media/v4l/func-mmap.rst b/Documentation/userspace-api/media/v4l/func-mmap.rst new file mode 100644 index 000000000..e3e5e64eb --- /dev/null +++ b/Documentation/userspace-api/media/v4l/func-mmap.rst @@ -0,0 +1,137 @@ +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later +.. c:namespace:: V4L + +.. _func-mmap: + +*********** +V4L2 mmap() +*********** + +Name +==== + +v4l2-mmap - Map device memory into application address space + +Synopsis +======== + +.. code-block:: c + + #include <unistd.h> + #include <sys/mman.h> + +.. c:function:: void *mmap( void *start, size_t length, int prot, int flags, int fd, off_t offset ) + +Arguments +========= + +``start`` + Map the buffer to this address in the application's address space. + When the ``MAP_FIXED`` flag is specified, ``start`` must be a + multiple of the pagesize and mmap will fail when the specified + address cannot be used. Use of this option is discouraged; + applications should just specify a ``NULL`` pointer here. + +``length`` + Length of the memory area to map. This must be the same value as + returned by the driver in the struct + :c:type:`v4l2_buffer` ``length`` field for the + single-planar API, and the same value as returned by the driver in + the struct :c:type:`v4l2_plane` ``length`` field for + the multi-planar API. + +``prot`` + The ``prot`` argument describes the desired memory protection. + Regardless of the device type and the direction of data exchange it + should be set to ``PROT_READ`` | ``PROT_WRITE``, permitting read + and write access to image buffers. Drivers should support at least + this combination of flags. + + .. note:: + + #. The Linux ``videobuf`` kernel module, which is used by some + drivers supports only ``PROT_READ`` | ``PROT_WRITE``. When the + driver does not support the desired protection, the + :c:func:`mmap()` function fails. + + #. Device memory accesses (e. g. the memory on a graphics card + with video capturing hardware) may incur a performance penalty + compared to main memory accesses, or reads may be significantly + slower than writes or vice versa. Other I/O methods may be more + efficient in such case. + +``flags`` + The ``flags`` parameter specifies the type of the mapped object, + mapping options and whether modifications made to the mapped copy of + the page are private to the process or are to be shared with other + references. + + ``MAP_FIXED`` requests that the driver selects no other address than + the one specified. If the specified address cannot be used, + :c:func:`mmap()` will fail. If ``MAP_FIXED`` is specified, + ``start`` must be a multiple of the pagesize. Use of this option is + discouraged. + + One of the ``MAP_SHARED`` or ``MAP_PRIVATE`` flags must be set. + ``MAP_SHARED`` allows applications to share the mapped memory with + other (e. g. child-) processes. + + .. note:: + + The Linux ``videobuf`` module which is used by some + drivers supports only ``MAP_SHARED``. ``MAP_PRIVATE`` requests + copy-on-write semantics. V4L2 applications should not set the + ``MAP_PRIVATE``, ``MAP_DENYWRITE``, ``MAP_EXECUTABLE`` or ``MAP_ANON`` + flags. + +``fd`` + File descriptor returned by :c:func:`open()`. + +``offset`` + Offset of the buffer in device memory. This must be the same value + as returned by the driver in the struct + :c:type:`v4l2_buffer` ``m`` union ``offset`` field for + the single-planar API, and the same value as returned by the driver + in the struct :c:type:`v4l2_plane` ``m`` union + ``mem_offset`` field for the multi-planar API. + +Description +=========== + +The :c:func:`mmap()` function asks to map ``length`` bytes starting at +``offset`` in the memory of the device specified by ``fd`` into the +application address space, preferably at address ``start``. This latter +address is a hint only, and is usually specified as 0. + +Suitable length and offset parameters are queried with the +:ref:`VIDIOC_QUERYBUF` ioctl. Buffers must be +allocated with the :ref:`VIDIOC_REQBUFS` ioctl +before they can be queried. + +To unmap buffers the :c:func:`munmap()` function is used. + +Return Value +============ + +On success :c:func:`mmap()` returns a pointer to the mapped buffer. On +error ``MAP_FAILED`` (-1) is returned, and the ``errno`` variable is set +appropriately. Possible error codes are: + +EBADF + ``fd`` is not a valid file descriptor. + +EACCES + ``fd`` is not open for reading and writing. + +EINVAL + The ``start`` or ``length`` or ``offset`` are not suitable. (E. g. + they are too large, or not aligned on a ``PAGESIZE`` boundary.) + + The ``flags`` or ``prot`` value is not supported. + + No buffers have been allocated with the + :ref:`VIDIOC_REQBUFS` ioctl. + +ENOMEM + Not enough physical or virtual memory was available to complete the + request. |