[v14] media: rockchip: add a driver for the rockchip camera interface

[PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Michael Riesch via B4 Relay 3 months, 2 weeks ago

Habidere,

This series introduces support for the Rockchip Camera Interface (CIF),
which is featured in many Rockchip SoCs in different variations.
For example, the PX30 Video Input Processor (VIP) is able to receive
video data via the Digital Video Port (DVP, a parallel data interface)
and transfer it into system memory using a double-buffering mechanism
called ping-pong mode.
The RK3568 Video Capture (VICAP) unit, on the other hand, features a
DVP and a MIPI CSI-2 receiver that can receive video data independently
(both using the ping-pong scheme).
The different variants may have additional features, such as scaling
and/or cropping.
Finally, the RK3588 VICAP unit constitutes an essential piece of the
camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
units, and a data path multiplexer (to scaler units, to ISP, ...).

The v14 of the series adds a media controller centric V4L2 device driver
for the Rockchip CIF with
 - support for the PX30 VIP (not tested, though, due to the lack of HW)
 - support for the RK3568 VICAP, including
    - capturing frames from the DVP
    - capturing frames from the MIPI CSI-2 receiver
 - abstraction for the ping-pong scheme to allow for future extensions
 - abstraction for the INTERFACE and CROP parts to allow for future
   extensions
 - initial support for different virtual channels (not tested, though,
   due to the lack of HW)
and a V4L2 subdevice driver for the Rockchip MIPI CSI-2 Receiver.

The RK3568 DVP has been tested by Gerald on a WolfVision PF5 hardware,
the RK3568 MIPI CSI-2 have been tested by me on a Radxa ROCK 3A + Radxa
Camera 8M.

The driver can be readily extended to provide support for the RK3588
VICAP variant. In order to keep things simple, however, this extension
shall be submitted separately.

Looking forward to your comments!

To: Mehdi Djait <mehdi.djait@linux.intel.com>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Théo Lebrun <theo.lebrun@bootlin.com>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Gerald Loacker <gerald.loacker@wolfvision.net>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To: Markus Elfring <Markus.Elfring@web.de>
To: Sakari Ailus <sakari.ailus@iki.fi>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Rob Herring <robh+dt@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Heiko Stuebner <heiko@sntech.de>
To: Kever Yang <kever.yang@rock-chips.com>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Collabora Kernel Team <kernel@collabora.com>
To: Paul Kocialkowski <paulk@sys-base.io>
To: Alexander Shiyan <eagle.alexander923@gmail.com>
To: Val Packett <val@packett.cool>
To: Rob Herring <robh@kernel.org>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-media@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>

Changes in v14:
- rkcsi: fixed invalid format handling in _set_fmt() (v4l2-compliance)
- rkcif-interface: fixed crop, reset crop at source when sink format
  is changed (v4l2-compliance)
- rebased onto media-committers/next
- Link to v13: https://lore.kernel.org/r/20240220-rk3568-vicap-v13-0-da164b4918fe@collabora.com

Changes in v13:
- fixed interrupt names in CSI-2 reciever bindings example (Rob's bot)
- revised Radxa Camera 8M device tree overlay
- Link to v12: https://lore.kernel.org/r/20240220-rk3568-vicap-v12-0-c6dbece6bb98@collabora.com

Changes in v12:
- added Radxa Camera 8M device tree overlay
- rebased onto v6.18-rc1
- fixed IOMMU pagefaults caused by wrong VLW (Mehdi)
- fixed indentation of register defines in -regs.h (Sakari)
- renamed CSI-2 receiver interrupts (Rob)
- added MEDIA_BUS_TYPE_* as comments in DT bindings (Bryan)
- added newline in rkcif-dev.c (Bryan)
- Link to v11: https://lore.kernel.org/r/20240220-rk3568-vicap-v11-0-af0eada54e5d@collabora.com

Changes in v11:
- rkcif: split large driver patch (6/13 of v10) into smaller
  patches (6-11/17 of v11) (Bryan)
- rkcsi: replaced devm_reset_control_array_get_exclusive with 
  devm_reset_control_get_exclusive (Philipp)
- Link to v10: https://lore.kernel.org/r/20240220-rk3568-vicap-v10-0-62d8a7b209b4@collabora.com

Changes in v10:
- rkcsi: fixed error handling in rkcsi_start (Bryan)
- rkcsi: fixed interrupt references in device tree and bindings
  (Rob's bot)
- added missing call to rkcif_mipi_stop_streaming from rkcif_mipi_isr
  (Mehdi)
- renamed remaining instances "cif_" -> "rkcif_" in functions
- Link to v9: https://lore.kernel.org/r/20240220-rk3568-vicap-v9-0-ace1e5cc4a82@collabora.com

Changes in v9:
- added compatible for RK3588 MIPI CSI-2 receiver, thus dropped
  Krzysztof's R-b
- added interrupts to rkcsi DT binding and RK356x DT
- added variant specific callback to rkcif-capture-mipi that puts
  together the CTRL0 register content (which varies between RK3568
  and RK3588)
- fixed v4l2_fill_pixfmt_mp() return value handling (Mehdi)
- Link to v8: https://lore.kernel.org/r/20240220-rk3568-vicap-v8-0-9d9cbc4b524d@collabora.com

Changes in v8:
- rebased onto v6.16-rc1
- fixed RKCIF_MIPI_MAX value in rkcif-common.h
- fixed rkcsi Kconfig (kernel test robot)
- sorted rkcsi DT bindings document properly, completed example
  (Krzysztof)
- squashed the defconfig patches (Krzysztof), dropped Bryan's R-b
- Link to v7: https://lore.kernel.org/r/20240220-rk3568-vicap-v7-0-7581fd96a33a@collabora.com

Changes in v7:
- moved MIPI CSI-2 receiver driver into separate directory (Laurent)
- rkcsi: fixed return values (Bryan)
- rkcsi: fixed v4l2_get_link_freq to use pad instead of control
  handler (Sakari)
- rkcsi: added data-lanes property (Mehdi)
- rkcif: fixed formatting (Bryan)
- fixed "int" -> "unsigned int" in all for loops (Sakari)
- rkcif-stream: fixed minimum number of required buffers (Mehdi)
- rkcif-stream: used guards for the spinlock (Markus and Mehdi)
- rkcif-stream: made driver less noisy with dev_dbg (Mehdi)
- rkcif-stream: fixed issues detected by v4l2-compliance (Mehdi)
- rkcif-dvp-capture: fixed return value propagation in _register()
  (Mehdi)
- removed stray "phy-names" from required properties (Rob's bot)
- Link to v6: https://lore.kernel.org/r/20240220-rk3568-vicap-v6-0-d2f5fbee1551@collabora.com

Changes in v6:
- rebased onto v6.15-rc1
- renamed "MIPI CSI HOST" -> "MIPI CSI RECEIVER" (Laurent)
- s/@wolfvision.net/@collabora.com where appropriate
- renamed DVP delay property and moved it to the endpoint (Sakari)
- implemented DT review comments (Krzysztof and Sakari)
- implemented driver review comments (Sakari)
- fixed issues raised by media-ci (yet again)
- added documentation including a RK3568 topology (new patch 1)
  (Sakari)
- added patch that enables rkcif in the defconfig (new patch 9)
- Link to v5: https://lore.kernel.org/r/20250306-v6-8-topic-rk3568-vicap-v5-0-f02152534f3c@wolfvision.net

Changes in v5:
- fixed issues raised by media-ci
- fixed dt bindings (comments by Rob and Sakari)
- fixed probe on systems with no DVP in DT (comment by Alexander)
- fixed error path in register offset calculation
- split off MIPI CSI host driver into separate module (comment
  by Mehdi)
- added MODULE_DEVICE_TABLE() for both drivers (comment by Mehdi)
- Link to v4: https://lore.kernel.org/r/20250219-v6-8-topic-rk3568-vicap-v4-0-e906600ae3b0@wolfvision.net

Changes in v4:
- added support for the MIPI CSI-2 receiver (new patches 4, 6, 7, 10)
- fixed asserts on stream stop
- fixed register address lookup
- fixed link validiation callback
- fixed issues raised by Rob's bot, kernel test robot, and media-ci
- Link to v3: https://lore.kernel.org/r/20250206-v6-8-topic-rk3568-vicap-v3-0-69d1f19e5c40@wolfvision.net

Changes in v3:
- renamed the driver "cif" -> "rkcif"
- rebased onto v6.14-rc1
- abstracted the generic INTERFACE+CROP part
- addressed comments by Rob and Sakari
- added V4L2 MPLANE formats to DVP
- added patch that enables the RK3568 VICAP DVP on PF5 IO Expander
- fixed formatting issues raised by media-ci bot
- Link to v2: https://lore.kernel.org/r/20241217-v6-8-topic-rk3568-vicap-v2-0-b1d488fcc0d3@wolfvision.net

Changes in v2:
- merged with Mehdi's v13
- refactored the complete driver towards a media controller centric driver
- abstracted the generic ping-pong stream (can be used for DVP as well as for CSI-2)
- switched to MPLANE API
- added support for notifications
- Link to v1: https://lore.kernel.org/r/20240220-v6-8-topic-rk3568-vicap-v1-0-2680a1fa640b@wolfvision.net

---
Mehdi Djait (2):
      media: dt-bindings: add rockchip px30 vip
      arm64: dts: rockchip: add the vip node to px30

Michael Riesch (16):
      Documentation: admin-guide: media: add rockchip camera interface
      media: dt-bindings: video-interfaces: add defines for sampling modes
      media: dt-bindings: add rockchip rk3568 vicap
      media: dt-bindings: add rockchip rk3568 mipi csi-2 receiver
      media: rockchip: add driver for the rockchip mipi csi-2 receiver
      media: rockchip: add driver for the rockchip camera interface
      media: rockchip: rkcif: add abstraction for interface and crop blocks
      media: rockchip: rkcif: add abstraction for dma blocks
      media: rockchip: rkcif: add support for px30 vip dvp capture
      media: rockchip: rkcif: add support for rk3568 vicap dvp capture
      media: rockchip: rkcif: add support for rk3568 vicap mipi capture
      arm64: defconfig: enable rockchip camera interface and mipi csi-2 receiver
      arm64: dts: rockchip: add vicap node to rk356x
      arm64: dts: rockchip: add mipi csi-2 receiver node to rk356x
      arm64: dts: rockchip: enable vicap dvp on wolfvision pf5 io expander
      arm64: dts: rockchip: add radxa camera 8m on rock 3a csi port

 .../admin-guide/media/rkcif-rk3568-vicap.dot       |  21 +
 Documentation/admin-guide/media/rkcif.rst          |  83 ++
 Documentation/admin-guide/media/v4l-drivers.rst    |   1 +
 .../bindings/media/rockchip,px30-vip.yaml          | 124 +++
 .../bindings/media/rockchip,rk3568-mipi-csi.yaml   | 146 ++++
 .../bindings/media/rockchip,rk3568-vicap.yaml      | 172 ++++
 MAINTAINERS                                        |  17 +
 arch/arm64/boot/dts/rockchip/Makefile              |   5 +
 arch/arm64/boot/dts/rockchip/px30.dtsi             |  12 +
 .../dts/rockchip/rk3568-rock-3a-radxa-cam8m.dtso   | 103 +++
 .../rk3568-wolfvision-pf5-io-expander.dtso         |  20 +
 arch/arm64/boot/dts/rockchip/rk356x-base.dtsi      |  78 ++
 arch/arm64/configs/defconfig                       |   2 +
 drivers/media/platform/rockchip/Kconfig            |   2 +
 drivers/media/platform/rockchip/Makefile           |   2 +
 drivers/media/platform/rockchip/rkcif/Kconfig      |  18 +
 drivers/media/platform/rockchip/rkcif/Makefile     |   8 +
 .../platform/rockchip/rkcif/rkcif-capture-dvp.c    | 865 +++++++++++++++++++++
 .../platform/rockchip/rkcif/rkcif-capture-dvp.h    |  25 +
 .../platform/rockchip/rkcif/rkcif-capture-mipi.c   | 777 ++++++++++++++++++
 .../platform/rockchip/rkcif/rkcif-capture-mipi.h   |  23 +
 .../media/platform/rockchip/rkcif/rkcif-common.h   | 250 ++++++
 drivers/media/platform/rockchip/rkcif/rkcif-dev.c  | 303 ++++++++
 .../platform/rockchip/rkcif/rkcif-interface.c      | 442 +++++++++++
 .../platform/rockchip/rkcif/rkcif-interface.h      |  31 +
 drivers/media/platform/rockchip/rkcif/rkcif-regs.h | 153 ++++
 .../media/platform/rockchip/rkcif/rkcif-stream.c   | 638 +++++++++++++++
 .../media/platform/rockchip/rkcif/rkcif-stream.h   |  32 +
 drivers/media/platform/rockchip/rkcsi/Kconfig      |  16 +
 drivers/media/platform/rockchip/rkcsi/Makefile     |   3 +
 drivers/media/platform/rockchip/rkcsi/rkcsi.c      | 742 ++++++++++++++++++
 include/dt-bindings/media/video-interfaces.h       |   4 +
 32 files changed, 5118 insertions(+)
---
base-commit: ea299a2164262ff787c9d33f46049acccd120672
change-id: 20240220-rk3568-vicap-b9b3f9925f44

Best regards,
-- 
Michael Riesch <michael.riesch@collabora.com>

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Sakari Ailus 3 months ago

Hi Michael,

On Fri, Oct 24, 2025 at 02:51:29PM +0200, Michael Riesch via B4 Relay wrote:
> Habidere,
> 
> This series introduces support for the Rockchip Camera Interface (CIF),
> which is featured in many Rockchip SoCs in different variations.
> For example, the PX30 Video Input Processor (VIP) is able to receive
> video data via the Digital Video Port (DVP, a parallel data interface)
> and transfer it into system memory using a double-buffering mechanism
> called ping-pong mode.
> The RK3568 Video Capture (VICAP) unit, on the other hand, features a
> DVP and a MIPI CSI-2 receiver that can receive video data independently
> (both using the ping-pong scheme).
> The different variants may have additional features, such as scaling
> and/or cropping.
> Finally, the RK3588 VICAP unit constitutes an essential piece of the
> camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
> units, and a data path multiplexer (to scaler units, to ISP, ...).

I understand both RK3568 and RK3588 include an ISP. Do you have insight on
how would this work, should the support for the ISP be added later on?

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Michael Riesch 3 months ago

Hi Sakari,

On 11/7/25 18:32, Sakari Ailus wrote:
> Hi Michael,
> 
> On Fri, Oct 24, 2025 at 02:51:29PM +0200, Michael Riesch via B4 Relay wrote:
>> Habidere,
>>
>> This series introduces support for the Rockchip Camera Interface (CIF),
>> which is featured in many Rockchip SoCs in different variations.
>> For example, the PX30 Video Input Processor (VIP) is able to receive
>> video data via the Digital Video Port (DVP, a parallel data interface)
>> and transfer it into system memory using a double-buffering mechanism
>> called ping-pong mode.
>> The RK3568 Video Capture (VICAP) unit, on the other hand, features a
>> DVP and a MIPI CSI-2 receiver that can receive video data independently
>> (both using the ping-pong scheme).
>> The different variants may have additional features, such as scaling
>> and/or cropping.
>> Finally, the RK3588 VICAP unit constitutes an essential piece of the
>> camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
>> units, and a data path multiplexer (to scaler units, to ISP, ...).
> 
> I understand both RK3568 and RK3588 include an ISP. Do you have insight on
> how would this work, should the support for the ISP be added later on?
> 

Short answer: Yes and yes.

Long answer:

The patch series at hand adds support for the PX30 VIP and the RK3568
VICAP. I cannot really say something about the PX30, but on the RK3568
VICAP and ISP are orthogonal (the ISP features its own MIPI CSI-2
receiver, different from that introduced in this series). Thus, ISP
support can be introduced anytime (whenever someone is motivated ;-)).

Once this patch series is merged, I'll push out changes that introduce
support for the RK3588 VICAP. We can discuss the integration of any
RK3588 ISP in this scope then -- and there may be some things to discuss
as there the VICAP and the ISP(s) are directly connected by means of a
MUX unit in the VICAP.

Alright?

Best regards,
Michael

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Laurent Pinchart 3 months ago

On Fri, Nov 07, 2025 at 07:41:59PM +0100, Michael Riesch wrote:
> On 11/7/25 18:32, Sakari Ailus wrote:
> > On Fri, Oct 24, 2025 at 02:51:29PM +0200, Michael Riesch via B4 Relay wrote:
> >> Habidere,
> >>
> >> This series introduces support for the Rockchip Camera Interface (CIF),
> >> which is featured in many Rockchip SoCs in different variations.
> >> For example, the PX30 Video Input Processor (VIP) is able to receive
> >> video data via the Digital Video Port (DVP, a parallel data interface)
> >> and transfer it into system memory using a double-buffering mechanism
> >> called ping-pong mode.
> >> The RK3568 Video Capture (VICAP) unit, on the other hand, features a
> >> DVP and a MIPI CSI-2 receiver that can receive video data independently
> >> (both using the ping-pong scheme).
> >> The different variants may have additional features, such as scaling
> >> and/or cropping.
> >> Finally, the RK3588 VICAP unit constitutes an essential piece of the
> >> camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
> >> units, and a data path multiplexer (to scaler units, to ISP, ...).
> > 
> > I understand both RK3568 and RK3588 include an ISP. Do you have insight on
> > how would this work, should the support for the ISP be added later on?
> 
> Short answer: Yes and yes.
> 
> Long answer:
> 
> The patch series at hand adds support for the PX30 VIP and the RK3568
> VICAP. I cannot really say something about the PX30, but on the RK3568
> VICAP and ISP are orthogonal (the ISP features its own MIPI CSI-2
> receiver, different from that introduced in this series). Thus, ISP
> support can be introduced anytime (whenever someone is motivated ;-)).

Won't they both be connected to the same sensor though, and probably the
same D-PHY in the SoC ? They don't seem entirely separate to me.

A block diagram that shows connections between the CSI-2 pins, D-PHY,
CSI-2 receivers, VICAP and ISP could help.

> Once this patch series is merged, I'll push out changes that introduce
> support for the RK3588 VICAP. We can discuss the integration of any
> RK3588 ISP in this scope then -- and there may be some things to discuss
> as there the VICAP and the ISP(s) are directly connected by means of a
> MUX unit in the VICAP.
> 
> Alright?

-- 
Regards,

Laurent Pinchart

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Michael Riesch 3 months ago

Hi Laurent,

On 11/7/25 19:54, Laurent Pinchart wrote:
> On Fri, Nov 07, 2025 at 07:41:59PM +0100, Michael Riesch wrote:
>> On 11/7/25 18:32, Sakari Ailus wrote:
>>> On Fri, Oct 24, 2025 at 02:51:29PM +0200, Michael Riesch via B4 Relay wrote:
>>>> Habidere,
>>>>
>>>> This series introduces support for the Rockchip Camera Interface (CIF),
>>>> which is featured in many Rockchip SoCs in different variations.
>>>> For example, the PX30 Video Input Processor (VIP) is able to receive
>>>> video data via the Digital Video Port (DVP, a parallel data interface)
>>>> and transfer it into system memory using a double-buffering mechanism
>>>> called ping-pong mode.
>>>> The RK3568 Video Capture (VICAP) unit, on the other hand, features a
>>>> DVP and a MIPI CSI-2 receiver that can receive video data independently
>>>> (both using the ping-pong scheme).
>>>> The different variants may have additional features, such as scaling
>>>> and/or cropping.
>>>> Finally, the RK3588 VICAP unit constitutes an essential piece of the
>>>> camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
>>>> units, and a data path multiplexer (to scaler units, to ISP, ...).
>>>
>>> I understand both RK3568 and RK3588 include an ISP. Do you have insight on
>>> how would this work, should the support for the ISP be added later on?
>>
>> Short answer: Yes and yes.
>>
>> Long answer:
>>
>> The patch series at hand adds support for the PX30 VIP and the RK3568
>> VICAP. I cannot really say something about the PX30, but on the RK3568
>> VICAP and ISP are orthogonal (the ISP features its own MIPI CSI-2
>> receiver, different from that introduced in this series). Thus, ISP
>> support can be introduced anytime (whenever someone is motivated ;-)).
> 
> Won't they both be connected to the same sensor though, and probably the
> same D-PHY in the SoC ? They don't seem entirely separate to me.

The MIPI CSI-2 DPHY is shared, indeed. Thus, they *maybe technically
could be* connected to the same sensor, but I don't know whether that
works and fail to see why anyone would to such a thing (if it is about
raw capture, the MIPI CSI-2 receiver in the ISP can do that on its own).

The DPHY can be operated in split mode, with two lanes for VICAP and two
lanes for ISP. This is not implemented yet, but can be done at a later
stage on PHY level (not media related). In this case, ISP and VICAP can
receive data from different subdevices via CSI-2.

BTW the ISP is able to process the data captured by VICAP, but
apparently this includes a RAM round trip (VICAP captures to memory, ISP
operates in mem2mem mode).

> A block diagram that shows connections between the CSI-2 pins, D-PHY,
> CSI-2 receivers, VICAP and ISP could help.
> 
>> Once this patch series is merged, I'll push out changes that introduce
>> support for the RK3588 VICAP. We can discuss the integration of any
>> RK3588 ISP in this scope then -- and there may be some things to discuss
>> as there the VICAP and the ISP(s) are directly connected by means of a
>> MUX unit in the VICAP.
>>
>> Alright?
> 

Best regards,
Michael

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Sakari Ailus 2 months, 4 weeks ago

Hi Michael, Laurent,

On Fri, Nov 07, 2025 at 09:51:37PM +0100, Michael Riesch wrote:
> Hi Laurent,
> 
> On 11/7/25 19:54, Laurent Pinchart wrote:
> > On Fri, Nov 07, 2025 at 07:41:59PM +0100, Michael Riesch wrote:
> >> On 11/7/25 18:32, Sakari Ailus wrote:
> >>> On Fri, Oct 24, 2025 at 02:51:29PM +0200, Michael Riesch via B4 Relay wrote:
> >>>> Habidere,
> >>>>
> >>>> This series introduces support for the Rockchip Camera Interface (CIF),
> >>>> which is featured in many Rockchip SoCs in different variations.
> >>>> For example, the PX30 Video Input Processor (VIP) is able to receive
> >>>> video data via the Digital Video Port (DVP, a parallel data interface)
> >>>> and transfer it into system memory using a double-buffering mechanism
> >>>> called ping-pong mode.
> >>>> The RK3568 Video Capture (VICAP) unit, on the other hand, features a
> >>>> DVP and a MIPI CSI-2 receiver that can receive video data independently
> >>>> (both using the ping-pong scheme).
> >>>> The different variants may have additional features, such as scaling
> >>>> and/or cropping.
> >>>> Finally, the RK3588 VICAP unit constitutes an essential piece of the
> >>>> camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
> >>>> units, and a data path multiplexer (to scaler units, to ISP, ...).
> >>>
> >>> I understand both RK3568 and RK3588 include an ISP. Do you have insight on
> >>> how would this work, should the support for the ISP be added later on?
> >>
> >> Short answer: Yes and yes.
> >>
> >> Long answer:
> >>
> >> The patch series at hand adds support for the PX30 VIP and the RK3568
> >> VICAP. I cannot really say something about the PX30, but on the RK3568
> >> VICAP and ISP are orthogonal (the ISP features its own MIPI CSI-2
> >> receiver, different from that introduced in this series). Thus, ISP
> >> support can be introduced anytime (whenever someone is motivated ;-)).
> > 
> > Won't they both be connected to the same sensor though, and probably the
> > same D-PHY in the SoC ? They don't seem entirely separate to me.
> 
> The MIPI CSI-2 DPHY is shared, indeed. Thus, they *maybe technically
> could be* connected to the same sensor, but I don't know whether that
> works and fail to see why anyone would to such a thing (if it is about
> raw capture, the MIPI CSI-2 receiver in the ISP can do that on its own).
> 
> The DPHY can be operated in split mode, with two lanes for VICAP and two
> lanes for ISP. This is not implemented yet, but can be done at a later
> stage on PHY level (not media related). In this case, ISP and VICAP can
> receive data from different subdevices via CSI-2.

