linux-kernel - [PATCH v2 0/4] Apple SoC cpufreq driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220504075153.185208-1-marcan@marcan.st>
Date:   Wed,  4 May 2022 16:51:49 +0900
From:   Hector Martin <marcan@...can.st>
To:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Hector Martin <marcan@...can.st>, Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Marc Zyngier <maz@...nel.org>,
        Mark Kettenis <mark.kettenis@...all.nl>,
        linux-arm-kernel@...ts.infradead.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH v2 0/4] Apple SoC cpufreq driver

Hi folks,

Here's a second take on the cpufreq driver for Apple SoCs. This is a
complete rewrite using a stand-alone cpufreq driver instead of using the
cpufreq-dt infrastructure.

Since v1 we ran some experiments on the memory controller performance
switching and it turns out it doesn't make a huge difference, so it
makes sense to punt that feature to the future (perhaps once a proper
memory controller driver exists for other reasons, e.g. for error
handling).

One advantage of having a standalone cpufreq driver is that we can
support fast switching. This also means any future interaction with
the memory controller will probably use some bespoke mechanism instead
of the genpd infrastructure, so we can keep the fast path without
allowing sleeps/etc.

The driver is based on scpi-cpufreq.c, with some bits (e.g. the
apple,freq-domain stuff) inspired by how cpufreq-qcom-hw does it.
I'm not sure if that particular property should be described
in a binding, since it goes in the cpu nodes (qcom doesn't have it
anywhere...).

Changes since v1:
- Complete rewrite
- Reports current frequency to userspace properly (incl. if different
  from requested due to hardware constraints)
- Supports fast switching
- MCC latency control stuff no longer included, punted for later
- Supports exposing higher states as turbo states

Hector Martin (4):
  MAINTAINERS: Add entries for Apple SoC cpufreq driver
  dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC
    cpufreq
  cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states
  arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103

 .../bindings/cpufreq/apple,soc-cpufreq.yaml   | 121 +++++++
 MAINTAINERS                                   |   2 +
 arch/arm64/boot/dts/apple/t8103.dtsi          | 203 ++++++++++-
 drivers/cpufreq/Kconfig.arm                   |   9 +
 drivers/cpufreq/Makefile                      |   1 +
 drivers/cpufreq/apple-soc-cpufreq.c           | 330 ++++++++++++++++++
 drivers/cpufreq/cpufreq-dt-platdev.c          |   2 +
 7 files changed, 658 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,soc-cpufreq.yaml
 create mode 100644 drivers/cpufreq/apple-soc-cpufreq.c

-- 
2.35.1