linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukasz Luba <lukasz.luba@arm.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-imx@nxp.com
Cc: Morten.Rasmussen@arm.com, Dietmar.Eggemann@arm.com,
	javi.merino@arm.com, cw00.choi@samsung.com,
	b.zolnierkie@samsung.com, rjw@rjwysocki.net,
	sudeep.holla@arm.com, viresh.kumar@linaro.org, nm@ti.com,
	sboyd@kernel.org, rui.zhang@intel.com,
	amit.kucheria@verdurent.com, mingo@redhat.com,
	peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, rostedt@goodmis.org,
	qperret@google.com, bsegall@google.com, mgorman@suse.de,
	shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com,
	kernel@pengutronix.de, khilman@kernel.org, agross@kernel.org,
	bjorn.andersson@linaro.org, robh@kernel.org,
	matthias.bgg@gmail.com, steven.price@arm.com,
	tomeu.vizoso@collabora.com, alyssa.rosenzweig@collabora.com,
	airlied@linux.ie, daniel@ffwll.ch, liviu.dudau@arm.com,
	lorenzo.pieralisi@arm.com, patrick.bellasi@matbug.net,
	orjan.eide@arm.com, rdunlap@infradead.org, mka@chromium.org
Subject: Re: [PATCH v5 1/5] PM / EM: add devices to Energy Model
Date: Mon, 6 Apr 2020 17:07:11 +0100	[thread overview]
Message-ID: <2a70b4ed-f18f-c1e6-1e8c-e4747807f276@arm.com> (raw)
In-Reply-To: <6b980e2a-c15c-0718-14b8-e8aa7510c832@linaro.org>



On 4/6/20 3:58 PM, Daniel Lezcano wrote:
> 
> Hi Lukasz,
> 
> 
> On 06/04/2020 15:29, Lukasz Luba wrote:
>> Hi Daniel,
>>
>> Thank you for the review.
>>
>> On 4/3/20 5:05 PM, Daniel Lezcano wrote:
>>>
>>> Hi Lukasz,
>>>
>>>
>>> On 18/03/2020 12:45, Lukasz Luba wrote:
>>>> Add support of other devices into the Energy Model framework not only
>>>> the
>>>> CPUs. Change the interface to be more unified which can handle other
>>>> devices as well.
>>>
>>> thanks for taking care of that. Overall I like the changes in this patch
>>> but it hard to review in details because the patch is too big :/
>>>
>>> Could you split this patch into smaller ones?
>>>
>>> eg. (at your convenience)
>>>
>>>    - One patch renaming s/cap/perf/
>>>
>>>    - One patch adding a new function:
>>>
>>>       em_dev_register_perf_domain(struct device *dev,
>>>                  unsigned int nr_states,
>>>                  struct em_data_callback *cb);
>>>
>>>      (+ EXPORT_SYMBOL_GPL)
>>>
>>>       And em_register_perf_domain() using it.
>>>
>>>    - One converting the em_register_perf_domain() user to
>>>      em_dev_register_perf_domain
>>>
>>>    - One adding the different new 'em' functions
>>>
>>>    - And finally one removing em_register_perf_domain().
>>
>> I agree and will do the split. I could also break the dependencies
>> for future easier merge.
>>
>>>
>>>
>>>> Acked-by: Quentin Perret <qperret@google.com>
>>>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>>>> ---
>>>
>>> [ ... ]
>>>
>>>>    2. Core APIs
>>>> @@ -70,14 +72,16 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM
>>>> framework.
>>>>    Drivers are expected to register performance domains into the EM
>>>> framework by
>>>>    calling the following API::
>>>>    -  int em_register_perf_domain(cpumask_t *span, unsigned int
>>>> nr_states,
>>>> -                  struct em_data_callback *cb);
>>>> +  int em_register_perf_domain(struct device *dev, unsigned int
>>>> nr_states,
>>>> +        struct em_data_callback *cb, cpumask_t *cpus);
>>>
>>> Isn't possible to get rid of this cpumask by using
>>> cpufreq_cpu_get() which returns the cpufreq's policy and from their get
>>> the related cpus ?
>>
>> We had similar thoughts with Quentin and I've checked this.
> 
> Yeah, I suspected you already think about that :)
> 
>> Unfortunately, if the policy is a 'new policy' [1] it gets
>> allocated and passed into cpufreq driver ->init(policy) [2].
>> Then that policy is set into per_cpu pointer for each related_cpu [3]:
>>
>> for_each_cpu(j, policy->related_cpus)
>>      per_cpu(cpufreq_cpu_data, j) = policy;
>>
>>   
>> Thus, any calls of functions (i.e. cpufreq_cpu_get()) which try to
>> take this ptr before [3] won't work.
>>
>> We are trying to register EM from cpufreq_driver->init(policy) and the
>> per_cpu policy is likely to be not populated at that phase.
> 
> What is the problem of registering at the end of the cpufreq_online ?

