- 16 Nov, 2016 40 commits
-
-
Marek Szyprowski authored
Replace open-coded driver data extraction code with generic helper. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Marek Szyprowski authored
Fix missing newline char in debug messages. Signed-off-by:
-
Marek Szyprowski authored
Remove dead, unused code. Signed-off-by:
-
Marek Szyprowski authored
System PM callbacks only ensure that device is runtime suspended/resumed, so remove them and use generic pm_runtime_force_suspend/resume helper. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Tested-by:
-
Ulf Hansson authored
It's not needed to keep a local flag about the current system PM state. Let's just remove that code and the corresponding debug print. [mszyprow: rebased onto v4.9-rc4] Signed-off-by:
-
Ulf Hansson authored
To potentially save more power in runtime PM suspend state, let's also prepare/unprepare the clock from the runtime PM callbacks. [mszyprow: rebased onto v4.9-rc4] Signed-off-by:
-
Ulf Hansson authored
To make sure the clock is fully gated in ->remove(), we first need to to bring the device into full power by invoking pm_runtime_get_sync(). Then, let's both unprepare and disable the clock. [mszyprow: rebased onto v4.9-rc4] Signed-off-by:
-
Ulf Hansson authored
There are no need to set up the PM callbacks (runtime and system) unless they are being used. It also causes compiler warnings about unused functions. Silence the warnings by making them available for CONFIG_PM (runtime callbacks) and CONFIG_PM_SLEEP (system sleep callbacks). [mszyprow: squashed two patches into one to avoid potential build break, changed patch subject and updated commit message] Signed-off-by:
-
Ulf Hansson authored
The driver depended on CONFIG_PM to be functional. Let's remove that dependency, by enable the runtime PM resourses during ->probe() and update the device's runtime PM status to reflect this. [mszyprow: rebased onto v4.9-rc4] Signed-off-by:
-
Ulf Hansson authored
Since gsc_m2m_resume() always returns 0, convert it to a void instead. [mszyprow: rebased onto v4.9-rc4] Signed-off-by:
-
Ulf Hansson authored
Instead of having separate functions that fetches, prepares and unprepares the clock, let's encapsulate this code into ->probe(). This makes error handling easier and decreases the lines of code. [mszyprow: rebased onto v4.9-rc4] Signed-off-by:
-
Shuah Khan authored
Include buffer size in s5p_mfc_alloc_priv_buf() the error message when it fails to allocate the buffer. Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Javier Martinez Canillas authored
Media drivers that use the videobuf2 framework have to give back to vb2 all the buffers that received from vb2 using its .buf_queue callback. But the exynos-gsc driver isn't doing a proper cleanup so vb2 complains that the number of buffers enqueued and received are not balanced: WARNING: CPU: 2 PID: 660 at drivers/media/v4l2-core/videobuf2-core.c:1654 __vb2_queue_cancel+0xec/0x150 [videobuf2_core] Modules linked in: mwifiex_sdio mwifiex uvcvideo exynos_gsc videobuf2_vmalloc s5p_mfc s5p_jpeg CPU: 2 PID: 660 Comm: lt-gst-validate Not tainted 4.8.0 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [<c010e24c>] (unwind_backtrace) from [<c010af30>] (show_stack+0x10/0x14) [<c010af30>] (show_stack) from [<c03291a4>] (dump_stack+0x88/0x9c) [<c03291a4>] (dump_stack) from [<c011a858>] (__warn+0xe8/0x100) [<c011a858>] (__warn) from [<c011a920>] (warn_slowpath_null+0x20/0x28) [<c011a920>] (warn_slowpath_null) from [<bf0b6ed0>] (__vb2_queue_cancel+0xec/0x150 [videobuf2_core]) [<bf0b6ed0>] (__vb2_queue_cancel [videobuf2_core]) from [<bf0b7464>] (vb2_core_streamoff+0x34/0x9c [videobuf2_core]) [<bf0b7464>] (vb2_core_streamoff [videobuf2_core]) from [<bf11b9e8>] (v4l2_m2m_streamoff+0x2c/0xe4 [v4l2_mem2mem]) [<bf11b9e8>] (v4l2_m2m_streamoff [v4l2_mem2mem]) from [<bf01b84c>] (__video_do_ioctl+0x298/0x30c [videodev]) [<bf01b84c>] (__video_do_ioctl [videodev]) from [<bf01b234>] (video_usercopy+0x174/0x4e8 [videodev]) [<bf01b234>] (video_usercopy [videodev]) from [<bf0165c8>] (v4l2_ioctl+0xc4/0xd8 [videodev]) [<bf0165c8>] (v4l2_ioctl [videodev]) from [<c01f291c>] (do_vfs_ioctl+0x9c/0x8f4) [<c01f291c>] (do_vfs_ioctl) from [<c01f31a8>] (SyS_ioctl+0x34/0x5c) [<c01f31a8>] (SyS_ioctl) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c) Fix this by passing back to vb2 all the received buffers that were not processed. Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't unregister the video device node when the driver is removed, this keeps video device nodes that makes the machine to crash with a NULL pointer dereference when nodes are attempted to be opened: [ 36.530006] Unable to handle kernel paging request at virtual address bf1f8200 [ 36.535985] pgd = edbbc000 [ 36.538486] [bf1f8200] *pgd=6d99a811, *pte=00000000, *ppte=00000000 [ 36.544727] Internal error: Oops: 7 [#1] PREEMPT SMP ARM [ 36.550016] Modules linked in: s5p_jpeg s5p_mfc v4l2_mem2mem videobuf2_dma_contig [ 36.566303] CPU: 6 PID: 533 Comm: v4l2-ctl Not tainted 4.8.0 [ 36.574466] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 36.580526] task: ee3cc600 task.stack: ed626000 [ 36.585046] PC is at try_module_get+0x1c/0xac [ 36.589364] LR is at try_module_get+0x1c/0xac [ 36.593698] pc : [<c0187a60>] lr : [<c0187a60>] psr: 80070013 [ 36.593698] sp : ed627de0 ip : a0070013 fp : 00000000 [ 36.605156] r10: 00000002 r9 : ed627ed0 r8 : 00000000 [ 36.610331] r7 : c01e5f14 r6 : ed57be00 r5 : bf1f8200 r4 : bf1f8200 [ 36.616834] r3 : 00000002 r2 : 00000002 r1 : 01930192 r0 : 00000001 .. [ 36.785004] [<c0187a60>] (try_module_get) from [<c01e5c10>] (cdev_get+0x1c/0x4c) [ 36.792362] [<c01e5c10>] (cdev_get) from [<c01e5f40>] (chrdev_open+0x2c/0x178) [ 36.799555] [<c01e5f40>] (chrdev_open) from [<c01df5d4>] (do_dentry_open+0x1e0/0x300) [ 36.807360] [<c01df5d4>] (do_dentry_open) from [<c01eecdc>] (path_openat+0x35c/0xf58) [ 36.815154] [<c01eecdc>] (path_openat) from [<c01f0668>] (do_filp_open+0x5c/0xc0) [ 36.822606] [<c01f0668>] (do_filp_open) from [<c01e09ac>] (do_sys_open+0x10c/0x1bc) [ 36.830235] [<c01e09ac>] (do_sys_open) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c) [ 36.837942] Code: 0a00001c e1a04000 e3a00001 ebfec92d (e5943000) Signed-off-by:
-
Javier Martinez Canillas authored
The struct v4l2_device instance for the G-Scaler is not dyanmically allocated but a member of the struct gsc_dev. In fact, the assigned .release callback is video_device_release_empty(). But gsc_register_m2m_device() attempts to release the v4l2_device by calling video_device_release() in its error path. This is wrong since the v4l2_device wasn't allocated directly and will be freed once its parent struct gsc_dev is freed. While being there, rename the remaining goto label in the error path to something that better explains the error path cleanup. Signed-off-by:
-
Javier Martinez Canillas authored
The driver don't take into account the differences between packed, semi planar and multi planar formats when calculating the pixel format bytes per lines and image size values. This makes GStreamer to fail when the following formats are used NV12, NV21, NV16, NV61, YV12, I420 and Y42B: "gst_video_frame_map_id: failed to map video frame plane 1" Nicolas suggested to use the logic found in the Exynos FIMC v4l2 driver since does this correctly. So this patch changes the bytes per line and image size calculation according to what's done in this media driver. After this patch most supported formats work correctly. There are still issues with the NV21 and NV61 formats, but that seems to be a separate problem since NV12 and NV16 work and these formats use the same values. So this can be fixed as a follow-up and shouldn't be a blocker for this change that improves the driver's support. Suggested-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
-
Javier Martinez Canillas authored
The driver exposes 32-bit A/XRGB 8-8-8-8 as supported format but testing shows that using this format produces frames with wrong colors. The test was done with the following GStreamer pipeline: $ gst-launch-1.0 videotestsrc num-buffers=20 ! video/x-raw,format=UYVY \ ! v4l2video3convert ! video/x-raw,format=xRGB ! videoconvert ! kmssink The manual seems to state that the Pixel Format are in Little Endianness so instead use the 32-bit BGRA/X 8-8-8-8 pixel format. This format works correctly when using the following pipeline: $ gst-launch-1.0 videotestsrc num-buffers=20 ! video/x-raw,format=UYVY \ ! v4l2video3convert ! video/x-raw,format=BGRx ! kmssink This change is similar to commit 7f2816e5 ("[media] s5p-fimc: Changed RGB32 to BGR32") that fixed the same issue on a different Samsung driver. Suggested-by:
-
Javier Martinez Canillas authored
User-space applications can use the VIDIOC_REQBUFS ioctl to determine if a memory mapped, user pointer or DMABUF based I/O is supported by a driver. For example, GStreamer attempts to determine the I/O methods supported by the driver by doing many VIDIOC_REQBUFS ioctl calls with different memory types and count 0. And then the real VIDIOC_REQBUFS call with count == n is be made to allocate the buffers. But for count 0, the driver not only frees the buffers but also clears the format set before with VIDIOC_S_FMT. This is a problem since STREAMON fails if a format isn't set but GStreamer first sets a format and then tries to determine the supported I/O methods, so the format will be cleared on REQBUFS(0), before the call to STREAMON. To avoid this issue, only free the buffers on VIDIOC_REQBUFS(0) but don't clear the format. Since is completely valid to set the format and then do different calls to REQBUFS before a call to STREAMON. Signed-off-by:
-
Javier Martinez Canillas authored
The driver try_fmt handler prints a message each time that the image size has been changed due the maximum and minimum width and height. Since user-space can try different format and sizes, this logs a lot of unnecessary messages. Change the message log level to debug and while being there, also add a new line to the message. Signed-off-by:
-
Shuah Khan authored
s5p_mfc_alloc_priv_buf() prints two message to report invalid memory configuration error. Collapse them into a single message. Signed-off-by:
-
Nicolas Dufresne authored
For tiled format, we need to allocated a multiple of the row size. A good example is for 1280x720, wich get adjusted to 1280x736. In tiles, this mean Y plane is 20x23 and UV plane 20x12. Because of the rounding, the previous code would only have enough space to fit half of the last row. [mchehab@s-opensource.com: fix coding style] Signed-off-by:
-
Kieran Bingham authored
The FDP1 driver performs advanced de-interlacing on a memory 2 memory based video stream, and supports conversion from YCbCr/YUV to RGB pixel formats Signed-off-by:
Kieran Bingham <kieran+renesas@bingham.xyz> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Kieran Bingham authored
The FDP1 is a de-interlacing module which converts interlaced video to progressive video. It is also capable of performing pixel format conversion between YCbCr/YUV formats and RGB formats. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Laurent Pinchart authored
The menu control selects the operation mode of a video deinterlacer. The menu entries are driver specific. Signed-off-by:
Kieran Bingham <kieran@bingham.xyz> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Peter Ujfalusi authored
When requesting the DMA channel it was mandatory that we do not have DMA resource nor valid DMA channel via DT. In this case the dma_request_slave_channel_compat() would fall back and request any channel with SW trigger. The same can be achieved with the dma_request_chan_by_mask() without the misleading use of the DMAengine API - implying that the omap3isp does need to have DMA resource or valid dma binding in DT. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Laurent Pinchart authored
When parsing the graph the driver loops over all endpoints using of_graph_get_next_endpoint(). The function handles reference counting of the passed and returned nodes, so the returned node's reference count must not be decreased manually in the normal path. Move the offending of_node_put() call to the error path that requires manual reference count handling. Reported-by:
H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by:
-
Philipp Zabel authored
The Rift CV1 Sensor has bInterfaceClass set to vendor specific, so we need an entry in uvc_ids to probe it. Just as the Rift DK2 IR tracker, it misreports the pixel format as YUYV instead of Y8. The sensor is configured with a low exposure time and high black level by default, so that only bright IR sources can be seen. Signed-off-by:
Philipp Zabel <philipp.zabel@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
The CEC_LOG_ADDRS_FL_CDC_ONLY flag is missing at the documentation, causing this warning: Documentation/output/cec.h.rst:6: WARNING: undefined label: cec-log-addrs-fl-cdc-only (if the link has no caption the label must precede a section header) Add a documentation for it, based on the commit that introduced the flag. Fixes: a69a168a ("[media] cec: add proper support for CDC-Only CEC devices") Signed-off-by:
-
Hans Verkuil authored
Make sure the TX counters are zeroed in the cec_msg struct. Non-zero TX counters make no sense when a message is received, and applications should not see non-zero values here. Signed-off-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Hans Verkuil authored
The cec framework and the pulse8-cec driver have been moved out of staging, so update the MAINTAINERS paths. Signed-off-by:
-
Hans Verkuil authored
Update the TODOs explaining why these two drivers remain in staging. The reason is that these drivers rely on userspace to set the physical address, but that should come from the HDMI output driver. This in turn needs the upcoming HDMI notifier framework. Signed-off-by:
-
Hans Verkuil authored
Now that the CEC framework has been moved out of staging and into the mainline kernel we can do the same for the pulse8-cec driver. Signed-off-by:
-
Hans Verkuil authored
An inner for-loop reused the outer loop variable. This was only noticeable with CEC adapters supporting more than one logical address. Signed-off-by:
-
Hans Verkuil authored
Replace bool by int or __u8 (when used in a struct). Signed-off-by:
-
Hans Verkuil authored
The CEC_MSG_FL_REPLY_TO_FOLLOWERS message flag only makes sense for transmitted messages where you want to wait for the reply. Clear the flag in all other cases. Signed-off-by:
-
Hans Verkuil authored
The last open issues have been addressed, so it is time to move this out of staging and into the mainline and to move the public cec headers to include/uapi/linux. Signed-off-by:
-
Hans Verkuil authored
CDC-Only CEC devices are CEC devices that can only handle CDC messages, all other messages are ignored. Add a flag to signal that this is a CDC-Only device and act accordingly. Also add helper functions to identify if a CEC device is configured as a CDC-Only device, a second TV, a switch or a processor, since these variations cannot be determined by the logical address alone. Signed-off-by:
-
Hans Verkuil authored
The CEC_MSG_INITIATE_ARC message is special since it is the ONLY CEC message that accepts two possible valid replies: CEC_MSG_REPORT_ARC_INITIATED and CEC_MSG_REPORT_ARC_TERMINATED. So if the transmitted message is CEC_MSG_INITIATE_ARC and the remote side replied with CEC_MSG_REPORT_ARC_INITIATED or CEC_MSG_REPORT_ARC_TERMINATED, then a msg->reply value of CEC_MSG_REPORT_ARC_INITIATED or CEC_MSG_REPORT_ARC_TERMINATED will match either reply. I thought about either adding a second reply2 field, but that's ugly for all other messages that have only one reply, and what if in the future a new message is added that can have three replies? Another option would be to add a cec_msg flag, but really, the combination of CEC_MSG_REPORT_ARC_INITIATED and a reply value of one of the two possible replies already functions as a flag. Another advantage of this approach is that it is safe to re-use a cec_msg struct. No need to zero a flags field or a reply2 field. So since this really is an exception in the CEC specification, I decided to implement it as an exception as well. Signed-off-by:
-
Hans Verkuil authored
As per the CEC specification: - CEC messages with a too-small payload should be ignored. - Broadcast messages that are only allowed as directed messages should be ignored. - Directed messages that are only allowed as broadcast messages should be ignored. Implement this in the core CEC framework. Signed-off-by:
-
Hans Verkuil authored
Give the caller more control over how replies to a transmit are handled. By default the reply will only go to the filehandle that called CEC_TRANSMIT. If this new flag is set, then the reply will also go to all followers. Signed-off-by:
-
