From patchwork Mon Oct 11 16:56:58 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hector Martin X-Patchwork-Id: 12550609 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AED06C433FE for ; Mon, 11 Oct 2021 16:59:43 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7D2B9610C7 for ; Mon, 11 Oct 2021 16:59:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7D2B9610C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=marcan.st Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=SA3bT+2GZt5yU8PARdhOZVKLV0Z1gigVtXtJT5ujcBk=; b=idDb0Lm3rWODKS uzBD3m9gFP4KybLSklxmKEsbgfdh4IqPJGyyU3QsFErd1cvSZkP2lYTdbY+WRtwGi60DrOKPQGoSB RfaKWwjeICErYUVY2txYfBbAROw3Sy2NYL6jZ3kenOdt0EwJCtJcJxkTG05NNcpHAFFrYxv7DBHsG Bx09DphsQIYWZvdNghTFy961FirH0D/yNSb9HNs6tMkNjDc65i00SQS9LMwYp0rY5jwbNvP5hUjdP jYycHgQ9/gBHG0ASST4dhBMvN35ezzJ7O74xQXSLuH973rgn3VpLFWFYtZ708K/QJQZRnBP2ouJOp 93kcF/3WxnT1W62xRA6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mZycN-00A8Ew-L3; Mon, 11 Oct 2021 16:57:39 +0000 Received: from marcansoft.com ([2a01:298:fe:f::2] helo=mail.marcansoft.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mZycI-00A8DN-To for linux-arm-kernel@lists.infradead.org; Mon, 11 Oct 2021 16:57:37 +0000 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 EFDA84206F; Mon, 11 Oct 2021 16:57:23 +0000 (UTC) From: Hector Martin To: linux-arm-kernel@lists.infradead.org Cc: Hector Martin , Alyssa Rosenzweig , Sven Peter , Marc Zyngier , Mark Kettenis , Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Viresh Kumar , Nishanth Menon , Catalin Marinas , "Rafael J. Wysocki" , Kevin Hilman , Ulf Hansson , linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH 0/9] Apple SoC CPU P-state switching Date: Tue, 12 Oct 2021 01:56:58 +0900 Message-Id: <20211011165707.138157-1-marcan@marcan.st> X-Mailer: git-send-email 2.33.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211011_095735_138841_6CF650EB X-CRM114-Status: GOOD ( 24.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi folks, here's a first attempt at cpufreq support for the Apple M1. I'd appreciate any feedback on this approach. The hardware in these SoCs is very simple: you just poke a single register to change the performance state of a CPU cluster. There's some init required on older firmware versions, but we're going to say that's the bootloader's responsibility. This keeps the driver nice and simple and generic and likely to work on future SoCs too. However, there's a catch: the memory controller config should also be modified when higher clock states are engaged on the P-cores, to get optimal performance. This series implements this using two drivers, on top of the existing cpufreq-dt infrastructure. The cpu clock driver represents the p-state switching as if it were a standard clock driver, so it can work with cpufreq-dt. To do this, it also needs access to the OPP table, so it can map the incoming clock frequences back to P-State index numbers, so that is present in the binding. This might be a bit strange, since the same OPP table is referenced by the CPUs themselves, and by the clocks driver that provides the actual switching for them... The memory controller stuff is implemented as a genpd provider that exposes two performance states that the CPU OPP tables can depend on. Unfortunately, the cpufreq path doesn't work properly for this, since the CPUs aren't typical devices participating in runtime-pm. So instead I opted to put that logic in the clock driver, which means it gets a power-domains reference to the memory controller. This required a hack to the OPP core so that it wouldn't complain about the missing parent domain when evaluating the OPPs in the context of the CPUs... The actual memory controller config is two magic numbers per performance state. I'd love to find out what they do, but this seems unlikely without docs or a deep memory performance analysis expedition... so I think we're going to have to settle for this way, at least for now. If things become better understood in the future, we can modify the binding and keep the driver backwards-compatible with old DTs at least. I did benchmark the CPU p-state switching, so the latency numbers there have been experimentally measured. The CPU capacity numbers are also based on real benchmarks (oddly enough, Dhrystone was a big outlier here that was not representative of everything else, so we didn't use it). Patches: #1: MAINTAINERS updates, split out so this can go through the SoC tree so we can spare all the subsystem maintainers the merge conflicts, since we have a bunch of other changes here going on in parallel. #2-3: DT bindings #4: The aforementioned hack for the OPP core #5: Add of_genpd_add_provider_simple_noclk() #6: Memory controller driver #7: CPU p-state clock driver #8: Add some deps for ARCH_APPLE #9: DT updates (for asahi-soc tree) Hector Martin (9): MAINTAINERS: apple: Add apple-mcc and clk-apple-cluster paths dt-bindings: memory-controller: Add apple,mcc binding dt-bindings: clock: Add apple,cluster-clk binding opp: core: Don't warn if required OPP device does not exist PM: domains: Add of_genpd_add_provider_simple_noclk() memory: apple: Add apple-mcc driver to manage MCC perf in Apple SoCs clk: apple: Add clk-apple-cluster driver to manage CPU p-states arm64: apple: Select MEMORY and APPLE_MCC arm64: apple: Add CPU frequency scaling support for t8103 .../bindings/clock/apple,cluster-clk.yaml | 115 ++++++++ .../memory-controllers/apple,mcc.yaml | 80 ++++++ .../opp/apple,mcc-operating-points.yaml | 62 +++++ MAINTAINERS | 5 + arch/arm64/Kconfig.platforms | 2 + arch/arm64/boot/dts/apple/t8103.dtsi | 255 +++++++++++++++++- drivers/base/power/domain.c | 39 ++- drivers/clk/Kconfig | 9 + drivers/clk/Makefile | 1 + drivers/clk/clk-apple-cluster.c | 184 +++++++++++++ drivers/memory/Kconfig | 9 + drivers/memory/Makefile | 1 + drivers/memory/apple-mcc.c | 130 +++++++++ drivers/opp/core.c | 5 +- include/linux/pm_domain.h | 8 + 15 files changed, 887 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/apple,cluster-clk.yaml create mode 100644 Documentation/devicetree/bindings/memory-controllers/apple,mcc.yaml create mode 100644 Documentation/devicetree/bindings/opp/apple,mcc-operating-points.yaml create mode 100644 drivers/clk/clk-apple-cluster.c create mode 100644 drivers/memory/apple-mcc.c