linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@linaro.org>
To: Sudeep Holla <sudeep.holla@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	linux-kernel@vger.kernel.org
Cc: Leo Yan <leo.yan@linaro.org>
Subject: [PATCH v1 0/3] arch_topology: Correct CPU capacity scaling
Date: Sun, 13 Mar 2022 13:55:09 +0800	[thread overview]
Message-ID: <20220313055512.248571-1-leo.yan@linaro.org> (raw)

This patch set is to address issues for CPU capacity scaling.

"capacity-dmips-mhz" property might be absent in all CPU nodes, and in
another situation, DT might have inconsistent binding issue, e.g. some
CPU nodes have "capacity-dmips-mhz" property and some nodes miss the
property.  Current code mixes these two cases and always rollback to CPU
capacity 1024 for these two cases.

Patches 01 and 02 in this set are used to distinguish the two different
DT binding cases, and for the inconsistent binding issue, it rolls back
to 1024 without CPU capacity scaling.

Patch 03 is to handle the case for absenting "capacity-dmips-mhz"
property in CPU nodes, the patch proceeds to do CPU capacity scaling based
on CPU maximum capacity.  Thus it can reflect the correct CPU capacity for
Arm platforms with "fast" and "slow" clusters (CPUs in two clusters have
the same raw capacity but with different maximum frequencies).

This patch set is applied on the mainline kernel with the latest commit
68453767131a ("ARM: Spectre-BHB: provide empty stub for non-config").
And tested on Arm64 Hikey960 platform (with a bit hacking to emulate
fast and slow clusters).


Leo Yan (3):
  arch_topology: Correct semantics for 'cap_parsing_failed'
  arch_topology: Handle inconsistent binding of CPU raw capacity
  arch_topology: Scale CPU capacity if without CPU raw capacity

 drivers/base/arch_topology.c | 42 +++++++++++++++++++++++++++++-------
 1 file changed, 34 insertions(+), 8 deletions(-)

-- 
2.25.1


             reply	other threads:[~2022-03-13  5:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-13  5:55 Leo Yan [this message]
2022-03-13  5:55 ` [PATCH v1 1/3] arch_topology: Correct semantics for 'cap_parsing_failed' Leo Yan
2022-03-13  5:55 ` [PATCH v1 2/3] arch_topology: Handle inconsistent binding of CPU raw capacity Leo Yan
2022-03-13  5:55 ` [PATCH v1 3/3] arch_topology: Scale CPU capacity if without " Leo Yan
2022-03-14 18:10 ` [PATCH v1 0/3] arch_topology: Correct CPU capacity scaling Ionela Voinescu
2022-03-15  3:29   ` Leo Yan
2022-03-15 10:08     ` Sudeep Holla
2022-03-15 14:59       ` Leo Yan
2022-03-15  9:49   ` Sudeep Holla

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=20220313055512.248571-1-leo.yan@linaro.org \
    --to=leo.yan@linaro.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@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).