The two would be part of the same media graph in that case and as there are
two CSI-2 receivers and a single PHY, the PHY would probably need to have a
sub-device as well, to allow link configuration to be used to select where
the PHY is connected.

I don't think we have such a setup elsewhere, and supporting this would
require changes in the MC framework.

How does the media graph look like for the device at the moment?

> 
> BTW the ISP is able to process the data captured by VICAP, but
> apparently this includes a RAM round trip (VICAP captures to memory, ISP
> operates in mem2mem mode).
> 
> > A block diagram that shows connections between the CSI-2 pins, D-PHY,
> > CSI-2 receivers, VICAP and ISP could help.
> > 
> >> Once this patch series is merged, I'll push out changes that introduce
> >> support for the RK3588 VICAP. We can discuss the integration of any
> >> RK3588 ISP in this scope then -- and there may be some things to discuss
> >> as there the VICAP and the ISP(s) are directly connected by means of a
> >> MUX unit in the VICAP.
> >>
> >> Alright?
> > 

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Michael Riesch 2 months, 4 weeks ago

Hi Sakari,

On 11/10/25 09:43, Sakari Ailus wrote:
> Hi Michael, Laurent,
> 
> On Fri, Nov 07, 2025 at 09:51:37PM +0100, Michael Riesch wrote:
>> Hi Laurent,
>>
>> On 11/7/25 19:54, Laurent Pinchart wrote:
>>> On Fri, Nov 07, 2025 at 07:41:59PM +0100, Michael Riesch wrote:
>>>> On 11/7/25 18:32, Sakari Ailus wrote:
>>>>> On Fri, Oct 24, 2025 at 02:51:29PM +0200, Michael Riesch via B4 Relay wrote:
>>>>>> Habidere,
>>>>>>
>>>>>> This series introduces support for the Rockchip Camera Interface (CIF),
>>>>>> which is featured in many Rockchip SoCs in different variations.
>>>>>> For example, the PX30 Video Input Processor (VIP) is able to receive
>>>>>> video data via the Digital Video Port (DVP, a parallel data interface)
>>>>>> and transfer it into system memory using a double-buffering mechanism
>>>>>> called ping-pong mode.
>>>>>> The RK3568 Video Capture (VICAP) unit, on the other hand, features a
>>>>>> DVP and a MIPI CSI-2 receiver that can receive video data independently
>>>>>> (both using the ping-pong scheme).
>>>>>> The different variants may have additional features, such as scaling
>>>>>> and/or cropping.
>>>>>> Finally, the RK3588 VICAP unit constitutes an essential piece of the
>>>>>> camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
>>>>>> units, and a data path multiplexer (to scaler units, to ISP, ...).
>>>>>
>>>>> I understand both RK3568 and RK3588 include an ISP. Do you have insight on
>>>>> how would this work, should the support for the ISP be added later on?
>>>>
>>>> Short answer: Yes and yes.
>>>>
>>>> Long answer:
>>>>
>>>> The patch series at hand adds support for the PX30 VIP and the RK3568
>>>> VICAP. I cannot really say something about the PX30, but on the RK3568
>>>> VICAP and ISP are orthogonal (the ISP features its own MIPI CSI-2
>>>> receiver, different from that introduced in this series). Thus, ISP
>>>> support can be introduced anytime (whenever someone is motivated ;-)).
>>>
>>> Won't they both be connected to the same sensor though, and probably the
>>> same D-PHY in the SoC ? They don't seem entirely separate to me.
>>
>> The MIPI CSI-2 DPHY is shared, indeed. Thus, they *maybe technically
>> could be* connected to the same sensor, but I don't know whether that
>> works and fail to see why anyone would to such a thing (if it is about
>> raw capture, the MIPI CSI-2 receiver in the ISP can do that on its own).
>>
>> The DPHY can be operated in split mode, with two lanes for VICAP and two
>> lanes for ISP. This is not implemented yet, but can be done at a later
>> stage on PHY level (not media related). In this case, ISP and VICAP can
>> receive data from different subdevices via CSI-2.
> 
> The two would be part of the same media graph in that case and as there are
> two CSI-2 receivers and a single PHY, the PHY would probably need to have a
> sub-device as well, to allow link configuration to be used to select where
> the PHY is connected.
> 
> I don't think we have such a setup elsewhere, and supporting this would
> require changes in the MC framework.

