Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4268212imm; Wed, 30 May 2018 02:18:02 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIzmpcVubfcOmlL5i3zg/jWoWp4tMwJeJgSNmw1QkKVhL+MIfV9EsBJZm1CMKvEmAx4w1Bj X-Received: by 2002:a17:902:a717:: with SMTP id w23-v6mr2078679plq.130.1527671882480; Wed, 30 May 2018 02:18:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527671882; cv=none; d=google.com; s=arc-20160816; b=JINW6YrCD1+1vJUMgkUzBtEIzrUIA1SSmhxF1KmSFYnYdv33eTZCRlTV/wQIIFO0wo C6mMmpMp8cZsOdErb7z5Oo4mgMys5Qm+28TuAWUPmGG9E0gt6ilJnv3ZpVkuF9eGoYBd perGEMfDcqV60oX3EMRyM2BWWApdbMjzqIqtSQ57MMk2K4ZKrLjS7lH4tXzgIcZXbBhG txiM7DjQJWarxQpw16JL5ysvAN5XcUg5S9pbdci/OtXv5tanty6SHxz5eIUUOL2VGm+v DhI9KbbVxmA+SMALWp7EKBYCSMuC/Wk25NEbBqfcvJvvWLEFg+c7skpfyvQHJFAy7OzG g5HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=BKtzdFgEdiH0RVp/wZHRe7/5buL9p8+yg05Tsxv6FHk=; b=tbIjOrLXu6mYwGGN+1F7rtw8GjCPFJyrH42aU4bV0fy381xqQKEnaS6oQovi1BuDj/ uygG76c573UEloY67dvcdezRJD90ONPoZqMrSZqlDx2WvT2DvFXrEfKBe/x7+N2FQ/G4 VVFPC2jdAGZdWTDHDEtJUCWyhQFdY5tvNQcVXp2Oz496xnsUOIOr/3XEaXyuieINL0X/ thZwn3eSx+6QA2b7jh17K1TcBQ0NQFHEH8pRVePjSdniu9rWWTc4dDUULXbxAM2wYiN0 OOpvtAUrHjTmcZwRsF4a1JDO3q3aDS14bSca61DbthiC1q/uxFV/deXAaAO7LfQyvcAZ 2UFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=YfFzhR/B; 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 u17-v6si26953860pgv.17.2018.05.30.02.17.48; Wed, 30 May 2018 02:18:02 -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=YfFzhR/B; 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 S965203AbeE3JRX (ORCPT + 99 others); Wed, 30 May 2018 05:17:23 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:39425 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965050AbeE3JRQ (ORCPT ); Wed, 30 May 2018 05:17:16 -0400 Received: by mail-io0-f194.google.com with SMTP id 200-v6so19782424ioz.6 for ; Wed, 30 May 2018 02:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BKtzdFgEdiH0RVp/wZHRe7/5buL9p8+yg05Tsxv6FHk=; b=YfFzhR/BoJwmyyg0ZmfPpw+/HnqdbItkY+7RwU3dy12MfbVdNdVhhnm1Xk+VxsE+2m hGow6gSQvgJj+sf1oBVXA3CgAH9K2IuwMIlDRLNvntFIki+tDRCzznYgL4jt0dhBDe+/ 4HX34Hzai1KyLCsT6Ivcqx6KBgNjCvD6czXEc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BKtzdFgEdiH0RVp/wZHRe7/5buL9p8+yg05Tsxv6FHk=; b=U2dGgLyObX696zGGweNFmLwO5iPDB+4pwEQR0KY1r2+hFibtd+4jki5swDVWrzQ3Ob 9H4+NRd61Oo5CWcfOK0Zjw/66FC+yH0uNGJdVU24XuTGe4aTcJuHu3GmvVUAunYHOCO1 /B5ea3mGJFG6m68lLwndLClmkwOFwNoX20Zf4GDYvzAAzEvcCbhsUZI9fdIPhtdaXzbJ MndRLoGv5gB/j6Sivrh9zRxBzvzrf+CAODUn8gOYpYm1BVuOnufRn1dRoToI7qJOOX4d xqz1aCp4ETe1IM4X7HQi/dS7eybbnhgYeLL2rMxlcjJjVicHIZkNhBbR5peBmx8swmh5 VsrQ== X-Gm-Message-State: APt69E1w7x7V7NUsmZ0ZbWlGImj4ATyUrIs+Nx9k97bFiJqr7aCdEG2Q XZPvt4JJvr89lQvBIZ9SoE621cZ7I5umnL13AeSrkg== X-Received: by 2002:a6b:1410:: with SMTP id 16-v6mr1450323iou.218.1527671836187; Wed, 30 May 2018 02:17:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:c054:0:0:0:0:0 with HTTP; Wed, 30 May 2018 02:17:15 -0700 (PDT) In-Reply-To: <20180525100121.28214-2-rnayak@codeaurora.org> References: <20180525100121.28214-1-rnayak@codeaurora.org> <20180525100121.28214-2-rnayak@codeaurora.org> From: Ulf Hansson Date: Wed, 30 May 2018 11:17:15 +0200 Message-ID: Subject: Re: [PATCH v2 1/6] soc: qcom: rpmpd: Add a powerdomain driver to model corners To: Rajendra Nayak Cc: Viresh Kumar , Stephen Boyd , Andy Gross , devicetree@vger.kernel.org, linux-arm-msm , Linux Kernel Mailing List , collinsd@codeaurora.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25 May 2018 at 12:01, Rajendra Nayak wrote: > The powerdomains for corners just pass the performance state set by the > consumers to the RPM (Remote Power manager) which then takes care > of setting the appropriate voltage on the corresponding rails to > meet the performance needs. > > We add all powerdomain data needed on msm8996 here. This driver can easily > be extended by adding data for other qualcomm SoCs as well. > > Signed-off-by: Rajendra Nayak > Signed-off-by: Viresh Kumar > --- > .../devicetree/bindings/power/qcom,rpmpd.txt | 55 ++++ Please split DT doc changes into separate patches, to simplify review. > drivers/soc/qcom/Kconfig | 9 + > drivers/soc/qcom/Makefile | 1 + > drivers/soc/qcom/rpmpd.c | 299 ++++++++++++++++++ > 4 files changed, 364 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmpd.txt > create mode 100644 drivers/soc/qcom/rpmpd.c > [...] > +++ b/drivers/soc/qcom/rpmpd.c > @@ -0,0 +1,299 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd) > + > +/* Resource types */ > +#define RPMPD_SMPA 0x61706d73 > +#define RPMPD_LDOA 0x616f646c > + > +/* Operation Keys */ > +#define KEY_CORNER 0x6e726f63 /* corn */ > +#define KEY_ENABLE 0x6e657773 /* swen */ > +#define KEY_FLOOR_CORNER 0x636676 /* vfc */ > + > +#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id) \ > + static struct rpmpd _platform##_##_active; \ > + static struct rpmpd _platform##_##_name = { \ > + .pd = { .name = #_name, }, \ > + .peer = &_platform##_##_active, \ > + .res_type = RPMPD_SMPA, \ > + .res_id = r_id, \ > + .key = KEY_CORNER, \ > + }; \ > + static struct rpmpd _platform##_##_active = { \ > + .pd = { .name = #_active, }, \ > + .peer = &_platform##_##_name, \ > + .active_only = true, \ > + .res_type = RPMPD_SMPA, \ > + .res_id = r_id, \ > + .key = KEY_CORNER, \ > + } > + > +#define DEFINE_RPMPD_CORN_LDOA(_platform, _name, r_id) \ > + static struct rpmpd _platform##_##_name = { \ > + .pd = { .name = #_name, }, \ > + .res_type = RPMPD_LDOA, \ > + .res_id = r_id, \ > + .key = KEY_CORNER, \ > + } > + > +#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type) \ > + static struct rpmpd _platform##_##_name = { \ > + .pd = { .name = #_name, }, \ > + .res_type = r_type, \ > + .res_id = r_id, \ > + .key = KEY_FLOOR_CORNER, \ > + } > + > +#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id) \ > + DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA) > + > +#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id) \ > + DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_LDOA) > + > +struct rpmpd_req { > + __le32 key; > + __le32 nbytes; > + __le32 value; > +}; > + > +struct rpmpd { > + struct generic_pm_domain pd; > + struct rpmpd *peer; > + const bool active_only; > + unsigned long corner; > + bool enabled; > + const char *res_name; > + const int res_type; > + const int res_id; > + struct qcom_smd_rpm *rpm; > + __le32 key; > +}; > + > +struct rpmpd_desc { > + struct rpmpd **rpmpds; > + size_t num_pds; > +}; > + > +static DEFINE_MUTEX(rpmpd_lock); > + > +/* msm8996 RPM powerdomains */ > +DEFINE_RPMPD_CORN_SMPA(msm8996, vddcx, vddcx_ao, 1); > +DEFINE_RPMPD_CORN_SMPA(msm8996, vddmx, vddmx_ao, 2); > +DEFINE_RPMPD_CORN_LDOA(msm8996, vddsscx, 26); > + > +DEFINE_RPMPD_VFC_SMPA(msm8996, vddcx_vfc, 1); > +DEFINE_RPMPD_VFC_LDOA(msm8996, vddsscx_vfc, 26); > + > +static struct rpmpd *msm8996_rpmpds[] = { > + [0] = &msm8996_vddcx, > + [1] = &msm8996_vddcx_ao, > + [2] = &msm8996_vddcx_vfc, > + [3] = &msm8996_vddmx, > + [4] = &msm8996_vddmx_ao, > + [5] = &msm8996_vddsscx, > + [6] = &msm8996_vddsscx_vfc, > +}; It's not my call, but honestly the above all macros makes the code less readable. Anyway, I think you should convert to allocate these structs dynamically from the heap (kzalloc/kcalloc), instead of statically as above. > + > +static const struct rpmpd_desc msm8996_desc = { > + .rpmpds = msm8996_rpmpds, > + .num_pds = ARRAY_SIZE(msm8996_rpmpds), > +}; > + > +static const struct of_device_id rpmpd_match_table[] = { > + { .compatible = "qcom,msm8996-rpmpd", .data = &msm8996_desc }, > + { } > +}; > +MODULE_DEVICE_TABLE(of, rpmpd_match_table); [...] > +static int rpmpd_aggregate_corner(struct rpmpd *pd) > +{ Isn't the aggregation of the performance states in genpd sufficient for your case? I guess this is SoC specific and needed anyways, but then could you perhaps add a few comments about what goes on here? > + int ret; > + struct rpmpd *peer = pd->peer; > + unsigned long active_corner, sleep_corner; > + unsigned long this_corner = 0, this_sleep_corner = 0; > + unsigned long peer_corner = 0, peer_sleep_corner = 0; > + > + to_active_sleep(pd, pd->corner, &this_corner, &this_sleep_corner); > + > + if (peer && peer->enabled) > + to_active_sleep(peer, peer->corner, &peer_corner, > + &peer_sleep_corner); > + > + active_corner = max(this_corner, peer_corner); > + > + ret = rpmpd_send_corner(pd, QCOM_RPM_ACTIVE_STATE, active_corner); > + if (ret) > + return ret; > + > + sleep_corner = max(this_sleep_corner, peer_sleep_corner); > + > + return rpmpd_send_corner(pd, QCOM_RPM_SLEEP_STATE, sleep_corner); > +} [...] > +static int rpmpd_probe(struct platform_device *pdev) > +{ > + int i; > + size_t num; > + struct genpd_onecell_data *data; > + struct qcom_smd_rpm *rpm; > + struct rpmpd **rpmpds; > + const struct rpmpd_desc *desc; > + > + rpm = dev_get_drvdata(pdev->dev.parent); > + if (!rpm) { > + dev_err(&pdev->dev, "Unable to retrieve handle to RPM\n"); > + return -ENODEV; > + } > + > + desc = of_device_get_match_data(&pdev->dev); > + if (!desc) > + return -EINVAL; > + > + rpmpds = desc->rpmpds; > + num = desc->num_pds; > + > + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL); > + if (!data) > + return -ENOMEM; > + > + data->domains = devm_kcalloc(&pdev->dev, num, sizeof(*data->domains), > + GFP_KERNEL); > + data->num_domains = num; > + > + for (i = 0; i < num; i++) { > + if (!rpmpds[i]) > + continue; > + > + rpmpds[i]->rpm = rpm; > + rpmpds[i]->pd.power_off = rpmpd_power_off; > + rpmpds[i]->pd.power_on = rpmpd_power_on; > + pm_genpd_init(&rpmpds[i]->pd, NULL, true); Question: Is there no hierarchical topology of the PM domains. No genpd subdomains? > + > + data->domains[i] = &rpmpds[i]->pd; > + } > + > + return of_genpd_add_provider_onecell(pdev->dev.of_node, data); > +} > + > +static int rpmpd_remove(struct platform_device *pdev) > +{ > + of_genpd_del_provider(pdev->dev.of_node); > + return 0; > +} > + > +static struct platform_driver rpmpd_driver = { > + .driver = { > + .name = "qcom-rpmpd", > + .of_match_table = rpmpd_match_table, > + }, > + .probe = rpmpd_probe, > + .remove = rpmpd_remove, > +}; > + > +static int __init rpmpd_init(void) > +{ > + return platform_driver_register(&rpmpd_driver); > +} > +core_initcall(rpmpd_init); > + > +static void __exit rpmpd_exit(void) > +{ > + platform_driver_unregister(&rpmpd_driver); > +} > +module_exit(rpmpd_exit); > + > +MODULE_DESCRIPTION("Qualcomm RPM Power Domain Driver"); > +MODULE_LICENSE("GPL v2"); > +MODULE_ALIAS("platform:qcom-rpmpd"); > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation > Besides the minor things above, this looks good to me. Kind regards Uffe