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