From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BDDB4C2D0E5 for ; Mon, 30 Mar 2020 14:54:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 92AFD20781 for ; Mon, 30 Mar 2020 14:54:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="L9/0Hme3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728159AbgC3OyC (ORCPT ); Mon, 30 Mar 2020 10:54:02 -0400 Received: from mail-qv1-f68.google.com ([209.85.219.68]:32829 "EHLO mail-qv1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727929AbgC3OyB (ORCPT ); Mon, 30 Mar 2020 10:54:01 -0400 Received: by mail-qv1-f68.google.com with SMTP id p19so9048618qve.0 for ; Mon, 30 Mar 2020 07:54:00 -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=blx2EeDdnBRgDBCmx0XMfKGgb9N83dhB/30meNy//yxdeZBwtGem2bxduO//hvrRnM DGudtLPzoYoarrIN+NF9QTstlhwS4YwBLAyoq5gkH0FSEiQor5yNNAcshSUQ6ugylJbH xLs3iLPMADErHXcUMTjiDZT+B3vHL9daVJYU9JxAlLdQdevX6vqWed6+rRayQ4H03bMi x2B8OSzGvkbdcKiyYb5kTGDEEjp20EeZFt3tbCn/sY3kOZJLzlA/gr9/5nkYvZ62U806 ZFITNoxWX11wq4nB1T3USc91ABeU0+DpvapxXHPVlghfE4umPa9IVEVGpmF2OCbdlXmF blaw== X-Gm-Message-State: ANhLgQ09sBbFW2G8++AsHgmmdb7TGRQWatQG+hb76gCIkhbMfslv8+VS 8aWK6C+3XXc+/ZsonGnOiYLILA== X-Google-Smtp-Source: ADFU+vvnZVsf13I2tKyzEPZbzZSTUzrSmDWcuIiitXTu0rbnYah/+4rhMe7ysN6LuRmkXvkXtRCo3Q== 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: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@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