Received: by 10.213.65.68 with SMTP id h4csp294142imn; Mon, 26 Mar 2018 22:08:23 -0700 (PDT) X-Google-Smtp-Source: AG47ELtjGbdJFs30SLRHoPrJGh7YW7ZWQK++Q0kCIDA+iseVcWKMX1GbnHW3Y46RN/lIN6w2z+Q4 X-Received: by 10.99.182.6 with SMTP id j6mr30337467pgf.122.1522127302938; Mon, 26 Mar 2018 22:08:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522127302; cv=none; d=google.com; s=arc-20160816; b=wbUjbrv2jSayEQ+aKuhh5p34CV5j08g2fZxN7hy+1s0PE2JYUNrx4RCOnDBSnmK+Xe aXTRzuejgzwSnedwd0TlgEzBhwe6zW0qGUbkMQaKM5qzNJ+Et/CSgTmpy1S3b/9mpg9N z+tgtmSv8dzjk5aX4tVIp/v2cbybmgoc/XXGAjXCHZWrlfYuekrIiB1X5YA2lz2l0noo 8GXcMugpQEbkswwe9T+NZIOGSnjMdXk5lsOO3MmLGHFda+wD9rtOExTQXLDDIY8Bo0md 3mSzY2cT1pG9GKl5RaEaeCSXwPzQNYvHUgVNlVGRCfUcnnloxnefWa9TTpuaZTQkH7gk o5rQ== 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=q23y/rnIF8sO2hG6cckOGjkIrTlI17mTs9tBsLzX670=; b=Wtq0A5hgoLnfifQijdnFlcEgCa95I5IqcEaX23xY7QkL9fkmODKS8sjnE6EsMJmb56 AKAk2pK91m+VApcOdziyeN82RW2gYAVVx12EG/SODgqK8LeYvrIuE6qvgW8yh/nEkCXS GgRkqFH9oPSrXhnjG27YuJGBr2Mi4oj+wRjs7/H9u0mV/TLRX1zNQ7OqlkGNpXoOX3O+ fo/ieD0VdhdFhFNsfK10VBSZvnyyXfl0ZB/ogjSeCeNLL8gfHa9CBR/ucy6yfqziqYRT 1/cCBTyVN/6D7yjZjVuANkMhAr/GrvcBaPljRKW6vSpKjqq9H/FQYZ3wGg6naZqlA2i8 qMTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=HF/MLv4A; dkim=pass header.i=@codeaurora.org header.s=default header.b=aywFwjv2; 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 r63-v6si435283plb.356.2018.03.26.22.08.08; Mon, 26 Mar 2018 22:08:22 -0700 (PDT) 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=HF/MLv4A; dkim=pass header.i=@codeaurora.org header.s=default header.b=aywFwjv2; 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 S1750944AbeC0FHS (ORCPT + 99 others); Tue, 27 Mar 2018 01:07:18 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:38416 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750836AbeC0FHQ (ORCPT ); Tue, 27 Mar 2018 01:07:16 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 94DDB603AF; Tue, 27 Mar 2018 05:07:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1522127235; bh=8Zn8qwL0HoPpgk2j8v+XQNWeuEZsCgF3tbIIADTwWYo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HF/MLv4AUuJYqhls2YVBQfpT6pwbB7AQR+UVmrI1EcpMzqshNlxhycqT8VQKBiVBG iuwcHYW3iV06HQlSqyUYF5TU3nPDmDu5baC//lNF5i9zVGi894k0iQTWvASXYRYwrD eeumFP3OpD4t1xMd7NJsVIYfdh6ifNu1bzkl0igo= 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 0F53860588; Tue, 27 Mar 2018 05:07:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1522127234; bh=8Zn8qwL0HoPpgk2j8v+XQNWeuEZsCgF3tbIIADTwWYo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aywFwjv2Ie20+qe/yGCTdkJTHeFcwfLfk09nCV31a+BEHT/9AL3uBqYE2omSI1j96 gYWU/If1Cc/KLDH32xcot02dWDi3A5FavcBXgm7BoZxij6zzu9cY8nufNBqGLv8Q1I HyIgUi5Gc1PnCGXDBKuS37Q/2cDeFrqS0ZBDhGPE= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 0F53860588 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 1/6] phy: qcom-qmp: Enable pipe_clk before checking USB3 PHY_STATUS To: Doug Anderson Cc: Kishon Vijay Abraham I , LKML , devicetree@vger.kernel.org, Rob Herring , linux-arm-msm@vger.kernel.org, Vivek Gautam , Varadarajan Narayanan , Viresh Kumar , Wei Yongjun , Fengguang Wu , Vivek Gautam , anischal@codeaurora.org References: <1521785487-29866-1-git-send-email-mgautam@codeaurora.org> <1521785487-29866-2-git-send-email-mgautam@codeaurora.org> From: Manu Gautam Message-ID: <8724ae37-5d71-4d5f-f750-da0cb8838f47@codeaurora.org> Date: Tue, 27 Mar 2018 10:37:08 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: 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 Doug, On 3/27/2018 9:56 AM, Doug Anderson wrote: > Manu > > On Thu, Mar 22, 2018 at 11:11 PM, Manu Gautam wrote: >> QMP PHY for USB mode requires pipe_clk for calibration and PLL lock >> to take place. This clock is output from PHY to GCC clock_ctl and then >> fed back to QMP PHY and is available from PHY only after PHY is reset >> and initialized, hence it can't be enabled too early in initialization >> sequence. >> >> Signed-off-by: Manu Gautam >> --- >> drivers/phy/qualcomm/phy-qcom-qmp.c | 33 ++++++++++++++++++++++++++++++++- >> 1 file changed, 32 insertions(+), 1 deletion(-) > So it's now new with this patch, but it's more obvious with this > patch. It seems like "UFS/PCIE" is kinda broken w/ respect to how it > controls its clock. Specifically: > > * If you init the PHY but don't power it on, then you "exit" the PHY: > you'll disable/unprepare "pipe_clk" even though you never > prepare/enabled it. > > * If you init the PHY, power it on, power it off, power it on, and > exit the PHY: you'll leave the clock prepared one extra time. > > Specifically I'd expect: for UFS/PCIE the disable/unprepare should be > symmetric with the enable/prepare and should be in "power off", not in > exit. > > ...or did I miss something? > > > Interestingly, your patch fixes this problem for USB3 (where init/exit > are now symmetric), but leaves the problem there for UFS/PCIE. > Thanks for review. One of the reason why pipe_clk is disabled as part of phy_exit is that halt_check from clk_disable reports error if called after PHY has been powered down or phy_exit. I believe that warning should be ignored in qcom gcc-clock driver (for applicable platforms) by using BRANCH_HALT_DELAY as halt_check for pipe_clk and performing clk_disable from power_off for UFS/PCIE. I can implement that as separate patch once dependent gcc driver patch(es) gets in. Would that be ok? -Manu -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project