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]
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

Powered by blists - more mailing lists