Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4435745imm; Wed, 30 May 2018 05:45:14 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLJgXHCzua2EyqSck3o/4pXGAUxBKL7Kv2yUeL+WNptbSYSJbx0KHdPe6UBX+EhOzpzetmI X-Received: by 2002:a65:4309:: with SMTP id j9-v6mr2093223pgq.375.1527684314139; Wed, 30 May 2018 05:45:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527684314; cv=none; d=google.com; s=arc-20160816; b=aOXXSb6O8iMnK2ClhXfwNjsZAEPheR2hCG67c2phYb0a5WlNMs6bKaMtPzwq1gncac K6jxlYt7UPCq8o/E3Ex9GTAgAkC8cJZk8SrpY2G6dwruLJQvujBs7BUJiWXCxXtx+TU2 RpTHv+IbtY2QvLK47aSjEorTScv48tBd3tTYEuy2YVWGlHTdLq2VvqeRLZctuNXaQ18u AgYwds/x9okepTjAobZKnubXnHjp7e48pmHMhPem2Fpu3UB0PG0g40S7706IvHos4erq spo3NhfP6C88r6E3ubc5+d/EAgS81p5AUxtJ3B+vZhWepfsHZe+BZvUbpeP9uRaSCo/p gUcg== 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=1LQpH4y9KPWV6elpVOIqzxHgxbSVPNZg60j8vSWoNL0=; b=ffq5viUcsn/DI5A7QLYOZqAT8cODVcxTIGZJfXlt02Yhuxs95Hhmul12E9+94Qn6RW HPawq4hXzdLy/KNt1W+8UpOjP5ET65wQXNHQWzAd/nA2nqrx44d5hljtNeTGRja/Ghlr I8VMiu8DLpC2yWoLmjdC8p4IbBJnr0rZufY198rGh0XwMbqXLMpLOFTnfvl6YwObSIhv NuLN0YuVqzzKnEwombQjwX9Bp1bCiy4pcO2Np3zkfo02xDVRklCRMnbiYgIVCyG0DGSF jM/8TJP52Du4SgTkSnHYYMVp2IMhyLlIdwCaGZar3I7lOGR0NfHKPN0Y2FxMnjEnv9cO CQ1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=DO/nva/A; 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 m4-v6si33923585plt.561.2018.05.30.05.44.59; Wed, 30 May 2018 05:45:14 -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=DO/nva/A; 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 S1752687AbeE3Moa (ORCPT + 99 others); Wed, 30 May 2018 08:44:30 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:41888 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752121AbeE3Mo0 (ORCPT ); Wed, 30 May 2018 08:44:26 -0400 Received: by mail-io0-f194.google.com with SMTP id t5-v6so8841551ioa.8 for ; Wed, 30 May 2018 05:44:26 -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=1LQpH4y9KPWV6elpVOIqzxHgxbSVPNZg60j8vSWoNL0=; b=DO/nva/A0wIH9k37QHgHc+x4HMn8pHaGRPwmEscONaVep3piR1Hg3aTJcqi/c2BjLq 8k2m49Nu9WnXW8aYRipQXaAOakMMS0O2ZYkclJEkDItNgLTT8qLDHcrvCwSAn1CHPyIy 0tS0+eLDXX76+uuSZSsAizlblMhSbNVvoJnRo= 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=1LQpH4y9KPWV6elpVOIqzxHgxbSVPNZg60j8vSWoNL0=; b=QiawMmosyt2U4ngc4zwLsV+vgWOjr/eEfRAUfWFaux1Bt3rB3WK1P68W+5QZm1rsUG GueAb98gOqyzlgZ/nGiqIs1LwpClVmISDZ0WeBZPR83wkLR8I9OnfgK30Xxzc5zzR3e0 Gx3yKREF7YJXxG7X8QaGaEn7fCvkfeaQEG1wfTyxhht6YBUqCaZv9TbTPHzOlEAdb4+J L23SPPWMUBDIrfvJctzYN17wndxY1TMzVU0+mXdwY8DcAP2u+dubiDufj895PfSV2/g8 YVJsrI/5DhcM+yAXxAi+do/qzzFSkV+PanaktElTMkOTrN2nys/TlnHj5BXF9jxdQAD2 ktvA== X-Gm-Message-State: APt69E2GonIkdLJIaP1NiEC4Fup5aye6Vm9Yyw/XxwnxAS56yuqZEyOK f/wGGr06OxoohJydfD5ikhYzsEz3Bpbp8uqCaJmgtQ== X-Received: by 2002:a6b:84e1:: with SMTP id o94-v6mr2019678ioi.119.1527684265769; Wed, 30 May 2018 05:44:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:c054:0:0:0:0:0 with HTTP; Wed, 30 May 2018 05:44:25 -0700 (PDT) In-Reply-To: <0e07d577-9728-e97a-2da0-dd7dd324f058@codeaurora.org> References: <20180525100121.28214-1-rnayak@codeaurora.org> <20180525100121.28214-2-rnayak@codeaurora.org> <0e07d577-9728-e97a-2da0-dd7dd324f058@codeaurora.org> From: Ulf Hansson Date: Wed, 30 May 2018 14:44:25 +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 [...] >>> + >>> +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. > > This is all static data per SoC. The macros will keep the new additions > needed for every new SoC to a minimal. Currently this supports only > msm8996. Right, that's fine then. > >> >> Anyway, I think you should convert to allocate these structs >> dynamically from the heap (kzalloc/kcalloc), instead of statically as >> above. However, I assume this is still doable!? [...] >>> + 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? > > The hierarchy if any is all handled by the remote core (RPM in this case). > For Linux its just a flat view. Okay, thanks for clarifying! Kind regards Uffe