mirror of
https://github.com/linux-msm/laptops-kernel.git
synced 2026-08-13 14:19:53 -07:00
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 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(). 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 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@ragnatech.se>
Co-developed-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com>
Signed-off-by: Jai Luthra <jai.luthra+renesas@ideasonboard.com>
Co-developed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>