From: Frank Li <Frank.li@nxp.com>
To: Xu Yang <xu.yang_2@nxp.com>
Cc: vkoul@kernel.org, kishon@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, gregkh@linuxfoundation.org,
peter.chen@kernel.org, herve.codina@bootlin.com,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-usb@vger.kernel.org, jun.li@nxp.com
Subject: Re: [PATCH 2/6] usb: phy: mxs: keep USBPHY2's clk always on
Date: Thu, 18 Jul 2024 11:00:06 -0400 [thread overview]
Message-ID: <Zpkt9i0jMsYQ7rx5@lizhi-Precision-Tower-5810> (raw)
In-Reply-To: <20240718102637.3964232-2-xu.yang_2@nxp.com>
On Thu, Jul 18, 2024 at 06:26:33PM +0800, Xu Yang wrote:
> Per IC engineer request, we need to keep USBPHY2's clk always on,
"IP require keep keep USBPHY2's clk always on."
Not personal request, even it is IC expert. It should base on the "fact"
instead of personal's opinion.
> in this way, the USBPHY2 (PLL7) power can be controlled by
> hardware suspend signal totally. It is benefit of USB remote wakeup
> case which needs the resume signal be sent out as soon as
> possible (without software interfere). Without this, we may see usb
> remote wakeup issue since the host does not send resume in time.
So USBPHY2 (PLL7) power can be controlled by suspend signal. USB remote
wakeup needs resume signal be sent out as soon as possible to match
"spec requirement" or some other requirement.
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> ---
> drivers/usb/phy/phy-mxs-usb.c | 36 ++++++++++++++++++++++++++++-------
> 1 file changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index 42fcc8ad9492..b6868cc22c1e 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -150,6 +150,16 @@
> #define MXS_PHY_TX_D_CAL_MIN 79
> #define MXS_PHY_TX_D_CAL_MAX 119
>
> +/*
> + * At some versions, the PHY2's clock is controlled by hardware directly,
It better declear which version, for example, which chip use if no version
info in IP.
> + * eg, according to PHY's suspend status. In these PHYs, we only need to
> + * open the clock at the initialization and close it at its shutdown routine.
> + * It will be benefit for remote wakeup case which needs to send resume
> + * signal as soon as possible, and in this case, the resume signal can be sent
> + * out without software interfere.
These PHYs can send resume signal without software interfere if not gate
clock.
> + */
> +#define MXS_PHY_HARDWARE_CONTROL_PHY2_CLK BIT(4)
> +
> struct mxs_phy_data {
> unsigned int flags;
> };
> @@ -161,12 +171,14 @@ static const struct mxs_phy_data imx23_phy_data = {
> static const struct mxs_phy_data imx6q_phy_data = {
> .flags = MXS_PHY_SENDING_SOF_TOO_FAST |
> MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
> - MXS_PHY_NEED_IP_FIX,
> + MXS_PHY_NEED_IP_FIX |
> + MXS_PHY_HARDWARE_CONTROL_PHY2_CLK,
> };
>
> static const struct mxs_phy_data imx6sl_phy_data = {
> .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
> - MXS_PHY_NEED_IP_FIX,
> + MXS_PHY_NEED_IP_FIX |
> + MXS_PHY_HARDWARE_CONTROL_PHY2_CLK,
> };
>
> static const struct mxs_phy_data vf610_phy_data = {
> @@ -175,7 +187,8 @@ static const struct mxs_phy_data vf610_phy_data = {
> };
>
> static const struct mxs_phy_data imx6sx_phy_data = {
> - .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
> + .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
> + MXS_PHY_HARDWARE_CONTROL_PHY2_CLK,
> };
>
> static const struct mxs_phy_data imx6ul_phy_data = {
> @@ -206,6 +219,7 @@ struct mxs_phy {
> u32 tx_reg_set;
> u32 tx_reg_mask;
> struct regulator *phy_3p0;
> + bool hardware_control_phy2_clk;
Needn't it. just check MXS_PHY_HARDWARE_CONTROL_PHY2_CLK flag is enough.
> };
>
> static inline bool is_imx6q_phy(struct mxs_phy *mxs_phy)
> @@ -518,12 +532,17 @@ static int mxs_phy_suspend(struct usb_phy *x, int suspend)
> }
> writel(BM_USBPHY_CTRL_CLKGATE,
> x->io_priv + HW_USBPHY_CTRL_SET);
> - clk_disable_unprepare(mxs_phy->clk);
> + if (!(mxs_phy->port_id == 1 &&
> + mxs_phy->hardware_control_phy2_clk))
> + clk_disable_unprepare(mxs_phy->clk);
> } else {
> mxs_phy_clock_switch_delay();
> - ret = clk_prepare_enable(mxs_phy->clk);
> - if (ret)
> - return ret;
> + if (!(mxs_phy->port_id == 1 &&
> + mxs_phy->hardware_control_phy2_clk)) {
> + ret = clk_prepare_enable(mxs_phy->clk);
> + if (ret)
> + return ret;
> + }
> writel(BM_USBPHY_CTRL_CLKGATE,
> x->io_priv + HW_USBPHY_CTRL_CLR);
> writel(0, x->io_priv + HW_USBPHY_PWD);
> @@ -819,6 +838,9 @@ static int mxs_phy_probe(struct platform_device *pdev)
> if (mxs_phy->phy_3p0)
> regulator_set_voltage(mxs_phy->phy_3p0, 3200000, 3200000);
>
> + if (mxs_phy->data->flags & MXS_PHY_HARDWARE_CONTROL_PHY2_CLK)
> + mxs_phy->hardware_control_phy2_clk = true;
> +
Needn't it.
> platform_set_drvdata(pdev, mxs_phy);
>
> device_set_wakeup_capable(&pdev->dev, true);
> --
> 2.34.1
>
next prev parent reply other threads:[~2024-07-18 15:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 10:26 [PATCH 1/6] usb: phy: mxs: Using regulator phy-3p0 Xu Yang
2024-07-18 10:26 ` [PATCH 2/6] usb: phy: mxs: keep USBPHY2's clk always on Xu Yang
2024-07-18 15:00 ` Frank Li [this message]
2024-07-19 7:16 ` Xu Yang
2024-07-18 10:26 ` [PATCH 3/6] dt-bindings: phy: mxs-usb-phy: add nxp,sim property Xu Yang
2024-07-23 2:51 ` Rob Herring
2024-07-24 1:29 ` Xu Yang
2024-07-18 10:26 ` [PATCH 4/6] usb: phy: mxs: add wakeup enable for imx7ulp Xu Yang
2024-07-18 10:26 ` [PATCH 5/6] usb: phy: mxs: enable weak 1p1 regulator for imx6ul during suspend Xu Yang
2024-07-18 15:12 ` Frank Li
2024-07-19 7:37 ` Xu Yang
2024-07-18 10:26 ` [PATCH 6/6] ARM: dts: imx7ulp: add "nxp,sim" property for usbphy1 Xu Yang
2024-07-18 14:42 ` [PATCH 1/6] usb: phy: mxs: Using regulator phy-3p0 Frank Li
2024-07-19 7:05 ` Xu Yang
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=Zpkt9i0jMsYQ7rx5@lizhi-Precision-Tower-5810 \
--to=frank.li@nxp.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=herve.codina@bootlin.com \
--cc=imx@lists.linux.dev \
--cc=jun.li@nxp.com \
--cc=kernel@pengutronix.de \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.chen@kernel.org \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=vkoul@kernel.org \
--cc=xu.yang_2@nxp.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