What follows is a response that also addresses issues raised during our
off-list discussion.

First of all, I agree with you that the RK3568 HW is "a bit special" (to
say the least) in that regard. Let's have an outlook to newer SoCs, such
as the RK3588: Here, the MIPI CSI-2 DPHYs (there are two of them) with
their split mode are present as well, but the assignment is fixed. For
example, the RK3588 VICAP has six MIPI CSI-2 receiver units and six MIPI
CSI-2 capture units. Units 1 and 2 handle a different MIPI PHY, units 3
and 5 handle the DPHYs (without split mode), units 4 and/or 6 are active
whenever DPHY 1 and/or 2 is in split mode.

I would model this by adding support for more than one (logical) PHYs
(phy-cells = <1>;) and assigning the logical PHYs to the MIPI CSI-2
receivers. There is not really a possibility to route anything at this
point (routing is done in a MUX unit that takes the different MIPI CSI-2
receivers as inputs).

Now back to the peculiar RK3568 situation: By default the split mode of
the DPHY is off and both VICAP and ISP are able to receive the same data
(from up to four lanes) with their MIPI CSI-2 receivers (not sure
whether both can be active at the same time, though). There are two bits
in the GRF that define the lanes that ISP and VICAP receive in split
mode (lane 0/1 or lane 2/3). Not sure whether these bits are supposed to
be changed during runtime.

