Re: [PATCH v5 01/12] media: rppx1: Add framework to support Dreamchip RPPX1 ISP

[Marek Vasut]

On 12/25/25 6:10 PM, Niklas Söderlund wrote:
> Add a framework driver for Dreamchip RPPX1 ISP. The driver aims to
> provide a framework for other V4L2 based drivers to drive the RPPX1
> functionality. The reason for this split is that the RPPX1 IP itself do
> not provide any DMA engines to drive data to/from the device, instead it
> depends on other IP blocks to implement these features.
>
> While the peripherals around the RPPX1 ISP used in different designs and
> by different vendors are different the RPPX1 core itself is the same.
> For this reason the framework solution to be able to split the Dreamchip
> RPPX1 driver from vendors usage of it have been picked in hope to reduce
> duplication of the common parts.
>
> The functions provided by the RPPX1 is similar to what is exposed by
> other ISP drivers already in tree (RkISP1 primarily), but the
> implementation of them are different. It do however open up for the
> possibility to reuse the RkISP1 parameter and statistics pixel formats
> in an initial implementation.
>
> The design is to try and keep the surface of this framework as small as
> possible. The intention of this change is to be able to fill all needs
> of this.
>
>    * Two functions to create and destroy a RPPX1 instance, rppx1_create()
>      and rppx1_destory(). These are intended to be called in the users
>      probe and remove code paths.
>
>    * Two functions to start and stop the RPPX1 processing, rppx1_start()
>      and rppx1_stop(). These are intended to be called in the users
>      stream on and stream off code paths.
>
>    * One function to ask the RPPX1 to process parameters buffer prepared
>      by user space, rppx1_params_rkisp1(). This is intended to translate
>      the parameter buffer (RkISP1 format) to the register writes needed
>      to be preformed on the RPPX1. The intention is to call this function
>      when the parameter buffer is queued to the V4L2 driver and the
>      result stored by the driver until the time it needs to be written to
>      the RPPX1. It's the users responsibility to write it either using
>      MMIO or other means.
>
>    * One function to fill in a statistic buffer (RkISP1 format) based on
>      the current status of the RPPX1, rppx1_stats_fill_isr(). The
>      intention is that the user call's this in its interrupt handler when
>      it knows the RPPX1 is done processing a frame.
>
>    * One function to ack and retrieve the interrupts generated by the
>      RPPX1, rppx1_interrupt(). The intention is to call this function
>      when the users interrupt handler detects the RPPX1 have raised and
>      interrupt. There is no need for the user to understand, or act, on
>      the actual RPPX1 interrupt, but it can if it wants too.
>
> The initial support in the framework is limited and do not implement any
> ISP processing algorithms other then configuring the RPPX1 to process
> any Bayer (8-, 10, or 12-bit) image and produce either a RGB or YUYV
> output. It do however probe all function blocks of the RPPX1 and provide
> an interface to interact with both parameter and statistic bufferers.
> The user of the framework will not change as algorithms for the
> different function blocks of the ISP are being added.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx>
> Tested-by: Marek Vasut'<marek.vasut+renesas@xxxxxxxxxxx>                        ^

Tested-by: Marek Vasut <marek.vasut+renesas@xxxxxxxxxxx>

(in case the apostrophe corrupted the TB tag)

Thank you for your hard work !