Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2442340ybi; Mon, 1 Jul 2019 12:08:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqw9fvymWrAQJTSetQA8FZ8VZ9fHDjwm1qd9fgFe5gGAjYvGNPVQgmvIY+XFb5/OjpFFUGNX X-Received: by 2002:a17:90a:ad89:: with SMTP id s9mr913349pjq.41.1562008130869; Mon, 01 Jul 2019 12:08:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562008130; cv=none; d=google.com; s=arc-20160816; b=y7dbWPRU2SZ8rylTpKt+6/926QxQzau27bSeRBdhFG/YkmnoE6C5t7SVbXGUV3tzWC RosFxhmXXpqnK9WkKDeQtgs2umTaqEY5H3jjPH2fSBnMefbTktehG0Fw1plxvKKdgJV+ v2aLyPGdiXP3+oUHUwbe4VY8lVaNL2XzL83Q2H2iqdES8DE7ybHd5kCznw7X5vFpsG6T W4LLKzClOUTb3aAl287iEMzEpVVDEH4HO+OJyPXelQvWeK2CRxe77IXtFVkIs3PC2156 YJ0XOOB6SJyM5a6sUd9ocUAnsUAGi+pyinG1kMVY8kIflMsmdTV0tJduQQ8vKudaGisA vSfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature; bh=0dsg9xzxFA2AlVqJFYsW/zjoHMBGb2EbL4O4H6OGK0U=; b=MydSab5+8sV+Dghbo3ND9bRSp/+bTqXV3kAdAqXgBnIQEZkK3rT/K+mxZOxllifPWb mKaqGkTlpsVqNp5t6xJ2QuLNyUbxX/2NJQJjDdwU0/bpfNdji3m94oowFyytCAdVISRi 53Gx2/HsRrxQ+U8rjjLx5idDWLFbFy0pQz4d+TonWW0wdkQ5LIZVviME8Kn2vkSfbI27 vKG1hVz1yz1qUlneQDehVK8uG3LNylA+own04sr5aOkg1VksQxd58W1+BQmxNNEezVCz 2H2z6/VQ5xGx5EM8sfYJBmWAcV1GnAR8iaPaiiIC+YRDyZyEiq4qOkWZY6aBvezItRHI 2eLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=ck38QBfh; dkim=pass header.i=@codeaurora.org header.s=default header.b=LU5l7gGr; 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 q85si12052771pfc.85.2019.07.01.12.08.35; Mon, 01 Jul 2019 12:08:50 -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=ck38QBfh; dkim=pass header.i=@codeaurora.org header.s=default header.b=LU5l7gGr; 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 S1726816AbfGATHt (ORCPT + 99 others); Mon, 1 Jul 2019 15:07:49 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:36502 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726668AbfGATHs (ORCPT ); Mon, 1 Jul 2019 15:07:48 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 726AF60909; Mon, 1 Jul 2019 19:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1562008067; bh=JOuG+nTYGCjaeKzLDowBOJbURARYzc8K6dnbmDqxo5w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ck38QBfhx0ASNbTLUs/P7hIZ/CHzVCxwrz+NbEpXD3OEIsHZe2T6LtR8briEtk0LK GWqgTvbW+tP+p+Wwb7vlXbN2cYcPcppYPG6jK6ituM1S012ZCzq3dgQwy3BCYYW5Nf KzSOwmJDz16LR+fzu6wOimuHBwIGOz3ZxAR8WRr4= 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.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED,SPF_NONE autolearn=no autolearn_force=no version=3.4.0 Received: from [10.226.58.28] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jhugo@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 1039860159; Mon, 1 Jul 2019 19:07:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1562008066; bh=JOuG+nTYGCjaeKzLDowBOJbURARYzc8K6dnbmDqxo5w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LU5l7gGr1FEPmta4AJmGEQAPQFGo0rdKD+PFdW62YuNsghwk7IwzUe6tzRFn6F7js PyWhjfYebOvd+IaTv+2fyeLFffPjkvQUKRJ/KTt/WY3HqzlSUUaWp1m3/ThDO3xO16 QU7nH04rCu8zINAGQPc/dTsdQoiuGfUSocRV9tp4= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 1039860159 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=jhugo@codeaurora.org Subject: Re: [PATCH 4/5] drm/msm/dsi: get the clocks into OFF state at init To: Rob Clark Cc: dri-devel , linux-arm-msm , freedreno , aarch64-laptops@lists.linaro.org, linux-clk , Linux PM , Rob Clark , Sean Paul , David Airlie , Daniel Vetter , Jordan Crouse , Abhinav Kumar , Sibi Sankar , Mamta Shukla , Chandan Uddaraju , Archit Taneja , Rajesh Yadav , Linux Kernel Mailing List References: <20190630150230.7878-1-robdclark@gmail.com> <20190630150230.7878-5-robdclark@gmail.com> <75a2921d-bf1a-c4c1-6d9a-122474eface4@codeaurora.org> From: Jeffrey Hugo Message-ID: <9fbf9226-578a-90aa-693d-9ea4fcda8281@codeaurora.org> Date: Mon, 1 Jul 2019 13:07:44 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/1/2019 12:58 PM, Rob Clark wrote: > On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo wrote: >> >> On 6/30/2019 9:01 AM, Rob Clark wrote: >>> From: Rob Clark >>> >>> Do an extra enable/disable cycle at init, to get the clks into disabled >>> state in case bootloader left them enabled. >>> >>> In case they were already enabled, the clk_prepare_enable() has no real >>> effect, other than getting the enable_count/prepare_count into the right >>> state so that we can disable clocks in the correct order. This way we >>> avoid having stuck clocks when we later want to do a modeset and set the >>> clock rates. >>> >>> Signed-off-by: Rob Clark >>> --- >>> drivers/gpu/drm/msm/dsi/dsi_host.c | 18 +++++++++++++++--- >>> drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 1 + >>> 2 files changed, 16 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c >>> index aabab6311043..d0172d8db882 100644 >>> --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c >>> +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c >>> @@ -354,6 +354,7 @@ static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm *pll) >>> if (rc) >>> pr_err("DSI PLL(%d) lock failed, status=0x%08x\n", >>> pll->id, status); >>> +rc = 0; // HACK, this will fail if PLL already running.. >> >> Umm, why? Is this intentional? >> > > I need to sort out a proper solution for this.. but PLL lock will fail > if the clk is already running (which, in that case, is fine since it > is already running and locked), which will cause the clk_enable to > fail.. > > I guess there is some way that I can check that clk is already running > and skip this check.. I'm sorry, but this makes no sense to me. What clock are we talking about here? If the pll is locked, the the lock check should just drop through. If the pll cannot lock, you have an issue. I'm confused as to how any of the downstream clocks can actually be running if the pll isn't locked. I feel like we are not yet on the same page about what situation you seem to be in. Can you describe in exacting detail?