- 13 May, 2014 30 commits
-
-
Jacek Anaszewski authored
Prevent decompression of a JPEG 4:2:0 with odd width to the YUV 4:2:0 compliant formats for Exynos4x12 SoCs and adjust capture format to RGB565 in such a case. This is required because the configuration would produce a raw image with broken luma component. Signed-off-by:
Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com>
-
Jacek Anaszewski authored
This patch fixes jpeg sysmmu page fault on Exynos4x12 SoCs. During encoding Exynos4x12 SoCs access wider memory area than it results from Image_x and Image_y values written to the JPEG_IMAGE_SIZE register. In order to avoid sysmmu page fault apply proper output buffer size alignment. Signed-off-by:
-
Jacek Anaszewski authored
Remove erroneous guard preventing successful execution of g_selection callback in case the driver variant is different from SJPEG_S5P. Signed-off-by:
-
Jacek Anaszewski authored
Simplify the code by adding m2m_ops field to the s5p_jpeg_variant structure which allows to avoid "if" statement in the s5p_jpeg_probe function. Signed-off-by:
-
Jacek Anaszewski authored
Change the driver variant check from "is not S5PC210" to "is Exynos4" while checking whether YUV format needs to be downgraded in order to prevent upsampling which is not supported by Exynos4 SoCs family. Signed-off-by:
-
Jacek Anaszewski authored
Simplify the code by adding fmt_ver_flag field to the s5p_jpeg_variant structure which allows to avoid "if" statement in the s5p_jpeg_find_format function. Signed-off-by:
-
Nicolas Dufresne authored
This formula did not take into account the required tiled alignement for NV12MT format. As this was already computed an stored in payload array initially, reuse that value. Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
-
Nicolas Dufresne authored
Testing showed that HW produces BGR32 rather then RGB32 as exposed in the driver. The documentation seems to state the pixels are stored in little endian order. Signed-off-by:
-
Nicolas Dufresne authored
Depth and payload is defined per memory plane. It's better to iterate using number of memory planes. This was not causing much issue since the rest of the arrays involved where intialized to zero. Signed-off-by:
-
Guennadi Liakhovetski authored
If a struct contains 64-bit fields, it is aligned on 64-bit boundaries within containing structs in 64-bit compilations. This is the case with struct v4l2_window, which contains pointers and is embedded into struct v4l2_format, and that one is embedded into struct v4l2_create_buffers. Unlike some other structs, used as a part of the kernel ABI as ioctl() arguments, that are packed, these structs aren't packed. This isn't a problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains a bug, that triggers in such 64-bit builds. That code wrongly assumes, that in struct v4l2_create_buffers, struct v4l2_format immediately follows the __u32 memory field, which in fact isn't the case. This bug wasn't visible until now, because until recently hardly any applications used this ioctl() and mostly embedded 32-bit only drivers implemented it. This is changing now with addition of this ioctl() to some USB drivers, e.g. UVC. This patch fixes the bug by copying parts of struct v4l2_create_buffers separately. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Guennadi Liakhovetski authored
Commit 75e2bdad "ov7670: allow configuration of image size, clock speed, and I/O method" uses a wrong index to iterate an array. Apart from being wrong, it also uses an unchecked value from user-space, which can cause access to unmapped memory in the kernel, triggered by a normal desktop user with rights to use V4L2 devices. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Cc: stable@vger.kernel.org Signed-off-by:
-
Hans Verkuil authored
If the sub-device did not report any tvnorms, then disable the STD ioctls. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Tested-by:
Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com> Signed-off-by:
-
Hans Verkuil authored
Report to soc_camera which standards are supported by tw9910. Signed-off-by:
-
Hans Verkuil authored
While there was already a g_tvnorms_output video op, it's counterpart for video capture was missing. Add it. This is necessary for generic bridge drivers like soc-camera to set the video_device tvnorms field correctly. Otherwise ENUMSTD cannot work. Signed-off-by:
-
Laurent Pinchart authored
Signed-off-by:
-
Laurent Pinchart authored
Signed-off-by:
-
Laurent Pinchart authored
Signed-off-by:
-
Laurent Pinchart authored
Signed-off-by:
-
Sakari Ailus authored
The input field in struct v4l2_buffer no longer exists but has been replaced by a reserved field. Remove the field documentation. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Sakari Ailus authored
V4L2_MBUS_FRAME_DESC_FL_BLOB intends to say the receiver must use 1D DMA to receive the image, as the format does not have line offsets. This typically includes all compressed formats. Signed-off-by:
-
Sakari Ailus authored
When the sub-device is registered, increment the use count of the sub-device owner only if it's different from the owner of the driver for the media device. This avoids increasing the use count by the module itself and thus making it possible to unload it when it's not in use. Signed-off-by:
-
Sakari Ailus authored
mdev->fops->owner is actually the owner of the very same module which implements media_device_register(), so it can't be unloaded anyway. Instead, use THIS_MODULE through a macro as does video_register_device(). Signed-off-by:
-
Sakari Ailus authored
VIDIOC_SUBDEV_[GS]_FRAME_INTERVAL IOCTLs argument structs contain the pad field but the validity check was missing. There should be no implications security-wise from this since no driver currently uses the pad field in the struct. Signed-off-by:
-
Hans Verkuil authored
Create consistent _vbq suffix for videobuf_queue fields. Signed-off-by:
-
Hans Verkuil authored
This is already available from saa7134_dev. Signed-off-by:
-
Hans Verkuil authored
Don't calculate this for every buffer, store it globally instead. Signed-off-by:
-
Hans Verkuil authored
This will make the next patch a bit easier to read. Signed-off-by:
-
Hans Verkuil authored
saa7134-alsa used low-level videobuf functions to allocate and sync DMA buffers. Replace this with saa7134-specific code. These functions will not be available when we convert to vb2. Signed-off-by:
-
Hans Verkuil authored
Just white space and coding style changes to reduce the noise in the following patches. Signed-off-by:
-
Hans Verkuil authored
This solves this bug: https://bugzilla.kernel.org/show_bug.cgi?id=73361 The problem is that when you quit tvtime it calls STREAMOFF, but then it queues a bunch of buffers for no good reason before closing the file descriptor. In the past closing the fd would free the vb queue since that was part of the file handle struct. Since that was moved to the global struct that no longer happened. This wouldn't be a problem, but the extra QBUF calls that tvtime does meant that the buffer list in videobuf (q->stream) contained buffers, so REQBUFS would fail with -EBUSY. The solution is to init the list head explicitly when releasing the file descriptor and to not free the video resource when calling streamoff. The real fix will hopefully go into kernel 3.16 when the vb2 conversion is merged. Basically the saa7134 driver with the old videobuf is so full of holes it ain't funny anymore, so consider this a band-aid for kernels 3.14 and 15. Signed-off-by:
-
- 23 Apr, 2014 10 commits
-
-
Sakari Ailus authored
Signed-off-by:
-
Sakari Ailus authored
The register address, width and flags are encoded as a 32-bit value. Add macros for obtaining these separately. Use the macros in register access functions. Signed-off-by:
-
Sakari Ailus authored
Add a quirk for diverting registers for on some sensors, even the standard registers are not where they can be expected to be found. Add a quirk to to help using such sensors. smiapp_write_no_quirk() and smiapp_read_no_quirk() functions are provided for the use of quirk implementations. Signed-off-by:
-
Sakari Ailus authored
This is more flexible. Quirk flags may be affected by configuration. Signed-off-by:
-
Sakari Ailus authored
No reason to keep this u8, really. Signed-off-by:
-
Sakari Ailus authored
It doesn't make sense to just copy the information to the PLL flags. Add a new fields for the quirks to contain the PLL flags. Signed-off-by:
-
Sakari Ailus authored
The sub-device names should be unique. Should two identical sensors be present in the same media device they would be indistinguishable. The names will change e.g. from "vs6555 pixel array" to "vs6555 1-0010 pixel array". Signed-off-by:
-
Sakari Ailus authored
Signed-off-by:
-
Sakari Ailus authored
8-bit reads are needed in some cases; however the condition used was wrong. Regular access (register width) was used if: len == SMIAPP_REG_8BIT && !only8 This causes 8-bit read access to be used always. The operator should be || instead: regular access can be used for 8-bit reads OR if allowed otherwise. Signed-off-by:
-
Sakari Ailus authored
SMIAPP_REG_ is the common prefix used in the driver for register related definitions. Use it consistently. Signed-off-by:
-
