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:   Tue, 14 Sep 2021 13:48:01 +0200
From:   Maxime Ripard <maxime@cerno.tech>
To:     Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc:     Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
        linux-media@vger.kernel.org, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev,
        linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
        linux-clk@vger.kernel.org, linux-staging@lists.linux.dev,
        Yong Deng <yong.deng@magewell.com>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Hans Verkuil <hans.verkuil@cisco.com>,
        Chen-Yu Tsai <wens@csie.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Helen Koike <helen.koike@collabora.com>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 20/22] staging: media: Add support for the Allwinner A31
 ISP
Message-ID: <20210914114801.krmzxbkwj6u7lfjd@gilmour>
References: <20210910184147.336618-1-paul.kocialkowski@bootlin.com>
 <20210910184147.336618-21-paul.kocialkowski@bootlin.com>
 <20210913083135.v7q7joux2xckat62@gilmour>
 <YUBUUQxBaGUkjzMP@aptenodytes>
 <YUCDVm4OA3C3Re09@pendragon.ideasonboard.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="rvmu2elmhrznwm6w"
Content-Disposition: inline
In-Reply-To: <YUCDVm4OA3C3Re09@pendragon.ideasonboard.com>
Precedence: bulk


--rvmu2elmhrznwm6w
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 14, 2021 at 02:11:18PM +0300, Laurent Pinchart wrote:
> Hi Paul,
>=20
> 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.
> > > >=20
> > > > 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.
> > > >=20
> > > > 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.
> > > >=20
> > > > Since many features are missing from the associated uAPI, the driver
> > > > is aimed to integrate staging until all features are properly
> > > > described.
> > >=20
> > > We can add new features/interfaces to a !staging driver. Why do you
> > > think staging is required?
> >=20
> > This is true for the driver but not so much for the uAPI, so it seems t=
hat
> > the uAPI must be added to staging in some way. Then I'm not sure it mak=
es sense
> > to have a !staging driver that depends on a staging uAPI.
> >=20
> > Besides that, I added it to staging because that's the process that was
> > followed by rkisp1, which is a very similar case.
>=20
> 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).
>=20
> 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.

The rule seems to be about whether or not the user-space gets broken in
the process:

https://lore.kernel.org/lkml/CAHk-=3DwiVi7mSrsMP=3DfLXQrXK_UimybW=3DziLOwSz=
FTtoXUacWVQ@mail.gmail.com/

Something that wouldn't compile cannot generate a regression, since it
never worked in the first place. Changing the semantic of an ioctl does.

Maxime

--rvmu2elmhrznwm6w
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYUCL8QAKCRDj7w1vZxhR
xTToAQDDtt/uV0Mc20Vef8PiiT2oboXw4IMiKcGnaGkiGeJF0AEA2qTN9vI6Lp2E
c1Q7OUUDoHcGOrZWXlkbdAD1T4FyvQw=
=vImF
-----END PGP SIGNATURE-----

--rvmu2elmhrznwm6w--