LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Laurent Pinchart <firstname.lastname@example.org> To: Paul Kocialkowski <email@example.com> Cc: Maxime Ripard <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Yong Deng <email@example.com>, Mauro Carvalho Chehab <firstname.lastname@example.org>, Rob Herring <email@example.com>, Sakari Ailus <firstname.lastname@example.org>, Hans Verkuil <email@example.com>, Chen-Yu Tsai <firstname.lastname@example.org>, Jernej Skrabec <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, Helen Koike <email@example.com>, Thomas Petazzoni <firstname.lastname@example.org> Subject: Re: [PATCH 20/22] staging: media: Add support for the Allwinner A31 ISP Date: Tue, 14 Sep 2021 14:11:18 +0300 [thread overview] Message-ID: <YUCDVm4OA3C3Re09@pendragon.ideasonboard.com> (raw) In-Reply-To: <YUBUUQxBaGUkjzMP@aptenodytes> Hi Paul, On Tue, Sep 14, 2021 at 09:50:41AM +0200, Paul Kocialkowski wrote: > On Mon 13 Sep 21, 10:31, Maxime Ripard wrote: > > On Fri, Sep 10, 2021 at 08:41:45PM +0200, 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; > > > - Semi-planar YUV (NV12/NV21) 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. > > > > We can add new features/interfaces to a !staging driver. Why do you > > think staging is required? > > This is true for the driver but not so much for the uAPI, so it seems that > the uAPI must be added to staging in some way. Then I'm not sure it makes sense > to have a !staging driver that depends on a staging uAPI. > > Besides that, I added it to staging because that's the process that was > followed by rkisp1, which is a very similar case. Maxime is right in the sense that uAPI can always be extended, but it has to be done in a backward-compatible manner, and staging is sometimes considered as not being covered by the ABI stability requirements of the kernel. Not everybody agrees on this, but there are clear cases where userspace really can't expect staging ABIs to be stable (for instance when the driver doesn't even compile). I think there's value in having the driver in staging to facilitate development until we consider the ABI stable, but I'm not entirely sure if there should be another step taken to mark this ABI is not being ready yet. > > > 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. > > > > This meta format needs to be documented > > You're right, there should probably be a pixfmt-meta-sun6i-isp.rst > documentation file. I guess it should live along in the staging driver > directory for now and be destaged later. Can documentation in staging be compiled ? If not I think it can go to Documentation/ -- Regards, Laurent Pinchart
next prev parent reply other threads:[~2021-09-14 11:11 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-10 18:41 [PATCH 00/22] Allwinner A31/A83T MIPI CSI-2 Support and A31 ISP Support Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 01/22] clk: sunxi-ng: v3s: Make the ISP PLL clock public Paul Kocialkowski 2021-09-13 7:54 ` Maxime Ripard 2021-09-13 8:53 ` Paul Kocialkowski 2021-09-16 16:30 ` Maxime Ripard 2021-09-10 18:41 ` [PATCH 02/22] ARM: dts: sun8i: v3s: Parent the CSI module clock to the ISP PLL Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 03/22] dt-bindings: sun6i-a31-mipi-dphy: Add optional direction property Paul Kocialkowski 2021-09-13 8:00 ` Maxime Ripard 2021-09-14 7:39 ` Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 04/22] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2 Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 05/22] dt-bindings: media: sun6i-a31-csi: Add MIPI CSI-2 input port Paul Kocialkowski 2021-09-13 8:09 ` Maxime Ripard 2021-09-14 7:43 ` Paul Kocialkowski 2021-09-14 12:06 ` Maxime Ripard 2021-09-10 18:41 ` [PATCH 06/22] dt-bindings: media: Add Allwinner A31 MIPI CSI-2 bindings documentation Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 07/22] media: sunxi: Add support for the A31 MIPI CSI-2 controller Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 08/22] MAINTAINERS: Add entry for the Allwinner A31 MIPI CSI-2 bridge driver Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 09/22] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support Paul Kocialkowski 2021-09-11 2:32 ` Samuel Holland 2021-09-13 7:44 ` Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 10/22] dt-bindings: media: Add Allwinner A83T MIPI CSI-2 bindings documentation Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 11/22] media: sunxi: Add support for the A83T MIPI CSI-2 controller Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 12/22] MAINTAINERS: Add entry for the Allwinner A83T MIPI CSI-2 bridge Paul Kocialkowski 2021-09-10 18:41 ` [PATCH NOT FOR MERGE 13/22] ARM: dts: sun8i: a83t: Add MIPI CSI-2 controller node Paul Kocialkowski 2021-09-11 2:53 ` Chen-Yu Tsai 2021-09-13 7:45 ` Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 14/22] ARM: dts: sun8i: a83t: bananapi-m3: Enable MIPI CSI-2 with OV8865 Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 15/22] media: sunxi: Remove the sun6i-csi driver implementation Paul Kocialkowski 2021-09-13 8:17 ` Maxime Ripard 2021-09-14 8:04 ` Paul Kocialkowski 2021-09-15 19:51 ` Sakari Ailus 2021-09-10 18:41 ` [PATCH 16/22] media: sunxi: Introduce a rewritten sun6i-csi driver Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 17/22] dt-bindings: media: Add Allwinner A31 ISP bindings documentation Paul Kocialkowski 2021-09-13 8:18 ` Maxime Ripard 2021-09-14 7:44 ` Paul Kocialkowski 2021-09-14 12:07 ` Maxime Ripard 2021-09-10 18:41 ` [PATCH 18/22] dt-bindings: media: sun6i-a31-csi: Add ISP output port Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 19/22] soc: sunxi: mbus: Add A31 ISP compatibles to the list Paul Kocialkowski 2021-09-11 2:36 ` Samuel Holland 2021-09-13 7:45 ` Paul Kocialkowski 2021-09-13 8:32 ` Maxime Ripard 2021-09-10 18:41 ` [PATCH 20/22] staging: media: Add support for the Allwinner A31 ISP Paul Kocialkowski 2021-09-13 8:31 ` Maxime Ripard 2021-09-14 7:50 ` Paul Kocialkowski 2021-09-14 11:11 ` Laurent Pinchart [this message] 2021-09-14 11:48 ` Maxime Ripard 2021-09-10 18:41 ` [PATCH 21/22] MAINTAINERS: Add entry for the Allwinner A31 ISP driver Paul Kocialkowski 2021-09-10 18:41 ` [PATCH 22/22] ARM: dts: sun8i: v3s: Add support for the ISP Paul Kocialkowski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YUCDVm4OA3C3Re09@pendragon.ideasonboard.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).