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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux