You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media into next
Pull media updates from Mauro Carvalho Chehab: "This contains: - a new frontend/tuner driver set for si2168 and sa2157 - Videobuf 2 core now supports DVB too - A new gspca sub-driver (dtcs033) - saa7134 is now converted to use videobuf2 - add support for 4K timings - several other driver fixes and improvements PS. This pull request is shorter than usual, partly because I have some other patches on topic branches that I'll be sending you later this week" * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (286 commits) [media] au0828-dvb: restore its permission to 644 [media] xc5000: delay tuner sleep to 5 seconds [media] xc5000: Don't use whitespace before tabs [media] xc5000: fix CamelCase [media] xc5000: Don't wrap msleep() [media] xc5000: get rid of positive error codes [media] au0828: reset streaming when a new frequency is set [media] au0828: Improve debug messages for urb_completion [media] au0828: Cancel stream-restart operation if frontend is disconnected [media] dib0700: fix RC support on Hauppauge Nova-TD [media] USB: as102_usb_drv.c: Remove useless return variables [media] v4l: Fix documentation of V4L2_PIX_FMT_H264_MVC and VP8 pixel formats [media] m5mols: Replace missing header [media] staging: lirc: Fix sparse warnings [media] fix mceusb endpoint type identification/handling [media] az6027: Added the PID for a new revision of the Elgato EyeTV Sat DVB-S Tuner [media] DocBook media: fix typo [media] adv7604: Add missing include to linux/types.h [media] v4l: Validate fields in the core code for subdev EDID ioctls [media] v4l: Add support for DV timings ioctls on subdev nodes ...
This commit is contained in:
@@ -125,7 +125,7 @@ location of the buffers in device memory can be determined with the
|
||||
<structfield>m.offset</structfield> and <structfield>length</structfield>
|
||||
returned in a &v4l2-buffer; are passed as sixth and second parameter to the
|
||||
<function>mmap()</function> function. When using the multi-planar API,
|
||||
struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each
|
||||
&v4l2-buffer; contains an array of &v4l2-plane; structures, each
|
||||
containing its own <structfield>m.offset</structfield> and
|
||||
<structfield>length</structfield>. When using the multi-planar API, every
|
||||
plane of every buffer has to be mapped separately, so the number of
|
||||
@@ -699,7 +699,12 @@ linkend="v4l2-buf-type" /></entry>
|
||||
buffer. It depends on the negotiated data format and may change with
|
||||
each buffer for compressed variable size data like JPEG images.
|
||||
Drivers must set this field when <structfield>type</structfield>
|
||||
refers to an input stream, applications when it refers to an output stream.</entry>
|
||||
refers to an input stream, applications when it refers to an output stream.
|
||||
If the application sets this to 0 for an output stream, then
|
||||
<structfield>bytesused</structfield> will be set to the size of the
|
||||
buffer (see the <structfield>length</structfield> field of this struct) by
|
||||
the driver. For multiplanar formats this field is ignored and the
|
||||
<structfield>planes</structfield> pointer is used instead.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
@@ -861,7 +866,11 @@ should set this to 0.</entry>
|
||||
<entry></entry>
|
||||
<entry>The number of bytes occupied by data in the plane
|
||||
(its payload). Drivers must set this field when <structfield>type</structfield>
|
||||
refers to an input stream, applications when it refers to an output stream.</entry>
|
||||
refers to an input stream, applications when it refers to an output stream.
|
||||
If the application sets this to 0 for an output stream, then
|
||||
<structfield>bytesused</structfield> will be set to the size of the
|
||||
plane (see the <structfield>length</structfield> field of this struct)
|
||||
by the driver.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
||||
@@ -79,13 +79,13 @@
|
||||
<entry>Entity id, set by the application.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>struct &media-pad-desc;</entry>
|
||||
<entry>&media-pad-desc;</entry>
|
||||
<entry>*<structfield>pads</structfield></entry>
|
||||
<entry>Pointer to a pads array allocated by the application. Ignored
|
||||
if NULL.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>struct &media-link-desc;</entry>
|
||||
<entry>&media-link-desc;</entry>
|
||||
<entry>*<structfield>links</structfield></entry>
|
||||
<entry>Pointer to a links array allocated by the application. Ignored
|
||||
if NULL.</entry>
|
||||
@@ -153,12 +153,12 @@
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>struct &media-pad-desc;</entry>
|
||||
<entry>&media-pad-desc;</entry>
|
||||
<entry><structfield>source</structfield></entry>
|
||||
<entry>Pad at the origin of this link.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>struct &media-pad-desc;</entry>
|
||||
<entry>&media-pad-desc;</entry>
|
||||
<entry><structfield>sink</structfield></entry>
|
||||
<entry>Pad at the target of this link.</entry>
|
||||
</row>
|
||||
|
||||
@@ -772,7 +772,7 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-H264-MVC">
|
||||
<entry><constant>V4L2_PIX_FMT_H264_MVC</constant></entry>
|
||||
<entry>'MVC'</entry>
|
||||
<entry>'M264'</entry>
|
||||
<entry>H264 MVC video elementary stream.</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-H263">
|
||||
@@ -812,7 +812,7 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-VP8">
|
||||
<entry><constant>V4L2_PIX_FMT_VP8</constant></entry>
|
||||
<entry>'VP8'</entry>
|
||||
<entry>'VP80'</entry>
|
||||
<entry>VP8 video elementary stream.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -242,6 +242,22 @@
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-event-src-change">
|
||||
<title>struct <structname>v4l2_event_src_change</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>changes</structfield></entry>
|
||||
<entry>
|
||||
A bitmask that tells what has changed. See <xref linkend="src-changes-flags" />.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="changes-flags">
|
||||
<title>Changes</title>
|
||||
<tgroup cols="3">
|
||||
@@ -270,6 +286,23 @@
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="src-changes-flags">
|
||||
<title>Source Changes</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_SRC_CH_RESOLUTION</constant></entry>
|
||||
<entry>0x0001</entry>
|
||||
<entry>This event gets triggered when a resolution change is
|
||||
detected at an input. This can come from an input connector or
|
||||
from a video decoder.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<refentry id="vidioc-dv-timings-cap">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_DV_TIMINGS_CAP</refentrytitle>
|
||||
<refentrytitle>ioctl VIDIOC_DV_TIMINGS_CAP, VIDIOC_SUBDEV_DV_TIMINGS_CAP</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_DV_TIMINGS_CAP</refname>
|
||||
<refname>VIDIOC_SUBDEV_DV_TIMINGS_CAP</refname>
|
||||
<refpurpose>The capabilities of the Digital Video receiver/transmitter</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
@@ -33,7 +34,7 @@
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_DV_TIMINGS_CAP</para>
|
||||
<para>VIDIOC_DV_TIMINGS_CAP, VIDIOC_SUBDEV_DV_TIMINGS_CAP</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
@@ -54,10 +55,19 @@
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>To query the capabilities of the DV receiver/transmitter applications can call
|
||||
this ioctl and the driver will fill in the structure. Note that drivers may return
|
||||
<para>To query the capabilities of the DV receiver/transmitter applications
|
||||
can call the <constant>VIDIOC_DV_TIMINGS_CAP</constant> ioctl on a video node
|
||||
and the driver will fill in the structure. Note that drivers may return
|
||||
different values after switching the video input or output.</para>
|
||||
|
||||
<para>When implemented by the driver DV capabilities of subdevices can be
|
||||
queried by calling the <constant>VIDIOC_SUBDEV_DV_TIMINGS_CAP</constant> ioctl
|
||||
directly on a subdevice node. The capabilities are specific to inputs (for DV
|
||||
receivers) or outputs (for DV transmitters), applications must specify the
|
||||
desired pad number in the &v4l2-dv-timings-cap; <structfield>pad</structfield>
|
||||
field. Attempts to query capabilities on a pad that doesn't support them will
|
||||
return an &EINVAL;.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-bt-timings-cap">
|
||||
<title>struct <structname>v4l2_bt_timings_cap</structname></title>
|
||||
<tgroup cols="3">
|
||||
@@ -127,7 +137,14 @@ different values after switching the video input or output.</para>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[3]</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad number as reported by the media controller API. This field
|
||||
is only used when operating on a subdevice node. When operating on a
|
||||
video node applications must set this field to zero.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[2]</entry>
|
||||
<entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
<refentry id="vidioc-enum-dv-timings">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_ENUM_DV_TIMINGS</refentrytitle>
|
||||
<refentrytitle>ioctl VIDIOC_ENUM_DV_TIMINGS, VIDIOC_SUBDEV_ENUM_DV_TIMINGS</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_ENUM_DV_TIMINGS</refname>
|
||||
<refname>VIDIOC_SUBDEV_ENUM_DV_TIMINGS</refname>
|
||||
<refpurpose>Enumerate supported Digital Video timings</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
@@ -33,7 +34,7 @@
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_ENUM_DV_TIMINGS</para>
|
||||
<para>VIDIOC_ENUM_DV_TIMINGS, VIDIOC_SUBDEV_ENUM_DV_TIMINGS</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
@@ -61,14 +62,21 @@ standards or even custom timings that are not in this list.</para>
|
||||
|
||||
<para>To query the available timings, applications initialize the
|
||||
<structfield>index</structfield> field and zero the reserved array of &v4l2-enum-dv-timings;
|
||||
and call the <constant>VIDIOC_ENUM_DV_TIMINGS</constant> ioctl with a pointer to this
|
||||
structure. Drivers fill the rest of the structure or return an
|
||||
and call the <constant>VIDIOC_ENUM_DV_TIMINGS</constant> ioctl on a video node with a
|
||||
pointer to this structure. Drivers fill the rest of the structure or return an
|
||||
&EINVAL; when the index is out of bounds. To enumerate all supported DV timings,
|
||||
applications shall begin at index zero, incrementing by one until the
|
||||
driver returns <errorcode>EINVAL</errorcode>. Note that drivers may enumerate a
|
||||
different set of DV timings after switching the video input or
|
||||
output.</para>
|
||||
|
||||
<para>When implemented by the driver DV timings of subdevices can be queried
|
||||
by calling the <constant>VIDIOC_SUBDEV_ENUM_DV_TIMINGS</constant> ioctl directly
|
||||
on a subdevice node. The DV timings are specific to inputs (for DV receivers) or
|
||||
outputs (for DV transmitters), applications must specify the desired pad number
|
||||
in the &v4l2-enum-dv-timings; <structfield>pad</structfield> field. Attempts to
|
||||
enumerate timings on a pad that doesn't support them will return an &EINVAL;.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-enum-dv-timings">
|
||||
<title>struct <structname>v4l2_enum_dv_timings</structname></title>
|
||||
<tgroup cols="3">
|
||||
@@ -82,8 +90,16 @@ application.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[3]</entry>
|
||||
<entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad number as reported by the media controller API. This field
|
||||
is only used when operating on a subdevice node. When operating on a
|
||||
video node applications must set this field to zero.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[2]</entry>
|
||||
<entry>Reserved for future extensions. Drivers and applications must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-dv-timings;</entry>
|
||||
@@ -103,7 +119,7 @@ application.</entry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-enum-dv-timings; <structfield>index</structfield>
|
||||
is out of bounds.</para>
|
||||
is out of bounds or the <structfield>pad</structfield> number is invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
||||
@@ -154,6 +154,26 @@
|
||||
frame interval in between them.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_SOURCE_CHANGE</constant></entry>
|
||||
<entry>5</entry>
|
||||
<entry>
|
||||
<para>This event is triggered when a source parameter change is
|
||||
detected during runtime by the video device. It can be a
|
||||
runtime resolution change triggered by a video decoder or the
|
||||
format change happening on an input connector.
|
||||
This event requires that the <structfield>id</structfield>
|
||||
matches the input index (when used with a video device node)
|
||||
or the pad index (when used with a subdevice node) from which
|
||||
you want to receive events.</para>
|
||||
|
||||
<para>This event has a &v4l2-event-src-change; associated
|
||||
with it. The <structfield>changes</structfield> bitfield denotes
|
||||
what has changed for the subscribed pad. If multiple events
|
||||
occurred before application could dequeue them, then the changes
|
||||
will have the ORed value of all the events generated.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
|
||||
<entry>0x08000000</entry>
|
||||
|
||||
@@ -10,7 +10,8 @@ Required properties:
|
||||
- compatible : value should be either one among the following
|
||||
(a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
|
||||
(b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
|
||||
(b) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
|
||||
(c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
|
||||
(d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
|
||||
|
||||
- reg : Physical base address of the IP registers and length of memory
|
||||
mapped region.
|
||||
|
||||
@@ -164,3 +164,4 @@
|
||||
163 -> Bt848 Capture 14MHz
|
||||
164 -> CyberVision CV06 (SV)
|
||||
165 -> Kworld V-Stream Xpert TV PVR878
|
||||
166 -> PCI-8604PW
|
||||
|
||||
@@ -92,3 +92,4 @@
|
||||
91 -> SpeedLink Vicious And Devine Laplace webcam (em2765) [1ae7:9003,1ae7:9004]
|
||||
92 -> PCTV DVB-S2 Stick (461e) (em28178)
|
||||
93 -> KWorld USB ATSC TV Stick UB435-Q V3 (em2874) [1b80:e34c]
|
||||
94 -> PCTV tripleStick (292e) (em28178)
|
||||
|
||||
@@ -140,39 +140,9 @@ You can either grep through the kernel log to find relevant information, i.e.
|
||||
or retrieve the information from /dev/media? with help of the media-ctl tool:
|
||||
# media-ctl -p
|
||||
|
||||
6. Platform support
|
||||
===================
|
||||
|
||||
The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select
|
||||
following options:
|
||||
|
||||
CONFIG_S5P_DEV_FIMC0 mandatory
|
||||
CONFIG_S5P_DEV_FIMC1 \
|
||||
CONFIG_S5P_DEV_FIMC2 | optional
|
||||
CONFIG_S5P_DEV_FIMC3 |
|
||||
CONFIG_S5P_SETUP_FIMC /
|
||||
CONFIG_S5P_DEV_CSIS0 \ optional for MIPI-CSI interface
|
||||
CONFIG_S5P_DEV_CSIS1 /
|
||||
|
||||
Except that, relevant s5p_device_fimc? should be registered in the machine code
|
||||
in addition to a "s5p-fimc-md" platform device to which the media device driver
|
||||
is bound. The "s5p-fimc-md" device instance is required even if only mem-to-mem
|
||||
operation is used.
|
||||
|
||||
The description of sensor(s) attached to FIMC/MIPI-CSIS camera inputs should be
|
||||
passed as the "s5p-fimc-md" device platform_data. The platform data structure
|
||||
is defined in file include/media/s5p_fimc.h.
|
||||
|
||||
7. Build
|
||||
========
|
||||
|
||||
This driver depends on following config options:
|
||||
PLAT_S5P,
|
||||
PM_RUNTIME,
|
||||
I2C,
|
||||
REGULATOR,
|
||||
VIDEO_V4L2_SUBDEV_API,
|
||||
|
||||
If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m)
|
||||
two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and
|
||||
optional s5p-csis.ko (MIPI-CSI receiver subdev).
|
||||
|
||||
@@ -77,7 +77,8 @@ struct skeleton {
|
||||
|
||||
spinlock_t qlock;
|
||||
struct list_head buf_list;
|
||||
unsigned int sequence;
|
||||
unsigned field;
|
||||
unsigned sequence;
|
||||
};
|
||||
|
||||
struct skel_buffer {
|
||||
@@ -124,7 +125,7 @@ static const struct v4l2_dv_timings_cap skel_timings_cap = {
|
||||
* Interrupt handler: typically interrupts happen after a new frame has been
|
||||
* captured. It is the job of the handler to remove the new frame from the
|
||||
* internal list and give it back to the vb2 framework, updating the sequence
|
||||
* counter and timestamp at the same time.
|
||||
* counter, field and timestamp at the same time.
|
||||
*/
|
||||
static irqreturn_t skeleton_irq(int irq, void *dev_id)
|
||||
{
|
||||
@@ -139,8 +140,15 @@ static irqreturn_t skeleton_irq(int irq, void *dev_id)
|
||||
spin_lock(&skel->qlock);
|
||||
list_del(&new_buf->list);
|
||||
spin_unlock(&skel->qlock);
|
||||
new_buf->vb.v4l2_buf.sequence = skel->sequence++;
|
||||
v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp);
|
||||
new_buf->vb.v4l2_buf.sequence = skel->sequence++;
|
||||
new_buf->vb.v4l2_buf.field = skel->field;
|
||||
if (skel->format.field == V4L2_FIELD_ALTERNATE) {
|
||||
if (skel->field == V4L2_FIELD_BOTTOM)
|
||||
skel->field = V4L2_FIELD_TOP;
|
||||
else if (skel->field == V4L2_FIELD_TOP)
|
||||
skel->field = V4L2_FIELD_BOTTOM;
|
||||
}
|
||||
vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE);
|
||||
}
|
||||
#endif
|
||||
@@ -160,6 +168,17 @@ static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
|
||||
{
|
||||
struct skeleton *skel = vb2_get_drv_priv(vq);
|
||||
|
||||
skel->field = skel->format.field;
|
||||
if (skel->field == V4L2_FIELD_ALTERNATE) {
|
||||
/*
|
||||
* You cannot use read() with FIELD_ALTERNATE since the field
|
||||
* information (TOP/BOTTOM) cannot be passed back to the user.
|
||||
*/
|
||||
if (vb2_fileio_is_active(vq))
|
||||
return -EINVAL;
|
||||
skel->field = V4L2_FIELD_TOP;
|
||||
}
|
||||
|
||||
if (vq->num_buffers + *nbuffers < 3)
|
||||
*nbuffers = 3 - vq->num_buffers;
|
||||
|
||||
@@ -173,10 +192,7 @@ static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
|
||||
|
||||
/*
|
||||
* Prepare the buffer for queueing to the DMA engine: check and set the
|
||||
* payload size and fill in the field. Note: if the format's field is
|
||||
* V4L2_FIELD_ALTERNATE, then vb->v4l2_buf.field should be set in the
|
||||
* interrupt handler since that's usually where you know if the TOP or
|
||||
* BOTTOM field has been captured.
|
||||
* payload size.
|
||||
*/
|
||||
static int buffer_prepare(struct vb2_buffer *vb)
|
||||
{
|
||||
@@ -190,7 +206,6 @@ static int buffer_prepare(struct vb2_buffer *vb)
|
||||
}
|
||||
|
||||
vb2_set_plane_payload(vb, 0, size);
|
||||
vb->v4l2_buf.field = skel->format.field;
|
||||
return 0;
|
||||
}
|
||||
|
||||
@@ -254,7 +269,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count)
|
||||
* Stop the DMA engine. Any remaining buffers in the DMA queue are dequeued
|
||||
* and passed on to the vb2 framework marked as STATE_ERROR.
|
||||
*/
|
||||
static int stop_streaming(struct vb2_queue *vq)
|
||||
static void stop_streaming(struct vb2_queue *vq)
|
||||
{
|
||||
struct skeleton *skel = vb2_get_drv_priv(vq);
|
||||
|
||||
@@ -262,7 +277,6 @@ static int stop_streaming(struct vb2_queue *vq)
|
||||
|
||||
/* Release all active buffers */
|
||||
return_all_buffers(skel, VB2_BUF_STATE_ERROR);
|
||||
return 0;
|
||||
}
|
||||
|
||||
/*
|
||||
@@ -319,10 +333,12 @@ static void skeleton_fill_pix_format(struct skeleton *skel,
|
||||
/* HDMI input */
|
||||
pix->width = skel->timings.bt.width;
|
||||
pix->height = skel->timings.bt.height;
|
||||
if (skel->timings.bt.interlaced)
|
||||
pix->field = V4L2_FIELD_INTERLACED;
|
||||
else
|
||||
if (skel->timings.bt.interlaced) {
|
||||
pix->field = V4L2_FIELD_ALTERNATE;
|
||||
pix->height /= 2;
|
||||
} else {
|
||||
pix->field = V4L2_FIELD_NONE;
|
||||
}
|
||||
pix->colorspace = V4L2_COLORSPACE_REC709;
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user