Received: by 10.192.165.148 with SMTP id m20csp2918519imm; Mon, 7 May 2018 03:34:31 -0700 (PDT) X-Google-Smtp-Source: AB8JxZofGrLvraQi3Mcg7nT/Oizxi5cXBhj5fyiMuVW72mWHFztrf16U9ewdlcHn7UUsuWt2BLtM X-Received: by 2002:a17:902:5a5:: with SMTP id f34-v6mr37149986plf.288.1525689271347; Mon, 07 May 2018 03:34:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525689271; cv=none; d=google.com; s=arc-20160816; b=WcU0hYPieeRMiZy/m+JLIpZe9nVwNARBgC8+RKoTqwBxA9XTRhrMyMkXytrch37Wvs dxUbWK2icMD4d62XswGVuPmr/rkE9/RcJHXLvOEWkWUPO1Ct9v6iAtHlf2xSeFIaAfss C8i6VaBQmBrvNvor2FCCsy3tzr7wWyXoRRe77qZiEqdKWIJKfnnqFSZ6eLrPYibYbjg8 Wqv9t5wsjiMMsBecCIKHEefnKTz04x1Qb5G3qQtVZr1Gp2CCv10pdQEr+JN50+bKdStA //v1FdmXTxBl7+UX9asdQYGHBhS07voV9PWihfhuNYOsBpkX/QMbBxAAPtzNUgSwcIke n4/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=5iUpupafCXU9n1NtOGJuwpcP2VZFkDSIIgCrhPEAcrE=; b=Ih5gnaEEOEqlMypHFnHQDrdSXf/eJUckGKs1vIj89CEQ7pNlPcL5BQML4kvU5d3jD/ Pbn0e5hDyA0BYCI05h5h/dEbJ4MUIfdgxF1XkwQXLZ+bK9oDqvvzjgO/nURnAeWeIee1 +T9tRO0lScgWDuJPXkMLxC4iVrOZeCu7zY0GFtE37a8/LPWAGg1KCvkABag/fyVs8fv6 le7kAiyQe2xjYsgj3PqDyZdG/KKMUzTq78WaicM+3GBJ3LyIH5IGUQ9nz/AZU5Sqh0Px ZBJKHoaV7R7g0JdwVumgJPh5sSDd9Y6DhGTQzywtCKWBNFZ+TBIOiFB72ZKb/Lmd+0rN RQ9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=Z4n99Uou; dkim=pass header.i=@codeaurora.org header.s=default header.b=dUaB6pKG; 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 m2si18511598pfb.259.2018.05.07.03.34.16; Mon, 07 May 2018 03:34:31 -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=Z4n99Uou; dkim=pass header.i=@codeaurora.org header.s=default header.b=dUaB6pKG; 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 S1752170AbeEGKdh (ORCPT + 99 others); Mon, 7 May 2018 06:33:37 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:55656 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750795AbeEGKde (ORCPT ); Mon, 7 May 2018 06:33:34 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 31F7660A06; Mon, 7 May 2018 10:33:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1525689214; bh=LECbUrLuKUErg0pfVvGaAvNS2yipuar962raIC8M9DY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Z4n99Uou/mdy6GguI9N2cAxMEtZrhff++1My4TbnJXsJrPJMp9N0OG+iJKQvomHHA PAj7GNbHAds8znrxNTxsaHb5PT+n+sSEVe3y7OfvCwtHQVifXKSj6HrestVldxH5lz h9dzTnKZfWpOtED9BnSOtmBRgRVN3/I+uztc34XM= 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 mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 3680160271; Mon, 7 May 2018 10:33:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1525689213; bh=LECbUrLuKUErg0pfVvGaAvNS2yipuar962raIC8M9DY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dUaB6pKG2ZDzUO+tGZYVhomhpEzvQw9xeGhMU4SVrw4jJ6H679ud5wwRkRKWdj1+J lwUwSMTbxMas+q24dARgHLRCgoZooOnXHQLP6h3XZ1xZWULkIjgM7It8qmuWjrJMmA KUxmv73P/GMmqnucDoD6+Z4oU9ENGoVv+NlFn7I8= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 07 May 2018 16:03:33 +0530 From: Amit Nischal To: Stephen Boyd 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 Subject: Re: [PATCH v6 1/3] clk: qcom: Configure the RCGs to a safe source as needed In-Reply-To: <152549069940.138124.10210385659890209429@swboyd.mtv.corp.google.com> 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> <152549069940.138124.10210385659890209429@swboyd.mtv.corp.google.com> Message-ID: X-Sender: anischal@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-05-05 08:54, Stephen Boyd wrote: > 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 = to_clk_rcg2(hw); >> >> + struct freq_tbl safe_src_tbl = { 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 = 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. Thanks for the suggestions. We will implement the new ops with the below logic which you suggested earlier i.e. re-dirtying the RCG in disable() path with real CFG settings and in enable() path, only hit the update bit. 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.