linux-kernel - Re: [PATCH v3 4/9] media: venus: vdec: add video decoder files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9ff4f3cf-f6d1-cebe-6f1a-e4209c55e4f4@xs4all.nl>
Date:   Mon, 21 Nov 2016 16:04:55 +0100
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     Andy Gross <andy.gross@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v3 4/9] media: venus: vdec: add video decoder files

On 18/11/16 10:11, Stanimir Varbanov wrote:
> Hi Hans,
>
>>>> +
>>>> +static int
>>>> +vdec_reqbufs(struct file *file, void *fh, struct v4l2_requestbuffers *b)
>>>> +{
>>>> +	struct vb2_queue *queue = to_vb2q(file, b->type);
>>>> +
>>>> +	if (!queue)
>>>> +		return -EINVAL;
>>>> +
>>>> +	return vb2_reqbufs(queue, b);
>>>> +}
>>>
>>> Is there any reason why the v4l2_m2m_ioctl_reqbufs et al helper functions
>>> can't be used? I strongly recommend that, unless there is a specific reason
>>> why that won't work.
>>
>> So that means I need to completely rewrite the v4l2 part and adopt it
>> for mem2mem device APIs.
>>
>> If that is what you meant I can invest some time to make a estimation
>> what would be the changes and time needed. After that we can decide what
>> to do - take the driver as is and port it to mem2mem device APIs later
>> on or wait for the this transition to happen before merging.
>>
>
> I made an attempt to adopt v4l2 part of the venus driver to m2m API's
> and the result was ~300 less lines of code, but with the price of few
> extensions in m2m APIs (and I still have issues with running
> simultaneously multiple instances).
>
> I have to add few functions/macros to iterate over a list (list_for_each
> and friends). This is used to find the returned from decoder buffers by
> address and associate them to vb2_buffer, because the decoder can change
> the order of the output buffers.
>
> The main problem I have is registering of the capture buffers before
> session_start. This is requirement (disadvantage) of the firmware
> implementation i.e. I need to announce capture buffers (address and size
> of the buffer) to the firmware before start buffer interaction by
> session_start.
>
> So having that I think I will need one more week to stabilize the driver
> to the state that it was before this m2m transition.
>
> Thoughts?
>

It sounds like this it worth doing, since if you need these extensions, then
it is likely someone else will need it as well.

Can you mail me a preliminary patch with the core m2m changes? That will be
helpful for me to look at.

Regards,

	Hans