From patchwork Mon Oct 24 04:39:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hector Martin X-Patchwork-Id: 570 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp250636wru; Sun, 23 Oct 2022 21:40:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7Zqpu8i4j0hvnpJIWyEs5+zdk6P/XVmTtlWQity5WroNTAK0VwkLugDpWtzABdenZZuR0v X-Received: by 2002:a17:907:7639:b0:79f:d1dd:2f86 with SMTP id jy25-20020a170907763900b0079fd1dd2f86mr9771978ejc.586.1666586447323; Sun, 23 Oct 2022 21:40:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666586447; cv=none; d=google.com; s=arc-20160816; b=V9FtuE60qHNK0CjcPbFYBs2zHmrcpbxXV1a8BRcLEs9F3vAub0F5rEpnSFt5UKaACH oBuoxmzk4rCLo9PF3hiM9G8qrzp1ZwjeXrMvS/nc2rN+zCvt+TFm8a6cvKOZcXYnlH5R 3D3kCY1cq4by5T79NlECuF03SXGtEbHTPfflHfy5Dc3UBCqphIM79JOMIZYWKvGtmnk6 p/KM72kBufspUAMNsArrF2xK2en5PT0jROYDTrSEFv/NbWNyFPBFa+rk/zbEGWj/a8JD C/L8wBcUvIudEnCn+H1kiAgD703YLRnc/T7hBe25uhB7IGJ9zUvflJkftIyDmHh29uy/ 6m1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=uRhhHP6qKxVc1gqYhiOXr9NVtE4id4e3BFIqR8ocTXc=; b=wwUxQmYAZ9ZS8QQ1O608/Z98/u4Zo0bAYjqvoLBBu4woWNRL0FWsIV76QbUr99ZUGs bU3UMEsc4f5wGR0yLrh+91ZAVwraJj8Yl+0Ar0uo8nhvmWt1RPF6D9ugrGvv7WKEc3Tz jtCl4025zWPG44N6GdLF6kfcfB/d2xfKC2At/8K0J4mGUUiFqoi5HkRIFKjgNpSpfs3Z zPFaluHFzHtpGgzCfG1cXKGMW41qE9ef8kvUjFUrpMqNe57i1uNBoNV7rPyumwXkag9T 7WPjLIkHDMPmR69o/MFbijJZbR7yQCsATSKGwqPZCmIdXNJyZVIoxuZF4v63Odt3FLm2 3PsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@marcan.st header.s=default header.b=NDsLUNRM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o11-20020a170906974b00b0077d1df3967asi19558638ejy.563.2022.10.23.21.40.24; Sun, 23 Oct 2022 21:40:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@marcan.st header.s=default header.b=NDsLUNRM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229914AbiJXEju (ORCPT + 99 others); Mon, 24 Oct 2022 00:39:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229738AbiJXEjs (ORCPT ); Mon, 24 Oct 2022 00:39:48 -0400 Received: from mail.marcansoft.com (marcansoft.com [212.63.210.85]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9CD61006; Sun, 23 Oct 2022 21:39:42 -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 921AC4248E; Mon, 24 Oct 2022 04:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=marcan.st; s=default; t=1666586380; bh=PSIFBicjAsCmHU1aD6l6zkYxcFB0FGKPngGEO+mAWSQ=; h=From:To:Cc:Subject:Date; b=NDsLUNRMLS+soEDN1/NPuJdzeXmAp7lorII8SuaT5AHcEwFwKw2sX4goU/57qx05k taoKsGazNkms5aVzIiYXpPyvPFfcfiloUyWS0EgwMRavQPlsLuDyZm1YYwuoalJ5gI 1LOZuEVhLHdRit8jOhSUMuJV1Dm0K5qs07I7gLx7yH24Mviz91FmXUV8oOTqtGUZ5i gx2krc7rsVPVABY97iw68tCd2PBoQEHSkc2ATqTKOxNalY/t+DEJhZxbskib+9Fz4y V8mkZvr62Or0qEbHVoikbCeUNkjQVh9uFgoUIf2ASfr+GmTRLfHrt+eeNjzVgSUdtK 64f4v/1ZATT3g== From: Hector Martin To: "Rafael J. Wysocki" , Viresh Kumar , Matthias Brugger Cc: Hector Martin , Sven Peter , Alyssa Rosenzweig , Rob Herring , Krzysztof Kozlowski , Stephen Boyd , Ulf Hansson , Marc Zyngier , Mark Kettenis , asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 0/5] Apple SoC cpufreq driver Date: Mon, 24 Oct 2022 13:39:20 +0900 Message-Id: <20221024043925.25379-1-marcan@marcan.st> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747542550161573340?= X-GMAIL-MSGID: =?utf-8?q?1747542550161573340?= Hi folks, Third time's the charm? Here's v3 of the cpufreq driver for Apple SoCs. This version takes a page from both v1 and v2, keeping the dedicated cpufreq style (instead of pretending to be a clock controller) but using dedicated DT nodes for each cluster, which accurately represents the hardware. In particular, this makes supporting t6002 (M1 Ultra) a lot more reasonable on the DT side. This version also switches to the standard performance-domains binding, so we don't need any more vendor-specific properties. In order to support this, I had to make the performance-domains parsing code more generic. This required a minor change to the only consumer (mediatek-cpufreq-hw). The Linux driver probes based on platform compatible, and then attempts to locate the cluster nodes by following the performance-domains links from CPU nodes (this will then fail for any incompatible nodes, e.g. if a future SoC needs a new compatible and can't fall back). This approach was suggested by robh as the right way to handle the impedance mismatch between the hardware, which has separate controllers per cluster, and the Linux model where there can only be one CPUFreq driver instance. Functionality-wise, there are no significant changes from v2. The only notable difference is support for t8112 (M2). This works largely the same as the other SoCs, but they ran out of bits in the current PState register, so that needs a SoC-specific quirk. Since that register is not used by macOS (it was discovered experimentally) and is not critical for functionality (it just allows accurately reporting the current frequency to userspace, given boost clock limitations), I've decided to only use it when a SoC-specific compatible is present. The default fallback code will simply report the requested frequency as actual. I expect this will work for future SoCs. As usual, MAINTAINERS and DT changes are split. I expect patches #2~#4 to go through the cpufreq tree, and we'll take care of #1 and #5 via the asahi-soc tree. Hector Martin (5): MAINTAINERS: Add entries for Apple SoC cpufreq driver dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq cpufreq: Generalize of_perf_domain_get_sharing_cpumask phandle format cpufreq: apple-soc: Add new driver to control Apple SoC CPU P-states arm64: dts: apple: Add CPU topology & cpufreq nodes for t8103 .../cpufreq/apple,cluster-cpufreq.yaml | 119 ++++++ MAINTAINERS | 2 + arch/arm64/boot/dts/apple/t8103.dtsi | 206 +++++++++- drivers/cpufreq/Kconfig.arm | 9 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/apple-soc-cpufreq.c | 352 ++++++++++++++++++ drivers/cpufreq/cpufreq-dt-platdev.c | 2 + drivers/cpufreq/mediatek-cpufreq-hw.c | 14 +- include/linux/cpufreq.h | 28 +- 9 files changed, 706 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml create mode 100644 drivers/cpufreq/apple-soc-cpufreq.c Acked-by: Marc Zyngier