i.MX6 V4L2 buffer status is not changed from V4L2_BUF_FLAG_QUEUED.

[satoshishimoda]

Hi community,

Our partner have a problem about i.MX6 V4L2 driver.
They want to do the following process to a buffer with V4L2 driver, but it was not succeeded.
(1) Write output data --> (2) VIDIOC_QBUF --> VIDIOC_DQBUF --> (1) --> (2) --> ...

Actually, process (3) was not work well when the input image data size is same as output field size.
Could you let me know how to resolve this issue?

For your information, they understand if the buffer status is changed from V4L2_BUF_FLAG_QUEUED (during driver output) to V4L2_BUF_FLAG_DONE (done driver output), the process by VIDIOC_DQBUF can start.
However, the buffer status was not changed from V4L2_BUF_FLAG_QUEUED if input data size = output field size.

Best Regards,
Satoshi Shimoda

[jamesbone]

Let me ask internally. I will get back to you.

[satoshishimoda]

Hi jamesbone,

Could you let me know your status?

[jamesbone]

Sorry about the latency response, can you please share a little details about the problem ?:

What is the customer trying to do ? Encode? Decode? Is this gstreamer or a homemade application?

It is unclear from the description what they are doing.

[satoshishimoda]

Hi jamesbone,

I got a reply to your question from our partner as following.

=====

> What is the customer trying to do ? Encode? Decode?

to output decoded data to "Display Interface" by "video output interface" of v4l2.

> Is this gstreamer or a homemade application?

homemade application

=====

Best Regards,

Satoshi Shimoda

[YixingKong]

Satoshi

We have not got your response yet and will close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Yixing

[satoshishimoda]

I'm sorry for getting back to you so late.

I got a information from our customer as following.

=====

> Or is this from a direct ioctl call ?

Yes.

> If so which one?

(1) /dev/video17 open

(2) VIDIOC_S_FMT/VIDIOC_G_FMT

(3) VIDIOC_REQBUFS<param:count=1, type:V4L2_BUF_TYPE_VIDEO_OUTPUT, memory:V4L2_MEMORY_USERPTR>

(4) VIDIOC_QBUF

(5) VIDIOC_STREAMON

(6) VIDIOC_QUERYBUF

(7) VIDIOC_DQBUF

=====

Best Regards,

Satoshi Shimoda

[gfine]

Hi Satoshi,

In my research I came across this definition.

V4L2_BUF_FLAG_QUEUED

0x0002

Internally drivers maintain two buffer queues, an incoming and outgoing queue. When this flag is set, the buffer is currently on the incoming queue. It automatically moves to the outgoing queue after the buffer has been filled (capture devices) or displayed (output devices). Drivers set or clear this flag when the VIDIOC_QUERYBUF ioctl is called. After (successful) calling the VIDIOC_QBUF ioctl it is always set and after VIDIOC_DQBUF always cleared.

From this it seems that if the input buffer is not filled, it will return the V4L2_BUF_FLAG_QUEUED.  Try making the size of the input buffer one less than the size of the output buffer and see if this flag still returns.

Cheers,

Glen

[satoshishimoda]

Hi Glen Fine,

I write our partner's test conditions of VIDIOC_QBUF -> VIDIOC_QUERYBUF and the results as following.

* Input buffer is the buffer size set to VIDIOC_QBUF

* Output buffer is the parameter setting of VIDIOC_S_FMT (v4l2_format.fmt.pix.width/fmt.pix.height)

* Projection field is the field size set by parameter of VIDIOC_S_CROP.

=====

(1) Input buffer < Output buffer (Projection field == Input buffer size)

VIDIOC_QBUF return flags = 0

* Failed at VDDIOC_QBUF : errno=Invalid argument

(2) Input buffer < Output buffer (Projection field == Output buffer size)

VIDIOC_QBUF return flags = 0

* Failed at VDDIOC_QBUF : errno=Invalid argument

(3) Input buffer > Output buffer (Projection field == Input buffer size)

VIDIOC_QBUF returns flags=0

