From: Xu Yang <xu.yang_2@nxp.com>
To: Frank Li <Frank.li@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: Fri, 19 Jul 2024 15:16:47 +0800 [thread overview]
Message-ID: <20240719071647.dwnsrvv5ndtbqhll@hippo> (raw)
In-Reply-To: <Zpkt9i0jMsYQ7rx5@lizhi-Precision-Tower-5810>
On Thu, Jul 18, 2024 at 11:00:06AM -0400, Frank Li wrote:
> 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.
Okay.
>
> > 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.
Will change.
>
> >
> > 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.
Okay, will add.
>
> > + * 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.
Will change.
>
> > + */
> > +#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.
Okay.
>
> > };
> >
> > 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.
Okay. Will remove this.
>
> > platform_set_drvdata(pdev, mxs_phy);
> >
> > device_set_wakeup_capable(&pdev->dev, true);
> > --
> > 2.34.1
> >
next prev parent reply other threads:[~2024-07-19 7:19 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
2024-07-19 7:16 ` Xu Yang [this message]
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=20240719071647.dwnsrvv5ndtbqhll@hippo \
--to=xu.yang_2@nxp.com \
--cc=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 \
/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