RK3588 combo MIPI D-PHY (phy-rockchip-samsung-dcphy) + real sensor - any known-working case?

[Evan O' Keeffe]

Hi Michael, my name is Evan O'Keeffe and I'm working on the RK3588S for a new
hyperspectral camera project.

Thanks for the rkcif/VICAP work landing in 7.2 - got us most of the way to a
working camera on an Orange Pi CM5 tablet board (RK3588S). Wanted to
check something
specific before I sink more time into it.

The board's camera connector is wired (confirmed independently from two
vendor BSP devicetree files) to CSI host port 0 via the Samsung combo D-PHY
(phy-rockchip-samsung-dcphy.c / mipidcphy0), not the simple Innosilicon D-PHY
path. Sensor is a Sony IMX219, 2-lane, 456MHz link frequency (912Mbps HS
rate).

Everything I can check in software passes cleanly:
- i2c control plane confirmed solid (chip ID, MODE_SELECT, CSI_LANE_MODE,
  DPHY_CNTRL all read back correct via direct register reads during an
  active stream attempt)
- Sensor confirmed actually in streaming mode (MODE_SELECT=0x01) via
  register readback, not just assumed
- Full media pipeline validates and v4l2_subdev_enable_streams succeeds
  through the whole chain (sensor -> dw-mipi-csi2rx -> rkcif-mipi0)
- The DCPHY's PLL_LOCK status bit genuinely passes (real register poll in
  samsung_mipi_dcphy_pll_enable, not just computed math) at the exact
  target rate (912MHz, prediv=1, fbdiv=76)
- CSI2 host CONTROL register readback exactly matches what
  dw_mipi_csi2rx_start() computes and writes

But: zero interrupts ever fire on rockchip-cif's IRQ line, and ERR1/ERR2 on
the CSI2 host stay at 0x0 - total silence, not corrupted data. Hardware
itself is confirmed good (same cable/sensor works fine on the vendor BSP
kernel/driver stack).

Before I go further down the register-level rabbit hole: do you know of
any real-sensor test case that's actually exercised the combo-PHY path
(as opposed to the simple-PHY ports 2/4 that the ROCK 5B+ IMX415 testing
covered)? Everything I can find in current devicetrees that enables
mipidcphy0/1 does so with no sensor attached at all, so I can't tell if
this is a known gap, a subtle bring-up step I'm missing, or something
board-specific on my end.

Happy to share full register dumps / dmesg / devicetree if useful.

Thanks for your time
All the best

-- 
Evan O'Keeffe
Forti Et Fideli , Nihil difficile