Merge tag 'media/v4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab: - new DVB frontend drivers: ascot2e, cxd2841er, horus3a, lnbh25 - new HDMI capture driver: tc358743 - new driver for NetUP DVB new boards (netup_unidvb) - IR support for DVBSky cards (smipcie-ir) - Coda driver has gain macroblock tiling support - Renesas R-Car gains JPEG codec driver - new DVB platform driver for STi boards: c8sectpfe - added documentation for the media core kABI to device-drivers DocBook - lots of driver fixups, cleanups and improvements * tag 'media/v4.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (297 commits) [media] c8sectpfe: Remove select on undefined LIBELF_32 [media] i2c: fix platform_no_drv_owner.cocci warnings [media] cx231xx: Use wake_up_interruptible() instead of wake_up_interruptible_nr() [media] tc358743: only queue subdev notifications if devnode is set [media] tc358743: add missing Kconfig dependency/select [media] c8sectpfe: Use %pad to print 'dma_addr_t' [media] DocBook media: Fix typo "the the" in xml files [media] tc358743: make reset gpio optional [media] tc358743: set direction of reset gpio using devm_gpiod_get [media] dvbdev: document most of the functions/data structs [media] dvb_frontend.h: document the struct dvb_frontend [media] dvb-frontend.h: document struct dtv_frontend_properties [media] dvb-frontend.h: document struct dvb_frontend_ops [media] dvb: Use DVBFE_ALGO_HW where applicable [media] dvb_frontend.h: document struct analog_demod_ops [media] dvb_frontend.h: Document struct dvb_tuner_ops [media] Docbook: Document struct analog_parameters [media] dvb_frontend.h: get rid of dvbfe_modcod [media] add documentation for struct dvb_tuner_info [media] dvb_frontend: document dvb_frontend_tune_settings ...
Tento commit je obsažen v:
@@ -217,6 +217,40 @@ X!Isound/sound_firmware.c
|
||||
-->
|
||||
</chapter>
|
||||
|
||||
<chapter id="mediadev">
|
||||
<title>Media Devices</title>
|
||||
|
||||
<sect1><title>Video2Linux devices</title>
|
||||
!Iinclude/media/v4l2-async.h
|
||||
!Iinclude/media/v4l2-ctrls.h
|
||||
!Iinclude/media/v4l2-dv-timings.h
|
||||
!Iinclude/media/v4l2-event.h
|
||||
!Iinclude/media/v4l2-flash-led-class.h
|
||||
!Iinclude/media/v4l2-mediabus.h
|
||||
!Iinclude/media/v4l2-mem2mem.h
|
||||
!Iinclude/media/v4l2-of.h
|
||||
!Iinclude/media/v4l2-subdev.h
|
||||
!Iinclude/media/videobuf2-core.h
|
||||
!Iinclude/media/videobuf2-memops.h
|
||||
</sect1>
|
||||
<sect1><title>Digital TV (DVB) devices</title>
|
||||
!Idrivers/media/dvb-core/dvb_ca_en50221.h
|
||||
!Idrivers/media/dvb-core/dvb_frontend.h
|
||||
!Idrivers/media/dvb-core/dvb_math.h
|
||||
!Idrivers/media/dvb-core/dvb_ringbuffer.h
|
||||
!Idrivers/media/dvb-core/dvbdev.h
|
||||
</sect1>
|
||||
<sect1><title>Remote Controller devices</title>
|
||||
!Iinclude/media/rc-core.h
|
||||
</sect1>
|
||||
<sect1><title>Media Controller devices</title>
|
||||
!Iinclude/media/media-device.h
|
||||
!Iinclude/media/media-devnode.h
|
||||
!Iinclude/media/media-entity.h
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="uart16x50">
|
||||
<title>16x50 UART Driver</title>
|
||||
!Edrivers/tty/serial/serial_core.c
|
||||
|
@@ -199,7 +199,8 @@ DVB_DOCUMENTED = \
|
||||
#
|
||||
|
||||
install_media_images = \
|
||||
$(Q)-cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
|
||||
$(Q)-mkdir $(MEDIA_OBJ_DIR)/media_api; \
|
||||
cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
|
||||
|
||||
$(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
|
||||
$(Q)base64 -d $< >$@
|
||||
|
@@ -163,9 +163,8 @@ are called:</para>
|
||||
<para>where N enumerates the DVB PCI cards in a system starting
|
||||
from 0, and M enumerates the devices of each type within each
|
||||
adapter, starting from 0, too. We will omit the “
|
||||
<constant>/dev/dvb/adapterN/</constant>” in the further dicussion
|
||||
of these devices. The naming scheme for the devices is the same wheter
|
||||
devfs is used or not.</para>
|
||||
<constant>/dev/dvb/adapterN/</constant>” in the further discussion
|
||||
of these devices.</para>
|
||||
|
||||
<para>More details about the data structures and function calls of all
|
||||
the devices are described in the following chapters.</para>
|
||||
|
@@ -3414,7 +3414,7 @@ giving priority to the center of the metered area.</entry>
|
||||
<row>
|
||||
<entry><constant>V4L2_EXPOSURE_METERING_MATRIX</constant> </entry>
|
||||
<entry>A multi-zone metering. The light intensity is measured
|
||||
in several points of the frame and the the results are combined. The
|
||||
in several points of the frame and the results are combined. The
|
||||
algorithm of the zones selection and their significance in calculating the
|
||||
final value is device dependent.</entry>
|
||||
</row>
|
||||
|
@@ -102,7 +102,7 @@
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>media_version</structfield></entry>
|
||||
<entry><structfield>driver_version</structfield></entry>
|
||||
<entry>Media device driver version, formatted with the
|
||||
<constant>KERNEL_VERSION()</constant> macro. Together with the
|
||||
<structfield>driver</structfield> field this identifies a particular
|
||||
|
@@ -62,28 +62,28 @@ buffer as a DMABUF file at any time after buffers have been allocated with the
|
||||
&VIDIOC-REQBUFS; ioctl.</para>
|
||||
|
||||
<para> To export a buffer, applications fill &v4l2-exportbuffer;. The
|
||||
<structfield> type </structfield> field is set to the same buffer type as was
|
||||
previously used with &v4l2-requestbuffers;<structfield> type </structfield>.
|
||||
Applications must also set the <structfield> index </structfield> field. Valid
|
||||
<structfield>type</structfield> field is set to the same buffer type as was
|
||||
previously used with &v4l2-requestbuffers; <structfield>type</structfield>.
|
||||
Applications must also set the <structfield>index</structfield> field. Valid
|
||||
index numbers range from zero to the number of buffers allocated with
|
||||
&VIDIOC-REQBUFS; (&v4l2-requestbuffers;<structfield> count </structfield>)
|
||||
minus one. For the multi-planar API, applications set the <structfield> plane
|
||||
</structfield> field to the index of the plane to be exported. Valid planes
|
||||
&VIDIOC-REQBUFS; (&v4l2-requestbuffers; <structfield>count</structfield>)
|
||||
minus one. For the multi-planar API, applications set the <structfield>plane</structfield>
|
||||
field to the index of the plane to be exported. Valid planes
|
||||
range from zero to the maximal number of valid planes for the currently active
|
||||
format. For the single-planar API, applications must set <structfield> plane
|
||||
</structfield> to zero. Additional flags may be posted in the <structfield>
|
||||
flags </structfield> field. Refer to a manual for open() for details.
|
||||
format. For the single-planar API, applications must set <structfield>plane</structfield>
|
||||
to zero. Additional flags may be posted in the <structfield>flags</structfield>
|
||||
field. Refer to a manual for open() for details.
|
||||
Currently only O_CLOEXEC, O_RDONLY, O_WRONLY, and O_RDWR are supported. All
|
||||
other fields must be set to zero.
|
||||
In the case of multi-planar API, every plane is exported separately using
|
||||
multiple <constant> VIDIOC_EXPBUF </constant> calls. </para>
|
||||
multiple <constant>VIDIOC_EXPBUF</constant> calls.</para>
|
||||
|
||||
<para> After calling <constant>VIDIOC_EXPBUF</constant> the <structfield> fd
|
||||
</structfield> field will be set by a driver. This is a DMABUF file
|
||||
<para>After calling <constant>VIDIOC_EXPBUF</constant> the <structfield>fd</structfield>
|
||||
field will be set by a driver. This is a DMABUF file
|
||||
descriptor. The application may pass it to other DMABUF-aware devices. Refer to
|
||||
<link linkend="dmabuf">DMABUF importing</link> for details about importing
|
||||
DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
|
||||
is no longer used to allow the associated memory to be reclaimed. </para>
|
||||
is no longer used to allow the associated memory to be reclaimed.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@@ -170,9 +170,9 @@ multi-planar API. Otherwise this value must be set to zero. </entry>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>Flags for the newly created file, currently only <constant>
|
||||
O_CLOEXEC </constant>, <constant>O_RDONLY</constant>, <constant>O_WRONLY
|
||||
</constant>, and <constant>O_RDWR</constant> are supported, refer to the manual
|
||||
<entry>Flags for the newly created file, currently only
|
||||
<constant>O_CLOEXEC</constant>, <constant>O_RDONLY</constant>, <constant>O_WRONLY</constant>,
|
||||
and <constant>O_RDWR</constant> are supported, refer to the manual
|
||||
of open() for more details.</entry>
|
||||
</row>
|
||||
<row>
|
||||
@@ -200,9 +200,9 @@ set the array to zero.</entry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>A queue is not in MMAP mode or DMABUF exporting is not
|
||||
supported or <structfield> flags </structfield> or <structfield> type
|
||||
</structfield> or <structfield> index </structfield> or <structfield> plane
|
||||
</structfield> fields are invalid.</para>
|
||||
supported or <structfield>flags</structfield> or <structfield>type</structfield>
|
||||
or <structfield>index</structfield> or <structfield>plane</structfield> fields
|
||||
are invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
@@ -267,7 +267,7 @@ is intended for still imaging applications. The idea is to get the
|
||||
best possible image quality that the hardware can deliver. It is not
|
||||
defined how the driver writer may achieve that; it will depend on the
|
||||
hardware and the ingenuity of the driver writer. High quality mode is
|
||||
a different mode from the the regular motion video capture modes. In
|
||||
a different mode from the regular motion video capture modes. In
|
||||
high quality mode:<itemizedlist>
|
||||
<listitem>
|
||||
<para>The driver may be able to capture higher
|
||||
|
@@ -616,7 +616,7 @@ pointer to memory containing the payload of the control.</entry>
|
||||
<entry><constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant></entry>
|
||||
<entry>0x0200</entry>
|
||||
<entry>The value provided to the control will be propagated to the driver
|
||||
even if remains constant. This is required when the control represents an action
|
||||
even if it remains constant. This is required when the control represents an action
|
||||
on the hardware. For example: clearing an error flag or triggering the flash. All the
|
||||
controls of the type <constant>V4L2_CTRL_TYPE_BUTTON</constant> have this flag set.</entry>
|
||||
</row>
|
||||
|
Odkázat v novém úkolu
Zablokovat Uživatele