From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: rjw@rjwysocki.net, sudeep.holla@arm.com,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpufreq,cppc: fix issue when hotplugging out policy->cpu
Date: Tue, 22 Sep 2020 17:25:40 +0100 [thread overview]
Message-ID: <20200922162540.GB796@arm.com> (raw)
In-Reply-To: <20200907061154.iiyaq4m3vjtrlkp4@vireshk-i7>
Hi,
Sorry for the delay, I just got back from holiday as well.
On Monday 07 Sep 2020 at 11:41:54 (+0530), Viresh Kumar wrote:
> On 04-09-20, 10:43, Ionela Voinescu wrote:
> > Do you know why it was designed this way in the first place?
>
> No.
>
> > I assumed it was designed like this (per-cpu cppc_cpudata structures) to
> > allow for the future addition of support for the HW_ALL CPPC coordination
> > type. In that case you can still have PSD (dependency) domains but the
> > desired performance controls would be per-cpu, with the coordination
> > done in hardware/firmware. So, in the HW_ALL case you'd end up having
> > different performance controls even for CPUs in the same policy.
> > Currently the CPPC driver only supports SW_ANY which is the traditional
> > cpufreq approach.
>
> Then the person who would add that feature will take care of fixing the issues
> then. We should make sure we handle the current use-case optimally. And a
> per-cpu thing isn't working well for that.
>
Okay, I'll follow your lead and remove the per-cpu structures.
Thanks,
Ionela.
> --
> viresh
prev parent reply other threads:[~2020-09-22 16:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-03 11:19 [PATCH] cpufreq,cppc: fix issue when hotplugging out policy->cpu Ionela Voinescu
2020-09-04 5:06 ` Viresh Kumar
2020-09-04 9:43 ` Ionela Voinescu
2020-09-07 6:11 ` Viresh Kumar
2020-09-22 16:25 ` Ionela Voinescu [this message]
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=20200922162540.GB796@arm.com \
--to=ionela.voinescu@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.