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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5401228b-e8e3-4f2b-b91c-7e202afd9fdb@mailbox.org>
Date: Thu, 25 Dec 2025 21:59:43 +0100
From: Marek Vasut <marek.vasut@...lbox.org>
To: Niklas Söderlund
 <niklas.soderlund+renesas@...natech.se>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
 Jacopo Mondi <jacopo.mondi@...asonboard.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 linux-media@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 01/12] media: rppx1: Add framework to support Dreamchip
 RPPX1 ISP

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@...natech.se>
> Tested-by: Marek Vasut'<marek.vasut+renesas@...lbox.org>                        ^

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

(in case the apostrophe corrupted the TB tag)

Thank you for your hard work !