Add the Rockchip ISP1 specific processing parameter format
V4L2_META_FMT_RK_ISP1_PARAMS and metadata format
V4L2_META_FMT_RK_ISP1_STAT_3A for 3A.

Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
[update for upstream]
Signed-off-by: Helen Koike <helen.koike@collabora.com>

Series-to: linux-rockchip@lists.infradead.org
Series-cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Series-cc: mchehab@kernel.org, linux-media@vger.kernel.org
Series-cc: sakari.ailus@linux.intel.com, hans.verkuil@cisco.com
Series-cc: tfiga@chromium.org, zhengsq@rock-chips.com
Series-cc: laurent.pinchart@ideasonboard.com, zyc@rock-chips.com
Series-cc: eddie.cai.linux@gmail.com, jeffy.chen@rock-chips.com
Series-cc: devicetree@vger.kernel.org, heiko@sntech.de
Series-cc: jacob2.chen@rock-chips.com
Series-cc: kernel@collabora.com, ezequiel@collabora.com
Series-version: 7
Series-changes: 7
- s/IPU3/RK_ISP1

Cover-letter:
Rockchip ISP1 Driver
Hello,

I'm re-sending a new version of ISP(Camera) v4l2 driver for rockchip
rk3399 SoC.

It is not perfect yet (see known issues below), but I'm sending in case
some other people already wants to start playing with it.
I believe de main design is ok (please let me know if
it is not) and it would be great to get some reviews already.

This patchset is also available at:
https://gitlab.collabora.com/koike/linux/tree/rockchip/isp/v7

Libcamera patched to work with this version:
https://gitlab.collabora.com/koike/libcamera
(I'll also sent it to the libcamera dev mailing list)

I tested on the rockpi 4 with a rpi v1.3 sensor and also with the
Scarlet Chromebook.
Images from the Scarlet are a bit dark and green for some reason, but I
believe it's a problem in the sensor's drivers as images from the
rockpi looks ok.

The main differences from previous version are (in a macro pov):
----------------------------------------------------------------
- dphy specific code migrated to drivers/phy
- design change: droped the subdevice for the interface. Now, in the
media topology, the sensors connect directly to the ISP1.
- v4l2-compliance fixes
- dropped rk3288 (as I'm not testing it)
- dropped txrx dphy support (as I'm not testing it and it requires a bit
more work to support dsi too)
- interrupts and hw config fixes
- minor bug fixes and cleanups
- I added myself in the MAINTAINERS, as I'm not sure if previous people
still wants to maintain it, please let me know if I should keep the old
names there.

Known issues:
-------------
- Reloading the module doesn't work (there is some missing cleanup when
unloading)
- When capturing in bayer format, changing the size doesn't seem to
affect the image.
- crop needs more tests
- v4l2-compliance error:
        fail: v4l2-test-controls.cpp(824): subscribe event for control 'Image Processing Controls' failed
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
It seems that if controls are supported, v4l2-compliance says that
controls of type 'Image Processing Controls' are mandatory, is this
correct?
- It seems there are still some issues with interrupts, but I couldn't
isolate them yet.

Reasoning for the design change:
--------------------------------
In the previous version, the isp subdevice call the mipidphy_g_mbus
from rkisp1.c, so it can get
informations from the sensor such as the type of mbus (V4L2_MBUS_BT656,
V4L2_MBUS_PARALLEL or V4L2_MBUS_CSI2_CPHY), the number of csi2 lanes,
flags (V4L2_MBUS_PCLK_SAMPLE_RISING, V4L2_MBUS_VSYNC_ACTIVE_LOW or
V4L2_MBUS_HSYNC_ACTIVE_LOW). And the isp driver uses those info to configure
the hardware properly.

These information come from the DT node of the sensor. And the current
implementation is propagating this information from the sensor to the isp
through this mipidphy_g_mbus_config() (thus the hack)

* 1st attempt to solve this hack) Separating the interface code from the isp.

With the topology:

isp -> csi2 -> sensor

I was trying to migrate the CSI2 hardware configuration to the csi2 subdevice code.
But the problem I found was that in the DT, the csi2 regs is in the middle of the isp1
regs, and declaring the same "regs = <>" in both nodes (isp0 and csi2) is no good.

* 2nd attempt) flatening the DT
So instead of having two DT nodes (isp0 and csi2), we can have a single node, similar
to omap3isp.
And we can have a property, "rk,phy-type" that defines the interface (csi2, bt656 or parallel).

But, now my question is: can the isp be connected to multiple interfaces at a
time? If yes, then this is not a good solution (as we won't be able to describe
multiple interfaces in the DT node).

* 3rd attemp - WIP) get rid of the interface subdevice (chosen design)
Is there a reason to have the topology like:

isp -> interface - - -> sensor1
        |   |-------->  sensor2
        | - - - - - - > sensor3

(only one sensor can be active at a time)

?

Would it be ok if I just hide the interface from the topology? Like:

isp - - - - - -> sensor1
| |----------->  sensor2
|- - - - - - - > sensor3

Like this, I could cleanup a bunch of v4l2 code from the interface node,
the isp would know the active sensor (and its configs), and it can
configure everything itself.

I don't really see a big reason to expose the interface (csi2,
bt656 or parallel) in the topology.
Unless I'm missing something.

Previous changelog:
-------------------

changes in V6:
  - add mipi txrx phy support
  - remove bool and enum from uapi header
  - add buf_prepare op
  - correct some spelling problems
  - return all queued buffers when starting stream failed

changes in V5: Sync with local changes,
  - fix the SP height limit
  - speed up the second stream capture
  - the second stream can't force sync for rsz when start/stop streaming
  - add frame id to param vb2 buf
  - enable luminance maximum threshold

changes in V4:
  - fix some bugs during development
  - move quantization settings to rkisp1 subdev
  - correct some spelling problems
  - describe ports in dt-binding documents

changes in V3:
  - add some comments
  - fix wrong use of v4l2_async_subdev_notifier_register
  - optimize two paths capture at a time
  - remove compose
  - re-struct headers
  - add a tmp wiki page: http://opensource.rock-chips.com/wiki_Rockchip-isp1

changes in V2:
  mipi-phy:
    - use async probing
    - make it be a child device of the GRF
  isp:
    - add dummy buffer
    - change the way to get bus configuration, which make it possible to
            add parallel sensor support in the future(without mipi-phy driver).

------------------
END