- 10 Apr, 2017 30 commits
-
-
Kieran Bingham authored
With multiple inputs through the BRU it is feasible for the streams to race each other at stream-on. Multiple VIDIOC_STREAMON calls racing each other could have process N-1 skipping over the pipeline setup section and then start the pipeline early, if videobuf2 has already enqueued buffers to the driver for process N but not called the .start_streaming() operation yet In the case of the video pipelines, this can present two serious issues. 1) A null-dereference if the pipe->dl is committed at the same time as the vsp1_video_setup_pipeline() is processing 2) A hardware hang, where a display list is committed without having called vsp1_video_setup_pipeline() first Repair this issue, by ensuring that only the stream which configures the pipeline is able to start it. Signed-off-by:Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Laurent Pinchart authored
The RPF and WPF U/V order bits have no effect for 3-planar formats on Gen3 hardware. Swap the U and V planes addresses manually instead in that case. Fixes: b915bd24 ("[media] v4l: vsp1: Add tri-planar memory formats support") Signed-off-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by:
-
Shailendra Verma authored
v4l2_fh_init is already done. So call the v4l2_fh_exit in error condition before returing from the function. Signed-off-by:
Shailendra Verma <shailendra.v@samsung.com> Reviewed-by:
-
Kieran Bingham authored
Minor tweaks to document the swap register and make the documentation match the struct ordering Signed-off-by:
Kieran Bingham <kieran@bingham.xyz> Reviewed-by:
-
Hans Verkuil authored
The documentation for video capture and output devices claims that the video standard ioctls are required. This is not the case, they are only required for PAL/NTSC/SECAM type inputs and outputs. Sensors do not implement this at all and e.g. HDMI inputs implement the DV Timings ioctls. Just drop the mention of 'video standard' ioctls. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
The driver moved to drivers/media/platform/atmel. Signed-off-by:
-
Hans Verkuil authored
Update the bindings for this device based on a working DT example. Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Hans Verkuil authored
The colorspace is independent of whether YUV or RGB is sent to the SoC. Fix this. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Hans Verkuil authored
Move this out of the soc_camera directory into the atmel directory where it belongs. Signed-off-by:
-
Hans Verkuil authored
This patch converts the atmel-isi driver from a soc-camera driver to a driver that is stand-alone. Signed-off-by:
-
Hans Verkuil authored
The original bindings documentation was incomplete (missing pinctrl-names, missing endpoint node properties) and the example was out of date. Add the missing information and tidy up the text. Signed-off-by:
-
Hans Verkuil authored
Add DT support. Use it to get the reset and pwdn pins (if there are any). Tested with one sensor requiring reset/pwdn and one sensor that doesn't have reset/pwdn pins. Signed-off-by:
-
Hans Verkuil authored
Get the clock for this sensor. Signed-off-by:
-
Hans Verkuil authored
Drop unnecesary memset. Drop the unnecessary extendedmode check and set the V4L2_CAP_TIMEPERFRAME capability. Signed-off-by:
-
Hans Verkuil authored
Add v4l2-async support for this driver. Signed-off-by:
-
Hans Verkuil authored
Add binding documentation and add that file to the MAINTAINERS entry. Signed-off-by:
-
Daniel Patrick Johnson authored
Add support for Intel SR300 depth camera in uvc driver. This includes adding three uvc GUIDs for the required pixel formats and updating the uvc driver GUID-to-4cc tables with the new formats. Signed-off-by:
Daniel Patrick Johnson <teknotus@teknot.us> Signed-off-by:
Aviv Greenberg <avivgr@gmail.com> Signed-off-by:
Evgeni Raikhel <evgeni.raikhel@intel.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Evgeni Raikhel authored
Provide the frame structure and data layout of V4L2-PIX-FMT-INZI format utilized by Intel SR300 Depth camera. Signed-off-by:
-
Kieran Bingham authored
The statistics function subtracts two timespecs manually. A helper is provided by the kernel to do this. Replace the implementation, using the helper. Signed-off-by:
-
Kieran Bingham authored
The frame counters are inadvertently counting packets with content as empty. Fix it by correcting the logic expression Fixes: 7bc5edb0 [media] uvcvideo: Extract video stream statistics Signed-off-by:
-
Hans Verkuil authored
All control menus use the english capitalization rules of titles. The only menu not following these rules is the RGB Quantization Range control menu. Fix this. Signed-off-by:
-
Johan Hovold authored
Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: e0d3bafd ("V4L/DVB (10954): Add cx231xx USB driver") Cc: stable <stable@vger.kernel.org> # 2.6.30 Cc: Sri Deevi <Srinivasa.Deevi@conexant.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
Make sure to release the snd_card also on a late allocation error. Fixes: e0d3bafd ("V4L/DVB (10954): Add cx231xx USB driver") Cc: stable <stable@vger.kernel.org> # 2.6.30 Cc: Sri Deevi <Srinivasa.Deevi@conexant.com> Signed-off-by:
-
Johan Hovold authored
Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: e0d3bafd ("V4L/DVB (10954): Add cx231xx USB driver") Cc: stable <stable@vger.kernel.org> # 2.6.30 Cc: Sri Deevi <Srinivasa.Deevi@conexant.com> Signed-off-by:
-
Johan Hovold authored
Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: 2a9f8b5d ("V4L/DVB (5206): Usbvision: set alternate interface modification") Cc: stable <stable@vger.kernel.org> # 2.6.21 Cc: Thierry MERLE <thierry.merle@free.fr> Signed-off-by:
-
Johan Hovold authored
Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: c4018fa2 ("[media] dib0700: fix RC support on Hauppauge Nova-TD") Cc: stable <stable@vger.kernel.org> # 3.16 Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by:
-
Hans Verkuil authored
The V4L2_INPUT_TYPE_CAMERA and V4L2_OUTPUT_TYPE_ANALOG descriptions were hopelessly out of date. Fix this, and also fix a few style issues in these documents. Finally add the missing documentation for V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY (only used by the zoran driver). Signed-off-by:
-
Hans Verkuil authored
Most ioctls do not have to write back the contents of the argument if an error is returned. But VIDIOC_S_EDID is an exception together with the EXT_CTRLS ioctls (already handled correctly). Add this exception to v4l2-compat-ioctl32. This fixes a compliance error when using compat32 and trying to set a new EDID with more blocks than the hardware supports. In that case the driver will return -E2BIG and set edid.blocks to the actual maximum number of blocks. This field was never copied back to userspace due to this bug. Signed-off-by:
Hans Verkuil <hansverk@cisco.com> Acked-by:
-
Hans Verkuil authored
Add the line "Camera sensors are also considered to be a video input." In practice all non-MC drivers for sensors support the input ioctls, and the compliance test actually tests for the presence of these ioctls. So clarify the documentation by explicitly mentioning sensors. Signed-off-by:
-
Arnd Bergmann authored
When CONFIG_PM is disabled, we get a couple of unused functions: drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c:927:13: error: 'mtk_jpeg_clk_off' defined but not used [-Werror=unused-function] static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg) ^~~~~~~~~~~~~~~~ drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c:916:13: error: 'mtk_jpeg_clk_on' defined but not used [-Werror=unused-function] static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg) Rather than adding more error-prone #ifdefs around those, this patch removes the existing #ifdef checks and marks the PM functions as __maybe_unused to let gcc do the right thing. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Acked-by:
Rick Chang <rick.chang@mediatek.com> Signed-off-by:
-
- 05 Apr, 2017 10 commits
-
-
Christophe JAILLET authored
According to the surrounding goto, it is likely that 'unprep_clk_gate' was expected here. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
Further investigation revealed that codec buffers also don't need to be allocated at higher addresses than firmware base for MFC v6+ hardware. Those buffers can be quite large and its size depends on the selected format and framesize. This patch changes the way the codec buffers are allocated - driver will use generic allocator for them instead of the pre-allocated buffer for firmware and contexts. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
Clock should be turned off after calling s5p_mfc_init_hw() from the watchdog worker, like it is already done in the s5p_mfc_open() which also calls this function. Fixes: af935746 ("[media] MFC: Add MFC 5.1 V4L2 driver") Signed-off-by:
-
Marek Szyprowski authored
Documentation for MFC hardware still uses 'left' and 'right' names for the memory channel/banks, so replace BANK1/2 defines with more appropriate BANK_L/R names. Suggested-by:
Shuah Khan <shuahkhan@gmail.com> Signed-off-by:
-
Marek Szyprowski authored
It turned out that all versions of MFC v6+ hardware doesn't have a strict requirement for ALL buffers to be allocated on higher addresses than the firmware base like it was documented for MFC v5. This requirement is true only for the device and per-context buffers. All video data buffers can be allocated anywhere for all MFC v6+ versions. Basing on this fact, the special DMA configuration based on two reserved memory regions is not really needed for MFC v6+ devices, because the memory requirements for the firmware, device and per-context buffers can be fulfilled by the simple probe-time pre-allocated block allocator introduced in previous patch. This patch enables support for such pre-allocated block based allocator always for MFC v6+ devices. Due to the limitations of the memory management subsystem the largest supported size of the pre-allocated buffer when no CMA (Contiguous Memory Allocator) is enabled is 4 MiB. This patch also removes the requirement to provide two reserved memory regions for MFC v6+ devices in device tree. Now the driver is fully functional without them. Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Tested-by:
Andrzej Hajda <a.hajda@samsung.com> Tested-by:
Smitha T Murthy <smitha.t@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
The main reason for using special configuration of IOMMU domain was the problem with MFC firmware, which failed to operate properly when placed at 0 DMA address. Instead of adding custom code for configuring each variant of IOMMU domain and architecture specific glue code, simply use what arch code provides and if the DMA base address equals zero, skip first 128 KiB to keep required alignment. This patch also make the driver operational on ARM64 architecture, because it no longer depends on ARM specific DMA-mapping and IOMMU glue code functions. Signed-off-by:
-
Marek Szyprowski authored
Current MFC driver depends on the fact that when IOMMU is available, the DMA-mapping framework and its IOMMU glue will use first-fit allocator. This was true for ARM architecture, but its not for ARM64 arch. However, in case of MFC v6+ hardware and latest firmware, it turned out that there is no strict requirement for ALL buffers to be allocated on higher addresses than the firmware base. This requirement is true only for the device and per-context buffers. All video data buffers can be allocated anywhere for all MFC v6+ versions. Such relaxed requirements for the memory buffers can be easily fulfilled by allocating firmware, device and per-context buffers from the probe-time preallocated larger buffer. This patch adds support for it. This way the driver finally works fine on ARM64 architecture. The size of the preallocated buffer is 8 MiB, what is enough for three instances H264 decoders or encoders (other codecs have smaller memory requirements). If one needs more for particular use case, one can use "mem" module parameter to force larger (or smaller) buffer (for example by adding "s5p_mfc.mem=16M" to kernel command line). [mchehab@s-opensource.com: fix two checkpatch warnings: don't initialize static to NULL; don't use S_foo permisions] Signed-off-by:
-
Marek Szyprowski authored
Move code for DMA memory configuration with IOMMU into separate function to make it easier to compare what is being done in each case. Signed-off-by:
-
Marek Szyprowski authored
Firmware for MFC v6+ variants is not larger than 400 KiB, so there is no need to allocate a full 1 MiB buffer for it. Reduce it to 512 KiB to keep proper alignment of allocated buffer. Signed-off-by:
-
Marek Szyprowski authored
Once firmware buffer has been converted to use s5p_mfc_priv_buf structure, it is possible to allocate it with existing s5p_mfc_alloc_priv_buf() function. This change will help to reduce code variants in the next patches. Signed-off-by:
-