I would suggest modelling this on PHY level in DT, e.g., by passing
reasonable properties to the dphy node, such as
    rockchip,dphy-split-mode;
    rockchip,dphy-split-invert;
where the former activates the split mode and assigns lanes 0/1 to the
ISP and lanes 2/3 to the VICAP, and the latter inverts this assignment
(lanes 2/3 to the ISP and lanes 0/1 to the VICAP). This would facilitate
the reasonable use cases with reasonable effort.

Otherwise, to keep it perfectly general and most flexible and
everything, we would have to introduce another subdevice indeed, which
would be active on the RK3568 exclusively. Therefore, I don't see that
the PHY driver introduces this subdevice, but a specialized (syscon?)
MUX driver that deals with the RK3568 GRF bits. Something like this

                           |----------------------|     |-------------|
 Sensor A --- /2 lanes --- | lane 0/1      to ISP | --- | ISP MIPI RX |
                           |                      |     |-------------|
                           |                      |
                           |                      |     |-------------|
 Sensor B --- /2 lanes --- | lane 2/3    to VICAP | --- |VICAP MIPI RX|
                           |----------------------|     |-------------|

But IMHO this will be too much effort for corner use case that I doubt
anyone will actually use.

What do you think:
 - Let's keep the PHYs out of V4L2/MC, ok?
 - Let's model the reasonable use cases with device tree properties in
   the dphy DT node, ok?

> How does the media graph look like for the device at the moment?

Please take a look at the media graph in the documentation patch (PATCH
v14 01/18). This is without the ISP, but gives an overview of what the
RK3568 VICAP is capable of.

Best regards,
Michael

> 
>>
>> BTW the ISP is able to process the data captured by VICAP, but
>> apparently this includes a RAM round trip (VICAP captures to memory, ISP
>> operates in mem2mem mode).
>>
>>> A block diagram that shows connections between the CSI-2 pins, D-PHY,
>>> CSI-2 receivers, VICAP and ISP could help.
>>>
>>>> Once this patch series is merged, I'll push out changes that introduce
>>>> support for the RK3588 VICAP. We can discuss the integration of any
>>>> RK3588 ISP in this scope then -- and there may be some things to discuss
>>>> as there the VICAP and the ISP(s) are directly connected by means of a
>>>> MUX unit in the VICAP.
>>>>
>>>> Alright?
>>>
>

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Laurent Pinchart 2 months, 4 weeks ago

On Mon, Nov 10, 2025 at 11:29:57AM +0100, Michael Riesch wrote:
> On 11/10/25 09:43, Sakari Ailus wrote:
> > On Fri, Nov 07, 2025 at 09:51:37PM +0100, Michael Riesch wrote:
> >> On 11/7/25 19:54, Laurent Pinchart wrote:
> >>> On Fri, Nov 07, 2025 at 07:41:59PM +0100, Michael Riesch wrote:
> >>>> On 11/7/25 18:32, Sakari Ailus wrote:
> >>>>> On Fri, Oct 24, 2025 at 02:51:29PM +0200, Michael Riesch via B4 Relay wrote:
> >>>>>> Habidere,
> >>>>>>
> >>>>>> This series introduces support for the Rockchip Camera Interface (CIF),
> >>>>>> which is featured in many Rockchip SoCs in different variations.
> >>>>>> For example, the PX30 Video Input Processor (VIP) is able to receive
> >>>>>> video data via the Digital Video Port (DVP, a parallel data interface)
> >>>>>> and transfer it into system memory using a double-buffering mechanism
> >>>>>> called ping-pong mode.
> >>>>>> The RK3568 Video Capture (VICAP) unit, on the other hand, features a
> >>>>>> DVP and a MIPI CSI-2 receiver that can receive video data independently
> >>>>>> (both using the ping-pong scheme).
> >>>>>> The different variants may have additional features, such as scaling
> >>>>>> and/or cropping.
> >>>>>> Finally, the RK3588 VICAP unit constitutes an essential piece of the
> >>>>>> camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
> >>>>>> units, and a data path multiplexer (to scaler units, to ISP, ...).
> >>>>>
> >>>>> I understand both RK3568 and RK3588 include an ISP. Do you have insight on
> >>>>> how would this work, should the support for the ISP be added later on?
> >>>>
> >>>> Short answer: Yes and yes.
> >>>>
> >>>> Long answer:
> >>>>
> >>>> The patch series at hand adds support for the PX30 VIP and the RK3568
> >>>> VICAP. I cannot really say something about the PX30, but on the RK3568
> >>>> VICAP and ISP are orthogonal (the ISP features its own MIPI CSI-2
> >>>> receiver, different from that introduced in this series). Thus, ISP
> >>>> support can be introduced anytime (whenever someone is motivated ;-)).
> >>>
> >>> Won't they both be connected to the same sensor though, and probably the
> >>> same D-PHY in the SoC ? They don't seem entirely separate to me.
> >>
> >> The MIPI CSI-2 DPHY is shared, indeed. Thus, they *maybe technically
> >> could be* connected to the same sensor, but I don't know whether that
> >> works and fail to see why anyone would to such a thing (if it is about
> >> raw capture, the MIPI CSI-2 receiver in the ISP can do that on its own).
> >>
> >> The DPHY can be operated in split mode, with two lanes for VICAP and two
> >> lanes for ISP. This is not implemented yet, but can be done at a later
> >> stage on PHY level (not media related). In this case, ISP and VICAP can
> >> receive data from different subdevices via CSI-2.
> > 
> > The two would be part of the same media graph in that case and as there are
> > two CSI-2 receivers and a single PHY, the PHY would probably need to have a
> > sub-device as well, to allow link configuration to be used to select where
> > the PHY is connected.
> > 
> > I don't think we have such a setup elsewhere, and supporting this would
> > require changes in the MC framework.
> 
> What follows is a response that also addresses issues raised during our
> off-list discussion.
> 
> First of all, I agree with you that the RK3568 HW is "a bit special" (to
> say the least) in that regard. Let's have an outlook to newer SoCs, such
> as the RK3588: Here, the MIPI CSI-2 DPHYs (there are two of them) with
> their split mode are present as well, but the assignment is fixed. For
> example, the RK3588 VICAP has six MIPI CSI-2 receiver units and six MIPI
> CSI-2 capture units. Units 1 and 2 handle a different MIPI PHY, units 3
> and 5 handle the DPHYs (without split mode), units 4 and/or 6 are active
> whenever DPHY 1 and/or 2 is in split mode.
> 
> I would model this by adding support for more than one (logical) PHYs
> (phy-cells = <1>;) and assigning the logical PHYs to the MIPI CSI-2
> receivers. There is not really a possibility to route anything at this
> point (routing is done in a MUX unit that takes the different MIPI CSI-2
> receivers as inputs).
> 
> Now back to the peculiar RK3568 situation: By default the split mode of
> the DPHY is off and both VICAP and ISP are able to receive the same data
> (from up to four lanes) with their MIPI CSI-2 receivers (not sure
> whether both can be active at the same time, though).

A common use case for capturing data from the same sensor through both
ISP and VICAP would be routing image data to the ISP and embedded data
to VICAP. Assuming the hardware is able to do this, there will be users
interested in this feature.

> There are two bits
> in the GRF that define the lanes that ISP and VICAP receive in split
> mode (lane 0/1 or lane 2/3). Not sure whether these bits are supposed to
> be changed during runtime.
> 
> I would suggest modelling this on PHY level in DT, e.g., by passing
> reasonable properties to the dphy node, such as
>     rockchip,dphy-split-mode;

Split mode should indeed be conveyed through DT, as it's a property of
the hardware.

>     rockchip,dphy-split-invert;
> where the former activates the split mode and assigns lanes 0/1 to the
> ISP and lanes 2/3 to the VICAP, and the latter inverts this assignment
> (lanes 2/3 to the ISP and lanes 0/1 to the VICAP). This would facilitate
> the reasonable use cases with reasonable effort.

This I'm less convinced about. The routing should be dynamic.

How do you envision the connections to the CSI-2 sources to be modelled
in DT ? We need ports and endpoints, and data-lanes properties. Where
would those reside on the RK3568 side ?

