Received: by 10.223.164.202 with SMTP id h10csp240820wrb; Wed, 22 Nov 2017 20:00:49 -0800 (PST) X-Google-Smtp-Source: AGs4zMaUGFFAQUBBHz1/wwcFln1XDgXanyqR64jiTlhiwFW6nS2ZZxJ5tEqD3t2VupIyRoB45JJ9 X-Received: by 10.159.254.19 with SMTP id r19mr22941644pls.271.1511409649589; Wed, 22 Nov 2017 20:00:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511409649; cv=none; d=google.com; s=arc-20160816; b=FiHtFE1Z9oopVHPiwRrDYsoLmCXVHt1FaweNv1SgVNoRV9kTZ4Jb1e3I7fyRHFWii6 JQcTBWqWMxlPGkugIRww+cHi69ttFbdsDC4L+XeOzzE6Wyk6XFIMhOPzLHF3uyLZptUD GvH09vYfF+Ee5kRg7FxSp30AxQp4YMVbnwdji9ZVo1RHO+wHBZK3tXC+crC9y3H6Is96 N3bg4eu4sf/2wSwVYHGIGKpIKsy4AqUOWLff8zBmFP2FCg8fNRi19mSTDfRpCkxapUZi BoHjpESkVR0o6A2FLEoi5xuFhD9bvF0WJNjLyCRU8kMzmCzsxD3+q1GzT3eW1drGaaQD r8Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=mqbEXf6cFmLjjJmFTvH7PTzkZIPXHdy7LfeVbmEcBEM=; b=uyHU9ikMZ06mI7fKp/g8U5HREvrgqYh7WyW0UTPxasXK+b7J9N245G9LMVACl40stC 7oF0t4HxMjpQkc9ZWHCSlB5NJPjlDPXq2T1IAShX9QVxtaC2ErOGweDEzpq3bNP1Ggfe UOp7aa3/r2JeHH+lwZbuTNSkiB2Or8TjzMLiqVMG2MpEJrcIV96Ps1Om4TIcFKuDkl3M Sqibjyd4mRDdR7Y1Lii9Mo7pf0+iLkZwjm9HNLqlsKzuMC47nN72CqYrHfHjWVgFva2S p8BmN1qzoT+urP93djmp/nlsYk8MrF3pPADMz8bFww53hCiR5IbRz36KqTbn3YAS9Lr+ Xquw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=WsJmlZSg; dkim=pass header.i=@codeaurora.org header.s=default header.b=KxHjztJM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y38si15462765plh.61.2017.11.22.20.00.38; Wed, 22 Nov 2017 20:00:49 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=WsJmlZSg; dkim=pass header.i=@codeaurora.org header.s=default header.b=KxHjztJM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752249AbdKWEAC (ORCPT + 77 others); Wed, 22 Nov 2017 23:00:02 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:42204 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110AbdKWEAA (ORCPT ); Wed, 22 Nov 2017 23:00:00 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 86995607F1; Thu, 23 Nov 2017 03:59:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1511409599; bh=34ejbENs6TofiTOhE7u21OEn2Y+1WvdThV7pj0U1zlo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WsJmlZSgZFSJf6JrDO9yvQUFxTy4Ab0NnxwOWhVVCtOQC5adxW19bYhFgjWPLkt+u +Jy5pvLxn6XS76gb1fSk0RTGyOKoUKTw9wMwFDeZgnpUqvWuZTDleCli6vl7EFp7VX Yp5PRXrmeE267A73BHYtMQoAKD4rxOjqD+tFrgJQ= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.206.25.65] (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgautam@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 5E65960600; Thu, 23 Nov 2017 03:59:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1511409598; bh=34ejbENs6TofiTOhE7u21OEn2Y+1WvdThV7pj0U1zlo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KxHjztJMNM2WkgedPTyFd8ZZ03hmpnuGoD/smHteNJQXHDNwsOP/75wqjVWo/DgW2 c7yb2cJqVGodI+L71Uygfez3tMgGHzKCoNhDaFVT0SCnYALFXGhWDIKQCPWvB7zVlu QrjfXYZvROsLKtAt51K4YBB68MwYmaxtUCTdYLRo= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 5E65960600 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=mgautam@codeaurora.org Subject: Re: [PATCH v3 03/16] phy: qcom-qmp: Power-on PHY before initialization To: Stephen Boyd , Kishon Vijay Abraham I Cc: linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, Vivek Gautam , Varadarajan Narayanan , smuthayy , Wei Yongjun , Fengguang Wu , "open list:GENERIC PHY FRAMEWORK" References: <1511256206-1587-1-git-send-email-mgautam@codeaurora.org> <1511256206-1587-4-git-send-email-mgautam@codeaurora.org> <1876f08f-818e-37aa-d080-ad97e03f5a3a@codeaurora.org> From: Manu Gautam Message-ID: Date: Thu, 23 Nov 2017 09:29:52 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1876f08f-818e-37aa-d080-ad97e03f5a3a@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 11/22/2017 11:33 PM, Stephen Boyd wrote: > On 11/21/2017 01:23 AM, Manu Gautam wrote: >> PHY must be powered on before turning ON clocks and >> attempting to initialize it. Driver is exposing >> separate init and power_on routines for this. >> Apparently USB dwc3 core driver performs power-on after >> init. Also, poweron and init for QMP PHY need to be > Why does dwc3 driver power on after init? Seems backwards. There are not many PHY drivers implementing power_on, rather they rely on init to take care of complete initialization. However though the name indicates power_on, but PHY drivers are not using it to turn on power supplies but rather PHY register operations to enable/ start PHY - somewhat like init only. > >> executed together always, hence remove poweron callback >> from phy_ops and explicitly perform this from com_init, > Why do they need to be executed together? Hardware programming guide requires PHY supplies to be ON before it is initialized. And if PHY supplies were turned-off, then it must be reset after turning them ON. > >> similar changes needed for poweroff. On similar lines move >> clk_enable from init to com_init which can be called once >> for multi lane PHYs. > Please add parenthesis, clk_enable() for example, to functions so we > know they're functions. Ok. > >> Signed-off-by: Manu Gautam >> --- >> drivers/phy/qualcomm/phy-qcom-qmp.c | 61 +++++++++++++------------------------ >> 1 file changed, 21 insertions(+), 40 deletions(-) >> >> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c >> index 90794dd..2f427e3 100644 >> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c >> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c >> @@ -720,33 +720,6 @@ static void qcom_qmp_phy_configure(void __iomem *base, >> } >> } >> >> -static int qcom_qmp_phy_poweron(struct phy *phy) >> -{ >> - struct qmp_phy *qphy = phy_get_drvdata(phy); >> - struct qcom_qmp *qmp = qphy->qmp; >> - int num = qmp->cfg->num_vregs; >> - int ret; >> - >> - dev_vdbg(&phy->dev, "Powering on QMP phy\n"); >> - >> - /* turn on regulator supplies */ >> - ret = regulator_bulk_enable(num, qmp->vregs); >> - if (ret) >> - dev_err(qmp->dev, "failed to enable regulators, err=%d\n", ret); >> - >> - return ret; >> -} >> - >> -static int qcom_qmp_phy_poweroff(struct phy *phy) >> -{ >> - struct qmp_phy *qphy = phy_get_drvdata(phy); >> - struct qcom_qmp *qmp = qphy->qmp; >> - >> - regulator_bulk_disable(qmp->cfg->num_vregs, qmp->vregs); >> - >> - return 0; >> -} >> - >> static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp) >> { >> const struct qmp_phy_cfg *cfg = qmp->cfg; >> @@ -759,6 +732,19 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp) >> return 0; >> } >> >> + /* turn on regulator supplies */ >> + ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs); >> + if (ret) { >> + mutex_unlock(&qmp->phy_mutex); >> + return ret; > This could also be a goto. Yes, I can replace with goto here. > >> + } >> + >> + ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks); >> + if (ret) { >> + dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret); >> + goto err_clk_enable; >> + } >> + >> for (i = 0; i < cfg->num_resets; i++) { >> ret = reset_control_deassert(qmp->resets[i]); >> if (ret) { -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project From 1584790427409782752@xxx Wed Nov 22 18:05:27 +0000 2017 X-GM-THRID: 1584667180237862520 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread