Re: [PATCH v2 63/66] staging: media: Add support for the Allwinner A31 ISP

[Paul Kocialkowski]

Hi Laurent,

On Wed 02 Mar 22, 15:33, Laurent Pinchart wrote:
> Hi Paul,
> 
> On Wed, Mar 02, 2022 at 02:23:37PM +0100, Paul Kocialkowski wrote:
> > On Wed 02 Mar 22, 10:51, Laurent Pinchart wrote:
> > > On Tue, Mar 01, 2022 at 04:58:51PM +0100, Paul Kocialkowski wrote:
> > > > On Mon 07 Feb 22, 18:16, Laurent Pinchart wrote:
> > > > > On Sat, Feb 05, 2022 at 07:54:26PM +0100, Paul Kocialkowski wrote:
> > > > > > Some Allwinner platforms come with an Image Signal Processor, which
> > > > > > supports various features in order to enhance and transform data
> > > > > > received by image sensors into good-looking pictures. In most cases,
> > > > > > the data is raw bayer, which gets internally converted to RGB and
> > > > > > finally YUV, which is what the hardware produces.
> > > > > > 
> > > > > > This driver supports ISPs that are similar to the A31 ISP, which was
> > > > > > the first standalone ISP found in Allwinner platforms. Simpler ISP
> > > > > > blocks were found in the A10 and A20, where they are tied to a CSI
> > > > > > controller. Newer generations of Allwinner SoCs (starting with the
> > > > > > H6, H616, etc) come with a new camera subsystem and revised ISP.
> > > > > > Even though these previous and next-generation ISPs are somewhat
> > > > > > similar to the A31 ISP, they have enough significant differences to
> > > > > > be out of the scope of this driver.
> > > > > > 
> > > > > > While the ISP supports many features, including 3A and many
> > > > > > enhancement blocks, this implementation is limited to the following:
> > > > > > - V3s (V3/S3) platform support;
> > > > > > - Bayer media bus formats as input;
> > > > > 
> > > > > Greyscale formats would also be nice to have, if the hardware can
> > > > > support that (it mostly just requires the ability to disable the CFA
> > > > > interpolation).
> > > > 
> > > > As far as I know there's no support for grayscale, only bayer formats
> > > > and YUV.
> > > > 
> > > > > > - Semi-planar YUV (NV12/NV21) as output;
> > > > > 
> > > > > Packed YUV would also be useful if the hardware supports it.
> > > > 
> > > > Same here, it only supports planar and semi-planar YUV as output.
> > > > 
> > > > > > - Debayering with per-component gain and offset configuration;
> > > > > > - 2D noise filtering with configurable coefficients.
> > > > > > 
> > > > > > Since many features are missing from the associated uAPI, the driver
> > > > > > is aimed to integrate staging until all features are properly
> > > > > > described.
> > > > > > 
> > > > > > On the technical side, it uses the v4l2 and media controller APIs,
> > > > > > with a video node for capture, a processor subdev and a video node
> > > > > > for parameters submission. A specific uAPI structure and associated
> > > > > > v4l2 meta format are used to configure parameters of the supported
> > > > > > modules.
> > > > > > 
> > > > > > One particular thing about the hardware is that configuration for
> > > > > > module registers needs to be stored in a DMA buffer and gets copied
> > > > > > to actual registers by the hardware at the next vsync, when instructed
> > > > > > by a flag. This is handled by the "state" mechanism in the driver.
> > > > > > 
> > > > > > Signed-off-by: Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx>
> > > > > > ---
> > > > > >  drivers/staging/media/sunxi/Kconfig           |   1 +
> > > > > >  drivers/staging/media/sunxi/Makefile          |   1 +
> > > > > >  drivers/staging/media/sunxi/sun6i-isp/Kconfig |  13 +
> > > > > >  .../staging/media/sunxi/sun6i-isp/Makefile    |   4 +
> > > > > >  .../staging/media/sunxi/sun6i-isp/sun6i_isp.c | 572 +++++++++++++
> > > > > >  .../staging/media/sunxi/sun6i-isp/sun6i_isp.h |  86 ++
> > > > > >  .../media/sunxi/sun6i-isp/sun6i_isp_capture.c | 751 ++++++++++++++++++
> > > > > >  .../media/sunxi/sun6i-isp/sun6i_isp_capture.h |  78 ++
> > > > > >  .../media/sunxi/sun6i-isp/sun6i_isp_params.c  | 573 +++++++++++++
> > > > > >  .../media/sunxi/sun6i-isp/sun6i_isp_params.h  |  52 ++
> > > > > >  .../media/sunxi/sun6i-isp/sun6i_isp_proc.c    | 599 ++++++++++++++
> > > > > >  .../media/sunxi/sun6i-isp/sun6i_isp_proc.h    |  61 ++
> > > > > >  .../media/sunxi/sun6i-isp/sun6i_isp_reg.h     | 275 +++++++
> > > > > >  .../sunxi/sun6i-isp/uapi/sun6i-isp-config.h   |  43 +
> > > > > 
> > > > > Could you add a TODO file to list the issues that need to be fixed for
> > > > > the driver to move out of staging ? I'll already propose one entry:
> > > > > 
> > > > > - Add support in libcamera
> > > > 
> > > > Maybe it would be good to narrow down what level of support you have in mind
> > > > here. Just adding basic support fort the pipeline is probably doable, but
> > > > developing complex 3A algorithms would require very significant effort and
> > > > it would be a shame that this prevents the driver from leaving staging.
> > > > 
> > > > I think another obvious task would be to have a complete uAPI that reflects
> > > > all modules that are part of the ISP.
> > > > 
> > > > What do you think?
> > > 
> > > The reason why I'd like to see libcamera support for the ISP driver is
> > > to ensure that the kernel API is adequate for real use cases. The API
> > > can be split in three parts:
> > > 
> > > - Pipeline configuration (this includes the media controller topology,
> > >   link setting, subdev pad format/selection rectangle configuration,
> > >   ...)
> > > - ISP parameters
> > > - ISP statistics
> > > 
> > > A pipeline handler implementation will cover the first parts. The second
> > > and third parts need to be tested too, but we don't need to implement
> > > every single feature. A very simple algorithm that demonstrates
> > > statistics can be captured and ISP parameters can be set should be
> > > enough to test and exercise the API in real scenarios. We're working on
> > > making basic AE and AWB algorithm implementations generic (or at least
> > > creating generic building blocks that can easily be assembled to create
> > > those algorithms, as the ISP statistics and parameters are specific to
> > > the ISP and thus require some ISP-specific code), so that should become
> > > a fairly easy task soon. I expect most of the work to go in the pipeline
> > > handler.
> > > 
> > > Does this sound fair to you ?
> > 
> > Yes I understand that these aspects need to be tested too, but I feel like
> > having an implementation with a feedback look (even rudimentary and using
> > some generic helpers) would be quite a stretch.
> 
> Don't be scared, it's not that difficult :-) A very basic feedback loop
> is easier to implement than the code that configures the pipeline and
> tracks buffers.

