Re: s5p-mfc should allow multiple call to REQBUFS before we start streaming

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

Le 2014-09-01 05:43, Kamil Debski a écrit :
> Hi Nicolas,
>
>
>> From: Nicolas Dufresne [mailto:nicolas.dufresne@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