Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2527731ybb; Mon, 30 Mar 2020 07:54:44 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsR0y00ERZFzLA4eAWfAUXGJC86Pr52ZGnVYHJlHm5QXpge7eZcQrEz/Is/HnPDb9O0fM2s X-Received: by 2002:aca:3c56:: with SMTP id j83mr8083434oia.52.1585580084540; Mon, 30 Mar 2020 07:54:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585580084; cv=none; d=google.com; s=arc-20160816; b=V4k/197r/pKNc3QdLJiDnzETkmgpq4F4Yfj0HIvKYVRevuqBCMhCRsRSP/KTKP58/w 1yRJuqu7e1avfACPza1JgJwQaF5rfNYkxu7rcrMyxK6nK96ZtvbGuBb+nRSzoQKv1poz zVv5UNAYAvKP88SIMmyzn7nXluO/PFTiv0KgniCYk/UQ9aQkwL6azTkBaBfQ2dGVDkst iYVs4DEeMR6H0WiLoHQopGs3RIntjLb6cKkoxQ4VWYN4DF0I6WYyXbZ0S8oNP5afGh99 cWh2KD/CKZLsRyb3pWLfYu2Ppgw3l55Hgv9D/pZqaetux6n4trJQKLxYIl1U1KYG9Za0 lf0w== 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:dkim-signature; bh=Ku5iL1N6RANAABzr84iAJg9CN/CMxTxUbEuZrAn7SbU=; b=M4OX0Ir09BjXNBLI8GnmvjrnT9KTz6ptkPi3a0Rp3OwPIPIG/PLSfInvMhgxnz1Q3t KfMPdCukEImPaMpePa7yGljcVXFKBLI73JdGOiMbDHf+CQFU+cwgqh4Q8/PNgx//mTnB VfWhLZpB/F517tL9NTzYQjptFpcWzYD6stSK1jaml8fnACItyHwVNNBpFkVYfHet9kTX tN8dRVc3chK4iL2CsdmLgpcbp6wYDN1pyynWnpbz6IcRYhWpMPyRXgkbnVPhOfL5CREe z9vWXfcCtVr8YzgTT7woyzIZN7du30E5LBBO2ryxmvz4wt4iZI9qGAHtJxtDPc/pONc/ D9IA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="L9/0Hme3"; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e13si6745583oom.86.2020.03.30.07.54.31; Mon, 30 Mar 2020 07:54:44 -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=@linaro.org header.s=google header.b="L9/0Hme3"; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728031AbgC3OyF (ORCPT + 99 others); Mon, 30 Mar 2020 10:54:05 -0400 Received: from mail-qv1-f67.google.com ([209.85.219.67]:41987 "EHLO mail-qv1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727929AbgC3OyC (ORCPT ); Mon, 30 Mar 2020 10:54:02 -0400 Received: by mail-qv1-f67.google.com with SMTP id ca9so9028006qvb.9 for ; Mon, 30 Mar 2020 07:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ku5iL1N6RANAABzr84iAJg9CN/CMxTxUbEuZrAn7SbU=; b=L9/0Hme32NofXz992b6CsrXgGCn+cAPnw0YKmlXlaEVc2EdsrME7DA1dyG6E68jsb5 +lEdHtcSG+Jh7vGSwM5eL03dAWRakzA5SVmGtw1s2vdArPYrqPo9j0GoPl6NzQSn0anC p4aaijoNZEDfjF9IzjVZRsWMrtm3Wi7rG/HP1SQ1OUc+hOa1qJouNTG9FTkRYpAKjZAD jhfcB0SpfkiH+Ycu3+SACdv1LE7IqPq71vnEZTCTWrRZ1ugePDlBu4g5uFUam58Vel0g pSywvkBrhQ2WvVjiobH6uT7Uyh8skIVlfpqAsGNhIiHl+BWEc20xyZzQrscHnvgbbkWb yJCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ku5iL1N6RANAABzr84iAJg9CN/CMxTxUbEuZrAn7SbU=; b=DbKUGjM4y9Hg9/5d12q90LQC/AdwL/tKWsq48EasfIxaMYSgA0UQEv42XgA7i8BxQi GcqFK5SAVVY7Uyrn4RsM1oUTIyLIFIcEhA5mDxBB2O06FdV1E9Rg4oW5leutq+PJZv/m XkqWlX1p2MVxs7/ZlhX2ID3X6JmZUNSmoSuCfwiaasUBKHyF4PaZ34RDL69LyWi7iVHu K8jEpYjixwZcw6IjmxtHp5480i4toEWE70WZRVaHtWM/DRsDyciYxJKdlcpUqk1PI7Pe APFhYeE7XXJ5C2mkc3sagKuzYuQkxzpWx3QEUUt7LQ8h8HQNO2pTQgXchPoZIbygVVRW PjtQ== X-Gm-Message-State: ANhLgQ2hWMREhJrQ+/FP2fwP2fk4ZksV8aJiUoqL+JtlS8AFmhRUEkq+ ZPWhXDbOILtSSRNvfxY+DdVUKXeiUJg= X-Received: by 2002:a0c:e08d:: with SMTP id l13mr12253135qvk.216.1585580040023; Mon, 30 Mar 2020 07:54:00 -0700 (PDT) Received: from [192.168.1.92] (pool-71-255-246-27.washdc.fios.verizon.net. [71.255.246.27]) by smtp.gmail.com with ESMTPSA id 73sm10651439qkf.82.2020.03.30.07.53.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Mar 2020 07:53:59 -0700 (PDT) Subject: Re: [Patch v5 4/6] soc: qcom: Extend RPMh power controller driver to register warming devices. To: Bjorn Andersson Cc: rui.zhang@intel.com, ulf.hansson@linaro.org, daniel.lezcano@linaro.org, agross@kernel.org, robh@kernel.org, amit.kucheria@verdurent.com, mark.rutland@arm.com, rjw@rjwysocki.net, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200320014107.26087-1-thara.gopinath@linaro.org> <20200320014107.26087-5-thara.gopinath@linaro.org> <20200327225345.GH5063@builder> From: Thara Gopinath Message-ID: Date: Mon, 30 Mar 2020 10:53:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200327225345.GH5063@builder> 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 3/27/20 6:53 PM, Bjorn Andersson wrote: > On Thu 19 Mar 18:41 PDT 2020, Thara Gopinath wrote: > >> RPMh power control hosts power domains that can be used as >> thermal warming devices. Register these power domains >> with the generic power domain warming device thermal framework. >> >> Reviewed-by: Ulf Hansson >> Signed-off-by: Thara Gopinath >> --- >> >> v3->v4: >> - Introduce a boolean value is_warming_dev in rpmhpd structure to >> indicate if a generic power domain can be used as a warming >> device or not.With this change, device tree no longer has to >> specify which power domain inside the rpmh power domain provider >> is a warming device. >> - Move registering of warming devices into a late initcall to >> ensure that warming devices are registered after thermal >> framework is initialized. > > This information is lost when we merge patches, as such I would like > such design decisions to be described in the commit message itself. > But... > >> >> drivers/soc/qcom/rpmhpd.c | 37 ++++++++++++++++++++++++++++++++++++- >> 1 file changed, 36 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c >> index 7142409a3b77..4e9c0bbb8826 100644 >> --- a/drivers/soc/qcom/rpmhpd.c >> +++ b/drivers/soc/qcom/rpmhpd.c >> @@ -11,6 +11,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -48,6 +49,7 @@ struct rpmhpd { >> bool enabled; >> const char *res_name; >> u32 addr; >> + bool is_warming_dev; >> }; >> >> struct rpmhpd_desc { >> @@ -55,6 +57,8 @@ struct rpmhpd_desc { >> size_t num_pds; >> }; >> >> +const struct rpmhpd_desc *global_desc; >> + >> static DEFINE_MUTEX(rpmhpd_lock); >> >> /* SDM845 RPMH powerdomains */ >> @@ -89,6 +93,7 @@ static struct rpmhpd sdm845_mx = { >> .pd = { .name = "mx", }, >> .peer = &sdm845_mx_ao, >> .res_name = "mx.lvl", >> + .is_warming_dev = true, >> }; >> >> static struct rpmhpd sdm845_mx_ao = { >> @@ -452,7 +457,14 @@ static int rpmhpd_probe(struct platform_device *pdev) >> &rpmhpds[i]->pd); >> } >> >> - return of_genpd_add_provider_onecell(pdev->dev.of_node, data); >> + ret = of_genpd_add_provider_onecell(pdev->dev.of_node, data); >> + >> + if (ret) >> + return ret; >> + >> + global_desc = desc; >> + >> + return 0; >> } >> >> static struct platform_driver rpmhpd_driver = { >> @@ -469,3 +481,26 @@ static int __init rpmhpd_init(void) >> return platform_driver_register(&rpmhpd_driver); >> } >> core_initcall(rpmhpd_init); >> + >> +static int __init rpmhpd_init_warming_device(void) >> +{ >> + size_t num_pds; >> + struct rpmhpd **rpmhpds; >> + int i; >> + >> + if (!global_desc) >> + return -EINVAL; >> + >> + rpmhpds = global_desc->rpmhpds; >> + num_pds = global_desc->num_pds; >> + >> + if (!of_find_property(rpmhpds[0]->dev->of_node, "#cooling-cells", NULL)) >> + return 0; >> + >> + for (i = 0; i < num_pds; i++) >> + if (rpmhpds[i]->is_warming_dev) >> + of_pd_warming_register(rpmhpds[i]->dev, i); >> + >> + return 0; >> +} >> +late_initcall(rpmhpd_init_warming_device); > > ...why can't this be done in rpmhpd_probe()? > > In particular with the recent patches from John Stultz to allow rpmhpd > to be built as a module I don't think there's any guarantees that > rpmh_probe() will have succeeded before rpmhpd_init_warming_device() > executes. It is to take care of boot order. So this has to happen after the thermal framework is initialized. Thermal framework is initialized with core_initcall. Can I move the rpmhpd init as a postcore_initcall ? Then I can get rid of this separate function and keep it as part of probe. > > Regards, > Bjorn > -- Warm Regards Thara