From: neil.armstrong@linaro.org
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Kever Yang <kever.yang@rock-chips.com>,
Frank Wang <frank.wang@rock-chips.com>
Cc: Alexey Charkov <alchark@gmail.com>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
kernel@collabora.com, linux-phy@lists.infradead.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/4] phy: rockchip: usbdp: reset USB3 and reinit on orientation switch
Date: Fri, 13 Jun 2025 10:55:43 +0200 [thread overview]
Message-ID: <49eb73df-9a15-436e-a05c-72dd3aa36bf8@linaro.org> (raw)
In-Reply-To: <20250610-rk3576-sige5-usb-v4-3-7e7f779619c1@collabora.com>
Hi,
On 10/06/2025 16:07, Nicolas Frattaroli wrote:
> Until now, super speed on Type-C only worked in one orientation. This is
> because on an orientation switch, the UDPHY was never reinitialised.
>
> Heiko presented a patch to do this[1], but there were concerns over the
> correctness of it[2]. Experimentally using Heiko's patch on RK3576 did
> make me run into issues, though they seemed to be related to the
> orientation switch actually happening while a clock driving a GRF
> register was disabled.
>
> The key issue is that the hardware wants the USB 3 controller to be held
> in reset while the PHY is being reconfigured, otherwise we may run into
> hard-to-catch race conditions.
>
> Either way, this patch implements the required ordering in a somewhat
> unpleasant way: we get the USB 3 controller from the DT, and use runtime
> power management to forcibly suspend it while the UDPHY is being
> reconfigured, and then forcibly resume it later. As an added pain in the
> rear, the suspend/resume of the USB 3 controller also tries fiddling
> with the USB 3 PHY part of the UDPHY, which means we introduce an atomic
> flag to skip suspending/resuming the UDPHY if we're resetting the USB 3
> controller. We may just need to skip trying to acquire the mutex again,
> but both ways work for me in practice.
>
> This solution may in fact be complete rubbish, but it works to get USB 3
> Super Speed working in both cable orientations on my board.
Yeah this is kind of a hack, and we have a similar situation on Qualcomm platforms
when dealing with USB2-only and DP-only altmodes, where we need the DWC3 to
disable the usb3 path. Hopefully on Qcom combo PHYs we can switch lanes without
disable the USB3 PHY.
So the proper solution would have the dwc3 driver to also react to mux and
orientation events and disable the usb3 path to allow the phy to reconfigure
itself.
We don't have any concrete proposal yet, but we will get something soonish.
Neil
>
> Link: https://lore.kernel.org/all/20250226103810.3746018-3-heiko@sntech.de/ [1]
> Link: https://lore.kernel.org/linux-rockchip/h57ok2hw6os7bcafqkrqknfvm7hnu25m2oe54qmrsuzdwqlos3@m4och2fcdm7s/ [2]
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/phy/rockchip/phy-rockchip-usbdp.c | 54 +++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index fff54900feea601c8fe6bf4c7123dfebc5661a15..5cd6bbc367f69bca15c2a94a07e72f850b381ae3 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -200,6 +200,10 @@ struct rk_udphy {
> /* PHY devices */
> struct phy *phy_dp;
> struct phy *phy_u3;
> +
> + /* USB 3 controller device */
> + struct device *ctrl_u3;
> + atomic_t ctrl_resetting;
> };
>
> static const struct rk_udphy_dp_tx_drv_ctrl rk3588_dp_tx_drv_ctrl_rbr_hbr[4][4] = {
> @@ -1255,6 +1259,9 @@ static int rk_udphy_usb3_phy_init(struct phy *phy)
> struct rk_udphy *udphy = phy_get_drvdata(phy);
> int ret = 0;
>
> + if (atomic_read(&udphy->ctrl_resetting))
> + return 0;
> +
> mutex_lock(&udphy->mutex);
> /* DP only or high-speed, disable U3 port */
> if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs) {
> @@ -1273,6 +1280,9 @@ static int rk_udphy_usb3_phy_exit(struct phy *phy)
> {
> struct rk_udphy *udphy = phy_get_drvdata(phy);
>
> + if (atomic_read(&udphy->ctrl_resetting))
> + return 0;
> +
> mutex_lock(&udphy->mutex);
> /* DP only or high-speed */
> if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
> @@ -1401,10 +1411,31 @@ static struct phy *rk_udphy_phy_xlate(struct device *dev, const struct of_phandl
> return ERR_PTR(-EINVAL);
> }
>
> +static struct device_node *rk_udphy_to_controller(struct rk_udphy *udphy)
> +{
> + struct device_node *np;
> +
> + for_each_node_with_property(np, "phys") {
> + struct of_phandle_iterator it;
> + int ret;
> +
> + of_for_each_phandle(&it, ret, np, "phys", NULL, 0) {
> + if (it.node != udphy->dev->of_node)
> + continue;
> +
> + of_node_put(it.node);
> + return np;
> + }
> + }
> +
> + return NULL;
> +}
> +
> static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
> enum typec_orientation orien)
> {
> struct rk_udphy *udphy = typec_switch_get_drvdata(sw);
> + int ret;
>
> mutex_lock(&udphy->mutex);
>
> @@ -1420,6 +1451,18 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
> rk_udphy_set_typec_default_mapping(udphy);
> rk_udphy_usb_bvalid_enable(udphy, true);
>
> + if (udphy->status != UDPHY_MODE_NONE && udphy->ctrl_u3) {
> + atomic_set(&udphy->ctrl_resetting, 1);
> + pm_runtime_force_suspend(udphy->ctrl_u3);
> +
> + ret = rk_udphy_setup(udphy);
> + if (!ret)
> + clk_bulk_disable_unprepare(udphy->num_clks, udphy->clks);
> +
> + pm_runtime_force_resume(udphy->ctrl_u3);
> + atomic_set(&udphy->ctrl_resetting, 0);
> + }
> +
> unlock_ret:
> mutex_unlock(&udphy->mutex);
> return 0;
> @@ -1430,12 +1473,22 @@ static void rk_udphy_orien_switch_unregister(void *data)
> struct rk_udphy *udphy = data;
>
> typec_switch_unregister(udphy->sw);
> + put_device(udphy->ctrl_u3);
> }
>
> static int rk_udphy_setup_orien_switch(struct rk_udphy *udphy)
> {
> + struct device_node *ctrl = rk_udphy_to_controller(udphy);
> struct typec_switch_desc sw_desc = { };
>
> + if (ctrl) {
> + udphy->ctrl_u3 = bus_find_device_by_of_node(udphy->dev->bus, ctrl);
> + of_node_put(ctrl);
> + }
> +
> + if (!udphy->ctrl_u3)
> + dev_info(udphy->dev, "couldn't find this PHY's USB3 controller\n");
> +
> sw_desc.drvdata = udphy;
> sw_desc.fwnode = dev_fwnode(udphy->dev);
> sw_desc.set = rk_udphy_orien_sw_set;
> @@ -1499,6 +1552,7 @@ static int rk_udphy_probe(struct platform_device *pdev)
> return ret;
>
> mutex_init(&udphy->mutex);
> + atomic_set(&udphy->ctrl_resetting, 0);
> platform_set_drvdata(pdev, udphy);
>
> if (device_property_present(dev, "orientation-switch")) {
>
next prev parent reply other threads:[~2025-06-13 8:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 14:07 [PATCH v4 0/4] RK3576 USB Enablement Nicolas Frattaroli
2025-06-10 14:07 ` [PATCH v4 1/4] phy: rockchip: inno-usb2: add soft vbusvalid control Nicolas Frattaroli
2025-06-13 9:02 ` neil.armstrong
2025-06-13 13:08 ` Nicolas Frattaroli
2025-06-16 12:48 ` Nicolas Frattaroli
2025-06-10 14:07 ` [PATCH v4 2/4] phy: rockchip: usbdp: move orientation handling further down Nicolas Frattaroli
2025-06-13 8:51 ` neil.armstrong
2025-06-10 14:07 ` [PATCH v4 3/4] phy: rockchip: usbdp: reset USB3 and reinit on orientation switch Nicolas Frattaroli
2025-06-13 8:55 ` neil.armstrong [this message]
2025-06-13 13:21 ` Nicolas Frattaroli
2025-06-16 7:55 ` Neil Armstrong
2025-06-10 14:07 ` [PATCH v4 4/4] arm64: dts: rockchip: enable USB on Sige5 Nicolas Frattaroli
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=49eb73df-9a15-436e-a05c-72dd3aa36bf8@linaro.org \
--to=neil.armstrong@linaro.org \
--cc=alchark@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frank.wang@rock-chips.com \
--cc=heiko@sntech.de \
--cc=kernel@collabora.com \
--cc=kever.yang@rock-chips.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=nicolas.frattaroli@collabora.com \
--cc=robh@kernel.org \
--cc=sebastian.reichel@collabora.com \
--cc=vkoul@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).