From patchwork Wed May 4 07:51:49 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hector Martin X-Patchwork-Id: 569513 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53544C4332F for ; Wed, 4 May 2022 07:52:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345913AbiEDH4I (ORCPT ); Wed, 4 May 2022 03:56:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243507AbiEDHzr (ORCPT ); Wed, 4 May 2022 03:55:47 -0400 Received: from mail.marcansoft.com (marcansoft.com [IPv6:2a01:298:fe:f::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D6AD1C10C for ; Wed, 4 May 2022 00:52:11 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hector@marcansoft.com) by mail.marcansoft.com (Postfix) with ESMTPSA id E009741E64; Wed, 4 May 2022 07:52:00 +0000 (UTC) From: Hector Martin To: "Rafael J. Wysocki" , Viresh Kumar Cc: Hector Martin , Sven Peter , Alyssa Rosenzweig , Rob Herring , Krzysztof Kozlowski , Stephen Boyd , Ulf Hansson , Marc Zyngier , Mark Kettenis , linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 0/4] Apple SoC cpufreq driver Date: Wed, 4 May 2022 16:51:49 +0900 Message-Id: <20220504075153.185208-1-marcan@marcan.st> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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