> Otherwise, to keep it perfectly general and most flexible and
> everything, we would have to introduce another subdevice indeed, which
> would be active on the RK3568 exclusively. Therefore, I don't see that
> the PHY driver introduces this subdevice, but a specialized (syscon?)
> MUX driver that deals with the RK3568 GRF bits. Something like this
> 
>                            |----------------------|     |-------------|
>  Sensor A --- /2 lanes --- | lane 0/1      to ISP | --- | ISP MIPI RX |
>                            |                      |     |-------------|
>                            |                      |
>                            |                      |     |-------------|
>  Sensor B --- /2 lanes --- | lane 2/3    to VICAP | --- |VICAP MIPI RX|
>                            |----------------------|     |-------------|
> 
> But IMHO this will be too much effort for corner use case that I doubt
> anyone will actually use.
> 
> What do you think:
>  - Let's keep the PHYs out of V4L2/MC, ok?
>  - Let's model the reasonable use cases with device tree properties in
>    the dphy DT node, ok?

I think the routing should be dynamic.

> > How does the media graph look like for the device at the moment?
> 
> Please take a look at the media graph in the documentation patch (PATCH
> v14 01/18). This is without the ISP, but gives an overview of what the
> RK3568 VICAP is capable of.
> 
> Best regards,
> Michael
> 
> >> BTW the ISP is able to process the data captured by VICAP, but
> >> apparently this includes a RAM round trip (VICAP captures to memory, ISP
> >> operates in mem2mem mode).
> >>
> >>> A block diagram that shows connections between the CSI-2 pins, D-PHY,
> >>> CSI-2 receivers, VICAP and ISP could help.
> >>>
> >>>> Once this patch series is merged, I'll push out changes that introduce
> >>>> support for the RK3588 VICAP. We can discuss the integration of any
> >>>> RK3588 ISP in this scope then -- and there may be some things to discuss
> >>>> as there the VICAP and the ISP(s) are directly connected by means of a
> >>>> MUX unit in the VICAP.
> >>>>
> >>>> Alright?

-- 
Regards,

Laurent Pinchart

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Michael Riesch 2 months, 4 weeks ago

Hi Laurent,

On 11/11/25 01:06, Laurent Pinchart wrote:
> On Mon, Nov 10, 2025 at 11:29:57AM +0100, Michael Riesch wrote:
>> On 11/10/25 09:43, Sakari Ailus wrote:
>>> On Fri, Nov 07, 2025 at 09:51:37PM +0100, Michael Riesch wrote:
>>>> On 11/7/25 19:54, Laurent Pinchart wrote:
>>>>> On Fri, Nov 07, 2025 at 07:41:59PM +0100, Michael Riesch wrote:
>>>>>> On 11/7/25 18:32, Sakari Ailus wrote:
>>>>>>> On Fri, Oct 24, 2025 at 02:51:29PM +0200, Michael Riesch via B4 Relay wrote:
>>>>>>>> Habidere,
>>>>>>>>
>>>>>>>> This series introduces support for the Rockchip Camera Interface (CIF),
>>>>>>>> which is featured in many Rockchip SoCs in different variations.
>>>>>>>> For example, the PX30 Video Input Processor (VIP) is able to receive
>>>>>>>> video data via the Digital Video Port (DVP, a parallel data interface)
>>>>>>>> and transfer it into system memory using a double-buffering mechanism
>>>>>>>> called ping-pong mode.
>>>>>>>> The RK3568 Video Capture (VICAP) unit, on the other hand, features a
>>>>>>>> DVP and a MIPI CSI-2 receiver that can receive video data independently
>>>>>>>> (both using the ping-pong scheme).
>>>>>>>> The different variants may have additional features, such as scaling
>>>>>>>> and/or cropping.
>>>>>>>> Finally, the RK3588 VICAP unit constitutes an essential piece of the
>>>>>>>> camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
>>>>>>>> units, and a data path multiplexer (to scaler units, to ISP, ...).
>>>>>>>
>>>>>>> I understand both RK3568 and RK3588 include an ISP. Do you have insight on
>>>>>>> how would this work, should the support for the ISP be added later on?
>>>>>>
>>>>>> Short answer: Yes and yes.
>>>>>>
>>>>>> Long answer:
>>>>>>
>>>>>> The patch series at hand adds support for the PX30 VIP and the RK3568
>>>>>> VICAP. I cannot really say something about the PX30, but on the RK3568
>>>>>> VICAP and ISP are orthogonal (the ISP features its own MIPI CSI-2
>>>>>> receiver, different from that introduced in this series). Thus, ISP
>>>>>> support can be introduced anytime (whenever someone is motivated ;-)).
>>>>>
>>>>> Won't they both be connected to the same sensor though, and probably the
>>>>> same D-PHY in the SoC ? They don't seem entirely separate to me.
>>>>
>>>> The MIPI CSI-2 DPHY is shared, indeed. Thus, they *maybe technically
>>>> could be* connected to the same sensor, but I don't know whether that
>>>> works and fail to see why anyone would to such a thing (if it is about
>>>> raw capture, the MIPI CSI-2 receiver in the ISP can do that on its own).
>>>>
>>>> The DPHY can be operated in split mode, with two lanes for VICAP and two
>>>> lanes for ISP. This is not implemented yet, but can be done at a later
>>>> stage on PHY level (not media related). In this case, ISP and VICAP can
>>>> receive data from different subdevices via CSI-2.
>>>
>>> The two would be part of the same media graph in that case and as there are
>>> two CSI-2 receivers and a single PHY, the PHY would probably need to have a
>>> sub-device as well, to allow link configuration to be used to select where
>>> the PHY is connected.
>>>
>>> I don't think we have such a setup elsewhere, and supporting this would
>>> require changes in the MC framework.
>>
>> What follows is a response that also addresses issues raised during our
>> off-list discussion.
>>
>> First of all, I agree with you that the RK3568 HW is "a bit special" (to
>> say the least) in that regard. Let's have an outlook to newer SoCs, such
>> as the RK3588: Here, the MIPI CSI-2 DPHYs (there are two of them) with
>> their split mode are present as well, but the assignment is fixed. For
>> example, the RK3588 VICAP has six MIPI CSI-2 receiver units and six MIPI
>> CSI-2 capture units. Units 1 and 2 handle a different MIPI PHY, units 3
>> and 5 handle the DPHYs (without split mode), units 4 and/or 6 are active
>> whenever DPHY 1 and/or 2 is in split mode.
>>
>> I would model this by adding support for more than one (logical) PHYs
>> (phy-cells = <1>;) and assigning the logical PHYs to the MIPI CSI-2
>> receivers. There is not really a possibility to route anything at this
>> point (routing is done in a MUX unit that takes the different MIPI CSI-2
>> receivers as inputs).
>>
>> Now back to the peculiar RK3568 situation: By default the split mode of
>> the DPHY is off and both VICAP and ISP are able to receive the same data
>> (from up to four lanes) with their MIPI CSI-2 receivers (not sure
>> whether both can be active at the same time, though).
> 
> A common use case for capturing data from the same sensor through both
> ISP and VICAP would be routing image data to the ISP and embedded data
> to VICAP. Assuming the hardware is able to do this, there will be users
> interested in this feature.

VICAP and ISP would capture different CSI-2 links. AFAIK the embedded
data is usually transmitted on the same CSI-2 link but on a different
virtual channel. The MIPI CSI receiver in the ISP is capable of
capturing (up to three, I think) virtual channels and passing e.g. one
VC to the ISP and capturing another VC to memory.

>> There are two bits
>> in the GRF that define the lanes that ISP and VICAP receive in split
>> mode (lane 0/1 or lane 2/3). Not sure whether these bits are supposed to
>> be changed during runtime.
>>
>> I would suggest modelling this on PHY level in DT, e.g., by passing
>> reasonable properties to the dphy node, such as
>>     rockchip,dphy-split-mode;
> 
> Split mode should indeed be conveyed through DT, as it's a property of
> the hardware.

Ack!

> 
>>     rockchip,dphy-split-invert;
>> where the former activates the split mode and assigns lanes 0/1 to the
>> ISP and lanes 2/3 to the VICAP, and the latter inverts this assignment
>> (lanes 2/3 to the ISP and lanes 0/1 to the VICAP). This would facilitate
>> the reasonable use cases with reasonable effort.
> 
> This I'm less convinced about. The routing should be dynamic.

Ack.

> How do you envision the connections to the CSI-2 sources to be modelled
> in DT ? We need ports and endpoints, and data-lanes properties. Where
> would those reside on the RK3568 side ?

Goto ASCII sketch below for that...

>> Otherwise, to keep it perfectly general and most flexible and
>> everything, we would have to introduce another subdevice indeed, which
>> would be active on the RK3568 exclusively. Therefore, I don't see that
>> the PHY driver introduces this subdevice, but a specialized (syscon?)
>> MUX driver that deals with the RK3568 GRF bits. Something like this
>>
>>                            |----------------------|     |-------------|
>>  Sensor A --- /2 lanes --- | lane 0/1      to ISP | --- | ISP MIPI RX |
>>                            |                      |     |-------------|
>>                            |                      |
>>                            |                      |     |-------------|
>>  Sensor B --- /2 lanes --- | lane 2/3    to VICAP | --- |VICAP MIPI RX|
>>                            |----------------------|     |-------------|
>>
>> But IMHO this will be too much effort for corner use case that I doubt
>> anyone will actually use.
>>
>> What do you think:
>>  - Let's keep the PHYs out of V4L2/MC, ok?
>>  - Let's model the reasonable use cases with device tree properties in
>>    the dphy DT node, ok?
> 
> I think the routing should be dynamic.

In this case, my suggestion would be the following:

 - An additional MUX subdevice on the RK3568 only, see sketch above
 - One or two input ports (depending on split mode being activated)
 - Two output ports (to ISP MIPI RX, to VICAP MIPI RX)
 - Routing possible 1:N (both input ports can be connected to one or two
   output ports)
 - The subdevice will have ports, endpoints, data-lanes properties on
   both sides.

