Re: [PATCH/RFC v2 2/2] v4l: vb2: Add fatal error condition flag
Hi Pawel, On Friday 06 June 2014 14:31:15 Pawel Osciak wrote: Hi Laurent, Thanks for the patch. Did you test this to work in fileio mode? Looks like it should, but would like to make sure. No, I haven't tested it. The OMAP4 ISS driver, which is my test target for this patch, doesn't support fileio mode. Adding VB2_READ would be easy, but the driver requires configuring the format on the file handle used for streaming, so I can't just run cat /dev/video*. On Thu, Jun 5, 2014 at 9:23 PM, Laurent Pinchart wrote: When a fatal error occurs that render the device unusable, the only options for a driver to signal the error condition to userspace is to set the V4L2_BUF_FLAG_ERROR flag when dequeuing buffers and to return an error from the buffer prepare handler when queuing buffers. The buffer error flag indicates a transient error and can't be used by applications to detect fatal errors. Returning an error from vb2_qbuf() is thus the only real indication that a fatal error occurred. However, this is difficult to handle for multithreaded applications that requeue buffers from a thread other than the control thread. In particular the poll() call in the control thread will not notify userspace of the error. This patch adds an explicit mechanism to report fatal errors to userspace. Applications can call the vb2_queue_error() function to signal a fatal error. From this moment on, buffer preparation will return -EIO to userspace, and vb2_poll() will set the POLLERR flag and return immediately. The error flag is cleared when cancelling the queue, either at stream off time (through vb2_streamoff) or when releasing the queue with vb2_queue_release(). Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 2/2] v4l: vb2: Add fatal error condition flag
On 06/06/2014 11:19 AM, Laurent Pinchart wrote: Hi Pawel, On Friday 06 June 2014 14:31:15 Pawel Osciak wrote: Hi Laurent, Thanks for the patch. Did you test this to work in fileio mode? Looks like it should, but would like to make sure. No, I haven't tested it. The OMAP4 ISS driver, which is my test target for this patch, doesn't support fileio mode. Adding VB2_READ would be easy, but the driver requires configuring the format on the file handle used for streaming, so I can't just run cat /dev/video*. Just test with vivi. Regards, Hans On Thu, Jun 5, 2014 at 9:23 PM, Laurent Pinchart wrote: When a fatal error occurs that render the device unusable, the only options for a driver to signal the error condition to userspace is to set the V4L2_BUF_FLAG_ERROR flag when dequeuing buffers and to return an error from the buffer prepare handler when queuing buffers. The buffer error flag indicates a transient error and can't be used by applications to detect fatal errors. Returning an error from vb2_qbuf() is thus the only real indication that a fatal error occurred. However, this is difficult to handle for multithreaded applications that requeue buffers from a thread other than the control thread. In particular the poll() call in the control thread will not notify userspace of the error. This patch adds an explicit mechanism to report fatal errors to userspace. Applications can call the vb2_queue_error() function to signal a fatal error. From this moment on, buffer preparation will return -EIO to userspace, and vb2_poll() will set the POLLERR flag and return immediately. The error flag is cleared when cancelling the queue, either at stream off time (through vb2_streamoff) or when releasing the queue with vb2_queue_release(). Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 2/2] libv4l2: release the lock before doing a DQBUF
Hi,
On 06/05/2014 05:31 PM, Thiago Santos wrote:
In blocking mode, if there are no buffers available the DQBUF will block
waiting for a QBUF to be called but it will block holding the streaming
lock which will prevent any QBUF from happening, causing a deadlock.
Can be tested with: v4l2grab -t 1 -b 1 -s 2000
Signed-off-by: Thiago Santos ts.san...@sisa.samsung.com
Thanks for catching this, and thanks for the patch fixing it.
I'm afraid it is not that simple though. Without the lock the app may do the
following:
Control-thread: set_fmt(fmt), requestbuf(x), map buffers, queue buffers,
streamon
Work-thread: dqbuf, process, qbuf, rinse-repeat
Control-thread: streamoff, requestbuf(0), wait for work thread, unmap buffers.
There is a race here with dqbuf succeeding, but not yet being processed
while the control-thread is tearing things down.
If we hit this race then the v4lconvert_convert call will be passed a no longer
valid pointer in the form of devices[index].frame_pointers[buf-index] and
likewise
its other parameters may also no longer be accurate (or point to invalid mem
alltogether).
Fixing this without breaking stuff / causing the risk of regressions is very
much
non trivial. Since this is a race (normally the dqbuf call would return with an
error because of the streamoff), I believe the best way to fix this is to just
detect this situation and make v4l2_dequeue_and_convert return an error in this
case.
So I suggest that you respin the patch with the following additions.
* Add a frame_info_generation variable to struct v4l2_dev_info
(below the frame_queued field)
* In v4l2_check_buffer_change_ok() increment this field *before* calling
v4l2_unmap_buffers()
* Read frame_info_generation into a local variable before dropping the lock for
the VIDIOC_DQBUF
* Check if frame_info_generation is not changed after this line:
devices[index].frame_queued = ~(1 buf-index);
* If it is changed set errno to -EINVAL (this is what the kernel does when a
streamoff is done
while a dqbuf is pending), and return -1.
* You should also unlock + relock around the DQBUF for the non converted case
around line 1297
in this case no special handling is needed.
Regards,
Hans
---
lib/libv4l2/libv4l2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/libv4l2/libv4l2.c b/lib/libv4l2/libv4l2.c
index c4d69f7..5589fe0 100644
--- a/lib/libv4l2/libv4l2.c
+++ b/lib/libv4l2/libv4l2.c
@@ -290,9 +290,11 @@ static int v4l2_dequeue_and_convert(int index, struct
v4l2_buffer *buf,
return result;
do {
+ pthread_mutex_unlock(devices[index].stream_lock);
result = devices[index].dev_ops-ioctl(
devices[index].dev_ops_priv,
devices[index].fd, VIDIOC_DQBUF, buf);
+ pthread_mutex_lock(devices[index].stream_lock);
if (result) {
if (errno != EAGAIN) {
int saved_err = errno;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 2/2] v4l: vb2: Add fatal error condition flag
Hi Hans, On Friday 06 June 2014 11:31:55 Hans Verkuil wrote: On 06/06/2014 11:19 AM, Laurent Pinchart wrote: Hi Pawel, On Friday 06 June 2014 14:31:15 Pawel Osciak wrote: Hi Laurent, Thanks for the patch. Did you test this to work in fileio mode? Looks like it should, but would like to make sure. No, I haven't tested it. The OMAP4 ISS driver, which is my test target for this patch, doesn't support fileio mode. Adding VB2_READ would be easy, but the driver requires configuring the format on the file handle used for streaming, so I can't just run cat /dev/video*. Just test with vivi. But vivi doesn't call the new vb2_queue_error() function. I understand that your vivi rework would make that easier as you now have an error control. Should I hack something similar in the existing vivi driver ? Any pointer ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/2] v4l: vb2: Don't return POLLERR during transient buffer underruns
Hi, On 06/05/2014 02:23 PM, Laurent Pinchart wrote: The V4L2 specification states that When the application did not call VIDIOC_QBUF or VIDIOC_STREAMON yet the poll() function succeeds, but sets the POLLERR flag in the revents field. The vb2_poll() function sets POLLERR when the queued buffers list is empty, regardless of whether this is caused by the stream not being active yet, or by a transient buffer underrun. Bring the implementation in line with the specification by returning POLLERR only when the queue is not streaming. Buffer underruns during streaming are not treated specially anymore and just result in poll() blocking until the next event. After your patch the implementation is still not inline with the spec, queuing buffers, then starting a thread doing the poll, then doing the streamon in the main thread will still cause the poll to return POLLERR, even though buffers are queued, which according to the spec should be enough for the poll to block. The correct check would be: if (list_empty(q-queued_list) !vb2_is_streaming(q)) eturn res | POLLERR; Regards, Hans Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/videobuf2-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 349e659..fd428e0 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2533,9 +2533,9 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait) } /* - * There is nothing to wait for if no buffers have already been queued. + * There is nothing to wait for if the queue isn't streaming. */ - if (list_empty(q-queued_list)) + if (!vb2_is_streaming(q)) return res | POLLERR; if (list_empty(q-done_list)) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 2/2] v4l: vb2: Add fatal error condition flag
On 06/06/2014 11:46 AM, Laurent Pinchart wrote: Hi Hans, On Friday 06 June 2014 11:31:55 Hans Verkuil wrote: On 06/06/2014 11:19 AM, Laurent Pinchart wrote: Hi Pawel, On Friday 06 June 2014 14:31:15 Pawel Osciak wrote: Hi Laurent, Thanks for the patch. Did you test this to work in fileio mode? Looks like it should, but would like to make sure. No, I haven't tested it. The OMAP4 ISS driver, which is my test target for this patch, doesn't support fileio mode. Adding VB2_READ would be easy, but the driver requires configuring the format on the file handle used for streaming, so I can't just run cat /dev/video*. Just test with vivi. But vivi doesn't call the new vb2_queue_error() function. I understand that your vivi rework would make that easier as you now have an error control. Should I hack something similar in the existing vivi driver ? Any pointer ? Just hack it in for testing. E.g. call it when the button control is pressed (see vivi_s_ctrl). Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/2] v4l: vb2: Don't return POLLERR during transient buffer underruns
On 06/06/2014 11:50 AM, Hans de Goede wrote: Hi, On 06/05/2014 02:23 PM, Laurent Pinchart wrote: The V4L2 specification states that When the application did not call VIDIOC_QBUF or VIDIOC_STREAMON yet the poll() function succeeds, but sets the POLLERR flag in the revents field. The vb2_poll() function sets POLLERR when the queued buffers list is empty, regardless of whether this is caused by the stream not being active yet, or by a transient buffer underrun. Bring the implementation in line with the specification by returning POLLERR only when the queue is not streaming. Buffer underruns during streaming are not treated specially anymore and just result in poll() blocking until the next event. After your patch the implementation is still not inline with the spec, queuing buffers, then starting a thread doing the poll, then doing the streamon in the main thread will still cause the poll to return POLLERR, even though buffers are queued, which according to the spec should be enough for the poll to block. The correct check would be: if (list_empty(q-queued_list) !vb2_is_streaming(q)) eturn res | POLLERR; Good catch! I should have seen that :-( v4l2-compliance should certainly be extended to test this as well. Regards, Hans Regards, Hans Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/videobuf2-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 349e659..fd428e0 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2533,9 +2533,9 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait) } /* - * There is nothing to wait for if no buffers have already been queued. + * There is nothing to wait for if the queue isn't streaming. */ -if (list_empty(q-queued_list)) +if (!vb2_is_streaming(q)) return res | POLLERR; if (list_empty(q-done_list)) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 2/2] v4l: vb2: Add fatal error condition flag
On Friday 06 June 2014 11:55:49 Hans Verkuil wrote: On 06/06/2014 11:46 AM, Laurent Pinchart wrote: On Friday 06 June 2014 11:31:55 Hans Verkuil wrote: On 06/06/2014 11:19 AM, Laurent Pinchart wrote: On Friday 06 June 2014 14:31:15 Pawel Osciak wrote: Hi Laurent, Thanks for the patch. Did you test this to work in fileio mode? Looks like it should, but would like to make sure. No, I haven't tested it. The OMAP4 ISS driver, which is my test target for this patch, doesn't support fileio mode. Adding VB2_READ would be easy, but the driver requires configuring the format on the file handle used for streaming, so I can't just run cat /dev/video*. Just test with vivi. But vivi doesn't call the new vb2_queue_error() function. I understand that your vivi rework would make that easier as you now have an error control. Should I hack something similar in the existing vivi driver ? Any pointer ? Just hack it in for testing. E.g. call it when the button control is pressed (see vivi_s_ctrl). Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com cat /dev/video0 outputs data until vivi calls vb2_queue_error(), at which points cat prints cat: /dev/video0: Input/output error Restarting capture works as expected. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/2] v4l: vb2: Don't return POLLERR during transient buffer underruns
On Friday 06 June 2014 11:58:18 Hans Verkuil wrote: On 06/06/2014 11:50 AM, Hans de Goede wrote: Hi, On 06/05/2014 02:23 PM, Laurent Pinchart wrote: The V4L2 specification states that When the application did not call VIDIOC_QBUF or VIDIOC_STREAMON yet the poll() function succeeds, but sets the POLLERR flag in the revents field. The vb2_poll() function sets POLLERR when the queued buffers list is empty, regardless of whether this is caused by the stream not being active yet, or by a transient buffer underrun. Bring the implementation in line with the specification by returning POLLERR only when the queue is not streaming. Buffer underruns during streaming are not treated specially anymore and just result in poll() blocking until the next event. After your patch the implementation is still not inline with the spec, queuing buffers, then starting a thread doing the poll, then doing the streamon in the main thread will still cause the poll to return POLLERR, even though buffers are queued, which according to the spec should be enough for the poll to block. The correct check would be: if (list_empty(q-queued_list) !vb2_is_streaming(q)) eturn res | POLLERR; Good catch! I should have seen that :-( I'll update the patch accordingly. v4l2-compliance should certainly be extended to test this as well. Regards, Hans Regards, Hans Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/videobuf2-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 349e659..fd428e0 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2533,9 +2533,9 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait) } /* - * There is nothing to wait for if no buffers have already been queued. + * There is nothing to wait for if the queue isn't streaming. */ - if (list_empty(q-queued_list)) + if (!vb2_is_streaming(q)) return res | POLLERR; if (list_empty(q-done_list)) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 2/2] v4l: vb2: Add fatal error condition flag
On 06/06/2014 03:42 PM, Laurent Pinchart wrote: On Friday 06 June 2014 11:55:49 Hans Verkuil wrote: On 06/06/2014 11:46 AM, Laurent Pinchart wrote: On Friday 06 June 2014 11:31:55 Hans Verkuil wrote: On 06/06/2014 11:19 AM, Laurent Pinchart wrote: On Friday 06 June 2014 14:31:15 Pawel Osciak wrote: Hi Laurent, Thanks for the patch. Did you test this to work in fileio mode? Looks like it should, but would like to make sure. No, I haven't tested it. The OMAP4 ISS driver, which is my test target for this patch, doesn't support fileio mode. Adding VB2_READ would be easy, but the driver requires configuring the format on the file handle used for streaming, so I can't just run cat /dev/video*. Just test with vivi. But vivi doesn't call the new vb2_queue_error() function. I understand that your vivi rework would make that easier as you now have an error control. Should I hack something similar in the existing vivi driver ? Any pointer ? Just hack it in for testing. E.g. call it when the button control is pressed (see vivi_s_ctrl). Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com cat /dev/video0 outputs data until vivi calls vb2_queue_error(), at which points cat prints cat: /dev/video0: Input/output error Restarting capture works as expected. Nice. Once this is merged I plan on adding support for this to my vivi rewrite. Finishing the vivi rewrite (mostly cleaning things up and documentation where appropriate) is a high-prio for me. I'd like to get this in for 3.17. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] v4l: vb2: Add fatal error condition flag
On 06/06/2014 03:53 PM, Laurent Pinchart wrote:
When a fatal error occurs that render the device unusable, the only
options for a driver to signal the error condition to userspace is to
set the V4L2_BUF_FLAG_ERROR flag when dequeuing buffers and to return an
error from the buffer prepare handler when queuing buffers.
The buffer error flag indicates a transient error and can't be used by
applications to detect fatal errors. Returning an error from vb2_qbuf()
is thus the only real indication that a fatal error occurred. However,
this is difficult to handle for multithreaded applications that requeue
buffers from a thread other than the control thread. In particular the
poll() call in the control thread will not notify userspace of the
error.
This patch adds an explicit mechanism to report fatal errors to
userspace. Drivers can call the vb2_queue_error() function to signal a
fatal error. From this moment on, buffer preparation will return -EIO to
userspace, and vb2_poll() will set the POLLERR flag and return
immediately. The error flag is cleared when cancelling the queue, either
at stream off time (through vb2_streamoff) or when releasing the queue
with vb2_queue_release().
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
---
drivers/media/v4l2-core/videobuf2-core.c | 39
+---
include/media/videobuf2-core.h | 3 +++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index a05f355..b1b7f78 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1582,6 +1582,11 @@ static int __buf_prepare(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
return -EINVAL;
}
+ if (q-error) {
+ dprintk(1, fatal error occurred on queue\n);
+ return -EIO;
+ }
+
vb-state = VB2_BUF_STATE_PREPARING;
vb-v4l2_buf.timestamp.tv_sec = 0;
vb-v4l2_buf.timestamp.tv_usec = 0;
@@ -1877,6 +1882,11 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q,
int nonblocking)
return -EINVAL;
}
+ if (q-error) {
+ dprintk(1, Queue in error state, will not wait for
buffers\n);
+ return -EIO;
+ }
+
if (!list_empty(q-done_list)) {
/*
* Found a buffer that we were waiting for.
@@ -1902,7 +1912,8 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q,
int nonblocking)
*/
dprintk(3, will sleep waiting for buffers\n);
ret = wait_event_interruptible(q-done_wq,
- !list_empty(q-done_list) || !q-streaming);
+ !list_empty(q-done_list) || !q-streaming ||
+ q-error);
/*
* We need to reevaluate both conditions again after reacquiring
@@ -2099,6 +2110,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
q-streaming = 0;
q-start_streaming_called = 0;
q-queued_count = 0;
+ q-error = 0;
/*
* Remove all buffers from videobuf's list...
@@ -2176,6 +2188,27 @@ static int vb2_internal_streamon(struct vb2_queue *q,
enum v4l2_buf_type type)
}
/**
+ * vb2_queue_error() - signal a fatal error on the queue
+ * @q: videobuf2 queue
+ *
+ * Flag that a fatal unrecoverable error has occurred and wake up all
processes
+ * waiting on the queue. Polling will now set POLLERR and queuing and
dequeuing
+ * buffers will return -EIO.
+ *
+ * The error flag will be cleared when cancelling the queue, either from
+ * vb2_streamoff or vb2_queue_release. Drivers should thus not call this
+ * function before starting the stream, otherwise the error flag will remain
set
+ * until the queue is released when closing the device node.
+ */
+void vb2_queue_error(struct vb2_queue *q)
+{
+ q-error = 1;
+
+ wake_up_all(q-done_wq);
+}
+EXPORT_SYMBOL_GPL(vb2_queue_error);
+
+/**
* vb2_streamon - start streaming
* @q: videobuf2 queue
* @type:type argument passed from userspace to vidioc_streamon handler
@@ -2534,9 +2567,9 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
/*
* There is nothing to wait for if no buffer has been queued and the
- * queue isn't streaming.
+ * queue isn't streaming, or if the error flag is set.
*/
- if (list_empty(q-queued_list) !vb2_is_streaming(q))
+ if ((list_empty(q-queued_list) !vb2_is_streaming(q)) || q-error)
return res | POLLERR;
if (list_empty(q-done_list))
diff --git
[PATCH v3 0/2] vb2: Report POLLERR for fatal errors only
Hello, This patch set modifies the vb2 implementation of the poll() operation to set the POLLERR flag for fatal errors only. The rationale and implementation details are explained in the individual commit messages. Changes since v2: - Return POLLERR when not streaming only when no buffers are queued - Tested with vivi and VB2_READ Changes since v1: - Rebased on top of the latest media tree master branch - Fixed typos Laurent Pinchart (2): v4l: vb2: Don't return POLLERR during transient buffer underruns v4l: vb2: Add fatal error condition flag drivers/media/v4l2-core/videobuf2-core.c | 40 +--- include/media/videobuf2-core.h | 3 +++ 2 files changed, 40 insertions(+), 3 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] v4l: vb2: Don't return POLLERR during transient buffer underruns
The V4L2 specification states that When the application did not call VIDIOC_QBUF or VIDIOC_STREAMON yet the poll() function succeeds, but sets the POLLERR flag in the revents field. The vb2_poll() function sets POLLERR when the queued buffers list is empty, regardless of whether this is caused by the stream not being active yet, or by a transient buffer underrun. Bring the implementation in line with the specification by returning POLLERR if no buffer has been queued only when the queue is not streaming. Buffer underruns during streaming are not treated specially anymore and just result in poll() blocking until the next event. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Pawel Osciak pa...@osciak.com --- drivers/media/v4l2-core/videobuf2-core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 349e659..a05f355 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2533,9 +2533,10 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait) } /* -* There is nothing to wait for if no buffers have already been queued. +* There is nothing to wait for if no buffer has been queued and the +* queue isn't streaming. */ - if (list_empty(q-queued_list)) + if (list_empty(q-queued_list) !vb2_is_streaming(q)) return res | POLLERR; if (list_empty(q-done_list)) -- 1.8.5.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] v4l: vb2: Add fatal error condition flag
When a fatal error occurs that render the device unusable, the only
options for a driver to signal the error condition to userspace is to
set the V4L2_BUF_FLAG_ERROR flag when dequeuing buffers and to return an
error from the buffer prepare handler when queuing buffers.
The buffer error flag indicates a transient error and can't be used by
applications to detect fatal errors. Returning an error from vb2_qbuf()
is thus the only real indication that a fatal error occurred. However,
this is difficult to handle for multithreaded applications that requeue
buffers from a thread other than the control thread. In particular the
poll() call in the control thread will not notify userspace of the
error.
This patch adds an explicit mechanism to report fatal errors to
userspace. Drivers can call the vb2_queue_error() function to signal a
fatal error. From this moment on, buffer preparation will return -EIO to
userspace, and vb2_poll() will set the POLLERR flag and return
immediately. The error flag is cleared when cancelling the queue, either
at stream off time (through vb2_streamoff) or when releasing the queue
with vb2_queue_release().
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/v4l2-core/videobuf2-core.c | 39 +---
include/media/videobuf2-core.h | 3 +++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index a05f355..b1b7f78 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1582,6 +1582,11 @@ static int __buf_prepare(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
return -EINVAL;
}
+ if (q-error) {
+ dprintk(1, fatal error occurred on queue\n);
+ return -EIO;
+ }
+
vb-state = VB2_BUF_STATE_PREPARING;
vb-v4l2_buf.timestamp.tv_sec = 0;
vb-v4l2_buf.timestamp.tv_usec = 0;
@@ -1877,6 +1882,11 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q,
int nonblocking)
return -EINVAL;
}
+ if (q-error) {
+ dprintk(1, Queue in error state, will not wait for
buffers\n);
+ return -EIO;
+ }
+
if (!list_empty(q-done_list)) {
/*
* Found a buffer that we were waiting for.
@@ -1902,7 +1912,8 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q,
int nonblocking)
*/
dprintk(3, will sleep waiting for buffers\n);
ret = wait_event_interruptible(q-done_wq,
- !list_empty(q-done_list) || !q-streaming);
+ !list_empty(q-done_list) || !q-streaming ||
+ q-error);
/*
* We need to reevaluate both conditions again after reacquiring
@@ -2099,6 +2110,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
q-streaming = 0;
q-start_streaming_called = 0;
q-queued_count = 0;
+ q-error = 0;
/*
* Remove all buffers from videobuf's list...
@@ -2176,6 +2188,27 @@ static int vb2_internal_streamon(struct vb2_queue *q,
enum v4l2_buf_type type)
}
/**
+ * vb2_queue_error() - signal a fatal error on the queue
+ * @q: videobuf2 queue
+ *
+ * Flag that a fatal unrecoverable error has occurred and wake up all processes
+ * waiting on the queue. Polling will now set POLLERR and queuing and dequeuing
+ * buffers will return -EIO.
+ *
+ * The error flag will be cleared when cancelling the queue, either from
+ * vb2_streamoff or vb2_queue_release. Drivers should thus not call this
+ * function before starting the stream, otherwise the error flag will remain
set
+ * until the queue is released when closing the device node.
+ */
+void vb2_queue_error(struct vb2_queue *q)
+{
+ q-error = 1;
+
+ wake_up_all(q-done_wq);
+}
+EXPORT_SYMBOL_GPL(vb2_queue_error);
+
+/**
* vb2_streamon - start streaming
* @q: videobuf2 queue
* @type: type argument passed from userspace to vidioc_streamon handler
@@ -2534,9 +2567,9 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file
*file, poll_table *wait)
/*
* There is nothing to wait for if no buffer has been queued and the
-* queue isn't streaming.
+* queue isn't streaming, or if the error flag is set.
*/
- if (list_empty(q-queued_list) !vb2_is_streaming(q))
+ if ((list_empty(q-queued_list) !vb2_is_streaming(q)) || q-error)
return res | POLLERR;
if (list_empty(q-done_list))
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index bca25dc..e5cb2a3 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -375,6 +375,7 @@ struct
Re: [PATCH] staging: omap4iss: copy paste error in iss_get_clocks
Hi Vitaly,
Thank you for the patch.
On Thursday 05 June 2014 17:07:48 Vitaly Osipov wrote:
It makes more sense to return PTR_ERR(iss-iss_ctrlclk) here. The
current code looks like an oversight in pasting the block just above
this one.
Signed-off-by: Vitaly Osipov vitaly.osi...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
and applied to my tree.
---
drivers/staging/media/omap4iss/iss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/omap4iss/iss.c
b/drivers/staging/media/omap4iss/iss.c index 2e422dd..4a9e444 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -1029,7 +1029,7 @@ static int iss_get_clocks(struct iss_device *iss)
if (IS_ERR(iss-iss_ctrlclk)) {
dev_err(iss-dev, Unable to get iss_ctrlclk clock info\n);
iss_put_clocks(iss);
- return PTR_ERR(iss-iss_fck);
+ return PTR_ERR(iss-iss_ctrlclk);
}
return 0;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] v4l: omap4iss: Don't reinitialize the video qlock at every streamon
Initialize the spin lock once only when initializing the video object. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/staging/media/omap4iss/iss_video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/omap4iss/iss_video.c b/drivers/staging/media/omap4iss/iss_video.c index ded31ea..7aded26 100644 --- a/drivers/staging/media/omap4iss/iss_video.c +++ b/drivers/staging/media/omap4iss/iss_video.c @@ -895,7 +895,6 @@ iss_video_streamon(struct file *file, void *fh, enum v4l2_buf_type type) video-queue = vfh-queue; INIT_LIST_HEAD(video-dmaqueue); - spin_lock_init(video-qlock); video-error = false; atomic_set(pipe-frame_number, -1); @@ -1175,6 +1174,7 @@ int omap4iss_video_init(struct iss_video *video, const char *name) if (ret 0) return ret; + spin_lock_init(video-qlock); mutex_init(video-mutex); atomic_set(video-active, 0); -- 1.8.5.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] v4l: omap4iss: Signal fatal errors to the vb2 queue
When a fatal error occurs in the pipeline signal it to the vb2 queue
with a call to vb2_queue_error(). The queue will then take care to
return -EIO when preparing buffers, remove the driver-specific code that
now duplicates that check.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/media/omap4iss/iss_video.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/omap4iss/iss_video.c
b/drivers/staging/media/omap4iss/iss_video.c
index a54ee8c..6dc6a45 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -331,15 +331,6 @@ static int iss_video_buf_prepare(struct vb2_buffer *vb)
if (vb2_plane_size(vb, 0) size)
return -ENOBUFS;
- /* Refuse to prepare the buffer is the video node has registered an
-* error. We don't need to take any lock here as the operation is
-* inherently racy. The authoritative check will be performed in the
-* queue handler, which can't return an error, this check is just a best
-* effort to notify userspace as early as possible.
-*/
- if (unlikely(video-error))
- return -EIO;
-
addr = vb2_dma_contig_plane_dma_addr(vb, 0);
if (!IS_ALIGNED(addr, 32)) {
dev_dbg(video-iss-dev,
@@ -363,6 +354,11 @@ static void iss_video_buf_queue(struct vb2_buffer *vb)
spin_lock_irqsave(video-qlock, flags);
+ /* Mark the buffer is faulty and give it back to the queue immediately
+* if the video node has registered an error. vb2 will perform the same
+* check when preparing the buffer, but that is inherently racy, so we
+* need to handle the race condition with an authoritative check here.
+*/
if (unlikely(video-error)) {
vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
spin_unlock_irqrestore(video-qlock, flags);
@@ -513,6 +509,7 @@ void omap4iss_video_cancel_stream(struct iss_video *video)
vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
}
+ vb2_queue_error(video-queue);
video-error = true;
spin_unlock_irqrestore(video-qlock, flags);
--
1.8.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] OMAP4 ISS: Miscellaneous fixes and improvements
Hello, This patch set brings miscellaneous fixes and improvements to the OMAP4 ISS driver. Please see individual patches for details. Patch 4/5 depends on the vb2: Report POLLERR for fatal errors only patch series posted to the linux-media mailing list. I plan to send a pull request that will include both series. Laurent Pinchart (5): v4l: omap4iss: Don't reinitialize the video qlock at every streamon v4l: omap4iss: Add module debug parameter v4l: omap4iss: Use the devm_* managed allocators v4l: omap4iss: Signal fatal errors to the vb2 queue MAINTAINERS: Add the OMAP4 ISS driver MAINTAINERS| 3 +- drivers/staging/media/omap4iss/iss.c | 84 +++--- drivers/staging/media/omap4iss/iss_video.c | 22 3 files changed, 22 insertions(+), 87 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] v4l: omap4iss: Use the devm_* managed allocators
This simplifies remove and error code paths.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/staging/media/omap4iss/iss.c | 84
1 file changed, 8 insertions(+), 76 deletions(-)
diff --git a/drivers/staging/media/omap4iss/iss.c
b/drivers/staging/media/omap4iss/iss.c
index 4a9e444..d548371 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -1003,32 +1003,17 @@ static void iss_disable_clocks(struct iss_device *iss)
clk_disable(iss-iss_fck);
}
-static void iss_put_clocks(struct iss_device *iss)
-{
- if (iss-iss_fck) {
- clk_put(iss-iss_fck);
- iss-iss_fck = NULL;
- }
-
- if (iss-iss_ctrlclk) {
- clk_put(iss-iss_ctrlclk);
- iss-iss_ctrlclk = NULL;
- }
-}
-
static int iss_get_clocks(struct iss_device *iss)
{
- iss-iss_fck = clk_get(iss-dev, iss_fck);
+ iss-iss_fck = devm_clk_get(iss-dev, iss_fck);
if (IS_ERR(iss-iss_fck)) {
dev_err(iss-dev, Unable to get iss_fck clock info\n);
- iss_put_clocks(iss);
return PTR_ERR(iss-iss_fck);
}
- iss-iss_ctrlclk = clk_get(iss-dev, iss_ctrlclk);
+ iss-iss_ctrlclk = devm_clk_get(iss-dev, iss_ctrlclk);
if (IS_ERR(iss-iss_ctrlclk)) {
dev_err(iss-dev, Unable to get iss_ctrlclk clock info\n);
- iss_put_clocks(iss);
return PTR_ERR(iss-iss_ctrlclk);
}
@@ -1104,29 +1089,11 @@ static int iss_map_mem_resource(struct platform_device
*pdev,
{
struct resource *mem;
- /* request the mem region for the camera registers */
-
mem = platform_get_resource(pdev, IORESOURCE_MEM, res);
- if (!mem) {
- dev_err(iss-dev, no mem resource?\n);
- return -ENODEV;
- }
-
- if (!request_mem_region(mem-start, resource_size(mem), pdev-name)) {
- dev_err(iss-dev,
- cannot reserve camera register I/O region\n);
- return -ENODEV;
- }
- iss-res[res] = mem;
- /* map the region */
- iss-regs[res] = ioremap_nocache(mem-start, resource_size(mem));
- if (!iss-regs[res]) {
- dev_err(iss-dev, cannot map camera register I/O region\n);
- return -ENODEV;
- }
+ iss-regs[res] = devm_ioremap_resource(iss-dev, mem);
- return 0;
+ return PTR_ERR_OR_ZERO(iss-regs[res]);
}
static void iss_unregister_entities(struct iss_device *iss)
@@ -1389,7 +1356,7 @@ static int iss_probe(struct platform_device *pdev)
if (pdata == NULL)
return -EINVAL;
- iss = kzalloc(sizeof(*iss), GFP_KERNEL);
+ iss = devm_kzalloc(pdev-dev, sizeof(*iss), GFP_KERNEL);
if (!iss) {
dev_err(pdev-dev, Could not allocate memory\n);
return -ENOMEM;
@@ -1456,7 +1423,8 @@ static int iss_probe(struct platform_device *pdev)
goto error_iss;
}
- if (request_irq(iss-irq_num, iss_isr, IRQF_SHARED, OMAP4 ISS, iss)) {
+ if (devm_request_irq(iss-dev, iss-irq_num, iss_isr, IRQF_SHARED,
+OMAP4 ISS, iss)) {
dev_err(iss-dev, Unable to request IRQ\n);
ret = -EINVAL;
goto error_iss;
@@ -1465,7 +1433,7 @@ static int iss_probe(struct platform_device *pdev)
/* Entities */
ret = iss_initialize_modules(iss);
if (ret 0)
- goto error_irq;
+ goto error_iss;
ret = iss_register_entities(iss);
if (ret 0)
@@ -1477,29 +1445,12 @@ static int iss_probe(struct platform_device *pdev)
error_modules:
iss_cleanup_modules(iss);
-error_irq:
- free_irq(iss-irq_num, iss);
error_iss:
omap4iss_put(iss);
error:
- iss_put_clocks(iss);
-
- for (i = 0; i OMAP4_ISS_MEM_LAST; i++) {
- if (iss-regs[i]) {
- iounmap(iss-regs[i]);
- iss-regs[i] = NULL;
- }
-
- if (iss-res[i]) {
- release_mem_region(iss-res[i]-start,
- resource_size(iss-res[i]));
- iss-res[i] = NULL;
- }
- }
platform_set_drvdata(pdev, NULL);
mutex_destroy(iss-iss_mutex);
- kfree(iss);
return ret;
}
@@ -1507,29 +1458,10 @@ error:
static int iss_remove(struct platform_device *pdev)
{
struct iss_device *iss = platform_get_drvdata(pdev);
- unsigned int i;
iss_unregister_entities(iss);
iss_cleanup_modules(iss);
- free_irq(iss-irq_num, iss);
- iss_put_clocks(iss);
-
- for (i = 0; i OMAP4_ISS_MEM_LAST; i++) {
- if (iss-regs[i]) {
- iounmap(iss-regs[i]);
- iss-regs[i] =
[PATCH 5/5] MAINTAINERS: Add the OMAP4 ISS driver
Update the OMAP Image Signal Processor entry to cover both the OMAP3 ISP and OMAP4 ISS. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6b7c633..6f2f537 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6402,11 +6402,12 @@ L: linux-o...@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c -OMAP IMAGE SIGNAL PROCESSOR (ISP) +OMAP IMAGING SUBSYSTEM (OMAP3 ISP and OMAP4 ISS) M: Laurent Pinchart laurent.pinch...@ideasonboard.com L: linux-media@vger.kernel.org S: Maintained F: drivers/media/platform/omap3isp/ +F: drivers/staging/media/omap4iss/ OMAP USB SUPPORT M: Felipe Balbi ba...@ti.com -- 1.8.5.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] v4l: omap4iss: Add module debug parameter
The parameter is used to initialize the video node debug field and activate the V4L debug infrastructure. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/staging/media/omap4iss/iss_video.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/staging/media/omap4iss/iss_video.c b/drivers/staging/media/omap4iss/iss_video.c index 7aded26..a54ee8c 100644 --- a/drivers/staging/media/omap4iss/iss_video.c +++ b/drivers/staging/media/omap4iss/iss_video.c @@ -25,6 +25,9 @@ #include iss_video.h #include iss.h +static unsigned debug; +module_param(debug, uint, 0644); +MODULE_PARM_DESC(debug, activates debug info); /* - * Helper functions @@ -1043,6 +1046,8 @@ static int iss_video_open(struct file *file) if (handle == NULL) return -ENOMEM; + video-video.debug = debug; + v4l2_fh_init(handle-vfh, video-video); v4l2_fh_add(handle-vfh); -- 1.8.5.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 3.16-rc1] updates and DT support for adv7604
On 06/06/2014 05:49 PM, Ben Dooks wrote: On 05/06/14 13:55, Mauro Carvalho Chehab wrote: Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media topic/adv76xx For adv7604 driver updates, including DT support. Can we use the adv7611 for the adv7612 with these? You can, except that you won't be able to use the second HDMI in. But it should be fairly trivial to add that. - Lars -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 3.16-rc1] updates and DT support for adv7604
On 05/06/14 13:55, Mauro Carvalho Chehab wrote: Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media topic/adv76xx For adv7604 driver updates, including DT support. Can we use the adv7611 for the adv7612 with these? -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 3.16-rc1] updates and DT support for adv7604
On 06/06/14 16:51, Lars-Peter Clausen wrote: On 06/06/2014 05:49 PM, Ben Dooks wrote: On 05/06/14 13:55, Mauro Carvalho Chehab wrote: Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media topic/adv76xx For adv7604 driver updates, including DT support. Can we use the adv7611 for the adv7612 with these? You can, except that you won't be able to use the second HDMI in. But it should be fairly trivial to add that. Thanks, we're going to try the rcar_vin driver and the HDMI in on the Lager board next week. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rcar_vin, soc_camera and videobuf2
Hi folks,
A colleague and I have been attempting to debug issues with rcar_vin,
soc_camera, and videobuf2.
Presently, We're using the adv7180 frontend to feed composite video to the rcar
hardware.
Using the streamer utility from xawtv3 (as packaged by wheezy), we have been
able to capture both stills and video, however there are significant issues.
There are a lot of warnings triggered in the videobuf2 code, primarily in
videobuf2-core.c
in vb2_buffer_done() we found that it appears that q-start_streaming_called is
0, due to the following code in __vb2_queue_cancel().
q-streaming = 0;
q-start_streaming_called = 0;
q-queued_count = 0;
if (WARN_ON(atomic_read(q-owned_by_drv_count))) {
for (i = 0; i q-num_buffers; ++i) {
if (q-bufs[i]-state == VB2_BUF_STATE_ACTIVE)
vb2_buffer_done(q-bufs[i],
VB2_BUF_STATE_ERROR);
}
/* Must be zero now */
WARN_ON(atomic_read(q-owned_by_drv_count));
}
This causes the code in vb2_buffer_done() to follow the DMA path and thus
generate a warning.
Moving the first three lines afer the if() clause means that we no longer see
the WARN_ON(state != VB2_BUF_STATE_QUEUED) in vb2_buffer_done(), however, we
still see the WARN_ON(vb-state != VB2_BUF_STATE_ACTIVE) later in the process.
When capturing video, the driver also exhibits very odd behaviour, including
apparently time running backwards, which appears to be the result of queuing
buffers in the wrong order. We also see a lot of messages re: buffers being
queued twice.
Looking at the rcar_vin driver, it appears to perform its allocations quite
differently from other soc_camera drivers.
Does anyone have any guidance on how to proceed? Clearly the state machine is
being violated here, but I'm at a loss as to how its actually *supposed* to
operate. Is there any good documentation?
--
Ian Molton ian.mol...@codethink.co.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rcar_vin, soc_camera and videobuf2
[[sorry for the repost - fixing CC's]]
Hi folks,
A colleague and I have been attempting to debug issues with rcar_vin,
soc_camera, and videobuf2.
Presently, We're using the adv7180 frontend to feed composite video to the rcar
hardware.
Using the streamer utility from xawtv3 (as packaged by wheezy), we have been
able to capture both stills and video, however there are significant issues.
There are a lot of warnings triggered in the videobuf2 code, primarily in
videobuf2-core.c
in vb2_buffer_done() we found that it appears that q-start_streaming_called is
0, due to the following code in __vb2_queue_cancel().
q-streaming = 0;
q-start_streaming_called = 0;
q-queued_count = 0;
if (WARN_ON(atomic_read(q-owned_by_drv_count))) {
for (i = 0; i q-num_buffers; ++i) {
if (q-bufs[i]-state == VB2_BUF_STATE_ACTIVE)
vb2_buffer_done(q-bufs[i],
VB2_BUF_STATE_ERROR);
}
/* Must be zero now */
WARN_ON(atomic_read(q-owned_by_drv_count));
}
This causes the code in vb2_buffer_done() to follow the DMA path and thus
generate a warning.
Moving the first three lines afer the if() clause means that we no longer see
the WARN_ON(state != VB2_BUF_STATE_QUEUED) in vb2_buffer_done(), however, we
still see the WARN_ON(vb-state != VB2_BUF_STATE_ACTIVE) later in the process.
When capturing video, the driver also exhibits very odd behaviour, including
apparently time running backwards, which appears to be the result of queuing
buffers in the wrong order. We also see a lot of messages re: buffers being
queued twice.
Looking at the rcar_vin driver, it appears to perform its allocations quite
differently from other soc_camera drivers.
Does anyone have any guidance on how to proceed? Clearly the state machine is
being violated here, but I'm at a loss as to how its actually *supposed* to
operate. Is there any good documentation?
--
Ian Molton ian.mol...@codethink.co.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hdpvr troubles
On 06/02/2014 06:23 PM, Scott Doty wrote: Hello Mr. Hans and mailing list, In a nutshell, I'm having some hdpvr trouble: I'm using vlc to view the stream. Kernel 3.9.11 works pretty well, including giving me AC3 5.1 audio from the optical input to the Hauppauge device. The only problem I've run across is the device hanging when I change channels, but I've learned to live with that. (Though naturally it would be nice to fix. :) ) However, every kernel I've tried after 3.9.11 seems to have trouble with the audio. I get silence, and pulseaudio reports there is only stereo. [...] Did I report this incorrectly? Sorry if I did. -Scott -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: v4l2-core: v4l2-dv-timings.c: Cleaning up code that putting values to the same variable twice
Instead of putting the same variable twice,
was rather intended to set this value to two different variable.
This was partly found using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
drivers/media/v4l2-core/v4l2-dv-timings.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 48b20df..eb3850c 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -599,10 +599,10 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8
hor_landscape, u8 vert_portrait)
aspect.denominator = 9;
} else if (ratio == 34) {
aspect.numerator = 4;
- aspect.numerator = 3;
+ aspect.denominator = 3;
} else if (ratio == 68) {
aspect.numerator = 15;
- aspect.numerator = 9;
+ aspect.denominator = 9;
} else {
aspect.numerator = hor_landscape + 99;
aspect.denominator = 100;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
fusion hdtv dual express 2
After confirming that it was supported I just bought a fusion hdtv dual express PCI adapter, only to find that I'd bought the 'dual express 2' version, which isn't supported (not the first time I've made such a mistake). This page http://www.linuxtv.org/wiki/index.php/DViCO_FusionHDTV_DVB-T_Dual_Express2 says that the new v2 card is still using CX23885 chipset but also uses DIB7070 (dib7000 + dib0070) which appears to be supported already but only via a few USB adapters. With a bit of cut and paste I have added some support for the card, to the point that dvbtune now says: # dvbtune -f 55050 -bw 7 -c 2 -cr 3_4 -gi 16 -tm 8 -I 1 -m -i Using DVB card DiBcom 7000PC tuning DVB-T (in United Kingdom) to 55050 Hz polling Getting frontend event FE_STATUS: polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Bit error rate: 0 Signal strength: 49390 SNR: 233 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC transponder type=T freq=55050 Nothing to read from fd_pat Nothing to read from fd_sdt /transponder Signal=49402, Verror=0, SNR=228dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49397, Verror=0, SNR=226dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49377, Verror=0, SNR=235dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49336, Verror=0, SNR=230dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49345, Verror=0, SNR=235dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49374, Verror=0, SNR=232dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49352, Verror=0, SNR=254dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49396, Verror=0, SNR=241dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49344, Verror=0, SNR=243dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49353, Verror=0, SNR=258dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49309, Verror=0, SNR=248dB, BlockErrors=0, (S|L|C|V|SY|) Signal=49334, Verror=0, SNR=243dB, BlockErrors=0, (S|L|C|V|SY|) ^C Which all looks correct at the start, but obviously not as it can't actually read the information in the dvb streams. Is it likely that getting it working only requires a small amount of further tinkering, or am I likely wasting my time? I know next to nothing about dvb and how it all hangs together. Thanks James -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: fusion hdtv dual express 2
Hi James, The first basic thing you should look at is if the dvb device has got all its pieces. A dvb adapter has, sort of, 4 sub-devices: [me@home ~]$ ll /dev/dvb/adapter2 total 0 crw-rw+ 1 root video 212, 12 Jun 5 12:31 demux0 crw-rw+ 1 root video 212, 13 Jun 5 12:31 dvr0 crw-rw+ 1 root video 212, 15 Jun 5 12:31 frontend0 crw-rw+ 1 root video 212, 14 Jun 5 12:31 net0 From your post you might miss the demux while the front-end is working. ls -al /dev/dvb/adapter1/ total 0 drwxr-xr-x 2 root root 120 Jun 7 10:08 . drwxr-xr-x 5 root root 100 Jun 7 10:08 .. crw-rw---T 1 root video 212, 5 Jun 7 10:08 demux0 crw-rw---T 1 root video 212, 6 Jun 7 10:08 dvr0 crw-rw---T 1 root video 212, 4 Jun 7 10:08 frontend0 crw-rw---T 1 root video 212, 7 Jun 7 10:08 net0 same for adapter2 (adapter0 is an existing usb dvb-t adapter) I think all the pieces are there, they just aren't connected up internally correctly. If I deliberately put in a wrong i2c address for the tuner (starts of at 0x12 and is reprogrammed to 0x80 in the usb version, which is what I've copied) then I get an error, so it can definitely see the tuner. And if I tune an incorrect frequency I never get lock or anything so I think that much is working. And my original post shows it can see a stream with no errors, and if I put the incorrect code rate in (eg 2_3 instead of 3_4) then it sees lots of errors. So suppose that the demux is what's wrong, how could I debug that further? Is there a block diagram somewhere that explains how the various dvb components feed into each other? Thanks James -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Jun 7 04:00:38 CEST 2014 git branch: test git hash: 5ea878796f0a1d9649fe43a6a09df53d3915c0ef gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-5.slh.3-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx: New device @ 480 Mbps (eb1a:2861, interface 0, class 0)
Hi, I've made tests with an August device. Model: August VGB200 USB 2.0 Video capture adapter idVendor=eb1a, idProduct=2861 I couldn't get analogue capture to work in Debian Linux using VLC. The manufacturer's website for the device is: http://www.augustint.com/en/productmsg-90-125.html Tested by:Alexi Nones alexi.no...@gmail.com The output of dmesg is: [ 35.990801] usb 4-2: new high-speed USB device number 2 using ehci-pci [ 36.123101] usb 4-2: New USB device found, idVendor=eb1a, idProduct=2861 [ 36.123109] usb 4-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 36.145793] media: Linux media interface: v0.10 [ 36.151799] Linux video capture interface: v2.00 [ 36.155113] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0, class 0) [ 36.155115] em28xx: Video interface 0 found: isoc [ 36.155535] em28xx: chip ID is em2860 [ 36.280956] em2860 #0: unknown eeprom format or eeprom corrupted ! [ 36.293007] em2860 #0: couldn't read from i2c device 0xb8: error -6 [ 36.303418] em2860 #0: couldn't read from i2c device 0xba: error -6 [ 36.317647] em2860 #0: couldn't read from i2c device 0x90: error -6 [ 36.327452] em2860 #0: couldn't read from i2c device 0x42: error -6 [ 36.341609] em2860 #0: couldn't read from i2c device 0x60: error -6 [ 36.341616] em2860 #0: No sensor detected [ 36.357157] em2860 #0: found i2c device @ 0x4a on bus 0 [saa7113h] [ 36.375668] em2860 #0: found i2c device @ 0xa0 on bus 0 [eeprom] [ 36.395093] em2860 #0: Your board has no unique USB ID and thus need a hint to be detected. [ 36.395100] em2860 #0: You may try to use card=n insmod option to workaround that. [ 36.395103] em2860 #0: Please send an email with this log to: [ 36.395105] em2860 #0: V4L Mailing List linux-media@vger.kernel.org [ 36.395108] em2860 #0: Board eeprom hash is 0x [ 36.395111] em2860 #0: Board i2c devicelist hash is 0x6ba50080 [ 36.395113] em2860 #0: Here is a list of valid choices for the card=n insmod option: [ 36.395116] em2860 #0: card=0 - Unknown EM2800 video grabber [ 36.395119] em2860 #0: card=1 - Unknown EM2750/28xx video grabber [ 36.395122] em2860 #0: card=2 - Terratec Cinergy 250 USB [ 36.395124] em2860 #0: card=3 - Pinnacle PCTV USB 2 [ 36.395127] em2860 #0: card=4 - Hauppauge WinTV USB 2 [ 36.395129] em2860 #0: card=5 - MSI VOX USB 2.0 [ 36.395131] em2860 #0: card=6 - Terratec Cinergy 200 USB [ 36.395134] em2860 #0: card=7 - Leadtek Winfast USB II [ 36.395136] em2860 #0: card=8 - Kworld USB2800 [ 36.395139] em2860 #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 / Plextor ConvertX PX-AV100U [ 36.395141] em2860 #0: card=10 - Hauppauge WinTV HVR 900 [ 36.395143] em2860 #0: card=11 - Terratec Hybrid XS [ 36.395146] em2860 #0: card=12 - Kworld PVR TV 2800 RF [ 36.395148] em2860 #0: card=13 - Terratec Prodigy XS [ 36.395150] em2860 #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 36.395153] em2860 #0: card=15 - V-Gear PocketTV [ 36.395155] em2860 #0: card=16 - Hauppauge WinTV HVR 950 [ 36.395157] em2860 #0: card=17 - Pinnacle PCTV HD Pro Stick [ 36.395159] em2860 #0: card=18 - Hauppauge WinTV HVR 900 (R2) [ 36.395162] em2860 #0: card=19 - EM2860/SAA711X Reference Design [ 36.395164] em2860 #0: card=20 - AMD ATI TV Wonder HD 600 [ 36.395166] em2860 #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video Encoder [ 36.395169] em2860 #0: card=22 - EM2710/EM2750/EM2751 webcam grabber [ 36.395171] em2860 #0: card=23 - Huaqi DLCW-130 [ 36.395173] em2860 #0: card=24 - D-Link DUB-T210 TV Tuner [ 36.395176] em2860 #0: card=25 - Gadmei UTV310 [ 36.395178] em2860 #0: card=26 - Hercules Smart TV USB 2.0 [ 36.395180] em2860 #0: card=27 - Pinnacle PCTV USB 2 (Philips FM1216ME) [ 36.395183] em2860 #0: card=28 - Leadtek Winfast USB II Deluxe [ 36.395185] em2860 #0: card=29 - EM2860/TVP5150 Reference Design [ 36.395187] em2860 #0: card=30 - Videology 20K14XUSB USB2.0 [ 36.395190] em2860 #0: card=31 - Usbgear VD204v9 [ 36.395192] em2860 #0: card=32 - Supercomp USB 2.0 TV [ 36.395194] em2860 #0: card=33 - Elgato Video Capture [ 36.395196] em2860 #0: card=34 - Terratec Cinergy A Hybrid XS [ 36.395199] em2860 #0: card=35 - Typhoon DVD Maker [ 36.395201] em2860 #0: card=36 - NetGMBH Cam [ 36.395203] em2860 #0: card=37 - Gadmei UTV330 [ 36.395205] em2860 #0: card=38 - Yakumo MovieMixer [ 36.395207] em2860 #0: card=39 - KWorld PVRTV 300U [ 36.395210] em2860 #0: card=40 - Plextor ConvertX PX-TV100U [ 36.395212] em2860 #0: card=41 - Kworld 350 U DVB-T [ 36.395214] em2860 #0: card=42 - Kworld 355 U DVB-T [ 36.395217] em2860 #0: card=43 - Terratec Cinergy T XS [ 36.395219] em2860 #0: card=44 - Terratec
Ping: [PATCH 0/10] drivers/media/rc/ati_remote.c tweaks
Just a ping... has anyone looked at this? (David Härdeman added to recipients list.) The series can be found in the linux-media archives stating at mid:2014051113.14427.qm...@ns.horizon.com http://www.spinics.net/lists/linux-media/msg76435.html http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/77678 or I'm happy to re-mail it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: fusion hdtv dual express 2 (working, kind of)
OK I have picture in mythtv now, but it's very glitchy (lines in video, bursts
of high pitched tone in audio). In fact it is behaving much like the dib0700
based adapter that I replaced with the express2 adapter because I thought it
had died. Could there been a regression somewhere? I'll check the git archives
but I don't know when it broke - somewhere between kernel 3.2.x and 3.14.x.
Alternatively the dib0700 adapter could actually be dead and maybe this is
something different...
The change I made was to set the output mode to OUTMODE_MPEG2_SERIAL after
copying the code from the USB dib7070 based adapter.
The Leadtek Research, Inc. WinFast DTV Dongle Gold (0413:6029) that I am
still using works fine so I don't think it's a physical reception problem
unless the signal has gotten suddenly really poor.
Any suggestions?
My current patch follows this email. It's a bit messy because the dib7070 stuff
is tied fairly closely to the usb code so there is a bit of duplication. And
there is some state required and I don't know that I've put it in the right
place (sec_priv).
Thanks
James
diff --git a/drivers/media/dvb-frontends/dib7000p.h
b/drivers/media/dvb-frontends/dib7000p.h
index 1fea0e9..4d1dbca 100644
--- a/drivers/media/dvb-frontends/dib7000p.h
+++ b/drivers/media/dvb-frontends/dib7000p.h
@@ -64,6 +64,7 @@ struct dib7000p_ops {
int (*get_adc_power)(struct dvb_frontend *fe);
int (*slave_reset)(struct dvb_frontend *fe);
struct dvb_frontend *(*init)(struct i2c_adapter *i2c_adap, u8 i2c_addr,
struct dib7000p_config *cfg);
+ int (*set_param_save)(struct dvb_frontend *fe);
};
#if IS_ENABLED(CONFIG_DVB_DIB7000P)
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 79f20c8..9ca8855 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -649,7 +649,12 @@ struct cx23885_board cx23885_boards[] = {
CX25840_NONE1_CH3,
.amux = CX25840_AUDIO6,
} },
- }
+ },
+ [CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP2] = {
+ .name = DViCO FusionHDTV DVB-T Dual Express2,
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -897,6 +902,10 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x1461,
.subdevice = 0xd939,
.card = CX23885_BOARD_AVERMEDIA_HC81R,
+ }, {
+ .subvendor = 0x18ac,
+ .subdevice = 0xdb98,
+ .card = CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP2,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1137,6 +1146,7 @@ int cx23885_tuner_callback(void *priv, int component, int
command, int arg)
break;
case CX23885_BOARD_DVICO_FUSIONHDTV_7_DUAL_EXP:
case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP:
+ case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP2:
/* Two identical tuners on two different i2c buses,
* we need to reset the correct gpio. */
if (port-nr == 1)
@@ -1280,6 +1290,7 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
cx_set(GP0_IO, 0x000f000f);
break;
case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP:
+ case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP2:
/* GPIO-0 portb xc3028 reset */
/* GPIO-1 portb zl10353 reset */
/* GPIO-2 portc xc3028 reset */
@@ -1585,6 +1596,7 @@ int cx23885_ir_init(struct cx23885_dev *dev)
ir_rxtx_pin_cfg_count, ir_rxtx_pin_cfg);
break;
case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP:
+ case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP2:
request_module(ir-kbd-i2c);
break;
}
@@ -1720,6 +1732,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
break;
case CX23885_BOARD_DVICO_FUSIONHDTV_7_DUAL_EXP:
case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP:
+ case CX23885_BOARD_DVICO_FUSIONHDTV_DVB_T_DUAL_EXP2:
ts2-gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts2-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index d037459..89d6c54 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -44,6 +44,7 @@
#include tuner-xc2028.h
#include tuner-simple.h
#include dib7000p.h
+#include dib0070.h
#include dibx000_common.h
#include zl10353.h
#include stv0900.h
@@ -746,6 +747,119 @@
