Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 3 Nov 2021 16:54:24 +0000
From:   Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To:     Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc:     Linux Media Mailing List <linux-media@vger.kernel.org>,
        Tsuchiya Yuto <kitakar@gmail.com>,
        Hans de Goede <hdegoede@redhat.com>,
        Patrik Gfeller <patrik.gfeller@gmail.com>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Kaixu Xia <kaixuxia@tencent.com>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Yang Li <abaci-bugfix@linux.alibaba.com>,
        Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
        Alex Dewar <alex.dewar90@gmail.com>,
        Aline Santana Cordeiro <alinesantanacordeiro@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>, Alan <alan@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@kernel.org>, linux-staging@lists.linux.dev,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: atomisp current issues
Message-ID: <20211103165424.67296e13@sal.lan>
In-Reply-To: <c39cac68-73ab-4ab0-a701-e92f01c92774@xs4all.nl>
References: <20211103135418.496f75d5@sal.lan>
        <c39cac68-73ab-4ab0-a701-e92f01c92774@xs4all.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

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