The nice thing about it is that the current state can be extended once
split mode is implemented, IOW patches 01/18 - 17/18 can be readily applied.

Patch 18/18 must not be applied at this time, as this would be the first
actual usage of the MIPI CSI-2 pipeline. I guess we need to implement
and insert the new subdevice first for the sake of uAPI compatibility.

So pretty-please-with-sugar-on-top can we merge 01-17 so that I don't
have to drag these patches along anymore?

Best regards,
Michael

> 
>>> How does the media graph look like for the device at the moment?
>>
>> Please take a look at the media graph in the documentation patch (PATCH
>> v14 01/18). This is without the ISP, but gives an overview of what the
>> RK3568 VICAP is capable of.
>>
>> Best regards,
>> Michael
>>
>>>> BTW the ISP is able to process the data captured by VICAP, but
>>>> apparently this includes a RAM round trip (VICAP captures to memory, ISP
>>>> operates in mem2mem mode).
>>>>
>>>>> A block diagram that shows connections between the CSI-2 pins, D-PHY,
>>>>> CSI-2 receivers, VICAP and ISP could help.
>>>>>
>>>>>> Once this patch series is merged, I'll push out changes that introduce
>>>>>> support for the RK3588 VICAP. We can discuss the integration of any
>>>>>> RK3588 ISP in this scope then -- and there may be some things to discuss
>>>>>> as there the VICAP and the ISP(s) are directly connected by means of a
>>>>>> MUX unit in the VICAP.
>>>>>>
>>>>>> Alright?
>

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Michael Riesch 2 months, 4 weeks ago

Hi Laurent,

On 11/11/25 09:37, Michael Riesch wrote:
> Hi Laurent,
> 
> On 11/11/25 01:06, Laurent Pinchart wrote:
>> On Mon, Nov 10, 2025 at 11:29:57AM +0100, Michael Riesch wrote:
>>> On 11/10/25 09:43, Sakari Ailus wrote:
>>>> On Fri, Nov 07, 2025 at 09:51:37PM +0100, Michael Riesch wrote:
>>>>> On 11/7/25 19:54, Laurent Pinchart wrote:
>>>>>> On Fri, Nov 07, 2025 at 07:41:59PM +0100, Michael Riesch wrote:
>>>>>>> On 11/7/25 18:32, Sakari Ailus wrote:
>>>>>>>> On Fri, Oct 24, 2025 at 02:51:29PM +0200, Michael Riesch via B4 Relay wrote:
>>>>>>>>> Habidere,
>>>>>>>>>
>>>>>>>>> This series introduces support for the Rockchip Camera Interface (CIF),
>>>>>>>>> which is featured in many Rockchip SoCs in different variations.
>>>>>>>>> For example, the PX30 Video Input Processor (VIP) is able to receive
>>>>>>>>> video data via the Digital Video Port (DVP, a parallel data interface)
>>>>>>>>> and transfer it into system memory using a double-buffering mechanism
>>>>>>>>> called ping-pong mode.
>>>>>>>>> The RK3568 Video Capture (VICAP) unit, on the other hand, features a
>>>>>>>>> DVP and a MIPI CSI-2 receiver that can receive video data independently
>>>>>>>>> (both using the ping-pong scheme).
>>>>>>>>> The different variants may have additional features, such as scaling
>>>>>>>>> and/or cropping.
>>>>>>>>> Finally, the RK3588 VICAP unit constitutes an essential piece of the
>>>>>>>>> camera interface with one DVP, six MIPI CSI-2 receivers, scale/crop
>>>>>>>>> units, and a data path multiplexer (to scaler units, to ISP, ...).
>>>>>>>>
>>>>>>>> I understand both RK3568 and RK3588 include an ISP. Do you have insight on
>>>>>>>> how would this work, should the support for the ISP be added later on?
>>>>>>>
>>>>>>> Short answer: Yes and yes.
>>>>>>>
>>>>>>> Long answer:
>>>>>>>
>>>>>>> The patch series at hand adds support for the PX30 VIP and the RK3568
>>>>>>> VICAP. I cannot really say something about the PX30, but on the RK3568
>>>>>>> VICAP and ISP are orthogonal (the ISP features its own MIPI CSI-2
>>>>>>> receiver, different from that introduced in this series). Thus, ISP
>>>>>>> support can be introduced anytime (whenever someone is motivated ;-)).
>>>>>>
>>>>>> Won't they both be connected to the same sensor though, and probably the
>>>>>> same D-PHY in the SoC ? They don't seem entirely separate to me.
>>>>>
>>>>> The MIPI CSI-2 DPHY is shared, indeed. Thus, they *maybe technically
>>>>> could be* connected to the same sensor, but I don't know whether that
>>>>> works and fail to see why anyone would to such a thing (if it is about
>>>>> raw capture, the MIPI CSI-2 receiver in the ISP can do that on its own).
>>>>>
>>>>> The DPHY can be operated in split mode, with two lanes for VICAP and two
>>>>> lanes for ISP. This is not implemented yet, but can be done at a later
>>>>> stage on PHY level (not media related). In this case, ISP and VICAP can
>>>>> receive data from different subdevices via CSI-2.
>>>>
>>>> The two would be part of the same media graph in that case and as there are
>>>> two CSI-2 receivers and a single PHY, the PHY would probably need to have a
>>>> sub-device as well, to allow link configuration to be used to select where
>>>> the PHY is connected.
>>>>
>>>> I don't think we have such a setup elsewhere, and supporting this would
>>>> require changes in the MC framework.
>>>
>>> What follows is a response that also addresses issues raised during our
>>> off-list discussion.
>>>
>>> First of all, I agree with you that the RK3568 HW is "a bit special" (to
>>> say the least) in that regard. Let's have an outlook to newer SoCs, such
>>> as the RK3588: Here, the MIPI CSI-2 DPHYs (there are two of them) with
>>> their split mode are present as well, but the assignment is fixed. For
>>> example, the RK3588 VICAP has six MIPI CSI-2 receiver units and six MIPI
>>> CSI-2 capture units. Units 1 and 2 handle a different MIPI PHY, units 3
>>> and 5 handle the DPHYs (without split mode), units 4 and/or 6 are active
>>> whenever DPHY 1 and/or 2 is in split mode.
>>>
>>> I would model this by adding support for more than one (logical) PHYs
>>> (phy-cells = <1>;) and assigning the logical PHYs to the MIPI CSI-2
>>> receivers. There is not really a possibility to route anything at this
>>> point (routing is done in a MUX unit that takes the different MIPI CSI-2
>>> receivers as inputs).
>>>
>>> Now back to the peculiar RK3568 situation: By default the split mode of
>>> the DPHY is off and both VICAP and ISP are able to receive the same data
>>> (from up to four lanes) with their MIPI CSI-2 receivers (not sure
>>> whether both can be active at the same time, though).
>>
>> A common use case for capturing data from the same sensor through both
>> ISP and VICAP would be routing image data to the ISP and embedded data
>> to VICAP. Assuming the hardware is able to do this, there will be users
>> interested in this feature.
> 
> VICAP and ISP would capture different CSI-2 links. AFAIK the embedded
> data is usually transmitted on the same CSI-2 link but on a different
> virtual channel. The MIPI CSI receiver in the ISP is capable of
> capturing (up to three, I think) virtual channels and passing e.g. one
> VC to the ISP and capturing another VC to memory.
> 
>>> There are two bits
>>> in the GRF that define the lanes that ISP and VICAP receive in split
>>> mode (lane 0/1 or lane 2/3). Not sure whether these bits are supposed to
>>> be changed during runtime.
>>>
>>> I would suggest modelling this on PHY level in DT, e.g., by passing
>>> reasonable properties to the dphy node, such as
>>>     rockchip,dphy-split-mode;
>>
>> Split mode should indeed be conveyed through DT, as it's a property of
>> the hardware.
> 
> Ack!
> 
>>
>>>     rockchip,dphy-split-invert;
>>> where the former activates the split mode and assigns lanes 0/1 to the
>>> ISP and lanes 2/3 to the VICAP, and the latter inverts this assignment
>>> (lanes 2/3 to the ISP and lanes 0/1 to the VICAP). This would facilitate
>>> the reasonable use cases with reasonable effort.
>>
>> This I'm less convinced about. The routing should be dynamic.
> 
> Ack.
> 
>> How do you envision the connections to the CSI-2 sources to be modelled
>> in DT ? We need ports and endpoints, and data-lanes properties. Where
>> would those reside on the RK3568 side ?
> 
> Goto ASCII sketch below for that...
> 
>>> Otherwise, to keep it perfectly general and most flexible and
>>> everything, we would have to introduce another subdevice indeed, which
>>> would be active on the RK3568 exclusively. Therefore, I don't see that
>>> the PHY driver introduces this subdevice, but a specialized (syscon?)
>>> MUX driver that deals with the RK3568 GRF bits. Something like this
>>>
>>>                            |----------------------|     |-------------|
>>>  Sensor A --- /2 lanes --- | lane 0/1      to ISP | --- | ISP MIPI RX |
>>>                            |                      |     |-------------|
>>>                            |                      |
>>>                            |                      |     |-------------|
>>>  Sensor B --- /2 lanes --- | lane 2/3    to VICAP | --- |VICAP MIPI RX|
>>>                            |----------------------|     |-------------|
>>>
>>> But IMHO this will be too much effort for corner use case that I doubt
>>> anyone will actually use.
>>>
>>> What do you think:
>>>  - Let's keep the PHYs out of V4L2/MC, ok?
>>>  - Let's model the reasonable use cases with device tree properties in
>>>    the dphy DT node, ok?
>>
>> I think the routing should be dynamic.
> 
> In this case, my suggestion would be the following:
> 
>  - An additional MUX subdevice on the RK3568 only, see sketch above
>  - One or two input ports (depending on split mode being activated)
>  - Two output ports (to ISP MIPI RX, to VICAP MIPI RX)
>  - Routing possible 1:N (both input ports can be connected to one or two
>    output ports)
>  - The subdevice will have ports, endpoints, data-lanes properties on
>    both sides.
> 
> The nice thing about it is that the current state can be extended once
> split mode is implemented, IOW patches 01/18 - 17/18 can be readily applied.
> 
> Patch 18/18 must not be applied at this time, as this would be the first
> actual usage of the MIPI CSI-2 pipeline. I guess we need to implement
> and insert the new subdevice first for the sake of uAPI compatibility.
> 
> So pretty-please-with-sugar-on-top can we merge 01-17 so that I don't
> have to drag these patches along anymore?

