Re: [PATCH v4 1/7] dt-bindings: phy: Add PHY_TYPE_DSI and PHY_TYPE_CSI definitions

Hi Krzysztof,

Thanks for the review.

(from the review of 2/7)

Please link/show the upstream DTS using simultaneously transmitter and
receiver, where the consumer does not know with whom is it talking to.

I grepped the tree and found a device tree that has simultaneously
transmitter and receiver. In the arch/arm/boot/dts/samsung/*,
exynos4412-midas.dtsi enables csis_0, and exynos4412-galaxy-s3.dtsi, which
includes it, enables dsi_0. Both consumers are declared in exynos4.dtsi,
on the same phy node:

    dsi_0:  phys = <&mipi_phy 1>;
    csis_0: phys = <&mipi_phy 0>;

Tracing that back, the provider is
Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml and
drivers/phy/samsung/phy-exynos-mipi-video.c.
It registers several struct phy in one node, and the binding says:

      For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the
      PHY specifier identifies the PHY and its meaning is as follows::
        0 - MIPI CSIS 0,
        1 - MIPI DSIM 0,
        2 - MIPI CSIS 1,
        3 - MIPI DSIM 1.

Resuming from the cover letter in v4, I treat this phy as one tx phy and one
rx phy. Maybe I can follow this pattern and introduce phy 0 and phy 1 in
rockchip,rk3588-mipi-dcphy.yaml, and add an enum for
SAMSUNG_MIPI_DCPHY_TX/RX in the driver. The binding would then say:

      Two cells select the mode and then one of the two PHYs that the
      block contains:
        0 - the transmitter, for a MIPI DSI host
        1 - the receiver, for a MIPI CSI-2 host

      A single cell is equivalent to a second cell of 0.

In this way, I don't need to add PHY_TYPE_CSI/DSI to
include/dt-bindings/phy/phy.h.
And I think this will not go against the discussion in v2, where Michael pointed
out that DSI and CSI are standard protocols and should not be named in
a Rockchip
specific header, and suggested introducing PHY_TYPE_CSI/DSI:

How is that Rockchip specific? As you state above this is either MIPI
CSI or MIPI DSI, two perfectly standard protocols.

@all Would it be reasonable to introduce PHY_TYPE_CSI and PHY_TYPE_DSI?

https://lore.kernel.org/r/82da3622-9c3a-454c-87bc-fb4ec7adb68d@collabora.com (local)

Where is any DTS using it? I did a search and no results of upstream
posting.

The user will be rk3588-base.dtsi. It adds csi0/1, which connect back
to the existing vicap_mipi0/1 ports. It also sets #phy-cells
and the dsi consumers to the shape that comes out of this review; with v4
that would have been #phy-cells = <2> and PHY_TYPE_CSI/DSI.

I thought the dts should wait until the binding and driver were settled,
so I did not post it. I will add it in v5.

Thanks,
Jason

Krzysztof Kozlowski [off-list ref] 於 2026年8月27日週四 下午7:46寫道：

On Fri, Aug 21, 2026 at 08:02:29PM +0800, Jason Yang wrote:

quoted

A MIPI D-PHY or C-PHY can be a transmitter (DSI) or a receiver (CSI),
and in some PHY blocks both work at the same time. The existing
PHY_TYPE_DPHY and PHY_TYPE_CPHY cannot tell whether a consumer wants
the transmitter or the receiver.

The consumer knows this already, no? Imagine consumer of the phy is some
ISP receiving data over CSI for given port, thus consumer cannot
transmit over that link.

All this seems redundant.

quoted

Add PHY_TYPE_DSI and PHY_TYPE_CSI, so that a binding can select both
D-PHY or C-PHY and transmitter or receiver. They do not replace
PHY_TYPE_DPHY/PHY_TYPE_CPHY, which remain the right choice where a cell
selects the mode. The first user is the Rockchip RK3588 MIPI DC-PHY
binding.

Suggested-by: Michael Riesch <michael.riesch@collabora.com>
Link: https://lore.kernel.org/r/82da3622-9c3a-454c-87bc-fb4ec7adb68d@collabora.com (local)
Signed-off-by: Jason Yang <redacted>

Where is any DTS using it? I did a search and no results of upstream
posting.

quoted

---
 include/dt-bindings/phy/phy.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 979b5dfd8353..8ee3f88e6d80 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h

@@ -24,6 +24,8 @@
 #define PHY_TYPE_CPHY                11
 #define PHY_TYPE_USXGMII     12
 #define PHY_TYPE_XAUI                13
+#define PHY_TYPE_DSI         14
+#define PHY_TYPE_CSI         15

DSI and CSI does not look like types of PHY...

Best regards,
Krzysztof