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

Hi Krzysztof,

On 8/27/26 13:45, Krzysztof Kozlowski wrote:

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.

Indeed the consumer should know what to request. For example, the MIPI
CSI receivers should request the PHY_TYPE_CSI PHY. But I am not sure why
this should be redundant?! Can you elaborate? TBH I don't really
understand your remark.

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...

Fair point. AFAIK both CSI and DSI are protocols on top of the physical
CPHY and DPHY communication. Maybe we should stick to
transmitter/receiver/RX/TX direction/.../something. Would work for me
too, my simple request is to *NOT* introduce the same magic for each
combo PHY block over and over again, but create something generic.

What about

    #define PHY_DIRECTION_RX	0
    #define PHY_DIRECTION_TX	1

or so?

This is pretty much what Jason had in v1, but 1) generic instead of
Rockchip-specific (if anything, it probably should be Samsung-specific)
and 2) switched the constants to match the state of the art in the
kernel better.

Best regards,
Michael