In an off-list chat with Sakari we found that it would make sense to
leave patches 01 and 12 away as well, in order to avoid uAPI
compatibility issues for good. The MIPI CSI-2 receiver bindings and
driver can be merged, as the only difference in the new setup will be
that on the RK3568 the receiver is connected to the new MUX subdevice,
rather than to a sensor (as will be the case on e.g. the RK3588).

Can we agree on the following plan:
 1) You shall merge patches 02/18 - 11/18 + 13/18 - 17/18.
 2) I shall add the MUX subdev and send a revised version of patches 01,
    12, 18 along with it.
 3) We shall have a solid basis to implement split mode in the DPHY
    driver, RK3568 ISP support (if anyone has time for that), and RK3588
    VICAP support.

OK for everyone? @Laurent: can we get an Ack from you?

Best regards,
Michael

> 
> Best regards,
> Michael
> 
>>
>>>> How does the media graph look like for the device at the moment?
>>>
>>> Please take a look at the media graph in the documentation patch (PATCH
>>> v14 01/18). This is without the ISP, but gives an overview of what the
>>> RK3568 VICAP is capable of.
>>>
>>> Best regards,
>>> Michael
>>>
>>>>> BTW the ISP is able to process the data captured by VICAP, but
>>>>> apparently this includes a RAM round trip (VICAP captures to memory, ISP
>>>>> operates in mem2mem mode).
>>>>>
>>>>>> A block diagram that shows connections between the CSI-2 pins, D-PHY,
>>>>>> CSI-2 receivers, VICAP and ISP could help.
>>>>>>
>>>>>>> Once this patch series is merged, I'll push out changes that introduce
>>>>>>> support for the RK3588 VICAP. We can discuss the integration of any
>>>>>>> RK3588 ISP in this scope then -- and there may be some things to discuss
>>>>>>> as there the VICAP and the ISP(s) are directly connected by means of a
>>>>>>> MUX unit in the VICAP.
>>>>>>>
>>>>>>> Alright?
>>
>

Re: [PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface

Posted by Michael Riesch 3 months, 2 weeks ago

Hi all,

On 10/24/25 14:51, Michael Riesch via B4 Relay wrote:
> Habidere,
> 
> This series introduces support for the Rockchip Camera Interface (CIF),
> which is featured in many Rockchip SoCs in different variations.
> [...]

Please find below the report of v4l2-compliance executed on my Radxa
ROCK 3A + Radxa Camera 8M setup. It should be noted that the two
warnings stem from the IMX219 driver, and apart from them no warnings
nor errors are reported.

Best regards,
Michael

$ v4l2-compliance -m /dev/media0
v4l2-compliance 1.28.1, 64 bits, 64-bit time_t

Compliance test for rockchip-cif device /dev/media0:

Media Driver Info:
	Driver name      : rockchip-cif
	Model            : rockchip-cif
	Serial           :
	Bus info         : platform:fdfe0000.video-capture
	Media version    : 6.18.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 6.18.0

Required ioctls:
	test MEDIA_IOC_DEVICE_INFO: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/media0 open: OK
	test MEDIA_IOC_DEVICE_INFO: OK
	test for unlimited opens: OK

Media Controller ioctls:
	test MEDIA_IOC_G_TOPOLOGY: OK
	Entities: 7 Interfaces: 7 Pads: 9 Links: 13
	test MEDIA_IOC_ENUM_ENTITIES/LINKS: OK
	test MEDIA_IOC_SETUP_LINK: OK

Total for rockchip-cif device /dev/media0: 8, Succeeded: 8, Failed: 0,
Warnings: 0
--------------------------------------------------------------------------------
Compliance test for rockchip-cif device /dev/video1:

Driver Info:
	Driver name      : rockchip-cif
	Card type        : rockchip-cif
	Bus info         : platform:fdfe0000.video-capture
	Driver version   : 6.18.0
	Capabilities     : 0xa4201000
		Video Capture Multiplanar
		I/O MC
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x24201000
		Video Capture Multiplanar
		I/O MC
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : rockchip-cif
	Model            : rockchip-cif
	Serial           :
	Bus info         : platform:fdfe0000.video-capture
	Media version    : 6.18.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 6.18.0
Interface Info:
	ID               : 0x03000009
	Type             : V4L Video
Entity Info:
	ID               : 0x00000007 (7)
	Name             : rkcif-mipi0-id0
	Function         : V4L2 I/O
	Pad 0x01000008   : 0: Sink
	  Link 0x0200000b: from remote pad 0x1000006 of entity 'rkcif-mipi0'
(Video Interface Bridge): Data, Enabled

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/video1 open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls (Input 0):
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
	test VIDIOC_QUERYCTRL: OK (Not Supported)
	test VIDIOC_G/S_CTRL: OK (Not Supported)
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 0 Private Controls: 0

Format ioctls (Input 0):
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK
	test VIDIOC_TRY_FMT: OK
	test VIDIOC_S_FMT: OK
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK

Codec ioctls (Input 0):
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls (Input 0):
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
	test CREATE_BUFS maximum buffers: OK
	test VIDIOC_REMOVE_BUFS: OK
	test VIDIOC_EXPBUF: OK
	test Requests: OK (Not Supported)

Total for rockchip-cif device /dev/video1: 48, Succeeded: 48, Failed: 0,
Warnings: 0
--------------------------------------------------------------------------------
Compliance test for rockchip-cif device /dev/video2:

Driver Info:
	Driver name      : rockchip-cif
	Card type        : rockchip-cif
	Bus info         : platform:fdfe0000.video-capture
	Driver version   : 6.18.0
	Capabilities     : 0xa4201000
		Video Capture Multiplanar
		I/O MC
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x24201000
		Video Capture Multiplanar
		I/O MC
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : rockchip-cif
	Model            : rockchip-cif
	Serial           :
	Bus info         : platform:fdfe0000.video-capture
	Media version    : 6.18.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 6.18.0
Interface Info:
	ID               : 0x0300000f
	Type             : V4L Video
Entity Info:
	ID               : 0x0000000d (13)
	Name             : rkcif-mipi0-id1
	Function         : V4L2 I/O
	Pad 0x0100000e   : 0: Sink
	  Link 0x02000011: from remote pad 0x1000006 of entity 'rkcif-mipi0'
(Video Interface Bridge): Data

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/video2 open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls (Input 0):
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
	test VIDIOC_QUERYCTRL: OK (Not Supported)
	test VIDIOC_G/S_CTRL: OK (Not Supported)
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 0 Private Controls: 0

Format ioctls (Input 0):
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK
	test VIDIOC_TRY_FMT: OK
	test VIDIOC_S_FMT: OK
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK

Codec ioctls (Input 0):
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls (Input 0):
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
	test CREATE_BUFS maximum buffers: OK
	test VIDIOC_REMOVE_BUFS: OK
	test VIDIOC_EXPBUF: OK
	test Requests: OK (Not Supported)

Total for rockchip-cif device /dev/video2: 48, Succeeded: 48, Failed: 0,
Warnings: 0
--------------------------------------------------------------------------------
Compliance test for rockchip-cif device /dev/video3:

Driver Info:
	Driver name      : rockchip-cif
	Card type        : rockchip-cif
	Bus info         : platform:fdfe0000.video-capture
	Driver version   : 6.18.0
	Capabilities     : 0xa4201000
		Video Capture Multiplanar
		I/O MC
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x24201000
		Video Capture Multiplanar
		I/O MC
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : rockchip-cif
	Model            : rockchip-cif
	Serial           :
	Bus info         : platform:fdfe0000.video-capture
	Media version    : 6.18.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 6.18.0
Interface Info:
	ID               : 0x03000015
	Type             : V4L Video
Entity Info:
	ID               : 0x00000013 (19)
	Name             : rkcif-mipi0-id2
	Function         : V4L2 I/O
	Pad 0x01000014   : 0: Sink
	  Link 0x02000017: from remote pad 0x1000006 of entity 'rkcif-mipi0'
(Video Interface Bridge): Data

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/video3 open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls (Input 0):
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
	test VIDIOC_QUERYCTRL: OK (Not Supported)
	test VIDIOC_G/S_CTRL: OK (Not Supported)
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 0 Private Controls: 0

Format ioctls (Input 0):
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK
	test VIDIOC_TRY_FMT: OK
	test VIDIOC_S_FMT: OK
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK

Codec ioctls (Input 0):
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls (Input 0):
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
	test CREATE_BUFS maximum buffers: OK
	test VIDIOC_REMOVE_BUFS: OK
	test VIDIOC_EXPBUF: OK
	test Requests: OK (Not Supported)

Total for rockchip-cif device /dev/video3: 48, Succeeded: 48, Failed: 0,
Warnings: 0
--------------------------------------------------------------------------------
Compliance test for rockchip-cif device /dev/video4:

Driver Info:
	Driver name      : rockchip-cif
	Card type        : rockchip-cif
	Bus info         : platform:fdfe0000.video-capture
	Driver version   : 6.18.0
	Capabilities     : 0xa4201000
		Video Capture Multiplanar
		I/O MC
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x24201000
		Video Capture Multiplanar
		I/O MC
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : rockchip-cif
	Model            : rockchip-cif
	Serial           :
	Bus info         : platform:fdfe0000.video-capture
	Media version    : 6.18.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 6.18.0
Interface Info:
	ID               : 0x0300001b
	Type             : V4L Video
Entity Info:
	ID               : 0x00000019 (25)
	Name             : rkcif-mipi0-id3
	Function         : V4L2 I/O
	Pad 0x0100001a   : 0: Sink
	  Link 0x0200001d: from remote pad 0x1000006 of entity 'rkcif-mipi0'
(Video Interface Bridge): Data

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/video4 open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls (Input 0):
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
	test VIDIOC_QUERYCTRL: OK (Not Supported)
	test VIDIOC_G/S_CTRL: OK (Not Supported)
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 0 Private Controls: 0

Format ioctls (Input 0):
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK
	test VIDIOC_TRY_FMT: OK
	test VIDIOC_S_FMT: OK
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK

Codec ioctls (Input 0):
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls (Input 0):
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
	test CREATE_BUFS maximum buffers: OK
	test VIDIOC_REMOVE_BUFS: OK
	test VIDIOC_EXPBUF: OK
	test Requests: OK (Not Supported)

Total for rockchip-cif device /dev/video4: 48, Succeeded: 48, Failed: 0,
Warnings: 0
--------------------------------------------------------------------------------
Compliance test for rockchip-cif device /dev/v4l-subdev0:

Driver Info:
	Driver version   : 6.18.0
	Capabilities     : 0x00000000
	Client Capabilities: 0x0000000000000002
interval-uses-which Media Driver Info:
	Driver name      : rockchip-cif
	Model            : rockchip-cif
	Serial           :
	Bus info         : platform:fdfe0000.video-capture
	Media version    : 6.18.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 6.18.0
Interface Info:
	ID               : 0x03000028
	Type             : V4L Sub-Device
Entity Info:
	ID               : 0x00000004 (4)
	Name             : rkcif-mipi0
	Function         : Video Interface Bridge
	Pad 0x01000005   : 0: Sink
	  Link 0x02000022: from remote pad 0x1000021 of entity
'rockchip-mipi-csi fdfb0000.csi' (Video Interface Bridge): Data, Enabled
	Pad 0x01000006   : 1: Source
	  Link 0x0200000b: to remote pad 0x1000008 of entity 'rkcif-mipi0-id0'
(V4L2 I/O): Data, Enabled
	  Link 0x02000011: to remote pad 0x100000e of entity 'rkcif-mipi0-id1'
(V4L2 I/O): Data
	  Link 0x02000017: to remote pad 0x1000014 of entity 'rkcif-mipi0-id2'
(V4L2 I/O): Data
	  Link 0x0200001d: to remote pad 0x100001a of entity 'rkcif-mipi0-id3'
(V4L2 I/O): Data

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_SUDBEV_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/v4l-subdev0 open: OK
	test VIDIOC_SUBDEV_QUERYCAP: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Sub-Device ioctls (Sink Pad 0):
	Try Stream 0
	test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
(Not Supported)
	test Try VIDIOC_SUBDEV_G/S_FMT: OK
	test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
	Active Stream 0
	test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
(Not Supported)
	test Active VIDIOC_SUBDEV_G/S_FMT: OK
	test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
	test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)

