Re: [PATCH 0/4] media: raspberrypi: Support RPi5's CFE

[Tomi Valkeinen]

On 19/03/2024 08:23, Krzysztof Kozlowski wrote:
> On 19/03/2024 07:21, Tomi Valkeinen wrote:
> > Hi,
> >
> > On 19/03/2024 08:05, Krzysztof Kozlowski wrote:
> > > On 18/03/2024 16:49, Tomi Valkeinen wrote:
> > > > This series adds support to the CFE hardware block on RaspberryPi 5. The
> > > > CFE (Camera Front End) contains a CSI-2 receiver and Front End, a small
> > > > ISP.
> > > >
> > > > This series is currently based on multiple other serieses:
> > > >
> > > > - Sakari's "[PATCH v8 00/38] Generic line based metadata support, internal
> > > >     pads" for metadata support
> > > > - Laurent's "[PATCH 00/15] media: Add driver for the Raspberry Pi <5
> > > >     CSI-2 receiver" for a few new pixel formats and imx219 (for testing).
> > > > - Jacopo's "[PATCH v5 0/9] media: raspberrypi: Add support for PiSP Back
> > > >     End" for some shared uapi headers.
> > > >
> > > > And to run this, one of course needs the basic RPi5 kernel support plus
> > > > relevant dts changes to enable the cfe and camera.
> > >
> > > Which makes it impossible to merge. Please work on decoupling.
> >
> > Yes, it's not for merging as I wrote: "So at the moment we cannot merge
> > this driver, but hopefully the dependencies will get merged before the
> > reviews on this one are done."
> >
> > I believe Sakari's and Jacopo's serieses should be very close to
> > merging, and those should satisfy the needs of the driver itself.
> >
> > The DT bindings example uses a header from RPi5 base support series, and
> > if merging the base support seems to take a long time, I guess I could
> > drop the include and just use numbers instead for RP1_INT_MIPI0 and
> > RP1_CLK_MIPI0_CFG. And change those back later when the base support is
> > merged.
>
> The problem is that your patches cannot be tested by automated tools.

Yes, I understand. I will send testable and mergeable patches when the 
dependencies are in, and until that this series is do-not-merge. But as 
reviews sometimes take a very long time, I think it's better to start 
sooner than later.

Is there a way to mark a series as "don't bother testing" for automated 
tools? RFC in the subject? I considered making this RFC, but I felt the 
patches themselves are not RFC quality. I've also seen DNI 
(do-not-integrate) used somewhere, but I'm not sure that's universally 
understood.

 Tomi