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

[Michael Riesch]

Hi Krzysztof,

On 9/3/26 11:53, Krzysztof Kozlowski wrote:
> On 31/08/2026 13:32, Michael Riesch wrote:
>> Hi Krzysztof,
>>
>> On 8/27/26 13:45, Krzysztof Kozlowski wrote:
>>> On Fri, Aug 21, 2026 at 08:02:29PM +0800, Jason Yang wrote:
>>>> 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.
> 
> It is redundant, because consumer CANNOT put there anything else than
> CSI type and the topology already defines that. It is basically
> duplicating existing information.

We might not be on same page here, so please let me write down my view
on this.

For the CSI PHY in this combo block, the consumer on the RK3588 is a
MIPI CSI receiver, that roughly looks like this:

csi0: csi at fdd10000 {
  compatible = "rockchip,rk3588-mipi-csi2", "rockchip,rk3568-mipi-csi2";
  [...]
  phys = <&mipidcphy0 PHY_TYPE_DPHY PHY_DIRECTION_RX>;

  ports {
    csi0_in: port at 0 { /* from image sensor */ }
    csi0_out: port at 1 { /* to RK3588 VICAP */ }
  }
}

For the DSI PHY in this combo block, on the other hand:

dsi0: dsi at fde20000 {
  compatible = "rockchip,rk3588-mipi-dsi2";
  [...]
  phys = <&mipidcphy0 PHY_TYPE_DPHY>;
  // or alternatively:
  phys = <&mipidcphy0 PHY_TYPE_DPHY PHY_DIRECTION_TX>;

  ports {
    dsi0_in: port at 0 { /* from VOP2 port*/ }
    dsi0_out: port at 1 { /* to display */ }
  }

That is assuming the DPHY case, of course.

With that in mind, yes, the consumer CAN put something different in
there as CSI (or RX). The argument can be omitted for backward
compatibility, in which case DSI (or TX) is selected.

And yes, the topology should make the selection of the PHY obvious, but
I can't see how the PHY driver should obtain this information if it
wasn't for an extra PHY_DIRECTION_* argument.

What am I missing here?

>>>> 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 at collabora.com>
>>>> Link: https://lore.kernel.org/r/82da3622-9c3a-454c-87bc-fb4ec7adb68d@collabora.com
>>>> Signed-off-by: Jason Yang <jason98166 at gmail.com>
>>>
>>> Where is any DTS using it? I did a search and no results of upstream
>>> posting.
>>>
>>>> ---
>>>>  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?
> 
> Well, I asked for any DTS user of it and I did not get it except
> pointing to irrelevant and completely different 15 year old Samsung chip
> and to some "future" work, so no clue. I still claim that direction is
> obvious from the graph between producer and consumer, thus is redundant,
> but I am happy to be corrected by showing me the code.
> 
> Talk is cheap.

:-)

I agree that having DTS patches showing how this is used in the RK3588
would tell more than thousand words. I hope the sketch above helped at
least a little in that regard.

@Jason: can you include the DTS additions in your series?

Best regards,
Michael

> 
> 
> Best regards,
> Krzysztof