From: Dmitry Rokosov <ddrokosov@sberdevices.ru>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: <gregkh@linuxfoundation.org>, <robh+dt@kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>, <neil.armstrong@linaro.org>,
<khilman@baylibre.com>, <jbrunet@baylibre.com>,
<mturquette@baylibre.com>, <vkoul@kernel.org>,
<kishon@kernel.org>, <hminas@synopsys.com>,
<Thinh.Nguyen@synopsys.com>, <yue.wang@amlogic.com>,
<hanjie.lin@amlogic.com>, <kernel@sberdevices.ru>,
<rockosov@gmail.com>, <linux-usb@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-amlogic@lists.infradead.org>,
<linux-phy@lists.infradead.org>
Subject: Re: [PATCH v2 1/5] phy: amlogic: enable/disable clkin during Amlogic USB PHY init/exit
Date: Tue, 25 Apr 2023 13:29:12 +0300 [thread overview]
Message-ID: <20230425102912.qhey7fpbuqvwg44j@CAB-WSD-L081021> (raw)
In-Reply-To: <CAFBinCDyhBQ5Nob38EmXor1PtcO09dRdReDTW+tc5CN4i20HhA@mail.gmail.com>
Hello Martin,
Thanks a lot for the review! Appreciate it!
Please find my comments below.
On Sun, Apr 23, 2023 at 07:42:25PM +0200, Martin Blumenstingl wrote:
> Hi Dmitry,
>
> On Tue, Apr 18, 2023 at 1:16 PM Dmitry Rokosov <ddrokosov@sberdevices.ru> wrote:
> >
> > Previously, all Amlogic boards used the XTAL clock as the default board
> > clock for the USB PHY input, so there was no need to enable it.
> > However, with the introduction of new Amlogic SoCs like the A1 family,
> > the USB PHY now uses a gated clock. Hence, it is necessary to enable
> > this gated clock during the PHY initialization sequence, or disable it
> > during the PHY exit, as appropriate.
> >
> > Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru>
> > ---
> > drivers/phy/amlogic/phy-meson-g12a-usb2.c | 13 +++++++++++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb2.c b/drivers/phy/amlogic/phy-meson-g12a-usb2.c
> > index 9d1efa0d9394..80938751da4f 100644
> > --- a/drivers/phy/amlogic/phy-meson-g12a-usb2.c
> > +++ b/drivers/phy/amlogic/phy-meson-g12a-usb2.c
> > @@ -172,10 +172,16 @@ static int phy_meson_g12a_usb2_init(struct phy *phy)
> > int ret;
> > unsigned int value;
> >
> > - ret = reset_control_reset(priv->reset);
> > + ret = clk_prepare_enable(priv->clk);
> > if (ret)
> > return ret;
> >
> > + ret = reset_control_reset(priv->reset);
> > + if (ret) {
> > + clk_disable_unprepare(priv->clk);
> > + return ret;
> > + }
> > +
> This part looks good. You asked why I suggested this approach instead
> of enabling the clock at probe time and only now I have time to reply
> to it.
> Consider the following scenario:
> - modprobe phy-meson-g12a-usb2
> - modprobe dwc3-meson-g12a (this will call phy_init)
> - rmmod dwc3-meson-g12a (this will call phy_exit)
>
> If the clock was enabled at probe time then it would only be disabled
> when using rmmod phy-meson-g12a-usb2.
> By manually calling clk_prepare_enable/clk_disable_unprepare we ensure
> that the clock gets disabled when we don't need the PHY anymore.
> Whether this makes any difference in terms of power draw: I can't say.
>
It makes sense. I fully agree with your approach, which looks better
compared to using the automatic devm_clk API.
> > udelay(RESET_COMPLETE_TIME);
> >
> > /* usb2_otg_aca_en == 0 */
> > @@ -277,8 +283,11 @@ static int phy_meson_g12a_usb2_init(struct phy *phy)
> > static int phy_meson_g12a_usb2_exit(struct phy *phy)
> > {
> > struct phy_meson_g12a_usb2_priv *priv = phy_get_drvdata(phy);
> > + int ret = reset_control_reset(priv->reset);
> > +
> > + clk_disable_unprepare(priv->clk);
> >
> > - return reset_control_reset(priv->reset);
> > + return ret;
> I think this can cause issues in case when reset_control_reset returns
> an error: If I understand the code in phy-core.c correctly it will
> only decrease the init ref-count if exit returns 0.
> Whenever phy_exit is called for the second time
> clk_disable_unprepare() will be called with a clock ref-count of 0, so
> it'll likely print some warning.
>
> My suggestion is to return early if reset_control_reset() fails and
> not call clk_disable_unprepare() in that case.
> What do you think?
After taking a closer look at the phy_exit core code, it appears that
your idea is spot on. Exiting immediately when reset fails seems like
the better choice.
I will work on a new version of the code accordingly.
--
Thank you,
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2023-04-25 10:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 11:16 [PATCH v2 0/5] arm64: meson: support Amlogic A1 USB OTG controller Dmitry Rokosov
2023-04-18 11:16 ` [PATCH v2 1/5] phy: amlogic: enable/disable clkin during Amlogic USB PHY init/exit Dmitry Rokosov
2023-04-18 11:42 ` neil.armstrong
2023-04-23 17:42 ` Martin Blumenstingl
2023-04-25 10:29 ` Dmitry Rokosov [this message]
2023-04-18 11:16 ` [PATCH v2 2/5] usb: dwc2: support dwc2 IP for Amlogic A1 SoC family Dmitry Rokosov
2023-04-18 11:42 ` neil.armstrong
2023-04-21 4:51 ` Minas Harutyunyan
2023-04-18 11:16 ` [PATCH v2 3/5] dt-bindings: usb: dwc2: add support for Amlogic A1 SoC USB peripheral Dmitry Rokosov
2023-04-21 18:01 ` Rob Herring
2023-04-23 17:43 ` Martin Blumenstingl
2023-04-18 11:16 ` [PATCH v2 4/5] usb: dwc3-meson-g12a: support OTG switch for all IP versions Dmitry Rokosov
2023-04-18 11:42 ` neil.armstrong
2023-04-23 17:44 ` Martin Blumenstingl
2023-04-18 11:16 ` [PATCH v2 5/5] arm64: dts: meson: a1: support USB controller in OTG mode Dmitry Rokosov
2023-04-23 17:51 ` Martin Blumenstingl
2023-04-25 11:06 ` Dmitry Rokosov
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=20230425102912.qhey7fpbuqvwg44j@CAB-WSD-L081021 \
--to=ddrokosov@sberdevices.ru \
--cc=Thinh.Nguyen@synopsys.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hanjie.lin@amlogic.com \
--cc=hminas@synopsys.com \
--cc=jbrunet@baylibre.com \
--cc=kernel@sberdevices.ru \
--cc=khilman@baylibre.com \
--cc=kishon@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--cc=robh+dt@kernel.org \
--cc=rockosov@gmail.com \
--cc=vkoul@kernel.org \
--cc=yue.wang@amlogic.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