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

[Krzysztof Kozlowski]

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.


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


Best regards,
Krzysztof