Sub-Device ioctls (Source Pad 1):
	Try Stream 0
	test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
(Not Supported)
	test Try VIDIOC_SUBDEV_G/S_FMT: OK
	test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK
	Active Stream 0
	test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
(Not Supported)
	test Active VIDIOC_SUBDEV_G/S_FMT: OK
	test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK
	test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)

Control ioctls:
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
	test VIDIOC_QUERYCTRL: OK (Not Supported)
	test VIDIOC_G/S_CTRL: OK (Not Supported)
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 0 Private Controls: 0

Format ioctls:
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK (Not Supported)
	test VIDIOC_TRY_FMT: OK (Not Supported)
	test VIDIOC_S_FMT: OK (Not Supported)
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK (Not Supported)

Codec ioctls:
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported)
	test CREATE_BUFS maximum buffers: OK
	test VIDIOC_REMOVE_BUFS: OK
	test VIDIOC_EXPBUF: OK (Not Supported)
	test Requests: OK (Not Supported)

Total for rockchip-cif device /dev/v4l-subdev0: 60, Succeeded: 60,
Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for rockchip-cif device /dev/v4l-subdev1:

Driver Info:
	Driver version   : 6.18.0
	Capabilities     : 0x00000000
	Client Capabilities: 0x0000000000000002
interval-uses-which Media Driver Info:
	Driver name      : rockchip-cif
	Model            : rockchip-cif
	Serial           :
	Bus info         : platform:fdfe0000.video-capture
	Media version    : 6.18.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 6.18.0
Interface Info:
	ID               : 0x0300002a
	Type             : V4L Sub-Device
Entity Info:
	ID               : 0x0000001f (31)
	Name             : rockchip-mipi-csi fdfb0000.csi
	Function         : Video Interface Bridge
	Pad 0x01000020   : 0: Sink, Must Connect
	  Link 0x02000026: from remote pad 0x1000025 of entity 'imx219 5-0010'
(Camera Sensor): Data, Enabled
	Pad 0x01000021   : 1: Source
	  Link 0x02000022: to remote pad 0x1000005 of entity 'rkcif-mipi0'
(Video Interface Bridge): Data, Enabled

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_SUDBEV_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/v4l-subdev1 open: OK
	test VIDIOC_SUBDEV_QUERYCAP: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Sub-Device ioctls (Sink Pad 0):
	Try Stream 0
	test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
	test Try VIDIOC_SUBDEV_G/S_FMT: OK
	test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
	Active Stream 0
	test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
	test Active VIDIOC_SUBDEV_G/S_FMT: OK
	test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
	test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)

Sub-Device ioctls (Source Pad 1):
	Try Stream 0
	test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
	test Try VIDIOC_SUBDEV_G/S_FMT: OK
	test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
	Active Stream 0
	test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
	test Active VIDIOC_SUBDEV_G/S_FMT: OK
	test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
	test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)

Control ioctls:
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
	test VIDIOC_QUERYCTRL: OK (Not Supported)
	test VIDIOC_G/S_CTRL: OK (Not Supported)
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 0 Private Controls: 0

Format ioctls:
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK (Not Supported)
	test VIDIOC_TRY_FMT: OK (Not Supported)
	test VIDIOC_S_FMT: OK (Not Supported)
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK (Not Supported)

Codec ioctls:
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported)
	test CREATE_BUFS maximum buffers: OK
	test VIDIOC_REMOVE_BUFS: OK
	test VIDIOC_EXPBUF: OK (Not Supported)
	test Requests: OK (Not Supported)

Total for rockchip-cif device /dev/v4l-subdev1: 60, Succeeded: 60,
Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for rockchip-cif device /dev/v4l-subdev2:

Driver Info:
	Driver version   : 6.18.0
	Capabilities     : 0x00000000
	Client Capabilities: 0x0000000000000002
interval-uses-which Media Driver Info:
	Driver name      : rockchip-cif
	Model            : rockchip-cif
	Serial           :
	Bus info         : platform:fdfe0000.video-capture
	Media version    : 6.18.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 6.18.0
Interface Info:
	ID               : 0x0300002c
	Type             : V4L Sub-Device
Entity Info:
	ID               : 0x00000024 (36)
	Name             : imx219 5-0010
	Function         : Camera Sensor
	Pad 0x01000025   : 0: Source
	  Link 0x02000026: to remote pad 0x1000020 of entity 'rockchip-mipi-csi
fdfb0000.csi' (Video Interface Bridge): Data, Enabled

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_SUDBEV_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/v4l-subdev2 open: OK
	test VIDIOC_SUBDEV_QUERYCAP: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Sub-Device ioctls (Source Pad 0):
	Try Stream 0
	test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
	test Try VIDIOC_SUBDEV_G/S_FMT: OK
		warn: v4l2-test-subdevs.cpp(566): VIDIOC_SUBDEV_G_SELECTION is
supported for target 0 but not VIDIOC_SUBDEV_S_SELECTION
	test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK
	Active Stream 0
	test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK
	test Active VIDIOC_SUBDEV_G/S_FMT: OK
		warn: v4l2-test-subdevs.cpp(566): VIDIOC_SUBDEV_G_SELECTION is
supported for target 0 but not VIDIOC_SUBDEV_S_SELECTION
	test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK
	test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)

Control ioctls:
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
	test VIDIOC_QUERYCTRL: OK
	test VIDIOC_G/S_CTRL: OK
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 17 Private Controls: 0

Format ioctls:
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK (Not Supported)
	test VIDIOC_TRY_FMT: OK (Not Supported)
	test VIDIOC_S_FMT: OK (Not Supported)
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK (Not Supported)

Codec ioctls:
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported)
	test CREATE_BUFS maximum buffers: OK
	test VIDIOC_REMOVE_BUFS: OK
	test VIDIOC_EXPBUF: OK (Not Supported)
	test Requests: OK (Not Supported)

Total for rockchip-cif device /dev/v4l-subdev2: 53, Succeeded: 53,
Failed: 0, Warnings: 2

Grand Total for rockchip-cif device /dev/media0: 373, Succeeded: 373,
Failed: 0, Warnings: 2