rcar_vin, soc_camera and videobuf2

rcar_vin, soc_camera and videobuf2

[Ian Molton]

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.molton@codethink.co.uk>

Re: rcar_vin, soc_camera and videobuf2

[Ian Molton]

[[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.molton@codethink.co.uk>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html