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:   Thu, 4 Nov 2021 08:37:37 +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: <20211104083737.55b88011@sal.lan>
In-Reply-To: <20211103165424.67296e13@sal.lan>
References: <20211103135418.496f75d5@sal.lan>
        <c39cac68-73ab-4ab0-a701-e92f01c92774@xs4all.nl>
        <20211103165424.67296e13@sal.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

Em Wed, 3 Nov 2021 16:54:24 +0000
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> 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;

I ended adding auto-detection support for USERPTR inside camorama,
for completeness.

The "-U" command line option remains, so one could use it to force USERPTR
mode.

As the way I implemented it is that camorama checks if REQBUFS doesn't
return any error, it means that it will automatically fallback to USERPTR
with atomisp driver (while MMAP support is not fixed there).

So, once I fix the issues with S_FMT/G_FMT, camorama will likely work
out of the box with it.

Regards,
Mauro