- 19 Aug, 2019 29 commits
-
-
Hans Verkuil authored
The existing documentation was incorrect and did not correspond to how actual codec drivers implemented this. Update the documentation to explicitly specify what is actually expected. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Tomasz Figa authored
Due to complexity of the video decoding process, the V4L2 drivers of stateful decoder hardware require specific sequences of V4L2 API calls to be followed. These include capability enumeration, initialization, decoding, seek, pause, dynamic resolution change, drain and end of stream. Specifics of the above have been discussed during Media Workshops at LinuxCon Europe 2012 in Barcelona and then later Embedded Linux Conference Europe 2014 in Düsseldorf. The de facto Codec API that originated at those events was later implemented by the drivers we already have merged in mainline, such as s5p-mfc or coda. The only thing missing was the real specification included as a part of Linux Media documentation. Fix it now and document the decoder part of the Codec API. Signed-off-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Maxime Jourdan authored
Tag all the coded formats where the vicodec stateful decoder supports dynamic resolution switching and bytestream parsing. Signed-off-by:
Maxime Jourdan <mjourdan@baylibre.com> Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
-
Maxime Jourdan authored
Tag all the coded formats where the mtk-vcodec decoder supports dynamic resolution switching. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
-
Maxime Jourdan authored
Tag all the coded formats where the venus vdec supports dynamic resolution switching. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Reviewed-by:
-
Maxime Jourdan authored
Add an enum_fmt format flag to specifically tag coded formats where dynamic resolution switching is supported by the device. This is useful for some codec drivers that can support dynamic resolution switching for one or more of their listed coded formats. It allows userspace to know whether it should extract the video parameters itself, or if it can rely on the device to send V4L2_EVENT_SOURCE_CHANGE when such changes are detected. Signed-off-by:
-
Hans Verkuil authored
Add an enum_fmt format flag to specifically tag coded formats where full bytestream parsing is supported by the device. Some stateful decoders are capable of fully parsing a bytestream, but others require that userspace pre-parses the bytestream into frames or fields (see the corresponding pixelformat descriptions for details). If this flag is set, then this pre-parsing step is not required (but still possible, of course). Signed-off-by:
-
Hertz Wong authored
Now that the generic bits have been added, we can activate H264 decoding on rk3288. Signed-off-by:
Hertz Wong <hertz.wong@rock-chips.com> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
-
Hertz Wong authored
Add the G1 specific bits to support H264 decoding. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Hertz Wong authored
Add helpers and patch hantro_{drv,v4l2}.c to prepare addition of H264 decoding support. Signed-off-by: -
Boris Brezillon authored
Some decoders use intra slice/frame references. The capture buffer pointed by these references might be new and thus have invalid timestamp which prevents the decoder logic from retrieving the vb2_buffer object based on the output buf timestamp. Copy all metadata (including the timestamp) before starting the decode operation. Suggested-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
Ezequiel Garcia authored
The cedrus VPU is slice-based and expects V4L2_PIX_FMT_H264_SLICE buffers to contain H264 slices with no start code. Expose this to userspace with the newly added menu control. These two controls are specified as mandatory for applications, but we mark them as non-required on the driver side for backwards compatibility. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
In order to introduce other controls, the control initialization needs to support an initial struct v4l2_ctrl_control. While here, let's cleanup the control initialization, removing unneeded fields. Signed-off-by:
-
Boris Brezillon authored
Those lists can be extracted from the dpb, let's simplify userspace life and build that list kernel-side (generic helpers will be provided for drivers that need this list). Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by:
-
Ezequiel Garcia authored
Stateless decoders have different expectations about the start code that is prepended on H264 slices. Add a menu control to express the supported start code types (including no start code). Drivers are allowed to support only one start code type, but they can support both too. Note that this is independent of the H264 decoding mode, which specifies the granularity of the decoding operations. Either in frame-based or slice-based mode, this new control will allow to define the start code expected on H264 slices. Signed-off-by:
-
Boris Brezillon authored
Some stateless decoders don't support per-slice decoding granularity (or at least not in a way that would make them efficient or easy to use). Expose a menu to control the supported decoding modes. Drivers are allowed to support only one decoding but they can support both too. To fully specify the decoding operation, we need to introduce a start_byte_offset, to indicate where slices start. Signed-off-by:
-
Ezequiel Garcia authored
The V4L2_PIX_FMT_H264_SLICE_RAW name was originally suggested because the pixel format would represent H264 slices without any start code. However, as we will now introduce a start code menu control, give the pixel format a more meaningful name, while it's still early enough to do so. Signed-off-by:
-
Rasmus Villemoes authored
Our list_sort() utility has always supported a context argument that is passed through to the comparison routine. Now there's a use case for the similar thing for sort(). This implements sort_r by simply extending the existing sort function in the obvious way. To avoid code duplication, we want to implement sort() in terms of sort_r(). The naive way to do that is static int cmp_wrapper(const void *a, const void *b, const void *ctx) { int (*real_cmp)(const void*, const void*) = ctx; return real_cmp(a, b); } sort(..., cmp) { sort_r(..., cmp_wrapper, cmp) } but this would do two indirect calls for each comparison. Instead, do as is done for the default swap functions - that only adds a cost of a single easily predicted branch to each comparison call. Aside from introducing support for the context argument, this also serves as preparation for patches that will eliminate the indirect comparison calls in common cases. Requested-by:Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Tested-by:
-
Hans Verkuil authored
If reg_r() fails, then gspca_dev->usb_buf was left uninitialized, and some drivers used the contents of that buffer in logic. This caused several syzbot errors: https://syzkaller.appspot.com/bug?extid=397fd082ce5143e2f67d https://syzkaller.appspot.com/bug?extid=1a35278dd0ebfb3a038a https://syzkaller.appspot.com/bug?extid=06ddf1788cfd048c5e82 I analyzed the gspca drivers and zeroed the buffer where needed. Reported-and-tested-by: syzbot+1a35278dd0ebfb3a038a@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+397fd082ce5143e2f67d@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+06ddf1788cfd048c5e82@syzkaller.appspotmail.com Signed-off-by:
-
Ezequiel Garcia authored
Update Jacob's address and add myself as co-maintainer. Signed-off-by:
-
Hans Verkuil authored
dev->usbc_buf was passed as argument for %s, but it was not safeguarded by a terminating 0. This caused this syzbot issue: https://syzkaller.appspot.com/bug?extid=79d18aac4bf1770dd050 Reported-and-tested-by: syzbot+79d18aac4bf1770dd050@syzkaller.appspotmail.com Signed-off-by:
-
Hans Verkuil authored
In the probe() function radio->int_in_urb was not killed if an error occurred in the probe sequence. It was also missing in the disconnect. This caused this syzbot issue: https://syzkaller.appspot.com/bug?extid=2d4fc2a0c45ad8da7e99 Reported-and-tested-by: syzbot+2d4fc2a0c45ad8da7e99@syzkaller.appspotmail.com Signed-off-by:
-
Hans Verkuil authored
One typo in the function name, one missing : after :c:type. Signed-off-by:
-
Hugues Fruchet authored
Add support of several sub-devices within pipeline instead of a single one. This allows to support a CSI-2 camera sensor connected through a CSI-2 to parallel bridge. Signed-off-by:
Hugues Fruchet <hugues.fruchet@st.com> Signed-off-by:
-
Hugues Fruchet authored
Add media controller support to dcmi in order to walk within remote subdevices pipeline. Signed-off-by:
-
Hugues Fruchet authored
Add a trace of the set of supported fourcc/mbus_code which intersect between DCMI and source sub-device. Signed-off-by:
-
Hugues Fruchet authored
Rename "subdev" entity struct field to "source" to prepare for several subdev support. Move asd field on top of entity struct. Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Geert Uytterhoeven authored
Fix typos. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Ezequiel Garcia authored
Some users have been having a hard time finding the hidden menus. A typically case are camera sensor drivers (e.g IMX219, OV5645, etc), which are common on embedded platforms and not really "ancillary" devices. The problem with MEDIA_SUBDRV_AUTOSELECT seems to be related to the fact that it uses the "visible" syntax to hide the menus. This is not obvious and it normally takes some time to figure out. To fix the problem, add a comment on each of hidden menus, which should clarify what option is causing menus to be hidden. Signed-off-by:
-
- 15 Aug, 2019 11 commits
-
-
Sakari Ailus authored
The ov5670 driver didn't get a MAINTAINERS entry when it was merged. Add one now. Signed-off-by:
-
Sébastien Szymanski authored
i.MX7 and i.MX6UL/L have the same CSI controller. So add i.MX6UL/L support to imx7-media-csi driver. Signed-off-by:
Sébastien Szymanski <sebastien.szymanski@armadeus.com> Reviewed-by:
Rui Miguel Silva <rmfrfs@gmail.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Sébastien Szymanski authored
Document "fsl,imx6ul-csi" entry. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Ezequiel Garcia authored
Not all sensors will be able to guarantee a proper initial state. This may be either because the driver is not properly written, or (probably unlikely) because the hardware won't support it. While the right solution in the former case is to fix the sensor driver, the real world not always allows right solutions, due to lack of available documentation and support on these sensors. Let's relax this requirement, and allow the driver to support stream start, even if the sensor initial sequence wasn't the expected. Also improve the warning message to better explain the problem and provide a hint that the sensor driver needs to be fixed. Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Reviewed-by:
-
Steve Longerbeam authored
Add a sentence that makes it more clear when the CSI-2 transmitter must, if possible, exit LP-11 mode. That is, maintain LP-11 mode until stream on, at which point the transmitter activates the clock lane and transition to HS mode. Signed-off-by:
-
Sakari Ailus authored
The raw Bayer formats have been listed under the label of RGB formats but in fact they're quite different. The latter are readily usable as such whereas the former require quite bit of image processing before useful. Split them into RGB and raw Bayer formats. Signed-off-by:
-
Sakari Ailus authored
When the support for serial busses was introduced in V4L2, it was decided to use the existing parallel bus media bus pixel codes to describe them. While this was a practical choice at the time, it necessitates choosing which one of the many parallel mbus pixel codes to use, for on the serial busses these formats are effectively all equivalent. The practice has always been to use the pixel code that describes a bus that transfers a single sample per clock. Document this. Signed-off-by:
-
Ezequiel Garcia authored
This is mostly a port of Jacopo's fix: commit aa4bb8b8 Author: Jacopo Mondi <jacopo@jmondi.org> Date: Fri Jul 6 05:51:52 2018 -0400 media: ov5640: Re-work MIPI startup sequence In the OV5645 case, the changes are: - At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode. - At set_power(0) time power down MIPI Tx/Rx (in addition to the current power down of regulators and clock gating). - At s_stream time enable/disable the MIPI interface output. With this commit the sensor is able to enter LP-11 mode during power up, as expected by some CSI-2 controllers. Many thanks to Fabio Estevam for his help debugging this issue. Tested-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
-
Sakari Ailus authored
The streaming state should be set to the first upstream sub-device only, not everywhere, for a sub-device driver itself knows how to best control the streaming state of its own upstream sub-devices. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
The omap3isp driver registered subdevs without the dev field being set. Do that now. Signed-off-by:
-
Luca Weiss authored
Parse async sub-devices related to the sensor by switching the async sub-device registration function. Signed-off-by:
Luca Weiss <luca@z3ntu.xyz> Signed-off-by:
-