VIDIOC_QUERYBUF return flags=4 (V4L2_BUF_FLAG_DONE)

* Projection continue even though image is jumble.

(4) Input buffer > Output buffer (Projection field == Output buffer size)

VIDIOC_QBUF returns flags=0

VIDIOC_QUERYBUF return flags=2 (V4L2_BUF_FLAG_DONE)

* VIDIOC_QUERYBUF remains flag=2, and projection cannot continue

(5) Input buffer size == Output Buffer size == Projection filed

VIDIOC_QBUF returns flags=0

VIDIOC_QUERYBUF return flags=2 (V4L2_BUF_FLAG_DONE)

* VIDIOC_QUERYBUF remains flag=2, and projection cannot continue

(6) Input buffer size == Output Buffer size > Projection filed

VIDIOC_QBUF returns flags=0

VIDIOC_QUERYBUF return flags=4 (V4L2_BUF_FLAG_DONE)

* Projection continue with scale down

=====

According to these results, VDDIOC_QBUF was failed if input buffer size < output buffer size.

Best Regards,

Satoshi Shimoda

[gfine]

Created CustomerTag:45417343

Do you have a testcase you can provide?

Who is the customer/partner?

Glen

[satoshishimoda]

Hi Glen Fine,

What did you mean testcase?

Do you want to a source code?

> Who is the customer/partner?

Sorry, I cannot tell you to keep secret.

Best Regards,

Satoshi Shimoda

[gfine]

Hi Satoshi,

We need a testcase that replicates the error. Without it, R&D can not replicate, and can not find the defect to address, if there is one.

We do not require their whole system (or Intellectual Property), just the source of the failing function or component. Please post it on the internal discussion ( https://community.freescale.com/thread/323764 ) if confidentiality is required.

Cheers,

Glen

[satoshishimoda]

Hi Glen,

OK, I understood, and I will try getting testcase.

By the way, I did not access to the internal discussion (https://community.freescale.com/thread/323764) with "Unauthorized" message.

Could you give me a authorization to access there?

Best Regards,

Satoshi Shimoda

[OliverB]

Can you provide the Linux BSP release and hardware platform (SOC, board freescale or custom)?

Regards,

Oliver

[satoshishimoda]

Hi Oliver,

I confirmed the BSP revision our customer is using.

I understood they are using L3.0.35_4.1.0 BSP, but it was wrong, sorry.

Actually, they are using Timesys Linux BSP, and I heard this issue was not occurred on L3.0.35_4.1.0.

So I have requested them to check the difference between L3.0.35_4.1.0 and Timesys BSP.

Maybe, this issue will be clear when they find the difference.

And I post the detail of the issue again if L3.0.35_4.1.0 causes same issue.

Thank you for your cooperation.

Best Regards,

Satoshi Shimoda

[gfine]

satoshishimoda

Can you respond to my last query? R&D is awiaiting answer.  Did customer determine which BSP shows the error?

Cheers,

Glen

[satoshishimoda]

Hi Glen,

Sorry for delay.

> What i.MX6 is this happening on? (Q. DL, Solo)?? Is the board a custom board or one of our EVKs?

i.MX6S and on a custom board.

> Is it correct that the error only occurs on the Timesys BSP?

Yes, only on the Timesys BSP.

Best Regards,

Satoshi Shimoda

[timesyssupport]

Hello Shimoda-san,

Can you please open a ticket with us at http://linuxlink.timesys.com/support? Also, please include any relevant information, like your Desktop Factory workorder/link to your Web Factory build, and steps that need to be taken to reproduce the issue.

Thanks,

Timesys Support

[gfine]

Hi Satoshi,

Unfortunately we do not maintain the Timesys BSP nor do we have the ability to fix their version.

Cheers,

Glen

[karina_valencia]

timesyssupport can you help here?

[gfine]

Hi Satoshi,

Thanks, and a reminder.  What i.MX6 is this happening on? (Q. DL, Solo)?? Is the board a custom board or one of our EVKs?

Is it correct that the error only occurs on the Timesys BSP? I will await your answer.

Cheers,

Glen