We want to enable driver developers to choose one of two options for the
registration of Energy Model:
1. a simple one via dev_pm_opp_of_register_em(), which uses default
    callback function calculating power based on: voltage, freq
    and DT entry 'dynamic-power-coefficient' for each OPP
2. a more sophisticated, when driver provides callback function, which
   will be called from EM for each OPP to ask for related power;
   This interface could also be used by devices which relay not only
   on one source of 'voltage', i.e. manipulate body bias or have
   other controlling voltage for gates in the new 3D transistors. They
   might provide custom callback function in their cpufreq driver.
   This is used i.e. in cpufreq drivers which use firmware to get power,
   like scmi-cpufreq.c;

To meet this requirement the registration of EM is moved into cpufreq
drivers, not in the framework i.e cpufreq_online(). If we could limit
the support for only option 1. then we could move the registration
call into cpufreq framework and clean the cpufreq drivers.

Regards,
Lukasz

  reply	other threads:[~2020-04-06 16:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18 11:45 [PATCH v5 0/5] Add support for devices in the Energy Model Lukasz Luba
2020-03-18 11:45 ` [PATCH v5 1/5] PM / EM: add devices to " Lukasz Luba
2020-04-03 16:05   ` Daniel Lezcano
2020-04-06 13:29     ` Lukasz Luba
2020-04-06 14:58       ` Daniel Lezcano
2020-04-06 16:07         ` Lukasz Luba [this message]
2020-04-06 21:17           ` Daniel Lezcano
2020-04-07  9:32             ` Lukasz Luba
2020-03-18 11:45 ` [PATCH v5 2/5] OPP: refactor dev_pm_opp_of_register_em() and update related drivers Lukasz Luba
2020-04-01  7:19   ` Lukasz Luba
2020-04-03 16:21   ` Daniel Lezcano
2020-04-06 14:05     ` Lukasz Luba
2020-03-18 11:45 ` [PATCH v5 3/5] thermal: devfreq_cooling: Use PM QoS to set frequency limits Lukasz Luba
2020-04-03 16:43   ` Daniel Lezcano
2020-04-03 17:18     ` Matthias Kaehlcke
2020-04-03 17:19       ` Daniel Lezcano
2020-03-18 11:45 ` [PATCH v5 4/5] thermal: devfreq_cooling: Refactor code and switch to use Energy Model Lukasz Luba
2020-04-01 10:49   ` Lukasz Luba
2020-04-03 17:44   ` Daniel Lezcano
2020-04-06 13:35     ` Lukasz Luba
2020-03-18 11:45 ` [PATCH v5 5/5] drm/panfrost: Register devfreq cooling and attempt to add " Lukasz Luba
2020-03-18 13:11   ` Alyssa Rosenzweig
2020-03-23 13:50     ` Lukasz Luba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2a70b4ed-f18f-c1e6-1e8c-e4747807f276@arm.com \
    --to=lukasz.luba@arm.com \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=Morten.Rasmussen@arm.com \
    --cc=agross@kernel.org \
    --cc=airlied@linux.ie \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=amit.kucheria@verdurent.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=bsegall@google.com \
    --cc=cw00.choi@samsung.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=festevam@gmail.com \
    --cc=javi.merino@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kernel@pengutronix.de \
    --cc=khilman@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=mka@chromium.org \
    --cc=nm@ti.com \
    --cc=orjan.eide@arm.com \
    --cc=patrick.bellasi@matbug.net \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=rdunlap@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=rui.zhang@intel.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sboyd@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=steven.price@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=tomeu.vizoso@collabora.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).