Le 2014-09-01 05:43, Kamil Debski a écrit :
Hi Nicolas,
From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
Sent: Friday, August 29, 2014 3:47 PM
Hi Kamil,
after a discussion on IRC, we concluded that s5p-mfc have this bug that
disallow multiple reqbufs calls before streaming. This has the impact
that it forces to call REQBUFS(0) before setting the new number of
buffers during re-negotiation, and is against the spec too.
I was out of office last week. Could you shed more light on this subject?
Do you have the irc log?
Sorry I didn't record this one, but feel free to ping Hans V.
As an example, in reqbufs_output() REQBUFS is only allowed in
QUEUE_FREE state, and setting buffers exits this state. We think that
the call to
<http://lxr.free-
electrons.com/ident?i=reqbufs_output>s5p_mfc_open_mfc_inst()
should be post-poned until STREAMON is called.
<http://lxr.free-electrons.com/ident?i=reqbufs_output>
How is this connected to the renegotiation scenario?
Are you sure you wanted to mention s5p_mfc_open_mfc_inst?
This limitation in MFC causes an important conflict between old videobuf
and new videobuf2 drivers. Old videobuf driver (before Hans G. proposed
patch) refuse REQBUFS(0). As MFC code has this bug that refuse
REBBUFS(N) if buffers are already allocated, it makes all this
completely incompatible. This open_mfc call seems to be the only reason
REQBUFS() cannot be called multiple time, though I must say you are
better placed then me to figure this out.
cheers,
Nicolas
--
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