Thanks for the reassurance :) In any case I think there's work to be done
to figure the precise meaning of the feedback data. I remember seeing headers
that describe the data layout but the meaning of individual fields seems
very vague. But in any case we need proper understanding of that since
that's what the driver will be returning.

> > It would probably be sufficient to have some demo code that can receive stats
> > and set parameters, but without necessarily any connection between the two.
> > As such it's also my feeling that a standalone demo program could be easier
> > to manage for that purpose than libcamera support.
> > 
> > So how about making the requirement that a (free software) userspace
> > implementration must demonstrate ability to read relevant statistics
> > from the ISP and (independently) control parameters that affect the output?
> 
> It's easy to create a test tool to demonstrate that the driver works
> fine, when the purpose of the test tool is to exercise the driver API in
> the way intended by the driver author. What such a test tool fails to
> demonstrate is the fitness of the API for real uses cases. This is why
> KMS requires userspace APIs to be exercised in a real display stack
> (X.org, Weston, Android hwcomposer, ...) and not just in a test tool.
> We're following the same rationale here.

Okay I understand your point here. If the expectation is to fully validate
proper use-cases and not just parts of the API individually, I don't object.
It's a high standard but it might prevent issues down the road.

Cheers,

Paul

> > > > > This isn't required to merge the driver in staging as long as ABI
> > > > > compatibility doesn't need to be preserved until the driver is moved out
> > > > > of staging.
> > > > >
> > > > > >  14 files changed, 3109 insertions(+)
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/Kconfig
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/Makefile
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/sun6i_isp.c
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/sun6i_isp.h
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.h
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_params.c
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_params.h
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_proc.c
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_proc.h
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_reg.h
> > > > > >  create mode 100644 drivers/staging/media/sunxi/sun6i-isp/uapi/sun6i-isp-config.h
> > > > > 
> > > > > [snip]
> 
> -- 
> Regards,
> 
> Laurent Pinchart

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Attachment: signature.asc
Description: PGP signature