From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Lukasz Luba <lukasz.luba@arm.com>
Cc: Rob Herring <robh@kernel.org>,
daniel.lezcano@linaro.org, devicetree@vger.kernel.org,
vireshk@kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, sudeep.holla@arm.com,
Nicola Mazzucato <nicola.mazzucato@arm.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
chris.redpath@arm.com, morten.rasmussen@arm.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies
Date: Mon, 12 Oct 2020 23:01:33 +0100 [thread overview]
Message-ID: <20201012220132.GA1715@arm.com> (raw)
In-Reply-To: <9fe56600-ba7d-d3b6-eea3-885475d94d7a@arm.com>
Hey Lukasz,
I think after all this discussion (in our own way of describing things)
we agree on how the current cpufreq based FIE implementation is affected
in systems that use hardware coordination.
What we don't agree on is the location where that implementation (that
uses the new mask and aggregation) should be.
On Monday 12 Oct 2020 at 19:19:29 (+0100), Lukasz Luba wrote:
[..]
> The previous FIE implementation where arch_set_freq_scale()
> was called from the drivers, was better suited for this issue.
> Driver could just use internal dependency cpumask or even
> do the aggregation to figure out the max freq for cluster
> if there is a need, before calling arch_set_freq_scale().
>
> It is not perfect solution for software FIE, but one of possible
> when there is no hw counters.
>
[..]
> Difference between new FIE and old FIE (from v5.8) is that the new one
> purely relies on schedutil max freq value (which will now be missing),
> while the old FIE was called by the driver and thus it was an option to
> fix only the affected cpufreq driver [1][2].
>
My final argument is that now you have 2 drivers that would need this
support, next you'll have 3 (the new mediatek driver), and in the future
there will be more. So why limit and duplicate this functionality in the
drivers? Why not make it generic for all drivers to use if the system
is using hardware coordination?
Additionally, I don't think drivers should not even need to know about
these dependency/clock domains. They should act at the level of the
policy, which in this case will be at the level of each CPU.
Thanks,
Ionela.
> IMO we can avoid this new cpumask in policy.
>
> Regards,
> Lukasz
>
> [1] https://elixir.bootlin.com/linux/v5.8/source/drivers/cpufreq/scmi-cpufreq.c#L58
> [2] https://elixir.bootlin.com/linux/v5.8/source/drivers/cpufreq/qcom-cpufreq-hw.c#L79
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-12 22:02 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 9:53 [PATCH v2 0/2] CPUFreq: Add support for cpu performance dependencies Nicola Mazzucato
2020-09-24 9:53 ` [PATCH v2 1/2] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies Nicola Mazzucato
2020-10-08 13:42 ` Ionela Voinescu
2020-09-24 9:53 ` [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Nicola Mazzucato
2020-10-06 7:19 ` Viresh Kumar
2020-10-07 12:58 ` Nicola Mazzucato
2020-10-08 11:02 ` Viresh Kumar
2020-10-08 15:03 ` Ionela Voinescu
2020-10-08 15:57 ` Rafael J. Wysocki
2020-10-08 17:08 ` Ionela Voinescu
2020-10-12 16:06 ` Sudeep Holla
2020-10-08 16:00 ` Nicola Mazzucato
2020-10-09 5:39 ` Viresh Kumar
2020-10-09 11:10 ` Nicola Mazzucato
2020-10-09 11:17 ` Viresh Kumar
2020-10-09 14:01 ` Rob Herring
2020-10-09 15:28 ` Nicola Mazzucato
2020-10-12 4:19 ` Viresh Kumar
2020-10-12 10:22 ` Lukasz Luba
2020-10-12 10:50 ` Rafael J. Wysocki
2020-10-12 11:05 ` Lukasz Luba
2020-10-12 10:59 ` Ionela Voinescu
2020-10-12 13:48 ` Lukasz Luba
2020-10-12 16:30 ` Ionela Voinescu
2020-10-12 18:19 ` Lukasz Luba
2020-10-12 22:01 ` Ionela Voinescu [this message]
2020-10-13 11:53 ` Rafael J. Wysocki
2020-10-13 12:39 ` Ionela Voinescu
2020-10-15 15:56 ` Rafael J. Wysocki
2020-10-15 18:38 ` Ionela Voinescu
2020-10-12 13:59 ` Rob Herring
2020-10-12 16:02 ` Sudeep Holla
2020-10-12 15:54 ` Sudeep Holla
2020-10-12 15:49 ` Sudeep Holla
2020-10-12 16:52 ` Ionela Voinescu
2020-10-12 17:18 ` Lukasz Luba
2020-10-14 4:25 ` Viresh Kumar
2020-10-14 9:11 ` Lukasz Luba
2020-10-19 8:50 ` Nicola Mazzucato
2020-10-19 9:46 ` Viresh Kumar
2020-10-19 13:36 ` Nicola Mazzucato
2020-10-20 10:48 ` Viresh Kumar
2020-10-13 13:53 ` Lukasz Luba
2020-10-14 4:20 ` Viresh Kumar
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=20201012220132.GA1715@arm.com \
--to=ionela.voinescu@arm.com \
--cc=chris.redpath@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=morten.rasmussen@arm.com \
--cc=nicola.mazzucato@arm.com \
--cc=rjw@rjwysocki.net \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=viresh.kumar@linaro.org \
--cc=vireshk@kernel.org \
--subject='Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies' \
/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
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).