[PATCH v14 00/18] media: rockchip: add a driver for the rockchip camera interface
Sakari Ailus
sakari.ailus at linux.intel.com
Mon Nov 10 00:43:41 PST 2025
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
More information about the linux-arm-kernel
mailing list