Message ID | 20230418111612.19479-2-ddrokosov@sberdevices.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2772137vqo; Tue, 18 Apr 2023 04:33:14 -0700 (PDT) X-Google-Smtp-Source: AKy350ZEHHUvzO1EuuvjgDmdD+Ha7VmY0D724CwhiZtqI85AoD3sD3loabgN9KH2EXdYQY8GxKgZ X-Received: by 2002:a17:902:ab8e:b0:1a2:8c7e:f301 with SMTP id f14-20020a170902ab8e00b001a28c7ef301mr1556375plr.45.1681817594191; Tue, 18 Apr 2023 04:33:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681817594; cv=none; d=google.com; s=arc-20160816; b=Pc9OUq0GDGQUKmOY8NdIY4tAtaqzSHJz6SKactcWzwo4XjmMLsanm8/pgSCkq368jj QP+ZH0NC0k0Hpk66eh7lJaRg7DvY6IEgU0vMgADi0riztUBOofqKCVlVAPIW0avlHK33 fGYZw5UA1CwJUkIh+vjk738UE3tHyisomsSRgVhklBkBMjKeJ1NeLYM6e+mMvBmZIWbW Ty9um8/wandg2QNTtTTQPuJE1Jtt3VkdMXNuBIHzlW82Qm41tt2ownSSCxxpcvHyqFEx KyWHXZW1yxdjOvwZrClJBVLGHVid644r2iipEIw6WMi/j8Zdq691K0+hV83CJPHPNd6r 6H6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=MDzMe5CZfB1jJP7T11BEyo9k6M0Db32prO+SmusTuWw=; b=CiePpj5Fps7UU1SmviO3FVAO0nYr4+W6yc+bzLb+oMLprPXQ5bhiFY3trMZxPWMjpo q7bI9ncH1mv6IX7NWA5/RBTikg+k7l3ou1M97ipXSNdAnxgrnFQcx+3nOLrtg361R/8u 7syR1gk4KhrphWei8TMF/cg2A3Q68iaVaTJLO0oRuozKlAT4fVukyGPGXgjTLk3CEjTb s8Pbe+5dVci5IRQxlV68qhmV0jaPurPRrYoz85R4R5/PsKBg5BdnBw6r6B8f+26qk4ex VSscnl9ZfNak3QGBDoYrumNlYRCeY6oOq2PhT2JJ+0x6K2SdMy9ZYxBhYQOH6MKUlEMi HpRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=brqLeNnH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n15-20020a170902d2cf00b001a2445dd0fasi14895343plc.381.2023.04.18.04.32.58; Tue, 18 Apr 2023 04:33:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=brqLeNnH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231428AbjDRLSZ (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Tue, 18 Apr 2023 07:18:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231302AbjDRLSX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 18 Apr 2023 07:18:23 -0400 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8896619AA; Tue, 18 Apr 2023 04:17:36 -0700 (PDT) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id F24565FD78; Tue, 18 Apr 2023 14:16:20 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1681816581; bh=MDzMe5CZfB1jJP7T11BEyo9k6M0Db32prO+SmusTuWw=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=brqLeNnHFhrcMVFs0R8yx2+7mwYyq+eOWHy5gKsQDSSPFOT7vG87eoE21J0MCPUtj /ZDLMSEpazMaB90uVs0YZdxxHZ7tOmH1cTT114+/ioSqRj/FsNG0Sp6dXxdFAaa1OX rKSIS8T9C8d5kkEeelMcSH88IvZqE4VcFgSF9189TzLEDVJ49KX/mNmRM7CNd7BN4s z/Qv7rzi2lLNjo+HKfZ4RDa7QP25N+bNu+y5IyVdZcn9ztNZXrPxytrGFO3+Vj+p6H G8OSARnLw0zTmHuJdvWWGWSFpibgD/h+oSUZaKgWAADMczYKrHxgbQgkD6xSvatfc7 UTNN778qGqelw== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Tue, 18 Apr 2023 14:16:20 +0300 (MSK) From: Dmitry Rokosov <ddrokosov@sberdevices.ru> To: <gregkh@linuxfoundation.org>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <neil.armstrong@linaro.org>, <khilman@baylibre.com>, <jbrunet@baylibre.com>, <martin.blumenstingl@googlemail.com>, <mturquette@baylibre.com>, <vkoul@kernel.org>, <kishon@kernel.org>, <hminas@synopsys.com>, <Thinh.Nguyen@synopsys.com> CC: <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>, Dmitry Rokosov <ddrokosov@sberdevices.ru> Subject: [PATCH v2 1/5] phy: amlogic: enable/disable clkin during Amlogic USB PHY init/exit Date: Tue, 18 Apr 2023 14:16:08 +0300 Message-ID: <20230418111612.19479-2-ddrokosov@sberdevices.ru> X-Mailer: git-send-email 2.36.0 In-Reply-To: <20230418111612.19479-1-ddrokosov@sberdevices.ru> References: <20230418111612.19479-1-ddrokosov@sberdevices.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH01.sberdevices.ru (172.16.1.4) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/04/18 05:44:00 #21123121 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763513565299784783?= X-GMAIL-MSGID: =?utf-8?q?1763513565299784783?= |
Series |
arm64: meson: support Amlogic A1 USB OTG controller
|
|
Commit Message
Dmitry Rokosov
April 18, 2023, 11:16 a.m. UTC
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(-)
Comments
On 18/04/2023 13:16, Dmitry Rokosov 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; > + } > + > 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; > } > > /* set_mode is not needed, mode setting is handled via the UTMI bus */ Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
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. > 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? Best regards, Martin
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.
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; + } + 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; } /* set_mode is not needed, mode setting is handled via the UTMI bus */