From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
To: Peter Chen <hzpeterchen@gmail.com>
Cc: Chaoyi Chen <kernel@airkyi.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Sandy Huang <hjc@rock-chips.com>,
Andy Yan <andy.yan@rock-chips.com>,
Yubing Zhang <yubing.zhang@rock-chips.com>,
Frank Wang <frank.wang@rock-chips.com>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Amit Sunil Dhamne <amitsd@google.com>,
Dragan Simic <dsimic@manjaro.org>,
Johan Jonker <jbx6244@gmail.com>,
Diederik de Haas <didi.debian@cknow.org>,
Peter Robinson <pbrobinson@gmail.com>,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v8 10/10] arm64: dts: rockchip: rk3399-evb-ind: Add support for DisplayPort
Date: Thu, 30 Oct 2025 14:50:33 +0800 [thread overview]
Message-ID: <e2fcc437-0650-4fdf-bb75-3463a80299fe@rock-chips.com> (raw)
In-Reply-To: <CAL411-rFK0o_cxBO_yJFHWurGFKxZGxw6=kpqxRipMetJskTaQ@mail.gmail.com>
On 10/30/2025 2:13 PM, Peter Chen wrote:
> On Thu, Oct 30, 2025 at 11:14 AM Chaoyi Chen <chaoyi.chen@rock-chips.com> wrote:
>> On 10/30/2025 10:50 AM, Peter Chen wrote:
>>
>>>>> Okay. My question is basic: USB2 PHY supplies DP/DM, and the DP/DM is
>>>>> short for Type-C connector,
>>>>> and no control is needed for Type-C application.
>>>>> Why is there a remote-endpoint connection between USB2 PHY and Type-C connector?
>>>> From the perspective of Type-C, this should not be added. Is the approach in v2 correct [0] ?
>>>>
>>> Have you tried debugging based on upstream code?
>> Yes, I have tried both the v2 and v8 approaches, and both can work.
>>
>>
>>> v2 is correct, but the dts needs to improve.
>>> - There is a remote-endpoint connection for USB role switch between
>>> Type-C connector
>>> device and USB controller device
>>> - There is a remote-endpoint connection for orientation and lane configuration
>>> between Type-C connector device and USB/DP PHY device.
>> In v8 patch5, we implemented typec_mux and typec_switch in the USB/DP PHY.
>>
>> I think the current remote-endpoint connections are all child node of the USB/DP PHY. That is:
>>
>>
>> &tcphy0_dp {
>> mode-switch;
>> ...
>> };
>>
>>
>> &tcphy0_usb3 {
>> orientation-switch;
>> ...
>> };
>>
>>
>> Does this still need to be improved? Thank you.
>>
> Hi Chaoyi,
>
> There are two questions I have still not seen the answer to:
> - Why USB2 PHY is related to your Type-C patch?
I was just following other people's approach. Sorry, this should be removed from the dts.
> - How does the USB role switch event notify the USB controller driver, eg dwc3?
Sorry, I misunderstood what you said before. There is indeed a missing usb-role-switch now. I referred to the approach in rk3588-evb1-v10.dts. Is the following way of writing correct?
&usbc_connector {
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
usbc_orien_sw: endpoint {
remote-endpoint = <&tcphy0_typec_orien_sw>;
};
};
port@1 {
reg = <1>;
usbc_role_sw: endpoint {
remote-endpoint = <&dwc3_0_role_switch>;
};
};
port@2 {
reg = <2>;
usbc_dp: endpoint {
remote-endpoint = <&tcphy0_typec_dp>;
};
};
};
};
&usbdrd_dwc3_0 {
status = "okay";
usb-role-switch;
port {
#address-cells = <1>;
#size-cells = <0>;
dwc3_0_role_switch: endpoint@0 {
reg = <0>;
remote-endpoint = <&usbc_role_sw>;
};
};
};
&tcphy0_usb3 {
orientation-switch;
port {
tcphy0_typec_orien_sw: endpoint {
remote-endpoint = <&usbc_orien_sw>;
};
};
};
&tcphy0_dp {
mode-switch;
port {
#address-cells = <1>;
#size-cells = <0>;
tcphy0_typec_dp: endpoint@0 {
reg = <0>;
remote-endpoint = <&usbc_dp>;
};
};
};
> Peter
>>> Peter
>>>
>>>> [0]: https://lore.kernel.org/all/20250715112456.101-6-kernel@airkyi.com/
>>>>
>>>> Or is the following approach correct?
>>>>
>>>>
>>>> port@0 {
>>>> reg = <0>;
>>>>
>>>> usbc_hs: endpoint {
>>>> remote-endpoint = <&tcphy0>;
>>>> };
>>>> };
>>>>
>>>> port@1 {
>>>> reg = <1>;
>>>>
>>>> usbc_ss: endpoint {
>>>> remote-endpoint = <&tcphy0>;
>>>> };
>>>> };
>>>>
>>>> port@2 {
>>>> reg = <2>;
>>>>
>>>> usbc_dp: endpoint {
>>>> remote-endpoint = <&tcphy0_typec_dp>;
>>>> };
>>>> };
>>>>
>>>>
>>>>>>>>> + port@1 {
>>>>>>>>> + reg = <1>;
>>>>>>>>> +
>>>>>>>>> + usbc_ss: endpoint {
>>>>>>>>> + remote-endpoint = <&tcphy0_typec_ss>;
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> +
>>>>>>>>> + port@2 {
>>>>>>>>> + reg = <2>;
>>>>>>>>> +
>>>>>>>>> + usbc_dp: endpoint {
>>>>>>>>> + remote-endpoint = <&tcphy0_typec_dp>;
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>> .....
>>>>>>>>> &u2phy0 {
>>>>>>>>> status = "okay";
>>>>>>>>> +
>>>>>>>>> + port {
>>>>>>>>> + u2phy0_typec_hs: endpoint {
>>>>>>>>> + remote-endpoint = <&usbc_hs>;
>>>>>>>>> + };
>>>>>>>>> + };
>>>>>>>>> };
>>>>>>>>>
>>>>>>>> There is no switch and mux, how to co-work with Type-C?
>>>>>>> I checked the phy-rockchip-inno-usb2.c but did not find any switch or mux. Does this mean that we need to implement them? Thank you.
>>>>>> Wait a minute, actually we have multiple hardware interfaces, one of which is Type-C, eventually connected to USBDPPHY, and the other is micro-usb connected to U2PHY.
>>>>> I assume the Micro-USB connector does not use Type-C/PD IC, is it
>>>>> right? Does it relate to this patch?
>>>>>
>>>>> Best regards,
>>>>> Peter
>>>>>
>> --
>> Best,
>> Chaoyi
>>
>
--
Best,
Chaoyi
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-10-30 6:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 7:14 [PATCH v8 00/10] Add Type-C DP support for RK3399 EVB IND board Chaoyi Chen
2025-10-29 7:14 ` [PATCH v8 01/10] usb: typec: Add notifier functions Chaoyi Chen
2025-10-31 13:39 ` Heikki Krogerus
2025-11-03 1:11 ` Chaoyi Chen
2025-10-29 7:14 ` [PATCH v8 02/10] usb: typec: Export all typec device types Chaoyi Chen
2025-10-31 13:49 ` Heikki Krogerus
2025-10-29 7:14 ` [PATCH v8 03/10] drm/bridge: Implement generic USB Type-C DP HPD bridge Chaoyi Chen
2025-10-31 13:58 ` Heikki Krogerus
2025-11-03 1:15 ` Chaoyi Chen
2025-11-03 4:00 ` Dmitry Baryshkov
2025-11-03 6:24 ` Chaoyi Chen
2025-11-03 13:48 ` Heikki Krogerus
2025-11-04 1:18 ` Chaoyi Chen
2025-11-06 3:06 ` Chaoyi Chen
2025-10-29 7:14 ` [PATCH v8 04/10] dt-bindings: phy: rockchip: rk3399-typec-phy: Support mode-switch Chaoyi Chen
2025-10-29 7:14 ` [PATCH v8 05/10] phy: rockchip: phy-rockchip-typec: Add typec_mux/typec_switch support Chaoyi Chen
2025-10-29 7:14 ` [PATCH v8 06/10] phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge Chaoyi Chen
2025-10-29 7:14 ` [PATCH v8 07/10] drm/rockchip: cdn-dp: Support handle lane info without extcon Chaoyi Chen
2025-10-29 7:14 ` [PATCH v8 08/10] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection Chaoyi Chen
2025-10-29 7:14 ` [PATCH v8 09/10] arm64: dts: rockchip: Add missing dp_out port for RK3399 CDN-DP Chaoyi Chen
2025-10-29 7:14 ` [PATCH v8 10/10] arm64: dts: rockchip: rk3399-evb-ind: Add support for DisplayPort Chaoyi Chen
2025-10-29 9:45 ` Peter Chen
2025-10-29 10:21 ` Chaoyi Chen
2025-10-29 10:31 ` Chaoyi Chen
2025-10-30 1:34 ` Peter Chen
2025-10-30 2:16 ` Chaoyi Chen
2025-10-30 2:50 ` Peter Chen
2025-10-30 3:13 ` Chaoyi Chen
2025-10-30 6:13 ` Peter Chen
2025-10-30 6:50 ` Chaoyi Chen [this message]
2025-10-31 2:57 ` Peter Chen (CIX)
2025-10-31 3:08 ` Chaoyi Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e2fcc437-0650-4fdf-bb75-3463a80299fe@rock-chips.com \
--to=chaoyi.chen@rock-chips.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=amitsd@google.com \
--cc=andrzej.hajda@intel.com \
--cc=andy.yan@rock-chips.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsimic@manjaro.org \
--cc=frank.wang@rock-chips.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=hzpeterchen@gmail.com \
--cc=jbx6244@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kernel@airkyi.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=pbrobinson@gmail.com \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
--cc=vkoul@kernel.org \
--cc=yubing.zhang@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox