[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