Re: atomisp current issues

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Em Wed, 3 Nov 2021 15:41:05 +0100
Hans Verkuil <hverkuil-cisco@xs4all.nl> escreveu:

> On 03/11/2021 14:54, Mauro Carvalho Chehab wrote:
> > Hi,
> > 
> > From what I've seen so far, those are the main issues with regards to V4L2 API,
> > in order to allow a generic V4L2 application to work with it.
> > 
> > MMAP support
> > ============
> > 
> > Despite having some MMAP code on it, the current implementation is broken. 
> > Fixing it is not trivial, as it would require fixing the HMM support on it, 
> > which does several tricks.
> > 
> > The best would be to replace it by something simpler. If this is similar
> > enough to IPU3, perhaps one idea would be to replace the HMM code on it by 
> > videodev2 + IPU3 HMM code.
> > 
> > As this is not trivial, I'm postponing such task. If someone has enough
> > time, it would be great to have this fixed.
> > 
> > From my side, I opted to add support for USERPTR on camorama:
> > 
> > 	https://github.com/alessio/camorama
> > 
> > As this is something I wanted to do anyway, and it allowed me to cleanup
> > several things in camorama's code.
> > 
> > Support for USERPTR is not autodetected. So, this should be selected  
> 
> You can autodetect this: the capabilities field returned by VIDIOC_REQBUFS
> or VIDIOC_CREATE_BUFS will indicate support for this. This works with any
> vb2-based driver.
> 
> Just thought I should mention this...

Yeah, surely the app could try it, but:

1. As libv4l doesn't support USERPTR, such detection should happen
   early inside camorama code;

2. Atomisp does have support for MMAP, but it is broken.
   (this is the most relevant reason)

Ok, we could change it to return -ENOIOCTLCMD for mmap, and add
a basic logic at camorama that would try to call REQBUFS in order
to verify if -ENOIOCTLCMD is returned.

Perhaps one more item to our todo list, if nobody fixes MMAP before
that.

Regards,
Mauro