Re: [PATCH v6 0/9] phy: rockchip-samsung-dcphy: Add the MIPI D-PHY receiver

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Jason,

On 11/10/26 9:18 AM, Jason Yang wrote:
> The Samsung MIPI D-/C-PHY block on RK3588 and RK3576 has a transmitter
> for DSI and a receiver for CSI-2. Both can be used at the same time.
> 
> Mainline only supports the transmitter and models the block as a single
> struct phy. The PHY core refcounts power_on() per struct phy, so the
> receiver cannot be powered independently of it, and the single
> devicetree cell selects the mode, so the provider cannot tell which of
> the two a consumer refers to.
> 
> This series registers a struct phy for the PHY transmitter and one for
> the PHY receiver, and implements the D-PHY receiver. As suggested in
> the v5 review, the single cell of the binding now selects the PHY
> transmitter or the PHY receiver. The cell values are the new generic
> PHY_DIRECTION_TX and PHY_DIRECTION_RX constants. The PHY transmitter
> and the PHY receiver cannot run in different modes. A phy-type property
> of the PHY node therefore sets the mode of the whole block, D-PHY by
> default.
> 
>    1/9  adds PHY_DIRECTION_TX and PHY_DIRECTION_RX to the generic header
>    2/9  changes the single cell of the rockchip,rk3588-mipi-dcphy binding
>         to select PHY_DIRECTION_TX or PHY_DIRECTION_RX, adds phy-type for
>         the mode of the whole block, and keeps PHY_TYPE_DPHY and
>         PHY_TYPE_CPHY as deprecated values
>    3/9  unwinds the PHY transmitter power-on when the PLL fails to lock
>    4/9  always writes the rate-dependent registers of the PHY transmitter
>    5/9  moves the block-level setup (APB reset, BIAS) to runtime resume
>    6/9  names the transmitter helpers and ops (no functional change)
>    7/9  takes the PHY mode from phy-type and the PHY from the cell, and
>         keeps the deprecated cell values on the PHY transmitter
>    8/9  registers the receiver's struct phy, takes PHY_DIRECTION_RX in
>         of_xlate() and implements the D-PHY receiver bring-up
>    9/9  adds the MIPI CSI-2 receiver nodes on RK3588 and connects them
>         to VICAP
> 
> 9/9 has to wait for 1/9 to 8/9. It uses PHY_DIRECTION_RX from 1/9,
> and the csi nodes need a PHY driver with receiver support.
> 
> Compatibility
> =============
> 
> In 2/9 and 7/9, the old cell values PHY_TYPE_DPHY and PHY_TYPE_CPHY
> remain valid as deprecated values. They select the PHY transmitter, so
> existing DTs keep working on a newer kernel.
> 
> New DTs following 1/9 and 2/9 are an ABI break on an older kernel. The
> older kernel ignores phy-type and takes any cell value as the mode of
> the block. A DSI node with PHY_DIRECTION_TX therefore gets no display,
> and a CSI-2 node with PHY_DIRECTION_RX gets no camera.
> 
> In 9/9, the dsi nodes keep PHY_TYPE_DPHY, which older and newer kernels
> both accept. With the csi nodes disabled, the display therefore keeps
> working on either kernel.
> 
> The csi nodes in 9/9 have no older value to keep and have to use
> PHY_DIRECTION_RX. Enabling csi0 or csi1 therefore needs a PHY driver
> with receiver support. Since v7.0, a CSI-2 host driver probes the csi
> nodes. An older PHY driver then gives the CSI-2 host the PHY transmitter
> that drives the display. The camera gets no frames, and the display can
> stop working as well.
> 
> Testing
> =======
> 
> Tested on an RK3588 board, with a DSI panel and an IMX219 camera on
> DCPHY0, and an LVDS panel behind a DSI-to-LVDS bridge on DCPHY1.
> 
>    - The PHY transmitter and the PHY receiver run at the same time: with
>      8/9 and 9/9, both panels light from boot, and the camera stream is
>      shown live on the DCPHY0 panel.
>    - The two can be powered independently: the DCPHY0 panel is turned
>      off and back on during a 1200-frame capture, and the capture
>      completes.
>    - The PHY receiver does not need the PHY transmitter: with dsi0
>      disabled, the camera alone brings the block up and streams, which
>      relies on 5/9 moving the block-level setup to runtime resume.
>    - Existing device trees keep working: with a single PHY_TYPE_DPHY
>      cell in dsi0 as before this series, the DCPHY0 panel lights.
>    - The DT of 9/9 keeps the display working on an older kernel: with
>      the csi nodes disabled and without this series, both panels light.
>    - The new cell works for the PHY transmitter: with PHY_DIRECTION_TX
>      in dsi0, with and without phy-type = <PHY_TYPE_DPHY>, the DCPHY0
>      panel lights.
> 
> No WARNING, underflow, "Internal error" or Oops in dmesg in any of
> these.
> 
> Not covered: the receiver of DCPHY1, the 3- and 4-lane receiver paths,
> and RK3576. 3/9 and 4/9 fix states found by reading the code. Those
> states were not reproduced on hardware.
> 

I can capture a frame on an RPi Camera module v2 with an IMX219 sensor 
configured in 2-lane mode, routed to the CSI part of the DCPHY1 PHY. I 
can capture a frame on an OV5675 camera sensor configured in 2-lane 
mode, routed to the CSI part of the DCPHY0, while I endlessly run "cat 
/dev/urandom > /dev/fb0" on the DSI part of DCPHY0. The noise on the 
display still "moves" while I'm capturing, as expected. Thus:

Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Tiger CSI1 
2-lane IMX219, CSI0 2-lane OV5675+DSI

> The DSI panels only light with the U-Boot SPLL fix [1] applied:

As far as I remember, this is only applicable from 2026.01-rc2 
(included) to 2027.01-rc2 (excluded). My 2025.07 downstream seems to be 
working just fine wrt to that issue.

Cheers,
Quentin