Received: by 10.192.165.148 with SMTP id m20csp768751imm; Fri, 4 May 2018 20:47:54 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpje/MI0ttAeEsaYmrYhsRCk8gn2RoFW9PTM0iWEokhK5t9VYDW8ybv2T1mV7hdLRVOqOCM X-Received: by 2002:a17:902:7b83:: with SMTP id w3-v6mr15444040pll.12.1525492074649; Fri, 04 May 2018 20:47:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525492074; cv=none; d=google.com; s=arc-20160816; b=vS7US3nj7BRyZ7Z/7VxbkyxxbT6T2S4s45L8KT7ICQSwLtJEHnGuJ992yZfnkyCbuM sA1yiOaY8I464MhNk8QXShwDqz6xd7GAo8l/RDr96inmK6hhElaAtKcEJP7tVUJ7l14Y yOoJ+fFiq3aS7OnZfDsyKevA7E89KWAtTnSO1gcJkc1+sG72hmBoqQDyEy41I1C4tB/W xuXrEKtTIdnWC6RhW5zzu4TFxxkTkV52loH5Z6cDIGOb1EUAFUNI2kphMO9PON74q6KV 07+y5Iz31tNdP5RBYi6RfDT3tQomoeG6XGC2TfLPKyuVGo1cowITVNrSPGeS0FvJrAOt YouA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature:arc-authentication-results; bh=lVdnOfmuaTeQq11MgORya0xMBrV0M4YcLSNQU0rvs2Q=; b=L8FB7c9bISh08QArAyM+boXHHijWHReL7FBElyC3tW1lJivNs9oVKduCtBfMcn35wy GmKfokhhX0bh+ImWmHQUpEAn/mYENuNFy5/c35WfYiFWP1kWy/23qBiB/ezhmhEPTQJH OdPOe+CQnkniwNUEfk6bqVWFEp8S40bobyDCfbnxv7JaX+5lmJD1xTFN5GYJctTlghqd l40XU7XckX092LGQBMzn4ZSZlKqXlfWXNjrlvKFn/wANd+AD2jNXrIiHM4cPDszWzGr0 hFTmEcrohx22nx7HdE9OPHixtLA3eQBw2c2XNEY5SoE3BdXk+K0QMJqmAeHsMPMYwxsg Ne7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Xl6IAJ94; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r8-v6si16998143pli.119.2018.05.04.20.47.40; Fri, 04 May 2018 20:47:54 -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=@kernel.org header.s=default header.b=Xl6IAJ94; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752020AbeEEDZC (ORCPT + 99 others); Fri, 4 May 2018 23:25:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:48568 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751811AbeEEDZA (ORCPT ); Fri, 4 May 2018 23:25:00 -0400 Received: from localhost (unknown [104.132.1.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1964B2133D; Sat, 5 May 2018 03:25:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1525490700; bh=8uEwUdM46wFUlJKAK8yPGrYAATo19pCSxHUmZyOVyq4=; h=To:From:In-Reply-To:Cc:References:Subject:Date:From; b=Xl6IAJ94/B4UolGUTDGodwR/EheZVXsQvHswLVgnsHdqaGLWp8/nHJmY5+osJoIeX CqUCOOAo1JOlsPGPPmPrGKqA9owSkw6gWe9ED2GVA9r3TOFPYZose+1ZB/I6MUQ+uk uFgmycczEaYC7JgV9HWCSVRmQ3Lu6llW4f+tGlK0= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Amit Nischal From: Stephen Boyd In-Reply-To: <68f6216b3de12d90a54207a6a0110c6b@codeaurora.org> Cc: Michael Turquette , Stephen Boyd , Andy Gross , David Brown , Rajendra Nayak , Odelu Kukatla , Taniya Das , linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-clk-owner@vger.kernel.org References: <1525105210-8689-1-git-send-email-anischal@codeaurora.org> <1525105210-8689-2-git-send-email-anischal@codeaurora.org> <152524713612.138124.1776677011439726084@swboyd.mtv.corp.google.com> <68f6216b3de12d90a54207a6a0110c6b@codeaurora.org> Message-ID: <152549069940.138124.10210385659890209429@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: Re: [PATCH v6 1/3] clk: qcom: Configure the RCGs to a safe source as needed Date: Fri, 04 May 2018 20:24:59 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Amit Nischal (2018-05-03 04:57:37) > On 2018-05-02 13:15, Stephen Boyd wrote: > > Quoting Amit Nischal (2018-04-30 09:20:08) > > = > >> +} > >> + > >> +static void clk_rcg2_shared_disable(struct clk_hw *hw) > >> +{ > >> + struct clk_rcg2 *rcg =3D to_clk_rcg2(hw); > >> + struct freq_tbl safe_src_tbl =3D { 0 }; > >> + > >> + /* > >> + * Park the RCG at a safe configuration - sourced off from = > >> safe source. > >> + * Force enable and disable the RCG while configuring it to = > >> safeguard > >> + * against any update signal coming from the downstream clock. > >> + * The current parent is still prepared and enabled at this = > >> point, and > >> + * the safe source is always on while application processor = > >> subsystem > >> + * is online. Therefore, the RCG can safely switch its parent. > >> + */ > >> + safe_src_tbl.src =3D rcg->safe_src_index; > >> + clk_rcg2_shared_force_enable_clear(hw, &safe_src_tbl); > > = > > This should then re-dirty the config register to have the software > > frequency settings that existed in the hardware when disable was = > > called. > > Given that MND shouldn't be changed here, this should be as simple as > > saving away the CFG register, forcing it to XO speed by changing the = > > src > > and disabling dual edge in the CFG register (please don't call > > force_enable_clear with some frequency pointer, just do this inline > > here), and then rewriting the cfg register with the "real" settings for > > whatever frequency it's supposed to run at and then returning from this > > function. > > = > > I guess we have to do a read cfg from hardware, write cfg, hit update > > config, and then write cfg again each time we disable. For enable, we > > just do an update config (if it's dirty?) inside of a force > > enable/disable pair. And set_rate doesn't really change except it = > > either > > does or doesn't hit the update config bit if the clk is enabled or > > disabled respectively. > > = > = > We have done the below changes suggested by you and that logic seems to = > be > working fine. But we have one concern about leaving the RCG registers in > dirty state and would like to have a little bit modification as = > explained > below: > = > Suggested Logic: > 1. set_rate()--> Update CFG, M, N and D registers and don't hit the = > update > bit if clock is disabled - call new = > __clk_rcg2_configure(). > Above will make the CFG register as dirty. > = > 2. _disable()--> 2.1 - Store the CFG register configuration in a = > variable. > 2.2 - Move to the safe source (XO) and hit the update = > bit. > It will only touch the CFG register and M, N, D > register values will remain as it was. > 2.3 - Write back the stored CFG value done in step #2.1 > This will again redirty the CFG register. > = > 3. _enable()--> Just hit the update bit as the configuration write will > be taken care in the steps #1 and #2. > = > It would be great if we don't redirty the CFG register and leave the RCG > CFG register to at safe source(XO) in disable() path. > = > This would help us to debug the issues where device crashes and we want > to dump the RCG registers to know whether from software, we have = > actually > moved to safe source or not. Otherwise, we would get the dirty register > values in crash dumps. > = > So instead of writing back the stored CFG(corresponding to real rate > settings) in disable path, we want to restore the stored CFG in enable > path and then hit the update bit. > CFG configuration store can happen at two places - set_rate() and = > disable() > path and above logic will be modified as below: > = > 1. set_rate()--> 1.1 - Update CFG, M, N and D registers and don't hit = > the > update bit if clock is disabled. > 1.2 - Store CFG register value in 'current_cfg' member > of 'rcg2' structure. > = > 2. _disable()--> 2.1 - Store the CFG register value in 'current_cfg' = > before > switching to the safe source (XO). > 2.2 - Move to the safe source (XO) and hit the update = > bit. > Now RCG configuration wil not be dirty. > = > 3. _enable()--> 3.1 - Check for 'current_cfg' value and if 0 then = > return. > This would catch the below one time condition: > - when clk_enable() gets call without set_rate(). We want clk_enable() to work without set_rate() though. So returning 0 if the value is 0 is wrong. > 3.2 - Write the CFG value from 'current_cfg' to CFG = > register. > 3.2 - Hit the update bit as we have already written the = > latest > configuration in step #3.2. > 3.3 - Clear the 'current_cfg' value. > = > We feel above logic will work as expected and in this way, we don't have = > CFG > registers in dirty state when clock is disabled. > Could you please inform us your thoughts about above implementation and = > based > on that I will send the required changes. > = If you want to save away current_cfg in a memory location so you know what it was before it was dirty, then perhaps that needs to be a debug patch that you stack on top when debugging. In the end, it would just be saving the state of the frequency setting that we have in software though, and that would be the latest rate of the clk we have configured the clk for. There aren't any mux switches going on when the clk is off, so you're saying you want to know the rate of the clk that the kernel set when we turned the clk off, which we already have with the clk rate. I'm confused.=20